一致性小记

Posted 2020-10-10 韬韬韬你羞得无礼

首先应该看能不能规避分布式的事务，如果业务允许的话最好将事务整合到一起，或者整合为一个单一的服务

Sagas长事物 
本质上是补偿机制的复杂实现，每个业务活动都是一个原子操作，每个业务活动均提供正反操作，任何一个业务活动发生错误，按照执行的反顺序，实时执行反操作，进行事务回滚，回滚失败情况下，需要记录待冲正事务日志，通过重试策略进行重试，冲正重试依然失败的场景，提供定时冲正服务器，对回滚失败的业务进行定时冲正，定时冲正依然失败的业务，等待人工干预。Sagas长事务模型支持对 数据一致性要求比较高的场景比较适用 ，由于采用了补偿的机制，每个原子操作都是先执行任务，避免了长时间的资源锁定，能做到实时释放资源，性能相对有保障

 

补偿机制

可逆服务 如果实际业务场景上不需要复杂的Sagas事务框架支撑，可以在业务中实现简单的补偿模式，基本可以是做到准实时的补偿，不会有太大的影响。比如在线下单，订单和库存是两个服务两个数据库，则新增订单会有一个对应的逆向操作【移除订单】，而扣减库存也会有一个可逆的操作【增加库存】

 

事物协调器

基于消息通过最终一致性实现的中间件，通过协调器来对比各个事务方的记录来做最终决定 可能整个周期比较长，需要较长的时间才能给得到最终的一致性。
假设现在三方的事务记录是 A 成功，B 失败，C 成功。那么最终决定有两种方式，根据具体场景：
1.重试 B，直到 B 成功，事务记录表里记录了各项调用参数等信息 
2.执行 A 和 B 的补偿操作(一种可行的补偿方式是回滚) 
对 b 场景做一个特殊说明：比如 B 是扣库存服务，在第一次调用的时候因为某种原因失败了，但是重试的时候库存已经变为 0，无法重试成功，这个时候只有回滚 A 和 C 了 
注意这几种方式都需要保证幂等性，否则因为未知原因造成的网络延迟，导致本地RPC调用失败但实际上目标已经执行成功了之后，再在本地进行重试或取消操作，会让数据不一致

 

其实这两种方式的根本原理是一样的，将分布式事务转换为多个本地事务，然后依靠重试等方式达到最终一致性
说到底，任何方式都不过是在一致性（实时一致性、最终一致性）、吞吐量(可用性)和复杂度（业务混乱、代码耦合、实现复杂）之间，做一个选择