Updates consensus part

consensus/acid.md

 ## ACID 原则
-即 Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）、Durability（持久性）。对分布式数据库的一致性，付出可用性的代价。
+即 Atomicity（原子性）、Consistency（一致性）、Isolation（隔离性）、Durability（持久性）。
 
-* Atomicity
-* Consistency
-* Isolation
-* Durability
+ACID 原则描述了对分布式数据库的一致性需求，同时付出了可用性的代价。
+
+* Atomicity：每次操作是原子的，要么成功，要么不执行；
+* Consistency：数据库的状态是一致的，无中间状态；
+* Isolation：各种操作彼此互相不影响；
+* Durability：状态的改变是持久的，不会失效。
 
 一个与之相对的原则是 BASE（Basic Availiability，Soft state，Eventually Consistency），牺牲掉对一致性的约束（最终一致性），来换取一定的可用性。
 

consensus/bft.md

 ## 拜占庭问题与算法
 
+拜占庭问题更为广泛，讨论的是允许存在少数节点作恶（消息可能被伪造）场景下的一致性达成问题。拜占庭算法讨论的是最坏情况下的保障。
+
 ### 中国将军问题
 
-拜占庭将军问题之前，就已经存在中国将军问题：两个将军要通过信使来达成进攻还是撤退的约定，但信使可能迷路或被敌军阻拦（通信可能故障），如何达成一致。根据 FLP 不可能原理，这个问题无解。
+拜占庭将军问题之前，就已经存在中国将军问题：两个将军要通过信使来达成进攻还是撤退的约定，但信使可能迷路或被敌军阻拦（消息丢失或伪造），如何达成一致。根据 FLP 不可能原理，这个问题无解。
 
 ### 拜占庭问题
 
-又叫拜占庭将军（Byzantine Generals Problem）问题，是 Leslie Lamport 1982 年提出用来解释一致性问题的一个虚构模型。拜占庭是古代东罗马帝国的首都，由于地域宽广，守卫边境的多个将军（系统中的多个节点）需要通过信使来传递消息，达成某些一致的决定。但由于将军中可能存在叛徒（系统中节点出错），可能会干扰一致性的达成。
+又叫拜占庭将军（Byzantine Generals Problem）问题，是 Leslie Lamport 1982 年提出用来解释一致性问题的一个虚构模型。拜占庭是古代东罗马帝国的首都，由于地域宽广，守卫边境的多个将军（系统中的多个节点）需要通过信使来传递消息，达成某些一致的决定。但由于将军中可能存在叛徒（系统中节点出错），这些叛徒将努力向不同的将军发送不同的消息，试图会干扰一致性的达成。
 
 拜占庭问题即为在此情况下，如何让忠诚的将军们能达成行动的一致。
 
@@ -24,15 +26,17 @@
 
 另外存在 F−1 个不确定的信息。合作者要想达成一致，必须进一步的对所获得的消息进行判定，询问其他人某个被怀疑对象的消息值，并通过取多数来作为被怀疑者的信息值。这个过程可以进一步递归下去。
 
-Leslie Lamport 证明，当叛变者不超过 $$\frac{1}{3}$$ 时，存在有效的算法达成一致。
+Leslie Lamport 证明，当叛变者不超过 $$\frac{1}{3}$$ 时，存在有效的算法，不论叛变者如何折腾，忠诚的将军们总能达成一致的结果。如果叛变者过多，则无法保证一定能达到一致性。
 
-### BFT 算法
+能确保达成一致的拜占庭系统节点数至少为 4，允许出现 1 个坏的节点。
 
-面向拜占庭问题的算法，解决的是网络通信可靠，但节点可能故障情况下的一致性达成。
+### Byzantine Fault Tolerant 算法
 
-最早由 Castro 和 Liskov 在 1999 年提出的 PBFT 是第一个得到广泛应用的 BFT 算法。只要系统中有 $$\frac{2}{3}$$ 的节点是正常工作的，则可以保证一致性。
+面向拜占庭问题的容错算法，解决的是网络通信可靠，但节点可能故障情况下的一致性达成。
 
+最早由 Castro 和 Liskov 在 1999 年提出的 Practical Byzantine Fault Tolerant（PBFT）是第一个得到广泛应用的 BFT 算法。只要系统中有 $$\frac{2}{3}$$ 的节点是正常工作的，则可以保证一致性。
 
+PBFT 算法包括三个阶段来达成共识：Pre-Prepare、Prepare 和 Commit。
 
 ### 新的解决思路
 

consensus/paxos.md

 ## Paxos 与 Raft
 
+Paxos 最初设计为解决存在故障，但不存在恶意节点（无伪造消息，但可能丢失或重复）场景下的一致性问题。
+
+Raft 是对 Paxos 的重新设计和实现。
+
 ### Paxos
 
-1990 年由 Leslie Lamport 提出的 [Paxos](http://research.microsoft.com/users/lamport/pubs/lamport-paxos.pdf) 一致性算法，在工程角度实现了一种最大化保障一致性（极小的概率无法实现一致性）的机制。
+1990 年由 Leslie Lamport 提出的 [Paxos](http://research.microsoft.com/users/lamport/pubs/lamport-paxos.pdf) 一致性算法，在工程角度实现了一种最大化保障一致性（存在极小的概率无法实现一致性）的机制。
+
+故事背景是古希腊 Paxon 岛上的多个法官在一个大厅内对一个议案进行表决，如何达成统一的结果。他们之间通过服务人员来传递纸条，但法官可能离开或进入大厅，服务人员可能偷懒去睡觉。
+
+Paxos 是第一个被证明的一致性算法，其原理基于两阶段提交并进行扩展。
+
+作为现在一致性算法设计的鼻祖，算法以复杂难懂出名。算法中将节点分为三种类型：
+
+* proposer：提出一个提案，等待大家批准为结案；
+* acceptor：负责对提案进行投票；
+* learner：被告知结案结果，并与之统一。
+
+基本过程包括 proposer 提出提案，先争取多个 acceptor 的支持，超过一半支持时，则发送结案结果给所有人。一个潜在的问题是 proposer 在此过程中出现故障，可以通过超时机制来解决。极为凑巧的情况下，每次新的一轮提案的 proposer 都恰好故障，系统则永远无法达成一致（概率很小）。
 
-Paxos 是第一个被证明的一致性算法，其原理是现在一致性算法设计的鼻祖，然而以复杂难懂出名。
+Paxos 能保证在超过一半的正常节点存在时，系统能达成一致。
 
 Paxos 被应用在 Chubby、ZooKeeper 这样的系统中。
 

consensus/summary.md

 ## 小结
 
+一致性是个古老而重要的问题。
+
+理想化的一致性解决方案是不存在的，在现实各种约束条件下，通过牺牲掉某些需求，可以设计出不同的一致性协议。
+
+或许，工程技术上大部分的问题，都在于如何合理地进行取舍。
\ No newline at end of file