通过P-SMR看State Machine Replication

在一个复制系统中，为了保持一致性，各个replicated server是串行运行。这样性能上就会比仅仅有一台server的系统慢，由于仅仅有一台server能够进行并行处理。假设在复制系统中各个server也能进行并行处理的话， 这将是非常大的进步。

可是假设各个线程之间没有共享变量的话。在复制系统的每一个server上进行并行处理也是可行的，实际上曾经非常多复制系统并行处理都是基于这一点去做的。 

P-SMR也是要依据命令之间的依赖关系推断什么情况下能够并行，什么情况下是串行。

我们须要将服务程序抽象成一个状态机，一个Mealy状态机。要构建一个State-Machine Replication系统，当中不可缺少的模块就是proxy。client的proxy和server的proxy。

比方当请求到达server时。须要server proxy去评估能否并行运行，以及怎样去并行。并且也是通过proxy在replicas之间和client-server之间传递信息。如同RPC（远程过程调用）一样。

再比如，对于一个命令，多个server会向client发送多个同样的response，可是经过server
proxy，发给client的仅仅会是一个response。

先来了解一下什么样的两个命令是相互依赖（dependent）的：他们訪问（读或写）一个公共变量v，而且至少当中一个命令改变了v的值。如一个命令是读v，还有一个是更新v。

但这种话不论是仅仅有一个server的系统还是replication系统，都不能并行运行，仅仅能依照total order来依次处理命令。所以假设命令间是dependent的，replication仅仅能採取串行运行。

这样越说越不正确劲了，这种话replication系统要解决什么问题呢？是让independent的命令并行运行，还是让dependent的命令并行运行？以下来寻找答案。

答案是independent。

你可能会问：这有什么难的？实际上我们忽略了一个问题，除了命令的运行能够并行化，怎样也让命令并行的传递（delivery），此时多个命令还是串行的在传递。所以这应该是P-SMR要去挑战的地方。做到所有并行化，而非半并行化。

所以P-SMR意思是 parallel state-machine replication。能做到命令运行和传递都并行化的一个方法。对于一个replica除了能做到并行运行命令外，也在multicast这个环节做到并行化。

究竟multicast这个地方并行化的难度在哪里呢？ 

这里引入P-SMR里的一个概念C-Dep（command dependencies），一般来说假设两条命令的參数是同一个对象。并且是update操作，则能够预判这两条命令相互依赖。在client proxy里有个函数叫 Command-to-Group (C-G) ，它会在client的命令和该命令要去的地方建立起映射，告诉哪个命令该去哪个地方。以下是这个过程的算法： 

让我们设想一下，在这个C-G函数中，须要做到： 

如果这时有4个命令亟待运行。

1）C-G函数要能推断这4个命令之间的C-Dep 

2）假如4个命令之间是independent的，C-G对这4个命令的目的地的映射要达到最大的并行化的目的 

3）假如4个命令之间是dependent，C-G要让这4个命令实现串行处理。

怎样做到 2） 呢？C-G要将这4个命令分配给不同的组groups。 

这里再解释一下P-SMR里的groups。

在replication系统中如果有5台server(A, B, C, D, E)，每台server配置一样。一台server上拥有4个core，这时我们能够说这个系统的MPL（multiprogramming level）是4。我们能够为每台server定义4个worker thread（t1, t2, t3, t4），这4个thread执行在4个core上，这时我们能够说这个系统有4个groups，各自是： 

g1: A(t1), B(t1), C(t1), D(t1), E(t1) 

g2: A(t2), B(t2), C(t2), D(t2), E(t2) 

g3: A(t3), B(t3), C(t3), D(t3), E(t3) 

g4: A(t4), B(t4), C(t4), D(t4), E(t4) 

g5: A(t5), B(t5), C(t5), D(t5), E(t5)

再来看一个C-G应用的场景。如果这时有两个命令： 

set_state(v) 

get_state(v) 

对于get_state，尽管这是一个复制系统。但这个命令并不须要发给全部replicas，仅仅需当中一个运行并返回结果就可以，而对于set_state，则须要让每个replica都去运行。

这里先记录下P-SMR的一个长处： 

P-SMR offloads scheduling decisions from the replicas, avoiding a bottleneck-prone scheduler, which must deliver a single stream of commands and assign them to the worker threads for execution。

尝试解释一下：传统的并行运行。是让linux内核来做调度，将4个independent的命令分配在4个线程上。而在P-SMR中client proxy中的C-G起到了调度官（scheduler）的作用，即由C-G来制定线程分配的调度策略，这种话就能指定某个命令分配到特定的线程上。而这在传统的linux内核调度上是做不到的，这也是P-SMR能做到并行运行的核心思想和方法所在。

以下是我对P-SMR的理解：