22. 为什么会有分布式事务？

从本地事务来看，我们可以看为两块，一个是 service 产生多个节点，另一个是 resource 产生多个节点。

? 可能会有胖说，我们就是一个单体应用，不存在这样的情况。OK ，没问题，那么我们回过头来想想用户下单完成，我们需要给用户发短信。如果发送短信失败，可能是网络抖动的原因，我们是不应该去回滚本地事务，那么此时也可以认为是一个分布式事务。

1）service 多个节点

随着互联网快速发展，微服务，SOA等服务架构模式正在被大规模的使用，举个简单的例子，一个公司之内，用户的资产可能分为好多个部分，比如余额，积分，优惠券等等。在公司内部有可能积分功能由一个微服务团队维护，优惠券又是另外的团队维护。

这样的话就无法保证积分扣减了之后，优惠券能否扣减成功。

2）resource 多个节点

同样的，互联网发展得太快了，我们的Mysql一般来说装千万级的数据就得进行分库分表，对于一个支付宝的转账业务来说，你给的朋友转钱，有可能你的数据库是在北京，而你的朋友的钱是存在上海，所以我们依然无法保证他们能同时成功。

? 可能会有胖友说，我们数据没做分库分表，不存在这样的情况。OK，没问题，那么我们回过头来想想最常见的场景，系统里引入了 Redis 做缓存，那么 DB 和 Redis 的一致性问题，就是一种分布式事务的场景。

? 是否真的要分布式事务？

在说分布式事务的方案之前，首先你一定要明确你是否真的需要分布式事务？

上面说过出现分布式事务的两个原因，其中有个原因是因为微服务过多。我见过太多团队一个人维护几个微服务，太多团队过度设计，搞得所有人疲劳不堪，而微服务过多就会引出分布式事务，这个时候我不会建议你去采用分布式事务的方案，而是请把需要事务的微服务聚合成一个单机服务，使用数据库的本地事务。因为不论任何一种方案都会增加你系统的复杂度，这样的成本实在是太高了，千万不要因为追求某些设计，而引入不必要的成本和复杂度。

当然，如果你是个人的练习 Demo 项目，请使劲的造，拼命的玩。甚至说，我建议你能读完所使用的分布式事务的方案的原理和源码。因为，一旦上了生产，出了问题，你很有可能无从下手~

所以，想清楚你是否需要分布式事务，你是否能够 hold 住分布式事务的解决方案。