分布式事务

CAP理论

• C 强一致性
• A 高可用性
• P 分区容错性
• 不存在同时满足一致性、可用性和分区容错性的系统，往往只能三者取其二。

BASE理论

• BA 基本可用
• S 软状态，即允许系统中的数据存在中间状态
• E 最终一致性
• BASE理论是对CAP中一致性和可用性权衡的结果，核心思想是即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性。

分布式事务解决方案

• 两阶段提交协议（2PC）
• 事务补偿（TCC）
• 消息事务
• 本地消息表
• Seata

什么是2PC

• 第一阶段：准备阶段（prepare）
  协调者通知参与者准备数据，参与者开始投票。
  协调者完成准备工作向协调者回应Yes。

• 第二阶段：提交(commit)/回滚(rollback)阶段
  协调者根据参与者的投票结果发起最终的提交指令。
  如果有参与者没有准备好则发起回滚指令。

  
  
  2PC原理
• 强一致性事务控制
• 缺点：需要引入协调者在多个节点之间去协调，性能较低，

什么是TCC

• Try 提交事务前的检查，并预留好资源。
• Confirm 确定执行业务操作。
• Cancel 取消执行业务操作，释放预留的资源。
• 最终一致性事务控制
• 缺点：需要额外维护三个接口，增加了开发成本。

消息事务

消息事务的原理是将两个事务「通过消息中间件进行异步解耦」，和本地消息表有点类似，但是是通过消息中间件的机制去做的，其本质就是'将本地消息表封装到了消息中间件中'，例如RocketMQ。

本地消息表

本地消息表

Seata的三种角色说明

• TC: 全局事务协调者，用来协调全局事务和各个分支事务（不同服务）的状态， 驱动全局事务和各个分支事务的回滚或提交。
• TM: 事务管理者，业务层中用来开启/提交/回滚一个整体事务（在调用服务的方法中用注解开启事务）。
• RM: 资源管理者，一般指业务数据库代表了一个分支事务（Branch Transaction），管理分支事务与 TC 进行协调注册分支事务并且汇报分支事务的状态，驱动分支事务的提交或回滚。
• UNDO_LOG：回滚日志记录表

Seata实现原理

• 第一阶段：
  1. 分析执行的sql语句，在UNDO_LOG中生成一条回滚日志
  2. RM事务提交，释放锁资源
• 第二阶段：
  1. 如若全局提交，RM异步删除对应的UNDO_LOG
  2. 如若全局回滚，RM根据UNDO_LOG回滚数据

DDD

传统开发方式的缺陷

• 臃肿的service
• 技术导向分层，导致业务分离

传统开发方式同DDD的比较

其他

如何做到服务高可用

• 一致性，例如配置、版本、环境等，影响问题定位
• 消除单点，容灾
• 群组，防止单个交换机故障导致服务不可用
• 流量隔离，分而治之
• 同城双活，防止单个机房故障导致服务不可用
• N+1冗余，防止实例故障导致服务应付不了高并发请求

分布式id的实现

• 雪花算法，高位时间戳，中间工作机器id，低位自增序列
• 如何分配工作机器id，使用zk
• 如何解决时间回拨问题，方案一、跟前一个id的时间戳比较，如果小发生了时间回拨，短则等待，长则抛异常；方案二、使用历史时间

负载均衡的常用算法

• 随机
• 轮询
• 加权轮询
• 加权随机
• 最小链接数

如何做到系统高可用的

1. 消除单点：所有的服务乃至中间件都需要做到消除单点，服务冗余
2. 故障转移：通过注册中心做到故障转移
3. 负载均衡：服务调用需要选择合适的负债均衡策略
4. 容错：应对异常情况需要做好容错策略和限流
5. 削峰：可以通过消息队列对流量削峰
6. 缓存：采用缓存减少DB或CPU压力，可以采用redis的高可用集群架构
7. 读写分离：DB可以使用主写从读的方式分摊压力。

参考

Seata实现原理