Update ch05.md

remove redundant * in ch05

ch05.md

@@ -138,7 +138,7 @@
 
 但这种方法有一些问题：
 
-1. **非确定性函数（nondeterministic）**的语句可能会在不同副本造成不同改动。如 NOW()、RAND()
+1. **非确定性函数（nondeterministic）** 的语句可能会在不同副本造成不同改动。如 NOW()、RAND()
 2. **使用自增列，或依赖于现有数据**。则不同用户的语句需要完全按相同顺序执行，当有并发事务时，可能会造成不同的执行顺序，进而导致副本不一致。
 3. **有副作用**（触发器、存储过程、UDF）的语句，可能不同副本由于上下文不同，产生的副作用不一样。除非副作用是确定的输出。
 
@@ -284,7 +284,7 @@
 
 事务！
 
-多副本异步复制所带来的一致性问题，都可以通过**事务（transaction）**来解决。单机事务已经存在了很长时间，但在数据库走向分布式时代，一开始很多 NoSQL 系统抛弃了事务。
+多副本异步复制所带来的一致性问题，都可以通过**事务（transaction）** 来解决。单机事务已经存在了很长时间，但在数据库走向分布式时代，一开始很多 NoSQL 系统抛弃了事务。
 
 - 这是为什么？
     1. 更容易的实现。2. 更好的性能。3. 更好的可用性。 
@@ -450,7 +450,7 @@ TODO（自动冲突解决）
 1. 可能不能够充分同步
 2. 同步时可能会发生回退
 
-可以用一种叫做**版本向量（version vectors）**的策略，对多个副本的事件进行排序，解决因果一致性问题。下一节会详细讨论。
+可以用一种叫做**版本向量（version vectors）** 的策略，对多个副本的事件进行排序，解决因果一致性问题。下一节会详细讨论。
 
 最后忠告：如果你要使用基于多主模型的系统，一定要知晓上面提到的问题，多做测试，确保其提供的保证符合你的使用场景。
 
@@ -468,7 +468,7 @@ TODO（自动冲突解决）
 通常来说，在无主模型中，写入时可以：
 
 1. 由客户端直接写入副本。
-2. 由**协调者（coordinator）**接收写入，转发给多副本。但与主副本不同，协调者并不负责定序。
+2. 由**协调者（coordinator）** 接收写入，转发给多副本。但与主副本不同，协调者并不负责定序。
 
 ## 有节点故障时的写入