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

它们在复制上的区别：

• 第一种方案，复制了事宜的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中的计划模式，你都知道吗？

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!