added Technical Considerations

content/replicated-log.md

@@ -288,4 +288,30 @@ class ReplicatedLog…
 如果以弗所（ephesus）回来或是恢复了网络连接，它会向锡兰（cyrene）发送请求。因为锡兰（cyrene）现在是第 3 代了，它会拒绝这个请求。以弗所（ephesus）会在拒绝应答中得到新的任期（term），下台成为一个追随者。
 
 ![拥有最新日志的节点赢得选举](../image/raft-leader-stepdown.png)
-<center>图7：Leader step-down</center>
+<center>图7：Leader step-down</center>
+
+#### 技术考量
+
+以下是任何复制日志机制都需要有的一些重要技术考量。
+
+* 任何共识建立机制的第一阶段都需要了解日志条目在上一个 Quorum 上可能已经复制过了。领导者需要了解所有这些条目，确保它们复制到集群的每个节点上。
+
+Raft 会确保当选领导者的集群节点拥有同服务器的 Quorum 拥有同样的最新日志，所以，日志条目无需从其它集群节点传给新的领导者。
+
+有可能一些条目存在冲突。在这种情况下，追随者日志中冲突的条目会被覆盖。
+
+* 有可能集群中的一些集群节点落后了，可能是因为它们崩溃后重新启动，可能是与领导者断开了连接。领导者需要跟踪每个集群节点，确保它发送了所有缺失的日志条目。
+
+Raft 会为每个集群节点维护一个状态，以便了解在每个节点上都已成功复制的日志条目的索引。向每个节点发送的复制请求都会包含从这个日志索引开始的所有条目，确保每个集群节点获得所有的日志条目。
+
+* 客户端如何与复制日志进行交互，以找到领导，这个实现在[一致性内核（Consistent Core）](consistent-core.md)中讨论过。
+
+在客户端重试的情况下，集群会检测重复的请求，通过采用[幂等接收者（Idempotent Receiver）](idempotent-receiver.md)就可以进行处理。
+
+* 日志通常会用[低水位标记（Low-Water Mark）](low-water-mark.md)进行压缩。复制日志会周期性地进行存储快照，比如，几千个条目之后就快照一次。然后，快照索引之前的日志就可以丢弃了。缓慢的追随者，或是新加入的服务器，需要发送完整的日志，发给它们的就是快照，而非单独的日志条目。
+
+* 这里的一个关键假设，所有的请求都是严格有序的。这可能并非总能满足的需求。例如，一个键值存储可能不需要对不同键值的请求进行排序。在这种情况下，有可能为每个键值运行一个不同的共识实例。这样一来，就不需要对所有的请求都有单一的领导者了。
+
+[EPaxos](https://www.cs.cmu.edu/~dga/papers/epaxos-sosp2013.pdf) 就是一种不依赖单一领导者对请求进行排序的算法。
+
+在像 [MongoDB](https://www.mongodb.com/) 这样的分区数据库中，每个分区都会维护一个复制日志。因此，请求是按分区排序的，而非跨分区。