【20211016】究竟分布式事务要解决什么问题

时间：2021年10月16日

作者：小蒋聊技术

大家好，欢迎来到小蒋聊技术。小蒋准备和大家一起聊聊技术的那些事。

通过上次小蒋的分享和大家一起分析和研究，弄明白了为什么“分布式服务框架”最近越来越火。原因是“分布式服务框架”这类技术符合业务发展的趋势。

究竟是社会进步推动了技术的快速发展？还是因为技术发展而推动了社会的快速进步？这类问题，小蒋就不去花精力思考了，“跟JAVA和PHP谁是最好的语言？”是一类问题。

总之，无论谁是原因，谁是结果，事实是互联网行业的技术是在快速迭代和发展的，系统也是变得越来越复杂。几乎所有IT公司的系统都已经从单体架构转型升级为分布式架构了，系统从传统部署也都升级上“云”了，分布式系统几乎无处不在。

做过软件开发的朋友，一般都能体会，技术的升级，很多时候是牵一发而动全身的。一个点的升级/调整，有时候会牵扯一大片级联的内容要跟着调整。就像，Java里一个核心的jar包的版本变更，那和这个包级联的包的版本都要跟着变更，甚至代码有时候都要跟着改，所以后来有了Maven这个技术去做包依赖管理。

小蒋上回和大家说了分布式服务架构，接下来就不得不谈谈分布式事务。

你试想一下，你去你家楼下小卖铺买东西，肯定是一手交钱，一手交货。老板给货，钱交给老板娘也没关系，老板娘隔着屋子喊一声就完了，也不会引起什么误会。

但是，小卖铺这生意做大了、做成体系了、做成规模了、做成世界级别的了，这就不一样了，人家成为分布式架构了！人家现在有专门的订单中心，支付中心，物流中心。你到支付中心把钱付了什么凭据不拿转头就跑，跑到人家订单中心空口无凭和人家要东西，人家订单中心的工作人员谁认识你呀？！也不是人家收的你得钱，人家凭什么相信你付款了呀，凭什么就给你东西呀！

你看，有了分布式服务，跟着就得需要分布式事务。否则，就会出现你在网上下了单，付了款。刚要查看订单，结果提示你未支付。因为人家下单服务、付款服务、查看订单服务，都是分布式的呀，根本就不在一起。和咱上面这个例子是一模一样的，订单服务人家认识你是谁呀？！凭什么相信你付了款？！分布式事务的出现，就是为了解决这类问题，你说分布式事务重要不重要。

这个时候，有人可能就要提出质疑了，付没付钱跟分布式事务有什么关系，如果我要是付了钱，你系统显示没付，那就是你系统的事，出了bug，就是你系统的问题！但是，我们做技术的，你得分析一下到底问题背后究竟是什么原因在作祟。大部分情况，问题就有可能出现在“分布式事务”这块，如果你还想不清楚，那可能你还没弄明白什么是“事务”，什么是“分布式事务”。今天，小蒋就和大家一起来聊一聊，什么叫“分布式事务”？

分布式事务就是，“事务” 加上一个  “分布式”  呗。

这……，说的没错。所以咱得先看一下“事务”的定义。事务提供一种机制将活动涉及到的所有操作都纳入到一个不可分割的执行单元，组成事务的所有操作只有在操作均正常执行的情况下才能提交，只要其中任何一操作执行失败，都会导致整个事务的回滚。

小蒋给你翻译一下，事务要么全成功，只要任何一个失败就全失败。例如，一家三口，商量周末去郊游，家里人都同意，马上准备东西，只要到周末一家三口就全部出发去郊游。要是突然周五这一天，爸爸偏偏病了，周末需要去医院，那郊游就取消了，一家三口谁也别想别去了，要去就一起去，要不去就都别去，就这意思。

所以，事务有四大特性：ACID

1. A（Atomic）：原子性，要么全部成功，要么全部失败，不存在一部分成功一部分失败的情况。
2. C（Consistency）：一致性，我去商店买100块钱东西，我钱包里扣除100元，商店账户增加了100元，这就是一致性。
3. I（Isolation）：隔离性，数据库中的事务一般都是并发的，隔离性是指并发的两个事务之间互不干扰，相互之间不能看到对方执行的中间状态，通过配置事务隔离级别可以避免脏读、幻读、不可重复读等问题。
4. D（Durability）：持久性，事务完成后，数据会持久到数据库中，并且不会被回滚。

传统单体事务

 

在之前传统单体架构上，代码都是打包在一起的，部署在同一个服务器上的。拿购物这个场景来说，虽然用户购物需要很多方法来支持，但是毕竟大家都是在一起的。就跟下楼去小卖店买东西是一个意思，虽然是老板给你拿的东西，但是你钱付给老板娘也没关系，老板娘隔着屋子喊一声，老板也能听得见，不会出什么幺儿子的。

分布式事务

随着业务和需求的不断发展，技术也必须跟着更新进步，以满足现实生活中的使用需要。这也是为什么，最近单体 软件架构都逐渐转型升级为分布式服务架构和面向服务的SOA体系架构的重要原因。

同时还产生了一个新词儿，微服务架构。其实就是将传统的单体架构，拆分成多个服务，然后服务和服务之间相互配合，来完成业务需求。

 

分布式事务就是指事务的参与者，支持事务的服务器，资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。

也就是刚刚我们上面👆🏻说到的，就是事务” 再加上一个  “分布式”，一点都没错。

咱拿个现实当中的场景大家就好理解了，例如在大型电商系统中，下单接口通常会调用扣减库存服务、减去优惠服务、生成订单 id服务, 而订单服务与库存、优惠、订单 id 都是不同的服务，下单接口的成功与否，不仅取决于本地的 db 操作，而且依赖第三方系统的结果，这时候分布式事务就保证这些操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。这样看，是不是好理解的多。

在分布式中，有一个著名的CAP原则，在这里小蒋和大家提一提：

1. C（Consistency）：一致性。服务A、B、C三个节点都存储了用户数据，三个节点的数据都需要保持同一时刻数据一致性
2. A（Availability）：可用性。服务A、B、C三个节点，其中一个节点如果宕机了，不能影响整个集群对外提供服务。
3. P（Partition Tolerance）：分区容错性就是允许系统通过网络协同工作，分区容错性要解决由于网络分区导致数据的不完整及无法访问等问题。

鱼和熊掌不可兼得，CAP原则也同样如此。在目前技术的水平条件下，CAP只能选择满足其中两条，还无法做到三者兼备。

因此当前分布式服务的策略中要么CA（一致性，可用性）、要么CP（一致性，分区容错性）、AP（可用性，分区容错性）当然也可以。而这个时候，又有一个理论出现了，那就是BASE理论。它是用来对CAP原则进行补充的，它说的是：

1. BA（Basically Available）：基本可用
2. S（Soft State）：软状态
3. E（Eventually Consistent）：最终一致性

这个理论的核心思想便是：如果我们无法做到强一致性，那么每个应用都应该根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

写在最后

以上内容，就是小蒋今天希望分享给大家的全部内容。关于分布式事务它的出现场景和具体的技术处理细节，小蒋将会下次和大家一起共同研究，让我们互为动力，一起成长。

借用段永平先生的一句话作为今天的收尾：“慢就是快，快就是慢。先找到正确的方向，再依据基本常识，慢慢地做正确的事，终究会有收获的”！

年龄的增长不可怕，可怕的是从未成长！

感谢大家支持小蒋，小蒋希望和大家共同成长，谢谢。

音频地址：

【20211016】究竟分布式事务要解决什么问题https://www.ximalaya.com/keji/51588599/463216977