Update ch09.md

ch09.md

@@ -310,7 +310,7 @@ CAP 最初被提出只是一个为了激发数据库取舍讨论的模糊的取
 
 **全序**（total order）意味着**系统内任意两个元素可比大小**。如，自然数是全序：任举两个自然数，比如 5 和 13，我们可以确定 13 是比 5 大的。但与此相对，数学中的集合就不是全序的，比如我们无从比较 {a, b} 和 {b, c} 的大小关系，因为他们互不为对方子集。对于这种情况，我们称其**不可比**（incomparable）。反之，集合是**偏序**（partially ordered）：在某些情况下，我们可以说一个集合比另一个集合大（两个集合间有包含关系）；但在另外一些情况下，两个集合间没有可比关系。
 
-全序和偏序的区别还方应在不同强度**数据库一致性模型**（database consistency models）上：
+全序和偏序的区别还反应在不同强度**数据库一致性模型**（database consistency models）上：
 
 - **线性一致性**（Linearizability）：让我们回忆下对于可线性化的理解，可线性化对外表现的像**所有操作都发生于单副本上，并且会原子性的完成**。这就意味着，对于任意两个操作，我们总是可以确定其发生的先后关系，也即在可线性化系统中，所有的操作顺序满足全序关系。如之前图 9-4 中给的例子。
 - **因果一致性**（Causality）。如果我们无从判定两个操作的先后关系，则称之为**并发的**（concurrent，参见[发生于之前和并发关系](https://ddia.qtmuniao.com/#/ch05?id=%e5%8f%91%e7%94%9f%e4%ba%8e%e4%b9%8b%e5%89%8d%ef%bc%88happens-before%ef%bc%89%e5%92%8c%e5%b9%b6%e5%8f%91%e5%85%b3%e7%b3%bb)）。从另一个角度说，如果两个事件因果相关，则其一定有序。也即，因果性定义了一种**偏序**（partial order）关系，而非全序关系：有些操作存在因果，因此可比；而另外一些操作则是并发的，即不可比。
@@ -479,7 +479,7 @@ Lamport 时间戳不依赖于物理时钟，但可以提供全序保证，对于
 2. （由于全序广播是异步的）不断读取日志，直到能够读到刚才你追加的消息条目。
 3. 检查所有想要使用该用户名的消息，这时你可能会得到多条消息，如果你当初写下的消息在第一条，则你是成功的。此时，你可以“确认”（持久化，比如追加日志，比如写入数据库）占有该用户名的信息，然后给客户端返回成功。如果第一条消息不是你的，则终止请求。
 
-> 这里其实隐藏了一些细节，即我们会将追加消息请求发送给全序广播系统，全序广播系统会真正将消息按之前提到的两条保证的方式（可靠送达和全序送达）同步到每个节点。因此，对于每个节点来说，会首先发起消息追加请求，然后之后某个时刻，可以等到真正同步回来的消息。如果觉得绕，可以带入 Raft 的付之日志来类比。
+> 这里其实隐藏了一些细节，即我们会将追加消息请求发送给全序广播系统，全序广播系统会真正将消息按之前提到的两条保证的方式（可靠送达和全序送达）同步到每个节点。因此，对于每个节点来说，会首先发起消息追加请求，然后之后某个时刻，可以等到真正同步回来的消息。如果觉得绕，可以带入 Raft 的复制日志来类比。
 
 由于所有日志条目都会以同样的顺序送达每个节点，若有并发写入，则所有节点都能依靠日志顺序就谁“先来后到”达成一致。当有同名冲突时，可以选择第一条作为赢家，并舍弃其后的冲突请求。可以使用类似的方式，基于日志来实现涉及到多对象的事务的可串行化。