update di

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

@@ -37,7 +37,7 @@ Twitter 的 snowflake 算法是这种场景下的一个典型解法。先来看
 
 数据中心 + 实例 id 共有 10 位，可以支持我们每数据中心部署 32 台机器，所有数据中心共 1024 台实例。
 
-表示 timestamp 的 41 位，可以支持我们将时间推进到 `2039/9/7 23:47:35`，暂时也够用了。如果不够用，我们就从数据中心 id 中接一位出来，可以用到遥不可及的未来了。
+表示 timestamp 的 41 位，可以支持我们使用 69 年。当然，我们的时间毫秒计数不会真的从 1970 年开始记，那样我们的系统跑到 `2039/9/7 23:47:35` 就不能用了，所以这里的 timestamp 实际上只是相对于某个时间的增量，比如我们的系统上线是 2018-08-01，那么我们可以把这个 timestamp 当作是从 `2018-08-01 00:00:00.000` 的偏移量。
 
 ## worker id　分配
 
@@ -102,4 +102,22 @@ func main() {
 
 ```
 
+当然，这个库也给我们留好了定制的后路： 
+
+```go
+    // Epoch is set to the twitter snowflake epoch of Nov 04 2010 01:42:54 UTC
+    // You may customize this to set a different epoch for your application.
+    Epoch int64 = 1288834974657
+
+    // Number of bits to use for Node
+    // Remember, you have a total 22 bits to share between Node/Step
+    NodeBits uint8 = 10
+
+    // Number of bits to use for Step
+    // Remember, you have a total 22 bits to share between Node/Step
+    StepBits uint8 = 12
+```
+
+Epoch 就是本节开头讲的起始时间，NodeBits 指的是机器编号的位长，StepBits 指的是自增序列的位长。
+
 sonyflake