Rex: Replication at the Speed of Multi-core

来自论文Rex: Replication at the Speed of Multi-core

 

对一系列请求的串行执行已经跟不上多核服务器的脚步了，但又不能直接并行化，因为并行会带来线程调度和锁竞争的不确定性，这就使得状态机复制的前提得不到满足，即要保持确定性。有一点要注意：全序的请求序列并不是保证一致性的必须，也就是说我们完全可以在并行化和一致性之间建立起双赢。本文旨在研究如何在多核机器上实现并行化，同时保证一致性，这样我们就会获得比一般状态机复制更高的吞吐率。那如何去实现这种并行化呢？

对于标准的复制状态机，是通过从一个相同的初始状态开始，以全序的顺序确定性地执行相同的请求集，从而保证一致性。而一旦并行，确定性就难以得到保证，所以这是我们的挑战。所以确定性的并行化就成了一个很热的研究方向，但是目前所采取的手段都是以牺牲性能为代价，还没有从架构上提供硬件支持的方法。Eve是通过mixer来实现了确定性的并行化，mixer会将请求划分成互相没有冲突的组，这样在不同机器上并行去执行这些组就有可能达到确定性和一致性。本文中我们提出Rex，一个execute-agree-follow模型，实现一致性。这个模型中有一个primary机器，一开始它会自由地去并行执行请求，在这个过程中会将不确定性的决定记录在一个偏序的trace中，之后其它的机器运行Paxos来对trace达成一致，最后secondary机器根据这个trace并行执行同样的不确定性选择，这样就跟primary机器保持了同样的一致性状态。进过实验，Rex会获得16倍于标准状态机复制的吞吐率。接下来让我们详细了解Rex。

Rex中有request handler，这个handler会通过标准的同步原语来控制线程对共享数据的访问，进而达到并行执行的目的。因为同步事件的次序是不确定性的唯一来源，所以这些handler会实现确定性。

 

1. Rex vs. State-Machine Replication

State-Machine Replication， 状态机复制使用consensus-execution模型，即首先会形成一个一致的请求序列ri（consensus阶段），然后根据这个顺序来执行请求（execution阶段）。这应该是最基本的想法了，要想保证在多个机器上执行同样的请求序列，首先要统一这个序列。但Rex却正好相反，它用的是execute-agree-follow模型，首先让primary去并行执行请求，同时把这些请求之间的细粒度的因果依赖关系记录在一个trace tri中（execute阶段），primary会定期地将最新的trace作为value发给下一个consensus instance。之后各个机器会对一系列的trace达成一致（agree阶段）。一旦提交，secondary会根据这些trace来复制在primary上的执行（follow阶段）。也就是说Rex会在达成一之前在primary上去执行。在state-machine replication中，会在请求达成一直后处理请求，处理完后primary会给client一个回复。而在Rex中，在处理完请求后，primary不能去回复client，而是要等到一个包含请求处理的trace，并且这个请求所有的依赖事件都已经提交给一个consensus instance。不过，primary不用去等在secondary上的重新执行完成。接下来详细了解一下Rex的各个阶段。

 

►Execute阶段

首先在Primary上执行请求，在执行过程中primary上的request handler会记录同步事件集中的因果依赖关系。

 

Figure 2 是一个例子，两个线程在处理两条不同的请求，锁L被用来控制对共享数据的访问，Lock和Unlock会在两个线程间引起因果依赖关系，如图中的edge，Lock（L）要在Unlock（L）之后。我们之前说的trace中有同步事件，这个同步事件由线程的id和本地时钟来确定，而两个同步事件之间的因果顺序由一条有向边来表示，如在Figure 2中，Unlock（t1，3）到Lock（t2，2）是一条因果边。随着primary继续处理到来的请求，trace会一直增加。这里引入一个概念：