分布式ID

分布式ID

在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识。

特点

• 全局唯一性：不能出现重复的ID号，既然是唯一标识，这是最基本的要求。
• 趋势递增：在MySQL InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。
• 单调递增：保证下一个ID一定大于上一个ID，例如事务版本号、IM增量消息、排序等特殊需求。
• 信息安全：如果ID是连续的，恶意用户的扒取工作就非常容易做了，直接按照顺序下载指定URL即可；如果是订单号就更危险了，竞对可以直接知道我们一天的单量。所以在一些应用场景下，会需要ID无规则、不规则。

条件

• 平均延迟和TP999延迟都要尽可能低。
• 可用性5个9。
• 高QPS。

常用方案

一、 UUID

1.1.1 实现方式

1.1.2 优劣势

优点：

• 性能非常高：本地生成，没有网络消耗。

缺点：

• 不易于存储：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。
• 信息不安全：基于MAC地址生成UUID的算法可能会造成MAC地址泄露，这个漏洞曾被用于寻找梅丽莎病毒的制作者位置。
• ID作为主键时在特定的环境会存在一些问题，比如做DB主键的场景下，UUID就非常不适用。
  • MySQL官方有明确的建议主键要尽量越短越好，36个字符长度的UUID不符合要求。
  • 对MySQL索引不利：如果作为数据库主键，在InnoDB引擎下，UUID的无序性可能会引起数据位置频繁变动，严重影响性能。

二、 类snowflake方案

这种方案大致来说是一种以划分命名空间来生成ID的一种算法

2.1.1 实现方式

图示：

​

1-bit的时间可以表示（1L<<41）/(1000L360024*365)=69年的时间，10-bit机器可以分别表示1024台机器。

2.1.2 优劣势

优点：

• 毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。
• 不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。
• 可以根据自身业务特性分配bit位，非常灵活。

缺点：

• 强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。

三、 数据库生成

3.1.1 实现方式

数据库主键自增模式

图示：