事务系统实现模式很简单？你确定没忽视这些差异？(3)

它们在复制上的区别：

• 第一种方案，复制了事务的REDO，事务的提交顺序由Raft Log的顺序确定，Failover等机制完全按照RSM的模型来即可;
• 第二种方案，Raft仅仅用于复制KV，事务的顺序和Raft Log的顺序没有关系，KV层的Failover和事务的Recovery完全独立;
• 第三种方案，已经区别于传统的RSM模型，因为它其实是先Apply，再Replication、Commit，可以实现并发Apply。

从复杂度来看：

• 第二种最简单清晰，从Raft，到Raft KV，再到Transactional KV，分层良好;
• 其次是第一种，在Leader节点会额外实现Lock Table、Transaction Manager，这个和Raft是紧密结合的，但是事务提交的顺序就是Raft Log的提交顺序，不会造成混淆;
• 最复杂的是第三种，由于事务提交顺序和Optime顺序不一致，对复制、读写等各种流程都会造成影响，看似简单但实则耦合。

从事务并发的角度来看：

• 第三种方案可以完美支持并发，且持有锁的时间较短，仅仅是写一次本地日志;
• 第一二种方案持有锁的时间更长，最后在Apply时理论上可以做到并发，如果没有其他约束。

从读写开销的角度来看：

• 第一种最好，Replication Log和Engine Log可以合并，每条事务只要复制一次Raft Log;
• 其次是第二种，通常会把binlog和存储引擎的journal独立，需要写两遍;不过oplog可以写到存储引擎里，一次IO即可提交(MongoDB的做法);
• 最后是第二种，在KV中增加了更多的数据，放大较多。

不过这仅仅是理论上的分析，实际的复杂度、性能，很大程度上取决于实现而非理论。

三、总结

如果我们从很粗的层面来看，会觉得这些系统不过都是几个技术点的组合，而每一个技术点看起来都很简单，进而觉得事务系统不过是如此。

但实际上事务系统绝非简单的KV+Raft+Snapshot Isolation，它们之间不同的组合方式，会最终造就不同的系统。

本文留下了很多问题，RSM的Order往往认为是全序的，而Transaction 的Serialization Order是偏序的(偏序关系由事务冲突定义)，它们之间如何统一?

RSM的Checkpoint和Transaction Checkpoint的统一?RSM的Recovery和Transaction Recovery的关系?写两条日志的系统(journal和binlog)两条日志之间的关系是什么?

【编辑推荐】

1. MySQL 小心了：MariaDB 会取代你！
2. Google 放权，让 AMP 框架采用开放治理的模式
3. 李炎恢老师PHP第三季(设计模式+MVC模式+SMARTY+在线商城)
4. 深入理解Java的三种工厂模式
5. 这些Spring中的设计模式，你都知道吗？

（编辑：ASP站长网）