分布式唯一id

1 背景

目前的系统中，有很多业务需要对数据进行唯一标识（订单号、用户券码、事件id等），系统对id号往往有以下几点要求：

• 全局唯一。不能出现重复的id号，这是基本的要求
• 趋势递增。为了保证mysql聚集索引性能，尽量保证有序性
• 非连续。数据不能是连续的，例如券的id是连续的，有可能被恶意请求领券；并且可以让外界知道一天的数据量

2 方案

2.1 uuid

uuid是大部分人第一个接触的唯一id生成方式。共包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符

优点：

• 性能高，本地直接生成，没有网络消耗
  缺点：
• uuid过长，作为主键性能太差
• 生成为字符串，很多场景需要使用long类型

2.2 雪花算法

image.png

• 1bit，不用，因为二进制中最高位是符号位，1表示负数，0表示正数。生成的id一般都是用整数，所以最高位固定为0。
• 41bit-时间戳，用来记录时间戳，毫秒级。
• 10bit-工作机器id，用来记录工作机器id。
• 12bit-序列号，序列号，用来记录同毫秒内产生的不同id。

由于在Java中64bit的整数是long类型，所以在Java中SnowFlake算法生成的id就是long来存储的。

转自：https://segmentfault.com/a/1190000011282426

public class IdWorker{

    //下面两个每个5位，加起来就是10位的工作机器id
    private long workerId;    //工作id
    private long datacenterId;   //数据id
    //12位的序列号
    private long sequence;

    public IdWorker(long workerId, long datacenterId, long sequence){
        // sanity check for workerId
        if (workerId > maxWorkerId || workerId < 0) {
            throw new IllegalArgumentException(String.format("worker Id can't be greater than %d or less than 0",maxWorkerId));
        }
        if (datacenterId > maxDatacenterId || datacenterId < 0) {
            throw new IllegalArgumentException(String.format("datacenter Id can't be greater than %d or less than 0",maxDatacenterId));
        }
        System.out.printf("worker starting. timestamp left shift %d, datacenter id bits %d, worker id bits %d, sequence bits %d, workerid %d",
                timestampLeftShift, datacenterIdBits, workerIdBits, sequenceBits, workerId);

        this.workerId = workerId;
        this.datacenterId = datacenterId;
        this.sequence = sequence;
    }

    //初始时间戳
    private long twepoch = 1288834974657L;

    //长度为5位
    private long workerIdBits = 5L;
    private long datacenterIdBits = 5L;
    //最大值
    private long maxWorkerId = -1L ^ (-1L << workerIdBits);
    private long maxDatacenterId = -1L ^ (-1L << datacenterIdBits);
    //序列号id长度
    private long sequenceBits = 12L;
    //序列号最大值
    private long sequenceMask = -1L ^ (-1L << sequenceBits);
    
    //工作id需要左移的位数，12位
    private long workerIdShift = sequenceBits;
   //数据id需要左移位数 12+5=17位
    private long datacenterIdShift = sequenceBits + workerIdBits;
    //时间戳需要左移位数 12+5+5=22位
    private long timestampLeftShift = sequenceBits + workerIdBits + datacenterIdBits;
    
    //上次时间戳，初始值为负数
    private long lastTimestamp = -1L;

    public long getWorkerId(){
        return workerId;
    }

    public long getDatacenterId(){
        return datacenterId;
    }

    public long getTimestamp(){
        return System.currentTimeMillis();
    }

     //下一个ID生成算法
    public synchronized long nextId() {
        long timestamp = timeGen();

        //获取当前时间戳如果小于上次时间戳，则表示时间戳获取出现异常
        if (timestamp < lastTimestamp) {
            System.err.printf("clock is moving backwards.  Rejecting requests until %d.", lastTimestamp);
            throw new RuntimeException(String.format("Clock moved backwards.  Refusing to generate id for %d milliseconds",
                    lastTimestamp - timestamp));
        }

        //获取当前时间戳如果等于上次时间戳（同一毫秒内），则在序列号加一；否则序列号赋值为0，从0开始。
        if (lastTimestamp == timestamp) {
            sequence = (sequence + 1) & sequenceMask;
            if (sequence == 0) {
                timestamp = tilNextMillis(lastTimestamp);
            }
        } else {
            sequence = 0;
        }
        
        //将上次时间戳值刷新
        lastTimestamp = timestamp;

        /**
          * 返回结果：
          * (timestamp - twepoch) << timestampLeftShift) 表示将时间戳减去初始时间戳，再左移相应位数
          * (datacenterId << datacenterIdShift) 表示将数据id左移相应位数
          * (workerId << workerIdShift) 表示将工作id左移相应位数
          * | 是按位或运算符，例如：x | y，只有当x，y都为0的时候结果才为0，其它情况结果都为1。
          * 因为个部分只有相应位上的值有意义，其它位上都是0，所以将各部分的值进行 | 运算就能得到最终拼接好的id
        */
        return ((timestamp - twepoch) << timestampLeftShift) |
                (datacenterId << datacenterIdShift) |
                (workerId << workerIdShift) |
                sequence;
    }

    //获取时间戳，并与上次时间戳比较
    private long tilNextMillis(long lastTimestamp) {
        long timestamp = timeGen();
        while (timestamp <= lastTimestamp) {
            timestamp = timeGen();
        }
        return timestamp;
    }

    //获取系统时间戳
    private long timeGen(){
        return System.currentTimeMillis();
    }

    //---------------测试---------------
    public static void main(String[] args) {
        IdWorker worker = new IdWorker(1,1,1);
        for (int i = 0; i < 30; i++) {
            System.out.println(worker.nextId());
        }
    }

}

优点：

• 毫秒数在高位，保证了递增趋势
• 不依赖第三方，性能很高

缺点：

• 强依赖于时钟，如果时钟回拨会造成重复

2.3 MySQL

给数据库主键设置 auto_increment_increment保证自增，每次需要获取唯一id时访问数据库即可
优点：

• 简单，不需要引入额外的技术

缺点：

• 数据库有单点故障，数据库宕机导致获取分布式id的服务不可用
• 每次获取都需要访问数据库，容易产生性能瓶颈

2.4 leaf

leaf是美团自研的分布式id服务，有Leaf-segment和Leaf-snowflake两种类型。分别弥补了MySQL和snowflake各自的缺点

2.4.1 Leaf-segment

Leaf-segment在mysql的基础上，解决了每次获取都需要访问mysql的弊端。改为每次获取一段数据，大大减少了访问数据库的频率。 image.png

同时，为了解决leaf服务同时访问数据库而造成的数据库压力过大，对 Leaf-segment做了些优化，采用双buffer的方式，Leaf服务内部有两个号段缓存区segment。当前号段已下发10%时，如果下一个号段未更新，则另启一个更新线程去更新下一个号段。当前号段全部下发完后，如果下个号段准备好了则切换到下个号段为当前segment接着下发，循环往复。

除此之外，Leaf-segment采用了类似于拥塞控制的思路，根据服务获取段的时间差，来控制步长。时间差短，步长增加；时间差长，减少步长。但是增大或减少都不会超过设定的阈值。

优点：

• leaf服务有一段缓存，即使数据库不可用，在一段时间内也可以提供服务

缺点：

• DB宕机会造成整个系统不可用。
• id不够随机

2.4.1 Leaf-snowflake

Leaf-snowflake是在snowflake的基础上进行了改进，避免的时间回拨造成的id重复。为了方便管理和配置，使用zk管理和分配workId，同时服务启动后将workId进行本地缓存，从而保证弱依赖zk。

• 启动Leaf-snowflake服务，连接Zookeeper，在leaf_forever父节点下检查自己是否已经注册过（是否有该顺序子节点）。
• 如果有注册过直接取回自己的workerID（zk顺序节点生成的int类型ID号），启动服务。
• 如果没有注册过，就在该父节点下面创建一个持久顺序节点，创建成功后取回顺序号当做自己的workerID号，启动服务。

解决时钟问题：

image.png

• 思路是保证zk上保存的时间是相对准确的，和zk上的时间进行对比，如果超过阈值就失败并报警。保证了时间回拨不会造成影响
• 如果节点是新的，则和其他节点的平均时间进行对比，如果超过阈值则失败
• 如果节点是旧的，则和该节点上次的时间进行比较，如果小于了上次的时间，则说明发生了时间回拨，失败并报警。
• 每隔3秒上传自己的时间到zk

转自：https://tech.meituan.com/2017/04/21/mt-leaf.html