diff --git a/SUMMARY.md b/SUMMARY.md
index b3b2b95..291b3a0 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -44,6 +44,7 @@
    * [6.3. Middleware中间件](ch6-web/ch6-03-middleware.md)
    * [6.4. Validator请求校验](ch6-web/ch6-04-validator.md)
    * [6.5. Database和数据库打交道](ch6-web/ch6-05-database.md)
+   * [6.8. Layout大型web项目分层](ch6-web/ch6-08-layout-of-web-project.md)
 * [附录](appendix/readme.md)
    * [附录A: Go语言常见坑](appendix/appendix-a-trap.md)
    * [附录B: 参考资料](appendix/appendix-b-ref.md)
diff --git a/ch6-web/ch6-12-load-balance.md b/ch6-web/ch6-12-load-balance.md
index 86fe867..02b4824 100644
--- a/ch6-web/ch6-12-load-balance.md
+++ b/ch6-web/ch6-12-load-balance.md
@@ -76,8 +76,17 @@ func request(params map[string]interface{}) error {
 
 2. 洗牌不均匀，会导致整个数组第一个节点有大概率被选中，并且多个节点的负载分布不均衡。
 
-第一点比较简单，应该不用在这里给出证明了。关于第二点，我们可以用概率知识来简单证明一下。假设
+第一点比较简单，应该不用在这里给出证明了。关于第二点，我们可以用概率知识来简单证明一下。假设每次挑选都是真随机，我们假设第一个位置的 endpoint 在 len(slice) 次交换中都不被选中的概率是 ((6/7)*(6/7))^7 ≈ 0.34。而分布均匀的情况下，我们肯定希望被第一个元素在任意位置上分布的概率均等，所以其被随机选到的概率应该 ≈ 1/7 ≈ 0.14。
 
-## 修正后的负载均衡算
+显然，这里给出的洗牌算法对于任意位置的元素来说，有 30% 的概率不对其进行交换操作。所以所有元素都倾向于留在原来的位置。因为我们每次对 shuffle 数组输入的都是同一个序列，所以第一个元素有更大的概率会被选中。在负载均衡的场景下，也就意味着 endpoints 数组中的第一台机器负载会比其它机器高不少(这里至少是 3 倍以上)。
+
+## 修正后的洗牌算法
+
+从数学上得到过证明的还是经典的 fisher-yates 算法，在 Go 的标准库中实际上已经为我们内置了该算法:
+
+```go
+```
 
 ## zk 集群的随机节点挑选问题
+
+## 故障节点摘除