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

回到一开始的第一种方案，在一个节点实现了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不一致?

（编辑：西安站长网）

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