图解各路分布式ID生成算法

时间 2019-11-07

标签图解各路分布式生成算法栏目系统架构繁體版

原文原文链接

在分布式系统中，一般会用到分布式ID来标注数据的惟一性，而分布式ID的生成方式又多种多样，今天咱们就来讨论一下主流的分布式ID生成策略。html

分布式ID基本需求

全局惟一
趋势递增
信息安全

全局惟一

这是基本要求，没必要解释git

趋势递增

为何要趋势递增呢？第一，因为咱们的分布式ID，是用来标识数据惟一性的，因此多数时候会被定义为主键或者惟一索引。第二，而且绝大多数互联网公司使用的数据库是：MySQL，存储引擎为innoDB。对于B + Tree这个数据结构来说，数据以自增顺序来写入的话，b+tree的结构不会时常被打乱重塑，存取效率是最高的。github

信息安全

因为数据是递增的，因此，恶意用户的能够根据当前ID推测出下一个，很是危险，因此，咱们的分布式ID尽可能作到不易被破解。算法

数据库主键自增(Flicker)

基于数据库主键自增的方案，名为Flicker。主要是利用MySQL的自增主键来实现分布式ID。数据库

如下为Flicker实现分布式ID的主流作法：segmentfault

一、须要单独创建一个数据库实例：flicker

create database `flicker`;
复制代码

二、建立一张表：sequence_id

create table sequence_id(
    id bigint(20) unsigned NOT NULL auto_increment, 
    stub char(10) NOT NULL default '',
    PRIMARY KEY (id),
    UNIQUE KEY stub (stub)
) ENGINE=MyISAM;
复制代码

为何用MyISAM？不用InnoDB？我的推测缘由是：flicker算法出来的时候，MySQL的默认引擎还依旧是MyISAM而不是InnoDB，做者只是想用默认引擎而已，并没有其余缘由。安全

stub: 票根，对应须要生成 Id 的业务方编码，能够是项目名、表名甚至是服务器 IP 地址。
stub 要设置为惟一索引

三、使用如下SQL来获取ID

REPLACE INTO ticket_center (stub) VALUES ('test');  
SELECT LAST_INSERT_ID();  
复制代码

Replace into 先尝试插入数据到表中，若是发现表中已经有此行数据（根据主键或者惟一索引判断）则先删除此行数据，而后插入新的数据，不然直接插入新数据。通常stub为特殊的相同的值。bash

这样，一个分布式ID系统算是能够搭建运行了。可是，有人要问：“这是一个单实例、单点的系统，万一挂了，岂不是影响全部关联的业务方？”服务器

改进升华

是的。确实如此，所以又有人说：“能够利用MySQL主从模式，主库挂了，使用从库。” 这只能算是一种比较low的策略，由于若是主库挂了，从库没来得及同步，就会生成重复的ID。有没有更好的方法呢？咱们可使用“双主模式“，也就是有两个MySQL实例，这两个都能生成ID。如图所示，咱们原来的模式：微信

双主模式是该怎么样呢？如何保持惟一性？咱们可让一台实例生成奇数ID，另外一台生成偶数ID。

奇数那一台：

set @@auto_increment_offset = 1;     -- 起始值
set @@auto_increment_increment = 2;  -- 步长

复制代码

偶数那一台：

set @@auto_increment_offset = 2;     -- 起始值
set @@auto_increment_increment = 2;  -- 步长

复制代码

当两台都OK的时候，随机取其中的一台生成ID；若其中一台挂了，则取另一台生成ID。如图所示：

细心会发现，N个节点，只要起始值为1，2，...N，而后步长为N，就会生成各不相同的ID。(PS:后文有推导公式)

总结

优势：

简单。充分利用了数据库自增 ID 机制，生成的 ID 有序递增。
ID递增

缺点：

并发量不大。
水平扩展困难，系统定义好了起始值、步长和机器台数，跑起来以后，添加额外的机器困难。
安全系数低

Redis

Redis为单线程的，因此操做为原子操做，利用incrby命令能够生成惟一的递增ID。

原理

单机单点，吞吐不够，加集群

假设N个节点，则步长为N，节点起始值为1，2，…… N。则三个节点生成的ID必定不一样！想一想为何？以上信息条件能够转化为数学推理： 1 + x * N = 2 + y * N 且 x、y、N都为整成数且N不为1，试问等式存不存在？

答：
假设存在在起始值是1的节点上叠加x次以后等于起始值为二、叠加y次的值，
既 “1 + x * N = 2 + y * N” 等式成立
则：
x * N = 1 + y * N
x * N - y * N = 1
(x - y) * N = 1
(x - y) = 1 / N

又由于 x、y都为整成数；
因此x - y 必为整成数；
又由于只有N等于1的时候，1/N才为整成数；
与条件N为1不符合，因此不存在。
复制代码

同理可证1 + x * N = 3 + y * N和2 + x * N = 3 + y * N也是如此。

优势

性能显然高于基于数据库的Flicker方案
ID递增

缺点

水平扩展困难
Redis集群宕机可能会产生重复的id
易破解

UUID

想必这个你们都熟悉。 UUID是通用惟一识别码（Universally Unique Identifier）的缩写，是一种软件建构的标准，亦为开放软件基金会组织在分布式计算环境领域的一部分。

原理

UUID是由一组32位数的16进制数字所构成，是故UUID理论上的总数为16^32 = 2^128，约等于3.4 x 10^38。也就是说若每纳秒产生1兆个UUID，要花100亿年才会将全部UUID用完。

UUID是利用同一时空中的全部机器都是惟一的这一规则来确保惟一性的。

具体外形为：

一般由如下几部分组成：

系统时间
时钟序列
全局惟一的IEEE机器识别，如网卡MAC、机器SN等

生成方式多种多样，业界公认的是五种，分别是uuid1,uuid2,uuid3,uuid4,uuid5。目前使用最普遍的UUID是微软的GUID。

优势

本地生成，性能极佳。无网络消耗
全局惟一

缺点

存储麻烦。16字节128位，一般以36长度的字符串表示，不少场景不适用
一般是字符串，非自增，无序，不利于作主键。每次插入都会对B+tree结构进行修改
破解相对困难，可是也不安全。参考"梅丽莎病毒事件，病毒做者制做的UUID包含Mac地址，被警方破解后，直接定位，抓捕归案😝"

snowflake

snowflake即雪花算法，Twitter发明的。

原理

外形长这样：

1位不用。二进制中最高位为1的都是负数，可是咱们生成的id通常都使用整数，因此这个最高位固定是0。
41位，用来记录毫秒的时间戳。41位能够表示的数值范围是：0 至 2^{41}-1，减1是由于可表示的数值范围是从0开始算的，而不是1，转化为年则是2^{41}-1) / (1000 * 60 * 60 * 24 * 365) = 69年。
10位，用来记录工做机器id。最多能够部署在2^{10} = 1024个节点，咱们能够根据具体的业务来定制具体分配的机器数量和每台机器1毫秒产生的id序号number数。例如能够把10bit分5bit给IDC，分5bit给工做机器。这样就能够表示32个IDC，每一个IDC下能够有32台机器，能够将内容配置在配置文件中，服务去获取。
12位。用来表示单台机器每毫秒生成的id序号，12位bit能够表示的最大正整数为2^12 - 1 = 4096，若超过4096，则从新从0开始。即，每台机器1毫秒内最多产生4096个ID，足够用了。

最后将上述4段bit经过位运算拼接起来组成64位bit. 因为是64位bit,因此彻底能够用数字来表示ID。

基本是根据：

优势

ID为数字且时间位在高位，整个ID都是趋势递增的。
不依赖任何第三方库，彻底能够本身写，且性能很是高。
可根据业务定制分配bit位，很是灵活。得益于10位机器IDbit位。
不太容易破解

缺点

依赖机器的时间，若是机器时间不许或者回拨，可能致使重复

总结

在国内也获得了比较广泛的应用，各大厂根据其基本原理，生成了本身的规则：

百度的uid-generator：github.com/baidu/uid-g…
美团Leaf：github.com/zhuzhong/id…

请关注个人微信公众号 `互联网技术窝`，问题直接在公众号内留言便可

参考文献： [flicker算法原文] code.flickr.com/blog/2010/0…

[分布式惟一ID极简教程] mp.weixin.qq.com/s/cqIK5Bv1U…

[分布式 ID 生成策略] mp.weixin.qq.com/s/UAvSUDFJ8…

[分布式ID系列（2）——UUID适合作分布式ID吗] mp.weixin.qq.com/s/kZAnYz_Jj…

segmentfault.com/a/119000001…

juejin.im/post/5d6fc8…