分布式系统 之 分布式事务问题

分布式系统 之 分布式事务问题

1、你怎么分享分布式事务？

分布式事务问题是分布式系统绕不开的技术话题。

“谈谈你对分布式事务的理解”、“分享下你团队在分布式事务上的解决方案”、“你用过哪几种分布式事务的中间件”？在技术交流/面试中很容易讨论到这些个话题，得到的反馈大概率是这样的：

• “额~~ ~~ ~~ ~~”，一时语噻 《《《 平时没有梳理和认知分布式事物的问题，一时不知如何组织语言。
• “我们没有使用分布式事务”《《《 分布式事务裸奔状态。
• “我知道有CAP和BASE理论，分别是XXX意思” 《《《 “学院派”选手，不够接地气。
• “我们没用分布式事务，但有做补偿方案，XXX” 《《《 有意识和思考，可以。
• “我们在个别特殊业务上，用了XXX中间件方案” 《《《 有数据、有实践心得，可以。
• etc…

的确，分布式事务问题比中间件技术问题难回答的多，因为：

1、它是一个解决方案。而不仅仅是某个功能的技术实现解答。

2、分布式事务是一项“有损解决方案”，是一项取舍决策，背后是业务适用性。

3、解决方案要基于业务场景，以及业务场景分析。不存在一招鲜吃遍天的最佳方案。

3、分布式事务是个综合的技术问题，涉及：业务代码、RPC、幂等性、DB、并发处理、局部高可用、网络分区、一致性视图等问题。

据笔者交流反馈的经验，在多数团队中并未落地“像样”的分布式方案。分布式事务在线上系统的应用比例是很小的。相比分布式事务的学习复杂度和实际应用概率，真有点“面试造火箭，实际拧螺丝”的感觉。

但，不论线上应用比例怎样。作为对技术深度的好奇和掌握（尤其是一堆技术的协同的原理掌握），我们仍要扎实的掌握分布式事务。做到知一返三、游刃有余。

2、分布式事务的本质

分布式事务问题

如上图：

• 分布式事务的问题/需求是随着系统分布式化后必然产生的。

• 分布式事务的目的或本质是追求分布式的多个DB数据的一致性。

  • 和本地数据库事务的本质原理是一样的。只不过是放大到一套技术栈中去实现，更多考虑因素和复杂度。

  • （以Mysql为例）本地数据库事务原理：undo log（原子性） + redo log（持久性） + 数据库锁（原子性&隔离性） + MVCC（隔离性）

  • 分布式事务原理：全局事务协调器（原子性） + 全局锁（隔离性） + DB本地事务（原子性、持久性）

  • 注，“一致性” 靠 “原子性 + 持久性 + 隔离性” 三者共同完成

• 分布式多个DB数据变更的一致性不是瞬间一致，而是会经历一个过程。
  • 需要考虑期间DB数据可见性和隔离性问题。

问题：

1、分布式系统中，日常研发线上发版，需要考虑分布式事务问题吗？如果要考虑，怎么应对？

2、分布式事务相关的技术问题：RPC、幂等性、DB、并发处理、局部高可用、网络分区、一致性视图等，胸有成竹吗？

3、CAP原则和BASE理论

下文并不会基于这两理论分解，毕竟是理论，不能解决实际的问题

但理论知识还是需要了解一些的。故，快速浏览下。

3.1、CAP原则

CAP原则：

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）中的两项。

• 一致性（Consistency）：一致性指“all nodes see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。

• 可用性（Availability）：可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。

• 分区容错性（Partition tolerance）：分区容错性指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

CAP的取舍策略：

策略	解释
CA	单点集群，满足一致性，可用性的系统，通常可扩展性较差。例如传统的单机数据库。 特点：故障时完全不可用。
【常选】AP	满足可用性，分区容错的系统，对一致性要求低一些，是很多分布式系统设计时的选择。 例如：Redis，HBase，Eureka。 例如：各云厂商的SLA几个9，也是牺牲了强一致性。
CP	满足一致性，分区容错的系统，通常性能不是特别高 例如：Zookeeper（通过ZAB协议达到强一致性）

3.2、BASE理论

BASE理论是对CAP理论的延伸，对AP的细化。

核心思想是“即使无法做到强一致性，但应可以采用适合的方式达到最终一致性”。

BASE是指：基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency）。

• 基本可用（Basically Available）

  • 基本可用是指分布式系统在出现故障时，为保证核心可用，允许损失部分可用性。
  • 例如：电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。

• 软状态（ Soft State）

  • 软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。
  • 例如：分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。

• 最终一致性（ Eventual Consistency）

  • 最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。
  • 最终一致性是弱一致性的一种特殊情况。

3.3、为什么分布式系统倾向BASE理论的架构

实际性问题：

• 工程师可以做到逻辑严密的代码，但无法确保硬件长期100%可用。
• 在大型分布式系统中，通信异常、网络分区、节点故障、磁盘损坏、机房掉电等等硬件问题随时都可能发生。

在商业中，越是大型的公司越是需要在线服务能力强的大型分布式系统，在线可用性和响应能力是大型公司的生命支柱（很多线上一次大故障毁掉一个公司的案例）【基本已排除CA和CP】。

且，数据最终一致的特点留给架构很多发挥的余地。即使是关键异常，也可以通过补偿的方式或人工的方式处理。

4、技术方案汇总

4.1、按方案本质分类

• 阿里Seata：http://seata.io/zh-cn/
• Hmily：https://github.com/dromara/hmily

4.2、怎么选

仅提供数据参考

一、一般业务都倾向选最终一致性

• 绝大部分使用“自研补偿/MQ方案 + 人工介入”。

  • 选型取向：

    • 方案最“轻”，可掌控性好。
    • 方案简单易懂，团队易接受、易维护。
    • 性能损失最少。

  • 笔者也赞同一般团队选型此方式。毕竟分布式事务问题是小概率事件，留有补救余地就行，性能的损失可是实打实的反应在线上每一个请求上。

二、阿里Seata AT模式，平均性能会降低35%以上

• 笔者团队的业务实测
• 大家可以根据Seata AT模式下额外做的事情来感受

三、RocketMQ事务消息

• 听起来挺好挺简单的方案，