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

本文试图接头这几个题目：

• MySQL的redo log和binlog为什么要用XA?
• MongoDB的oplog是凭证什么次序复制?
• Raft真的只能串行Apply吗?
• 数据库的复制和事宜是完全独立的两回事?
• 为什么MySQL不早点做一个Raft插件，直接用Raft实现高可用?

本文旨在叙述Fault-Tolerant Transaction的几种实现模式。固然乍一看它们也许都是Raft+KVEngine +Concurrency Control，轻易被以为是统一类要领，但现实上的差别很大，在接头时不该该忽视它们之间的差别。

一、根基观念

接头的Fault-Tolerance，指的是通过收集通讯的多个计较机节点，在部门节点产生Stop Failure的环境下，如故极力担保可用性;

不接头详细的Fault-Tolerance要领，默认读者对Raft等算法有根基领略;

也不接头详细的Concurrency Control要领，默认读者对其有根基的领略;

会涉及到Spanner、TiKV、MongoDB等详细的数据库。

1、基于RSM的Fault-Tolerant KV

Replicated State Machine最早应该是在『Implementing fault-tolerant services using the state machine approach』提出。它是一种很简质朴用的实现容错的要领，焦点头脑是：几个状态机具有沟通的初始状态，而且凭证同样的次序执行了同样的呼吁序列，那么它们的最终状态也是一样的。因为状态一样，那么恣意一个状态机宕机，都可以被其他的取代，因此实现了Fault Tolerant。

这里提到了几个观念，呼吁、执行次序、状态机，它们都是抽象观念，对应到详细的应用场景才有现实意义。在KVEngine的场景下，呼吁就是Put/Get等操纵，状态机就是KVEngine自己，而执行序列，则由Replication Log抉择。

既然提到了RSM和KV，那么基于RSM的KV也就呼之欲出了。把发到KVEngine的操纵先用Raft复制一遍，在Apply的时辰扔回到KVEngine执行，于是我们就获得了一个Fault-Tolerant的KVEngine。

看起来很简朴，但我在这里显然忽略了许多细节：

• 串行照旧并行Apply：Raft被人诟病的一点是串行Commit、串行Apply，但这并不是Raft的锅;
• 两条Log：Raft复制必要一个Log，KVEngine也会有一个WAL，会带来IO放大，能不能归并成一个呢?
• Checkpoint：为了加快Recovery，必要做Checkpoint;
• 只读操纵必要复制吗?
• 呼吁可所以复合操纵吗：单行的CAS操纵可以吗，多行的事宜操纵可以作为一个呼吁吗?

2、基于RSM的事宜

我们来思量最后一个题目，RSM中的呼吁，可以直接是一个事宜吗?

既然Raft都是串行Apply了，那么看起来把事宜的全部操纵作为一个呼吁扔到状态机执行并没有什么题目。

但题目在于，现实中的事宜是交互式的，也就是包括了if-else等逻辑的，而且逻辑还也许依靠了数据库体系外部的状态，以是不能简朴地用Write Batch + Snapshot来实现一个事宜，照旧要有Concurrency Control的逻辑。

为了办理Concurrency Control的题目，我们在Raft Leader上，实现一个Lock Table和Transaction Manager。拿S2PL要领举例：

• 读数据之前加读锁，写数据之前加写锁;读操纵通过Raft读数据，写操纵Buffer在当地;
• 在用户抉择事宜提交时，即可开释读锁;通过Raft写一条事宜日记，包括全部写操纵;
• 在Raft Apply事宜日记时，把写操纵应用到KVEngine，而且开释写锁。

这里举的例子是S2PL，但对付其他的并发节制要领也根基通用。譬喻Snapshot Isolation，事宜开始时得到KV的Snapshot，读操纵都走Snapshot，写操纵得到写锁，数据Buffer在当地，事宜提交时搜查[begin, end]之间有没有写斗嘴，没有的话则通过Raft写事宜日记，在Apply事宜日记之后，把写操纵应用到KVEngine，最后开释写锁。

这种要领靠近Spanner的做法，它具有几个特点：

• 只有Leader必要维护Lock Table、Transaction Manager，事宜并发节制根基在Leader节点完成;
• 从RSM的角度来看，这里的Lock Table起到了呼吁定序的浸染，担保全部State Machine凭证同样的次序执行呼吁;
• 加锁操纵不走复制协议，解锁操纵在复制协议Apply之后完成，锁会在复制的开始到Commit一向持有：也就意味着，复制协议的Commit等于事宜的Commit，在Commit之前产生Failover，事宜城市Abort;
• Raft所复制的，等于事宜的REDO。

3、基于共享存储的事宜

从头看一下上面这个模子，复制协议所做的工作很是简朴，和其他模块的耦合也很小，仅仅是维护一个有序的Log，因此，我们可以把它从share-nothing推广到share-storage的模子中。

也就是说，我们把平凡的单机事宜引擎，放到一个高可用的存储上，就获得了根基可用的Fault-Tolerant 事宜引擎了，连复制协议也不必要实现的。

不外工作显然不会这么简朴：

• 怎样实现只读节点，提供读扩展的手段;
• 计较节点怎样更快地Failover;
• 怎样把更多的操纵下推到存储节点。

（编辑：河北网）

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