分布式ID生成器_架构师之路 - (EPUB全文下载)

文件大小：0.05 mb。
文件格式：epub 格式。
书籍内容：

分布式ID生成器 | 架构师之路
一、需求缘起
几乎所有的业务系统，都有生成一个唯一记录标识的需求
，例如：
消息标识：
message-id
订单标识：
order-id
帖子标识：
tiezi-id
这个记录标识往往就是数据库中的
主键

，数据库上会建立聚集索引
（
cluster index），即在物理存储上以这个字段排序。
 
这个记录标识上的查询，往往又有分页或者排序的业务需求
，例如：
拉取最新的一页消息
select message-id/ order by time/ limit 100
拉取最新的一页订单
select order-id/ order by time/ limit 100
拉取最新的一页帖子
select tiezi-id/ order by time/ limit 100
所以往往要有一个
time字段，并且在
time字段上建立普通索引
（
non-cluster index）。
 
普通索引存储的是实际记录的指针，其访问效率会比聚集索引慢，如果记录标识在生成时能够基本按照时间有序，则可以省去这个
time字段的索引查询：
select message-id/ (order by message-id)/limit 100
强调，能这么做的前提是，
message-id的生成基本是
趋势时间递增的

。
 
这就引出了记录标识生成（也就是上文提到的三个
XXX-id）的两大核心需求：
全局唯一
趋势有序
这也是本文要讨论的核心问题：
如何高效生成趋势有序的全局唯一
ID。
 
二、常见方法、不足与优化
方法一：使用数据库的 
auto_increment 
来生成全局唯一递增
ID
优点：
简单，使用数据库已有的功能
能够保证唯一性
能够保证递增性
步长固定
缺点：
可用性难以保证：数据库常见架构是一主多从
+读写分离，生成自增
ID是写请求，主库挂了就玩不转了
扩展性差，性能有上限：因为写入是单点，数据库主库的写性能决定
ID的生成性能上限，并且难以扩展
改进方法：
冗余主库，避免写入单点
数据水平切分，保证各主库生成的
ID不重复
如上图所述，由
1
个写库变成
3
个写库，
每个写库设置不同的
auto_increment
初始值，以及相同的增长步长
，以保证每个数据库生成的
ID
是不同的（上图中库
0
生成
0,3,6,9…
，库
1
生成
1,4,7,10
，库
2
生成
2,5,8,11…
）
改进后的架构保证了可用性，但缺点
是：
丧失了
ID
生成的“绝对递增性”
：先访问库
0
生成
0,3
，再访问库
1
生成
1
，可能导致在非常短的时间内，
ID
生成不是绝对递增的（这个问题不大，目标是趋势递增，不是绝对递增）
数据库的写压力依然很大
，每次生成
ID都要访问数据库
为了解决上述两个问题，引出了第二个常见的方案。
 
方法二：单点批量
ID生成服务
分布式系统之所以难，很重要的原因之一是“没有一个全局时钟，难以保证绝对的时序”，要想保证绝对的时序，还是只能使用单点服务，用本地时钟保证“绝对时序”。
数据库写压力大，是因为每次生成
ID都访问了数据库，可以使用批量的方式降低数据库写压力
。
如上图所述，数据库使用双
master
保证可用性，
数据库中只存储当前
ID
的最大值
，例如
0
。
ID
生成服务假设每次批量拉取
6
个
ID
，服务访问数据库，将当前
ID
的最大值修改为
5
，这样应用访问
ID
生成服务索要
ID
，
ID
生成服务不需要每次访问数据库，就能依次派发
0,1,2,3,4,5
这些
ID
了。
当
ID
发完后，再将
ID
的最大值修改为
11
，就能再次派发
6,7,8,9,10,11
这些
ID
了，于是数据库的压力就降低到原来的
1/6
。
优点
：
保证了
ID生成的绝对递增有序
大大的降低了数据库的压力，
ID生成可以做到每秒生成几万几十万个
缺点
：
服务仍然是单点
如果服务挂了，服务重启起来之后，继续
生成
ID可能会不连续，中间出现空洞
（服务内存是保存着
0,1,2,3,4,5，数据库中
max-id是
5，分配到
3时，服务重启了，下次会从
6开始分配，
4和
5就成了空洞，不过这个问题也不大）
虽然每秒可以生成几万几十万个
ID，但毕竟还是有性能上限，无法进行水平扩展
改进方法
：
单点服务的常用高可用优化方案是“备用服务”，也叫“影子服务”
，所以我们能用以下方法优化上述缺点（
1）：
如上图，对外提供的服务是主服务，有一个影子服务时刻处于备用状态，当主服务挂了的时候影子服务顶上。
这个切换的过程对调用方是透明的，可以自动完成，常用的技术是
vip+keepalived
，具体就不在这里展开。
另外，ID-gen-service也可以实施水平扩展，以解决上述缺点（3），但会引发一致性问题，具体解决方案详见《浅谈CAS在分布式ID生成方案上的应用
》。
 
方法三：
uuid/guid
不管是通过数据库，还是通过服务来生成
ID，业务方
Application都需要进行一次远程调用，比较耗时。
有没有一种本地生成
ID的方法，即高性能，又时延低呢？
uuid是一种常见的方案：
string ID =GenUUID();
优点
：
本地生成
ID，不需要进行远程调用，时延低
扩展性好，基本可以认为没有性能上限
缺点
：
无法保证趋势递增
uuid过长，往往用字符串表示，作为主键建立索引查询效率低
，常见优化方案为
“转化为两个
uint64整数存储
”或者
“折半存储
”（折半后不能保证唯一性）
 
方法四：取当前毫秒数
uuid是一个本地算法，生成性能高，但无法保证趋势递增，且作为字符串
I ............

书籍插图：

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。