fix 6-1

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

@@ -6,32 +6,11 @@
 
 Twitter的snowflake算法是这种场景下的一个典型解法。先来看看snowflake是怎么一回事：
 
-```
+![snowflake](../images/ch6-snowflake.png)
-                                                               datacenter_id          sequence_id
-    unused
-                                                                      │                     │
-       │                                                              │                     │
-       │                                                              │                     │
-       │  │                                                      │    │                     │
-       │  │                                                      │    │                     │
-       ▼  │◀──────────────────    41 bits   ────────────────────▶│    ▼                     ▼
-    ┌─────┼──────────────────────────────────────────────────────┼────────┬────────┬────────────────┐
-    │  0  │ 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0  │ 00000  │ 00000  │ 0000 0000 0000 │
-    └─────┴──────────────────────────────────────────────────────┴────────┴────────┴────────────────┘
-                                      ▲                                        ▲
-                                      │                                        │
-                                      │                                        │
-                                      │                                        │
-                                      │                                        │
-                                      │                                        │
-                                      │                                        │
-
-                            time in milliseconds                          worker_id
-```
 
 首先确定我们的数值是64 位，int64类型，被划分为四部分，不含开头的第一个bit，因为这个bit是符号位。用41位来表示收到请求时的时间戳，单位为毫秒，然后五位来表示数据中心的id，然后再五位来表示机器的实例id，最后是12位的循环自增id(到达 1111 1111 1111 后会归 0)。
 
-这样的机制可以支持我们在同一台机器上，同一毫秒内产生 2 ^ 12 = 4096 条消息。一秒共 409.6w 条消息。从值域上来讲完全够用了。
+这样的机制可以支持我们在同一台机器上，同一毫秒内产生`2 ^ 12 = 4096`条消息。一秒共409.6万条消息。从值域上来讲完全够用了。
 
 数据中心 + 实例id共有10位，可以支持我们每数据中心部署32台机器，所有数据中心共1024台实例。
 
@@ -68,11 +47,7 @@ mysql> select last_insert_id();
 
 `github.com/bwmarrin/snowflake` 是一个相当轻量化的snowflake的Go实现。其文档指出：
 
-```
+![ch6-snowflake-easy](../images/ch6-snowflake-easy.png)
-+--------------------------------------------------------------------------+
-| 1 Bit Unused | 41 Bit Timestamp |  10 Bit NodeID  |   12 Bit Sequence ID |
-+--------------------------------------------------------------------------+
-```
 
 和标准的snowflake完全一致。使用上比较简单：
 
@@ -128,15 +103,11 @@ Epoch 就是本节开头讲的起始时间，NodeBits 指的是机器编号的
 
 sonyflake是Sony公司的一个开源项目，基本思路和snowflake差不多，不过位分配上稍有不同：
 
-```
+![sonyflake](../images/ch6-snoyflake.png)
-+-----------------------------------------------------------------------------+
-| 1 Bit Unused | 39 Bit Timestamp |  8 Bit Sequence ID  |   16 Bit Machine ID |
-+-----------------------------------------------------------------------------+
-```
 
 这里的时间只用了39个bit，但时间的单位变成了10ms，所以理论上比41位表示的时间还要久(174 years)。
 
-Sequence ID 和之前的定义一致，Machine ID 其实就是节点 id。sonyflake 与众不同的地方在于其在启动阶段的 setting 配置：
+`Sequence ID`和之前的定义一致，`Machine ID`其实就是节点id。`sonyflake`与众不同的地方在于其在启动阶段的配置参数：
 
 ```go
 func NewSonyflake(st Settings) *Sonyflake
@@ -154,7 +125,7 @@ type Settings struct {
 
 StartTime选项和我们之前的Epoch差不多，如果不设置的话，默认是从`2014-09-01 00:00:00 +0000 UTC`开始。
 
-MachineID 可以由用户自定义的函数，如果用户不定义的话，会默认将本机 ip 的低 16 位作为 machine id。
+MachineID可以由用户自定义的函数，如果用户不定义的话，会默认将本机IP的低16位作为`machine id`。
 
 CheckMachineID是由用户提供的检查MachineID是否冲突的函数。这里的设计还是比较巧妙的，如果有另外的中心化存储并支持检查重复的存储，那我们就可以按照自己的想法随意定制这个检查MachineID是否冲突的逻辑。如果公司有现成的Redis集群，那么我们可以很轻松地用Redis的set来检查冲突。