缘起

最近阅读<<Go微服务实战>> (刘金亮, 2021.1)
本系列笔记拟采用golang练习之

Saga模式

saga模式将分布式长事务切分为一系列独立短事务
每个短事务是可通过补偿动作进行撤销的
事务动作和补动作偿都是幂等的, 允许重复执行而不会有副作用

Saga由一系列的子事务“Ti”组成，
每个Ti都有对应的补偿“Ci”，
当Ti出现问题时Ci用于处理Ti执行带来的问题。

可以通过下面的两个公式理解Saga模式。
T = T1 T2 … Tn
T = TCT

Saga模式的核心理念是避免使用长期持有锁（如14.2.2节介绍的两阶段提交）的长事务，
而应该将事务切分为一组按序依次提交的短事务，
Saga模式满足ACD（原子性、一致性、持久性）特征。

摘自 <<Go微服务实战>> 刘金亮, 2021.1

目标

为实现saga模式的分布式事务, 先撸一个pub/sub事务消息队列服务
事务消息队列服务的功能性要求
- 消息不会丢失: 消息的持久化
- 消息的唯一性: 要求每个消息有全局ID和子事务ID
- 确保投递成功: 投递队列持久化, 投递状态持久化, 失败重试

Saga模式小结:

写一个Saga模式的小demo, 居然累计投入20工时左右的码力, 看来分布式事务确实是个大麻烦
Saga模式虽然区区两个公式, 但手撸一遍, 深刻理解后, 才发现后面很多道道
首先看看事务拆分: T = T1 T2...Tn
1. 首先如何拆分事务就非常讲究
2. 其次必须确保每个事务的原子性和幂等性, 不能产生副作用. 这要求很高, 事实上几乎只能选择RDBMS的本地事务
3. 复杂逻辑处理遇上原子性, 则很可能需要持久化很多中间状态, 因为云环境下, 必须假设Pod随时可能挂掉. 这就好比在战棋类游戏中, 走一步存一个挡.
再看看补偿机制: T = TCT
1. 首先事务必须是可撤销/可补偿的. 但有些场景很难撤销/完全补偿
2. 比如电商大促, 消费者买买买
3. 如果店小二填入库单的时候, 不小心输多一个0, 库存暴涨
4. 则可能导致大量蜂拥而至的消费者, 产生大量销售订单.
5. 如果有禁止负数库存的硬约束, 想要撤销入库单是很难的
6. 必须先撤销大量的销售订单, 这个实施成本很高.
其他技术难点:
1. 事务消息队列服务MQS本身的单点故障: 这个可以做主从HA+消费端保活+消费端自动失败重试
2. 事务消息的100%可达性: 持久化+消费应答机制
3. 事务消息的可重复消费/幂等: 事务ID+已消费记录的持久化, 这个要在消费端做, 服务端不能100%避免
4. 生产者早于消费者上线: 消费端还没上线订阅, 生产者就已经Pub大量消息. 这个要有时序控制机制.
5. 慢消费者: 某个消费端因负载过高, 通信很慢, 比起其他消费端总是慢吞吞, 则最终一致性要很久才能达成.
6. MQS的过载保护: 需要实时采集和监测, 发布队列与消费队列的深度