逆流而上读书笔记1

买了一本阿里巴巴的逆流而上这本书，今天专门花一下午时间好好看了下，还是有些收获的，简单总结下下午读书的笔记

业务案例

发红包场景

对于我们经常使用的发红包场景，业务逻辑也比较简单，发一个红包，需要从预算端先进行扣款，然后红包端再进行发红包

解决方案

1. 二阶段提交

— 在事务开始的第一阶段，首先预算端进行冻结要扣除的预算，红包端需要插入一条不可用的红包记录
— 在事务的第二阶段，即第一阶段的两步都已经完成，开始进行事务提交阶段，预算阶段需要对第一阶段的冻结的金额进行实际的扣减，红包端需要对第一阶段不可用的红包记录变为可用。如果回滚操作的话，预算端需要对冻结的部分资金进行撤销，红包端需要删除上个阶段的不可用的红包记录

在整个的过程中，预算端会涉及2次针对预算端记录的事务操作，而这个记录也会存在热点写，使用二阶段提交更会放大该写的操作

业务的关键点
1. 预算和红包两端保持事务一致，即同时成功或者同时失败
2. 红包发放不能变成一个个顺序的操作，会影响性能，可以存在中间态的预算剩余金额，这个是允许的，只需要保证最终一致即可

2. 微型总线处理

把预算扣减成功以及操作事件消息等在同一个本地事务中，写入数据库，然后会对写入的事件进行分发，通知每一个事件的订阅者（当前业务即红包端），然后对事件的处理结果进行记录
那对应到我们当前的业务，即预算端进行一次预算的扣减，一次事件的写入，可能还会进行一次事件的读取，一次事件的状态更新；对于红包端，仅需要进行一次用户红包数据的写入。那这样的话如果红包端失败，只需要对修改该事件的状态，并且撤销本地扣减。

该系统分为三部分
1. 事件分发者：由业务逻辑在业务事务中调用，并将事件写入到与业务相同的数据库中
2. 事件配置：管理事件的基本信心，订阅关系等
3. 事件调试器：读取待分发的事件，根据订阅关系进行分发，调用相应的事件处理器，然后记录事件分发的结果

总结

满足以下两个要求的都可以适用该方案
1. 短暂的中间状态是可以接受的
2. 要求最终一致性