From 81ad2fcaf27b090977cff9cb6110ec8ec0066138 Mon Sep 17 00:00:00 2001 From: sfw Date: Wed, 8 Aug 2018 06:09:31 +0800 Subject: [PATCH] ch6-5-fix typos --- ch6-cloud/ch6-05-load-balance.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ch6-cloud/ch6-05-load-balance.md b/ch6-cloud/ch6-05-load-balance.md index 00fb651..95eb274 100644 --- a/ch6-cloud/ch6-05-load-balance.md +++ b/ch6-cloud/ch6-05-load-balance.md @@ -109,7 +109,7 @@ func shuffle(n int) []int { 本节中的场景是从 N 个节点中选择一个节点发送请求，初始请求结束之后，后续的请求会重新对数组洗牌，所以每两个请求之间没有什么关联关系。因此我们上面的洗牌算法，理论上不初始化随机库的种子也是不会出什么问题的。 -但在一些特殊的场景下，例如使用 zk 时，客户端初始化从多个服务节点中挑选一个节点后，是会向该节点建立长连接的。并且之后如果有请求，也都会发送到该节点去。直到该节点不可用，才会在 endpoints 列表中挑选下一个节点。在这种场景下，我们的初始连接节点选择就要求必须是“真”随机了。否则，所以客户端起动时，都会去连接同一个 zk 的实例，根本无法起到负载均衡的目的。如果在日常开发中，你的业务也是类似的场景，也务必考虑一下是否会发生类似的情况。为 rand 库设置种子的方法: +但在一些特殊的场景下，例如使用 zk 时，客户端初始化从多个服务节点中挑选一个节点后，是会向该节点建立长连接的。并且之后如果有请求，也都会发送到该节点去。直到该节点不可用，才会在 endpoints 列表中挑选下一个节点。在这种场景下，我们的初始连接节点选择就要求必须是“真”随机了。否则，所有客户端起动时，都会去连接同一个 zk 的实例，根本无法起到负载均衡的目的。如果在日常开发中，你的业务也是类似的场景，也务必考虑一下是否会发生类似的情况。为 rand 库设置种子的方法: ```go rand.Seed(time.Now().UnixNano()) @@ -177,4 +177,4 @@ map[0:224436 1:128780 5:129310 6:129194 2:129643 3:129384 4:129253] map[6:143275 5:143054 3:143584 2:143031 1:141898 0:142631 4:142527] ``` -分布结果和我们推导出的理论是一致的。 +分布结果和我们推导出的结论是一致的。