finished solution in replicated log

content/replicated-log.md

@@ -1,4 +1,4 @@
-# 请求管道（Request Pipeline）
+# 可复制日志（Replicated Log）
 
 **原文**
 
@@ -16,4 +16,10 @@ https://martinfowler.com/articles/patterns-of-distributed-systems/replicated-log
 
 ## 解决方案
 
-集群节点维护了一个[预写日志（Write-Ahead Log）](write-ahead-log.md)。每个日志项都存储了共识所需的状态以及相应的用户请求。这些节点通过日志项的协调建立起了共识，这样一来，所有的节点都拥有了完全相同的预写日志。然后，请求按照日志的顺序进行执行。因为所有的集群节点在每条日志项都达成了一致，它们就是以相同的顺序执行相同的请求。这就确保了所有集群节点共享相同的状态。
+集群节点维护了一个[预写日志（Write-Ahead Log）](write-ahead-log.md)。每个日志项都存储了共识所需的状态以及相应的用户请求。这些节点通过日志项的协调建立起了共识，这样一来，所有的节点都拥有了完全相同的预写日志。然后，请求按照日志的顺序进行执行。因为所有的集群节点在每条日志项都达成了一致，它们就是以相同的顺序执行相同的请求。这就确保了所有集群节点共享相同的状态。
+
+使用 [Quorum](quorum.md) 的容错共识建立机制需要两个阶段。
+* 一个阶段负责建立[世代时钟（Generation Clock）](generation-clock.md)，了解在前一个 [Quorum](quorum.md) 中复制的日志项。
+* 一个阶段负责在所有集群节点上复制请求。
+
+每次状态变化的请求都去执行两个阶段，这么做并不高效。所以，集群节点会在启动时选择一个领导者。领导者会在选举阶段建立起[世代时钟（Generation Clock）](generation-clock.md)，然后检测上一个 [Quorum](quorum.md) 所有的日志项。（前一个领导者或许已经将大部分日志项复制到了大多数集群节点上。）一旦有了一个稳定的领导者，复制就只由领导者协调了。客户端与领导者通信。领导者将每个请求添加到日志中，并确保其复制到到所有的追随者上。一旦日志项成功地复制到大多数追随者，共识就算已经达成。按照这种方式，当有一个稳定的领导者时，对于每次状态变化的操作，只要执行一个阶段就可以达成共识。