共计 1677 个字符，预计需要花费 5 分钟才能阅读完成。
一、概述
随着工夫和业务的倒退，数据库中表的数据量会越来越大，相应地，数据操作，增删改查的开销也会越来越大。因而，把其中一些大表进行拆分到多个数据库中的多张表中。
本篇文章是基于非事务音讯的异步确保的形式来实现分库分表中的事务问题。
二、须要解决问题
2.1 原有事务
因为分库分表之后，新表在另外一个数据库中，如何保障主库和分库的事务性是必须要解决的问题。
解决办法：通过在主库中创立一个流水表，把操作数据库的逻辑映射为一条流水记录。当整个大事务执行结束后（流水被插入到流水表）, 而后通过其余形式来执行这段流水，保障最终一致性。
2.2 流水
所谓流水，能够了解为一条事务音讯
下面通过在数据库中创立一张流水表，应用一条流水记录代表一个业务解决逻辑，因而，一个流水肯定是能最终正确执行的. 因而，当把一段业务代码提取流水中必须要思考到:
- 流水提早解决性。 流水不是实时处理的，而是用过流水执行器来异步执行的。因而，如果在原有逻辑中，须要特地留神后续流程对该流水是不是有实时依赖性（例如后续业务逻辑中会应用流水后果来做一些计算等）。
- 流水解决无序性。 保障即便后生成的流水先执行，也不能呈现问题。
- 流水最终胜利性。 对每条插入的流水，该条流水肯定要保障能执行胜利
因而，提取流水的时候:
- 流水解决越简略越好
- 散失解决依赖越少越好
- 提取的流水在该业务逻辑中无实时性依赖
2.3 流水处理器
流水处理器即要保障流水解决尽可能解决快，又能保障流水最终能执行胜利。
构想一个场景：当呈现某一条流水解决失败，如果散失执行器要等以后流水执行胜利才持续往后执行，那么会影响后续流水的执行，更重大的是始终卡在当条记录，导致整个零碎呈现问题
因而，流水执行器中设置 2 个工作：
- 第一个工作, 流水解决工作，已最快的速度执行流水，如果流水解决失败了，也不影响前面流水解决
- 第二个工作, 流水校验工作，这个工作就是程序查看流水记录，保障所有流水都执行胜利，如果失败，进行重试，多次重试失败当前收回告警以让人工染指解决。
2.4 流水解决实现
因为流水表是放在原数据库中，而流水解决实现后是操作分库，如果分库操作实现去更新老表流水音讯，那么又是夸库事务，如何保障流水状态的更新和分库也是在一个事务的？
解决办法是：在分库中创立一个流水表，当散失解决实现当前，不是去更新老表状态，而是插入分库流水表中、
这样做的益处：
- 个别会对流水做惟一索引，那么如果流水反复屡次执行的时候，插入分库流水表的时候必定因为惟一索引检测不通过，整个事务就会回滚（当然也能够在解决流水事先应该再做一下幂等性判断）
- 这样通过判断主库流水是否在分库中就能判断一条流水是否执行结束
三、流水处理器根本框架
流水处理器其实不蕴含任何业务相干的解决逻辑，外围性能就是：
- 告诉业务接入方何时解决什么样的流水
- 测验流水执行的胜利
注：流水执行器并不知道该流水示意什么逻辑，具体须要业务零碎去辨认后去执行绝对应业务逻辑。
3.1 流水执行工作
流水解决调度工作就是通过扫描待处理的流水，而后告诉业务零碎该执行哪一条流水。
示意图如下：
3.2 流水校验工作
流水校验工作就是要比拟主库和分库中的流水记录，对执行未胜利的流水告诉业务零碎进行重新处理，如果多次重试失败则收回告警。
流程示意图：
四、为什么不必事务音讯
因为是既有我的项目进行革新（自己从事互联网金融，所以是相对不容忍有任何音讯失落或者音讯解决失败 )，不应用事务音讯有 1 个起因
- 须要额定引入音讯队列，减少零碎的复杂度，而且也须要额定的逻辑保障和音讯队列通信失败的时候解决
- 其实 1 不算是次要起因，而是因为事务音讯须要手动的 commit 和 rollback（应用数据库不须要），那么问题来了，spring 中事务是有传递性的，那咱们事务音讯何时提交又是个大问题，例如 A.a() 原本就是一个事务，然而另外一个事务 B.b() 中又调用了 A.a() 那事务音讯提交是放在 A.a() 还是 B.b() 中呢？
写在最初
欢送大家关注我的公众号【 惊涛骇浪如码 】，海量 Java 相干文章，学习材料都会在外面更新，整顿的材料也会放在外面。
感觉写的还不错的就点个赞，加个关注呗！点关注，不迷路，继续更新！！！
