设计思想赏析-分布式id生成算法-雪花算法

唯一ID怎么生成？

在数据库的使用中，根据第二范式的设计准则：数据库中的每行必须可以被唯一的区分，因此我们经常需要生成唯一id。在RDBMS（关系数据库管理系统）时代，数据库提供序列生成器，例如oracle的sequence，mysql的increment自增长字段等。RDBMS是中心化环境（单机环境），全局唯一只需要当前机器自己说了算就行；但是在分布式环境（去中心化）下，多台主机并存，如何让他们自动生成全局不会重复的id呢？

主要的解决方案有以下两类

方法一：仍然采用中心化的思路

    在RDBMS中预生成一批序列，分布式环境中的每个节点启动时到RDBMS中获取一个号段，各自使用。美团leaf的Segment模式就属于此类型。

方法二：采用去中心化的思想

    约定一个规则，分布式环境中的每个节点自己生成全局唯一的id即可。UUID、GUID、雪花算法都属于此类情况。

❉❉❉❉❉❉雪花算法❉❉❉❉❉❉

雪花算法是由Twitter开源的，设定64个bit【思考：为什么是64位？】，由首位、时间戳、机器id和自增序列四部分组成。

• 首位，1个bit，固定为0；【思考：为什么首位为0？】

• 时间戳，41个bit，当前时间与指定日期的毫秒级时间差；【思考：为什么是时间差？】

• 集群节点id，10个bit，最多2^10，共计1024台机器；

• 自增序列，12个bit，最多2^12，共计4096个id。

天下没有两片相同的雪花

     每个节点在生成id时，会因为时间戳和自增序列的不同，生成的id局部唯一；加上集群节点id，自然就做到了全局唯一，因此雪花算法做到了“天下没有两片相同的雪花”的目的。

     同时，时间戳按毫秒计，每毫秒最多可支持4096个id，因此，每个节点每秒可生成4096000个id，且生成的id在(2^41-1)/86400/365/1000=69年之后才会超出41位，应对多大的量都够用了。

设计核心

1、  循环使用的自增id，保证某个时间内局部唯一；

2、毫秒级时间戳，提供秒级生成大量id，应对高请求；

3、集群节点id，保证全局唯一。

      设计思想明白了，就可以进行相应改良。例如百度的集群已经超过1024台了，那该怎么办？

      百度对雪花算法进行了调整，他的uid是1bit首位+28bit时间戳+22bit机器id+13bit序列号。所以百度uid支持2^22=4194304个节点，每个节点每个秒可生成2^13=8192个id。但是时间戳变短了，只能支持到秒级，所以这个算法生成的id，在(2^28-1)/86400/365=8.5年之后就会超出28bit的长度。