修改排版

ch4-rpc/ch4-07-pbgo.md

@@ -77,7 +77,7 @@ type Plugin interface {
 }
 ```
 
-我们需要在 Generate 和 GenerateImports 函数中分别生成相关的代码。而 Protobuf 文件的全部信息都在 * generator.FileDescriptor 类型函数参数中描述，因此我们需要从函数参数中提前扩展定义的元数据。
+我们需要在 Generate 和 GenerateImports 函数中分别生成相关的代码。而 Protobuf 文件的全部信息都在 `*generator.FileDescriptor` 类型函数参数中描述，因此我们需要从函数参数中提前扩展定义的元数据。
 
 pbgo 框架中的插件对象是 pbgoPlugin，在 Generate 方法中首先需要遍历 Protobuf 文件中定义的全部服务，然后再遍历每个服务的每个方法。在得到方法结构之后再通过自定义的 getServiceMethodOption 方法提取 rest 扩展信息：
 

ch6-cloud/ch6-04-search-engine.md

@@ -61,7 +61,7 @@ func equal() {
 }
 ```
 
-多个有序列表求交集的时间复杂度是：`O(N * M)`，N 为给定列表当中元素数最小的集合，M 为给定列表的个数。
+多个有序列表求交集的时间复杂度是：`O(N*M)`，N 为给定列表当中元素数最小的集合，M 为给定列表的个数。
 
 在整个算法中起决定作用的一是最短的倒排列表的长度，其次是词数总和，一般词数不会很大（想像一下，你会在搜索引擎里输入几百字来搜索么？），所以起决定性作用的，一般是所有倒排列表中，最短的那一个的长度。
 

ch6-cloud/ch6-05-load-balance.md

@@ -70,7 +70,6 @@ func request(params map[string]interface{}) error {
 真的没有问题么？还是有问题的。这段简短的程序里有两个隐藏的隐患:
 
 1. 没有随机种子。在没有随机种子的情况下，`rand.Intn()` 返回的伪随机数序列是固定的。
-
 2. 洗牌不均匀，会导致整个数组第一个节点有大概率被选中，并且多个节点的负载分布不均衡。
 
 第一点比较简单，应该不用在这里给出证明了。关于第二点，我们可以用概率知识来简单证明一下。假设每次挑选都是真随机，我们假设第一个位置的节点在 `len(slice)` 次交换中都不被选中的概率是 `((6/7)*(6/7))^7≈0.34`。而分布均匀的情况下，我们肯定希望被第一个元素在任意位置上分布的概率均等，所以其被随机选到的概率应该约等于 `1/7≈0.14`。