Merge branch 'master' of https://github.com/chai2010/advanced-go-programming-book

SUMMARY.md

@@ -55,7 +55,7 @@
    * [6.4. 分布式队列(TODO)](ch6-cloud/ch6-04-queue.md)
    * [6.5. 分布式缓存(TODO)](ch6-cloud/ch6-05-cache.md)
    * [6.6. etcd(TODO)](ch6-cloud/ch6-06-etcd.md)
-   * [6.7. confd(TODO)](ch6-cloud/ch6-07-confd.md)
+   * [6.7. 分布式 id 生成器(DOING)](ch6-cloud/ch6-07-dist-id.md)
    * [6.8. 分布式锁(TODO)](ch6-cloud/ch6-08-lock.md)
    * [6.9. 分布式任务调度系统(TODO)](ch6-cloud/ch6-09-sched.md)
    * [6.10. 延时任务系统](ch6-cloud/ch6-10-delay-job.md)

ch6-cloud/ch6-07-dist-id.md

@@ -41,6 +41,17 @@ Twitter 的 snowflake 算法是这种场景下的一个典型解法。先来看
 
 ## worker id　分配
 
+timestamp，datacenter_id，worker_id 和 sequence_id 这四个字段中，timestamp 和 sequence_id 是由程序在运行期生成的。但 datacenter_id 和 worker_id 需要我们在部署阶段就能够获取得到，并且一旦程序启动之后，就是不可更改的了(想想，如果可以随意更改，可能被不慎修改，造成最终生成的 id 有冲突)。
+
+一般不同数据中心的机器，会提供对应的获取数据中心 id 的 api，所以 datacenter_id 我们是可以在部署阶段简单地获取到的。而 worker_id 是我们逻辑上给机器分配的一个 id，这个要怎么办呢？比较简单的想法是由能够提供这种自增 id 功能的工具来支持，比如 MySQL:
+
+```
+```
+
+当然，使用 MySQL 相当于给我们简单的 id 生成服务增加了一个外部依赖。依赖越多，我们的服务的可运维性就越差。
+
+考虑到集群中即使有单个 id 生成服务的实例挂了，也就是损失一段时间的一部分 id，所以我们也可以更简单暴力一些，把 worker_id 直接写在 worker 的配置中，上线时，由部署脚本完成 worker_id 字段替换。
+
 ## 开源实例
 
 gosnowflake