分布式全局唯一ID解决方案（雪花算法）

---

---

为什么需要分布式全局唯一ID以及分布式ID的业务需求

在复杂分布式系统中，往往需要对大量的数据和消息进行唯一标识
如在美团点评的金融、支付、餐饮、酒店;
猫眼电影等产品的系统中数据日渐增长，对数据分库分表后需要有一个唯一ID来标识一条数据或消息;
此时一个能够生成全局唯一ID的系统是非常必要的。

---

---

为什么无序的UUID会导致入库性能变差呢?

1. 无序，无法预测他的生成顺序，不能生成递增有序的数字。
   首先分布式id一般都会作为主键，但是安装mysql官方推荐主键要尽量越短越好，UUID每一个都很长，所以不是很推荐。
2. 主键，ID作为主键时在特定的环境会存在一些问题。
   比如做DB主键的场景下，UUID就非常不适用MySQL官方有明确的建议主键要尽量越短越好36个字符长度的UUID不符合要求
3. 索引，B+树索引的分裂
   既然分布式id是主键，然后主键是包含索引的，然后mysql的索引是通过b+树来实现的，每一次新的UUID数据的插入，为了查询的优化，都会对索引底层的b+树进行修改，因为UUID数据是无序的，所以每一次UUID数据的插入都会对主键地跋的b+材进行很大的修改，这一点很不好。插入完全无序，不但会导致一些中间节点产生分裂，也会白白创造出很多不饱和的节点，这样大大降低了数据库插入的性能。

---

---

数据库自增ID机制适合作分布式ID吗

答案是不太适合

1. 系统水平扩展比较困难，比如定义好了步长和机器台数之后，如果要添加机器该怎么做?假设现在只有一台机器发号是1,2,3.4.5（步长是1)，这个时候需要扩容机器一台。可以这样做:把第二台机器的初始值设置待比第一台超过很多，貌似还好，现在想象一下如果我们线上有100台机器，这个时候要扩容该怎么做?简直是噩梦。所以系统水平扩展方案复杂难以实现。
2. 数据库压力还是很大，每次获取ID都得读写一次数据库，非常影响性能，不符合分布式ID里面的延迟低和要高QPS的规则(在高并发下，如果都去数据库里面获取id，那是非常影响性能的)

---

---

Redis集群实现分布式ID的利弊

实现方式：

注意:在Redis集群情况下，同样和MySQL一样需要设置不同的增长步长，同时key一定要设置有效期

可以使用Redis集群来获取更高的吞吐量。
假如一个集群中有5台Redis。可以初始化每台Redis的值分别是1,2,3,4,5，然后步长都是5。

各个Redis生成的ID为:

A:1,6,11,16,21
B:2,7,12,17,22
c:3,8,13,18,23
D:4,9,14,19,24
E:5,10,15,20,25

缺点：

维护Redis集群太麻烦，仅仅为了一个全局唯一id，性价比不高。

---

---

雪花算法(SonwFlake)

Twitter的分布式雪花算法 SnowFlake，经测试snowflake每秒能够产生26万个自增可排序的ID

1. twitter的SnowFlake生成ID能够按照时间有序生成
2. SnowFlake算法生成id的结果是一个64bit大小的整数，为一个Long型(转换成字符串后长度最多19)。
3. 分布式系统内不会产生ID碰撞（由datacenter和workerld作区分）并且效率较高。

雪花算法的几个核心组成部分:

号段解析:

1bit，

• 不用，因为二进制中最高位是符号位，1表示负数，0表示正数。生成的id一般都是用整数，所以最高位固定为0。

41bit-时间戳，用来记录时间戳，毫秒级。

• 41位可以表示2^[41]-1个数字，
• 如果只用来表示正整数〈计算机中正数包含0)，可以表示的数值范围是:O至2^[41]-1，减1是因为可表示的数值范围是从O开始算的，而不是1。
• 也就是说41位可以表示2^[41]-1个毫秒的值，转化成单位年则是(2^[41]-1)/(1000*60*60*24 *365)=69年

10bit-工作机器id，用来记录工作机器id。

• 可以部署在2[10]= 1024个节点，包括5位datacenterld和5位workerld
• 5位(bit〉可以表示的最大正整数是2[5]-1=31,-即可以用0、1、2、3、.…31这32个数字，来表示不同的datecenterld或workerld

12bit-序列号，序列号，用来记录同毫秒内产生的不同id。

• 12位.(bit)可以表示的最大正整数是2[12]-1=4095，即可以用0、1、2、3、…4094这4095个数字，来表示同一机器同一时间截(毫秒)内产生的4095个ID序号。

所以综上，雪花算法可以保证：

• 所有生成的id按时间趋势递增
• 整个分布式系统内不会产生重复id(因为有datacenterld和workerld来做区分)

使用糊涂工具包实现

import cn.hutool.core.lang.Snowflake;
import cn.hutool.core.net.NetUtil;
import cn.hutool.core.util.IdUtil;
import lombok.extern.slf4j.Slf4j;
import javax.annotation.PostConstruct;

@Slf4j
public class IdGeneratorSnowFlake {

    // 取值范围0到31
    private long workerId = 0;

    // 取值范围0到31 指定机房号，可以放到配置文件中读取
    private long datacenterId = 0;

    private Snowflake snowflake = IdUtil.createSnowflake(workerId, datacenterId);

    @PostConstruct
    public void init(){
        try {
            workerId = NetUtil.ipv4ToLong(NetUtil.getLocalhostStr());
            log.info("当前机器的workerid：{}", workerId);
        }catch (Exception e){
            e.printStackTrace();
            log.warn("当前机器的workerId", e);
        }
    }

    public synchronized long snowflakeId(){
        return snowflake.nextId();
    }

    public synchronized long snowflakeId(long workerId, long datacenterId){
        Snowflake snowflake = IdUtil.createSnowflake(workerId, datacenterId);
        return snowflake.nextId();
    }

}

雪花算法优缺点：

优点:

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

缺点:

• 依赖机器时钟，如果机器时钟回拨，会导致重复ID生成
• 在单机上是递增的，但是由于设计到分布式环境，每台机器上的时钟不可能完全同步，有时候会出现不是全局递增的情况
  (此缺点可以认为无所谓，一般分布式ID只要求趋势递增，并不会严格要求递增，90%的需求都只要求趋势递增)