Skip to content

Commit 903b12b

Browse files
cch123cch123
committed
fix 6-1
1 parent 59f26a0 commit 903b12b

File tree

4 files changed

+25
-54
lines changed

4 files changed

+25
-54
lines changed

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

Lines changed: 25 additions & 54 deletions
Original file line numberDiff line numberDiff line change
@@ -1,47 +1,26 @@
11
# 6.1 分布式 id 生成器
22

3-
有时我们需要能够生成类似 MySQL 自增 ID 这样不断增大，同时又不会重复的 id。以支持业务中的高并发场景。比较典型的，电商促销时，短时间内会有大量的订单涌入到系统，比如每秒 10w+。明星出轨时，会有大量热情的粉丝发微博以表心意，同样会在短时间内产生大量的消息。
3+
有时我们需要能够生成类似MySQL自增ID这样不断增大，同时又不会重复的id。以支持业务中的高并发场景。比较典型的，电商促销时，短时间内会有大量的订单涌入到系统，比如每秒10w+。明星出轨时，会有大量热情的粉丝发微博以表心意，同样会在短时间内产生大量的消息。
44

5-
在插入数据库之前，我们需要给这些消息/订单先打上一个 ID，然后再插入到我们的数据库。对这个 id 的要求是希望其中能带有一些时间信息，这样即使我们后端的系统对消息进行了分库分表，也能够以时间顺序对这些消息进行排序。
5+
在插入数据库之前，我们需要给这些消息/订单先打上一个ID，然后再插入到我们的数据库。对这个id的要求是希望其中能带有一些时间信息，这样即使我们后端的系统对消息进行了分库分表，也能够以时间顺序对这些消息进行排序。
66

7-
Twitter 的 snowflake 算法是这种场景下的一个典型解法。先来看看 snowflake 是怎么一回事：
7+
Twitter的snowflake算法是这种场景下的一个典型解法。先来看看snowflake是怎么一回事：
88

9-
```
10-
datacenter_id sequence_id
11-
unused
12-
│ │
13-
│ │ │
14-
│ │ │
15-
│ │ │ │ │
16-
│ │ │ │ │
17-
▼ │◀────────────────── 41 bits ────────────────────▶│ ▼ ▼
18-
┌─────┼──────────────────────────────────────────────────────┼────────┬────────┬────────────────┐
19-
│ 0 │ 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0 │ 00000 │ 00000 │ 0000 0000 0000 │
20-
└─────┴──────────────────────────────────────────────────────┴────────┴────────┴────────────────┘
21-
▲ ▲
22-
│ │
23-
│ │
24-
│ │
25-
│ │
26-
│ │
27-
│ │
28-
29-
time in milliseconds worker_id
30-
```
9+
![snowflake](../images/ch6-snowflake.png)
3110

32-
首先确定我们的数值是 64 位，int64 类型，被划分为四部分，不含开头的第一个 bit，因为这个 bit 是符号位。用 41 位来表示收到请求时的时间戳，单位为毫秒，然后五位来表示数据中心的 id，然后再五位来表示机器的实例 id，最后是 12 位的循环自增 id(到达 1111 1111 1111 后会归 0)。
11+
首先确定我们的数值是64 位，int64类型，被划分为四部分，不含开头的第一个bit，因为这个bit是符号位。用41位来表示收到请求时的时间戳，单位为毫秒，然后五位来表示数据中心的id，然后再五位来表示机器的实例id，最后是12位的循环自增id(到达 1111 1111 1111 后会归 0)。
3312

34-
这样的机制可以支持我们在同一台机器上，同一毫秒内产生 2 ^ 12 = 4096 条消息。一秒共 409.6w 条消息。从值域上来讲完全够用了。
13+
这样的机制可以支持我们在同一台机器上，同一毫秒内产生`2 ^ 12 = 4096`条消息。一秒共409.6万条消息。从值域上来讲完全够用了。
3514

36-
数据中心 + 实例 id 共有 10 位，可以支持我们每数据中心部署 32 台机器，所有数据中心共 1024 台实例。
15+
数据中心 + 实例id共有10位，可以支持我们每数据中心部署32台机器，所有数据中心共1024台实例。
3716

38-
表示 timestamp 的 41 位，可以支持我们使用 69 年。当然，我们的时间毫秒计数不会真的从 1970 年开始记，那样我们的系统跑到 `2039/9/7 23:47:35` 就不能用了，所以这里的 timestamp 实际上只是相对于某个时间的增量，比如我们的系统上线是 2018-08-01，那么我们可以把这个 timestamp 当作是从 `2018-08-01 00:00:00.000` 的偏移量。
17+
表示timestamp的41位，可以支持我们使用69年。当然，我们的时间毫秒计数不会真的从1970年开始记，那样我们的系统跑到`2039/9/7 23:47:35`就不能用了，所以这里的timestamp实际上只是相对于某个时间的增量，比如我们的系统上线是2018-08-01，那么我们可以把这个timestamp当作是从`2018-08-01 00:00:00.000`的偏移量。
3918

40-
## 6.1.1 worker_id 分配
19+
## 6.1.1 worker_id分配
4120

42-
timestamp，datacenter_id，worker_id 和 sequence_id 这四个字段中，timestamp 和 sequence_id 是由程序在运行期生成的。但 datacenter_id 和 worker_id 需要我们在部署阶段就能够获取得到，并且一旦程序启动之后，就是不可更改的了(想想，如果可以随意更改，可能被不慎修改，造成最终生成的 id 有冲突)。
21+
timestamp，datacenter_id，worker_id和sequence_id这四个字段中，timestamp和 sequence_id是由程序在运行期生成的。但datacenter_id和worker_id需要我们在部署阶段就能够获取得到，并且一旦程序启动之后，就是不可更改的了(想想，如果可以随意更改，可能被不慎修改，造成最终生成的id有冲突)。
4322

44-
一般不同数据中心的机器，会提供对应的获取数据中心id的API，所以 datacenter_id 我们可以在部署阶段轻松地获取到。而 worker_id 是我们逻辑上给机器分配的一个 id，这个要怎么办呢？比较简单的想法是由能够提供这种自增 id 功能的工具来支持，比如 MySQL:
23+
一般不同数据中心的机器，会提供对应的获取数据中心id的API，所以datacenter_id我们可以在部署阶段轻松地获取到。而worker_id是我们逻辑上给机器分配的一个id，这个要怎么办呢？比较简单的想法是由能够提供这种自增id功能的工具来支持，比如MySQL:
4524

4625
```shell
4726
mysql> insert into a (ip) values("10.1.2.101");
@@ -56,25 +35,21 @@ mysql> select last_insert_id();
5635
1 row in set (0.00 sec)
5736
```
5837
59-
从 MySQL 中获取到 worker_id 之后，就把这个 worker_id 直接持久化到本地，以避免每次上线时都需要获取新的 worker_id。让单实例的 worker_id 可以始终保持不变。
38+
从MySQL中获取到worker_id之后，就把这个worker_id直接持久化到本地，以避免每次上线时都需要获取新的worker_id。让单实例的worker_id可以始终保持不变。
6039
61-
当然，使用 MySQL 相当于给我们简单的 id 生成服务增加了一个外部依赖。依赖越多，我们的服务的可运维性就越差。
40+
当然，使用MySQL相当于给我们简单的id生成服务增加了一个外部依赖。依赖越多，我们的服务的可运维性就越差。
6241
63-
考虑到集群中即使有单个 id 生成服务的实例挂了，也就是损失一段时间的一部分 id，所以我们也可以更简单暴力一些，把 worker_id 直接写在 worker 的配置中，上线时，由部署脚本完成 worker_id 字段替换。
42+
考虑到集群中即使有单个id生成服务的实例挂了，也就是损失一段时间的一部分id，所以我们也可以更简单暴力一些，把worker_id直接写在worker的配置中，上线时，由部署脚本完成worker_id字段替换。
6443
6544
## 6.1.2 开源实例
6645
6746
### 6.1.2.1 标准 snowflake 实现
6847
69-
`github.com/bwmarrin/snowflake` 是一个相当轻量化的 snowflake 的 Go 实现。其文档指出：
48+
`github.com/bwmarrin/snowflake` 是一个相当轻量化的snowflake的Go实现。其文档指出：
7049
71-
```
72-
+--------------------------------------------------------------------------+
73-
| 1 Bit Unused | 41 Bit Timestamp | 10 Bit NodeID | 12 Bit Sequence ID |
74-
+--------------------------------------------------------------------------+
75-
```
50+
![ch6-snowflake-easy](../images/ch6-snowflake-easy.png)
7651
77-
和标准的 snowflake 完全一致。使用上比较简单：
52+
和标准的snowflake完全一致。使用上比较简单：
7853
7954
```go
8055
package main
@@ -122,21 +97,17 @@ func main() {
12297
StepBits uint8 = 12
12398
```
12499
125-
Epoch 就是本节开头讲的起始时间，NodeBits 指的是机器编号的位长，StepBits 指的是自增序列的位长。
100+
Epoch 就是本节开头讲的起始时间，NodeBits指的是机器编号的位长，StepBits指的是自增序列的位长。
126101
127102
### 6.1.2.2 sonyflake
128103
129-
sonyflake 是 Sony 公司的一个开源项目，基本思路和 snowflake 差不多，不过位分配上稍有不同：
104+
sonyflake是Sony公司的一个开源项目，基本思路和snowflake差不多，不过位分配上稍有不同：
130105
131-
```
132-
+-----------------------------------------------------------------------------+
133-
| 1 Bit Unused | 39 Bit Timestamp | 8 Bit Sequence ID | 16 Bit Machine ID |
134-
+-----------------------------------------------------------------------------+
135-
```
106+
![sonyflake](../images/ch6-snoyflake.png)
136107
137-
这里的时间只用了 39 个 bit，但时间的单位变成了 10ms，所以理论上比 41 位表示的时间还要久(174 years)。
108+
这里的时间只用了39个bit，但时间的单位变成了10ms，所以理论上比41位表示的时间还要久(174 years)。
138109
139-
Sequence ID 和之前的定义一致，Machine ID 其实就是节点 id。sonyflake 与众不同的地方在于其在启动阶段的 setting 配置：
110+
`Sequence ID`和之前的定义一致，`Machine ID`其实就是节点id。`sonyflake`与众不同的地方在于其在启动阶段的配置参数：
140111
141112
```go
142113
func NewSonyflake(st Settings) *Sonyflake
@@ -152,11 +123,11 @@ type Settings struct {
152123
}
153124
```
154125
155-
StartTime 选项和我们之前的 Epoch 差不多，如果不设置的话，默认是从 `2014-09-01 00:00:00 +0000 UTC` 开始。
126+
StartTime选项和我们之前的Epoch差不多，如果不设置的话，默认是从`2014-09-01 00:00:00 +0000 UTC`开始。
156127
157-
MachineID 可以由用户自定义的函数，如果用户不定义的话，会默认将本机 ip 的低 16 位作为 machine id。
128+
MachineID可以由用户自定义的函数，如果用户不定义的话，会默认将本机IP的低16位作为`machine id`。
158129
159-
CheckMachineID 是由用户提供的检查 MachineID 是否冲突的函数。这里的设计还是比较巧妙的，如果有另外的中心化存储并支持检查重复的存储，那我们就可以按照自己的想法随意定制这个检查 MachineID 是否冲突的逻辑。如果公司有现成的 Redis 集群，那么我们可以很轻松地用 Redis 的 set 来检查冲突。
130+
CheckMachineID是由用户提供的检查MachineID是否冲突的函数。这里的设计还是比较巧妙的，如果有另外的中心化存储并支持检查重复的存储，那我们就可以按照自己的想法随意定制这个检查MachineID是否冲突的逻辑。如果公司有现成的Redis集群，那么我们可以很轻松地用Redis的set来检查冲突。
160131
161132
```shell
162133
redis 127.0.0.1:6379> SADD base64_encoding_of_last16bits MzI0Mgo=

‎images/ch6-snowflake-easy.png‎

5.5 KB
Loading

‎images/ch6-snowflake.png‎

13.2 KB
Loading

‎images/ch6-snoyflake.png‎

5.54 KB
Loading

0 commit comments

Comments
 (0)