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

回到一开始的第一种方案，在一个节点实现了KV、Raft、Lock Table、Transaction Manager，看起来耦合度较量大了，我们能不能对其举办分层，进一步简化呢?譬喻Google的经典做法，基于GFS实现Bigtable，基于Bigtable实现Percolator，Layered计划易于迭代、易于开拓、易于调试。

因此我们可以思量把KV层单独抽离出来，基于KV去实现Lock Table、Txn Manager：

• Lock Table：在本来的KV中增进一列，酿成Key => {Value, Lock};
• Txn Manager: 从事宜修改的全部Key中选出一个Primary Key，用来记录事宜状态，因此KV进一步酿成 Key => {Value, Lock, TxnStatus};
• MVCC：乃至我们不宁肯情愿于Single Version，还想用Multi Version的并发节制，那么KV就酿成{Key, Version} => {Value, Lock, TxnStatus}。

看过Percolator、TiKV计划的应该会较量认识，它们就是基于一个高可用的KV，把事宜的状态都下沉到KV中。这种计划很轻易拓展到漫衍式事宜的场景，假如KV可以或许scale，那么上层的事宜也可以或许scale了。

5、基于单机事宜引擎实现高可用事宜

上面的方案看起来都较量简朴，不外有一个细节不容忽视：锁根基都是在复制协议提交之后才会开释，换句话说事宜持有的锁会从事宜开始直到多个节点写完日记，经验多次收集耽误、IO耽误，而且在拥塞环境下谋面对列队耽误的风险。而锁意味着互斥，互斥意味着事宜吞吐低落。

翻译一下：

• 并发且有斗嘴的事宜，其提交次序由Lock Table抉择，而且和复制协议的Log次序同等;
• 事宜的Serialization Order，和RSM 中的Order同等。

不外这里存在一个题目：

• 锁必然要在复制协议提交之后才气开释吗?
• 提前开释会粉碎Order的同等性吗?
• RSM的Order必然要和事宜的Serialization Order同等吗?

临时不做答复，我们再看最后一种方案，基于单机事宜引擎的高可用事宜。

在正常的单机事宜流程中，增进一个复制的环节：当地事宜提交之后不是当即返回用户，而是写binlog，守候binlog复制到其他节点之后再返回用户。

这种方法的事宜耽误，看起来照旧当地事宜的耽误，加上复制日记的耽误;但对比于之前的方案，当地事宜可以先提交，锁可以提交开释，总体的事宜吞吐对比之下会有所晋升。

看起来乃至比之前的方案越发简朴，事宜和复制模块获得了美满的疏散，但这里忽略了一个伟大的题目：

• 基于哪个日记来复制，基于数据库的Journal，照旧再写一个binlog?
• 基于什么次序举办复制，假如是基于Journal复制可以用Journal次序，假如基于binlog，次序又是什么?
• 假若有两个日记，两个日记着实意味着Transaction Serialization Order和RSM的State Machine Order纷歧样，会不会发闹事宜的并发非常，可能导致State Machine纷歧致?

因为直接复制Journal会引起一系列伟大的耦合题目，大部门数据库都选择单独写一个binlog/oplog来实现复制，不外在实现时可以做优化，由于假如然的写两个log会有原子性的题目(一个写乐成了另一个没写乐成)以及IO放大的题目。

这里的计划空间较量复杂，不做具体接头，仅仅思量在简化的模子下复制次序的题目。

对付并发执行的事宜，为了确定复制次序，这里维护一个称之为OpTime的自增ID。后续的复制会凭证OpTime的次序，OpTime小的先复制。假如OpTime仅仅是在事宜的开始和竣事之间分派，会带来题目：

• 有斗嘴且并发的事宜T1先Commit，具有较大的OpTime，也就意味会被后复制;
• 后Commit的事宜T2先Replication Commit，而先Commit的事宜T1也许由于复制失败而Rollback;
• 对付事宜来说，这种场景下呈现的非常相同Read-Uncommitted，事宜T2读到了未Commit的数据。

因此，OpTime的分派必要有更强的限定：对付并发且有斗嘴的事宜，OpTime的次序要和事宜的Serialization Order一样：

在S2PL的场景中，我们把OpTime分派放到Lock之后Commit之前，即可满意这个要求。由于凭证S2PL的调治，事宜的Commit-Point就是Lock完成和Unlock之间。比较上面的例子，事宜T2的OpTime被推迟到T1之后，复制的次序也会响应改变，不会产生先前的非常了。

推广到其他的并发节制要领也是相同，譬喻上面的Snapshot Isolation。提交之前会搜查[begin, end]是否有斗嘴，有斗嘴直接重启事宜。相等于在[begin, end]区间内分派OpTime即可。

（编辑：河北网）

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