分布式id解决方案

最近在做分布式任务调度系统，遇到分布式id的问题，我们需要一个全局唯一的id，但是服务又部署在多台服务器上面。因为之前没有什么分布式系统的经验，想当然的就是用了全局分布式锁来保证id的唯一性。后来小组周会，经领导一点拨，突然想起之前看过的一些分布式id解决方案(所以说知识需要不断巩固实践以及复习，不然全忘光了- -)。其实网上的分布式id的文章也很多了，但是为了让自己理解更加深刻，决定专门写一篇博客来记录一下这些分布式id的解决方案。

一、UUID

UUID 是 通用唯一识别码（Universally Unique Identifier）的缩写，在一个机器上生成的UUID，可以保证在同一个时空下都是唯一的。UUID的生成主要和以太网卡地址、纳秒级时间、芯片ID码和许多可能的数字有关，可以保证绝对唯一，完全满足分布式id的唯一性原则。

java实现
String id = UUID.randomUUID().toString();
优点
  1. 实现简单，不依赖第三方组件，,java语言就自带了uuid的实现
  2. 性能高，在单机上通过算法直接生成，速度非常快
  3. 全球唯一
缺点
  1. 生成的id是36个字符的字符串，占用空间太大，不适合用在数据库主键上面，也不适合作为索引字段
  2. 由于是字符串，不适用于需要id自增的场景，也不能用来排序

二、数据库自增长序列

先给某个字段设置为自增长，然后每次插入一条记录并获取最新的id。

mysql实现

先创建一张表 test

create table test(
id int auto_increment,
name varchar(8),
PRIMARY KEY (`id`)
)

每次要获取id使用以下语句

begin;
REPLACE INTO test (NAME) VALUES ('a');
SELECT LAST_INSERT_ID();
commit;
优点
  1. 实现简单，直接利用数据库语句就可以了
  2. 全局id单调递增,适合对id有特殊要求的业务
缺点
  1. 每次获取id都要进行一次IO，性能较差
  2. 高并发场景下性能也比较差
  3. 重度依赖于DB，如果DB挂了，那么获取id的功能就完全不能用了
  4. 每个业务都需要用到一张表，扩展非常不方便

三、数据库分段获取id

第二种方案每次都要去数据库获取id，这就意味着频繁的IO操作造成了性能的瓶颈。所以就有人想出了优化方案，也就是提前把一个号码段从数据库中取出来放到内存中，之后拿到号码段的进程再慢慢消耗这些号码段，再去数据库中获取新的号码段，这样就大大的减少了IO次数。

mysql实现方案
create table test2(
id int auto_increment,
tag varchar(255) comment '用来表示业务',
max_id int comment '表示当前已取走的最大id',
step int comment '表示一次取多长的号段',
PRIMARY KEY (`id`)
);

之后用以下sql语句获取号段

Begin;
UPDATE test2 SET max_id=max_id+step WHERE tag='test';
SELECT tag,max_id,step from test2 WHERE tag='test';
Commit;

这样进程就拿到了step个号在进程中使用。

优点

  1. 所有的业务用一张表就可以实现，扩展方便
  2. 满足id递增的需求
  3. 有一定的容灾能力，假如DB挂掉了，缓存的号码段还能用一段时间
  4. 可以自定义max_id,方便业务从其他地方迁移过来
缺点
  1. 在号段用完时会进行一次IO获取新的号段，所以在性能曲线上会尖刺
  2. 还是依赖于DB，如果DB长时间挂了就无法工作了
  3. 号码段不够随机，这也是所有id自增方案的风险。竞争对手很可能通过id来推断一天的数据量。
  4. 实现稍微麻烦写，现实使用中还要考虑持久化号段使用情况信息，也就是记录下当前使用到了哪里，以便重启后可以继续使用该号段，避免号码的浪费
优化方案
  1. 针对缺点1，我们可以使用双号段缓存，当一个号段用完马上可以使用第二个，同时开启一个异步线程再去获取一个号段，保证系统同时维护两个号段
  2. 针对缺点2，可以做一些mysql主备方案来应对

四、snowflake

snowflake是Twitter开源的分布式ID生成算法，结果是一个long型的ID。其核心思想是：使用41bit作为毫秒数，10bit作为机器的ID（5个bit是数据中心，5个bit的机器ID），12bit作为毫秒内的流水号（意味着每个节点在每毫秒可以产生 4096 个 ID），最后还有一个符号位，永远是0。

java实现

/**
 * @author yangjb
 * @since 2018-07-26 20:22
 * <p>
 * snowflake分布式id生成器
 * 最高位在long中表示符号位，id一般都是正数，所以第一位默认都用0表示
 * 接下来的41位表示时间戳,注意，这里的时间戳不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截)
 * 得到的值），这里的的开始时间截，一般是我们的id生成器开始使用的时间，由我们程序来指定的（如下下面程序类的TWEPOCH属性）。41位的时间截，可以使用69年
 * 10位的数据机器位，可以部署在1024个节点，包括5位datacenterId和5位workerId
 * 12位序列号，在同一个毫秒同一个机器内，可以产生4096个ID序号使用
 * 1+41+10+12 = 64，也就是一个long类型的长度。当然，不一定要严格使用这样的分配来计算id，比如比如机器较少，可以把机器的10位切割出几位出来给序列号使用等等
 */
public class IdGenerator {

    //id生成器的开始使用时间
    private final static long TWEPOCH = 1288834974657L;

    // 机器标识位数
    private final static long WORKER_ID_BITS = 5L;
    // 数据中心标识位数
    private final static long DATA_CENTER_ID_BITS = 5L;
    // 机器ID最大值 31
    private final static long MAX_WORKER_ID = -1L ^ (-1L << WORKER_ID_BITS);
    // 数据中心ID最大值 31
    private final static long MAX_DATA_CENTER_ID = -1L ^ (-1L << DATA_CENTER_ID_BITS);
    // 毫秒内自增位
    private final static long SEQUENCE_BITS = 12L;
    // 机器ID偏左移12位
    private final static long WORKER_ID_SHIFT = SEQUENCE_BITS;
    private final static long DATA_CENTER_ID_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS;
    // 时间毫秒左移22位
    private final static long TIMESTAMP_LEFT_SHIFT = SEQUENCE_BITS + WORKER_ID_BITS + DATA_CENTER_ID_BITS;
    private final static long SEQUENCE_MASK = -1L ^ (-1L << SEQUENCE_BITS);
    private long lastTimestamp = -1L;
    private long sequence = 0L;
    private final long workerId;
    private final long dataCenterId;

    IdGenerator(long workerId, long dataCenterId) {
        if (workerId > MAX_WORKER_ID || workerId < 0) {
            throw new IllegalArgumentException(String.format("%s must range from %d to %d", workerId, 0,
                    MAX_WORKER_ID));
        }

        if (dataCenterId > MAX_DATA_CENTER_ID || dataCenterId < 0) {
            throw new IllegalArgumentException(String.format("%s must range from %d to %d", dataCenterId, 0,
                    MAX_DATA_CENTER_ID));
        }

        this.workerId = workerId;
        this.dataCenterId = dataCenterId;
    }

    synchronized long nextValue() {
        long timestamp = time();
        if (timestamp < lastTimestamp) {
            throw new RuntimeException("Clock moved backwards, refuse to generate id for "
                    + (lastTimestamp - timestamp) + " milliseconds");
        }

        if (lastTimestamp == timestamp) {
            // 当前毫秒内，则+1
            sequence = (sequence + 1) & SEQUENCE_MASK;
            if (sequence == 0) {
                // 当前毫秒内计数满了，则等待下一秒
                timestamp = untilNextMillis(lastTimestamp);
            }
        } else {
            sequence = 0;
        }
        lastTimestamp = timestamp;

        // ID偏移组合生成最终的ID，并返回ID
        return ((timestamp - TWEPOCH) << TIMESTAMP_LEFT_SHIFT)
                | (dataCenterId << DATA_CENTER_ID_SHIFT) | (workerId << WORKER_ID_SHIFT) | sequence;
    }

    private long untilNextMillis(final long lastTimestamp) {
        long timestamp = this.time();
        while (timestamp <= lastTimestamp) {
            timestamp = this.time();
        }
        return timestamp;
    }

    private long time() {
        return System.currentTimeMillis();
    }

    public static void main(String[] args) throws ParseException {
        long id = new IdGenerator(1, 1).nextValue();
        System.out.println(Long.toBinaryString(id));
    }
}
优点
  1. id是递增的，且数值随机，安全性较高
  2. 性能高，直接在单机上通过算法计算出来,不用跨网络跨IO
  3. 不用依赖第三方组件，健壮性好
  4. 根据业务特性分配bit位，非常灵活
缺点
  1. 强依赖于系统时钟，如果出现机器时间回拨，可能造成id重复的问题
优化 和 使用注意点

使用snowflake最需要防止由于系统时钟回拨导致的id重复问题。上面的java实现方案中有做一些简单的时间戳检查来防止大幅度的系统时钟回拨，但是也没有彻底的解决时钟回拨问题。由于lastTimestamp变量是存储在内存的，一旦程序关闭，就失去了这个值，所以最好的方案还是需要定时的把lastTimestamp持久化起来。可以考虑利用zk的节点时间来记录这个lastTimestamp。

另外提一句，MongoDB的objectId也是用类snowflake的方案来生成id的。objectId由12个字节组成，4个字节表示秒级时间戳，3个字节表示机器id，2个字节表示pid，最后3个字节表示自增序列。也就是表示，在同一秒同一台机器的同一个进程内，可以产生4096个id。
objectId最终标识成一个24长度的十六进制字符。

五、redis incr命令实现id自增

使用redis的incr命令可以很简单的实现id的自增，并保证全局id唯一。

redis语句

每次要获取id，只要执行以下语句

incr test
优点
  1. 实现简单，直接执行redis的一个命令就可以获取到id
  2. 性能较高，redis是内存型数据库，获取id时不需要经过io，速度很快
  3. 获取的id是递增的，可以满足对id有要求的场景
缺点
  1. 重度依赖于redis，假如redis挂了，系统也就不能正常运行了
  2. 同样由于id是自增的，有暴露自己业务数据量的风险

总结

可以说除了第二种方案，其他各个分布式id解决方案都各自有各自的使用场景，也不能一概而论的说哪种方案是最好的。没有最好的方案，只有最适合的方案。当我们需要用到分布式id的时候，应该要先考虑好使用场景，之后分析各个分布式id解决方案各自的优缺点，综合考虑后再决定使用哪种方案。

本人的CSDN博客地址:
https://blog.csdn.net/u013332124/article/details/81234125

美团的leaf解决方案:
https://tech.meituan.com/MT_Leaf.html?utm_source=tool.lu

最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
  • 人面猴
    序言：七十年代末，一起剥皮案震惊了整个滨河市，随后出现的几起案子，更是在滨河造成了极大的恐慌，老刑警刘岩，带你破解...
    沈念sama阅读 204,793评论 6赞 478
  • 死咒
    序言：滨河连续发生了三起死亡事件，死亡现场离奇诡异，居然都是意外死亡，警方通过查阅死者的电脑和手机，发现死者居然都...
    沈念sama阅读 87,567评论 2赞 381
  • 救了他两次的神仙让他今天三更去死
    文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
    开封第一讲书人阅读 151,342评论 0赞 338
  • 道士缉凶录：失踪的卖姜人
    文/不坏的土叔 我叫张陵，是天一观的道长。 经常有香客问我，道长，这世上最难降的妖魔是什么？ 我笑而不...
    开封第一讲书人阅读 54,825评论 1赞 277
  • 港岛之恋（遗憾婚礼）
    正文 为了忘掉前任，我火速办了婚礼，结果婚礼上，老公的妹妹穿的比我还像新娘。我一直安慰自己，他们只是感情好，可当我...
    茶点故事阅读 63,814评论 5赞 368
  • 恶毒庶女顶嫁案：这布局不是一般人想出来的
    文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
    开封第一讲书人阅读 48,680评论 1赞 281
  • 城市分裂传说
    那天，我揣着相机与录音，去河边找鬼。 笑死，一个胖子当着我的面吹牛，可吹牛的内容都是我干的。 我是一名探鬼主播，决...
    沈念sama阅读 38,033评论 3赞 399
  • 双鸳鸯连环套：你想象不到人心有多黑
    文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
    开封第一讲书人阅读 36,687评论 0赞 258
  • 万荣杀人案实录
    序言：老挝万荣一对情侣失踪，失踪者是张志新（化名）和其女友刘颖，没想到半个月后，有当地人在树林里发现了一具尸体，经...
    沈念sama阅读 42,175评论 1赞 300
  • 护林员之死
    正文 独居荒郊野岭守林人离奇死亡，尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,668评论 2赞 321
  • 白月光启示录
    正文 我和宋清朗相恋三年，在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,775评论 1赞 332
  • 活死人
    序言：一个原本活蹦乱跳的男人离奇死亡，死状恐怖，灵堂内的尸体忽然破棺而出，到底是诈尸还是另有隐情，我是刑警宁泽，带...
    沈念sama阅读 33,419评论 4赞 321
  • 日本核电站爆炸内幕
    正文 年R本政府宣布，位于F岛的核电站，受9级特大地震影响，放射性物质发生泄漏。R本人自食恶果不足惜，却给世界环境...
    茶点故事阅读 39,020评论 3赞 307
  • 男人毒药：我在死后第九天来索命
    文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹，春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,978评论 0赞 19
  • 一桩弑父案，背后竟有这般阴谋
    文/苍兰香墨 我抬头看了看天上的太阳。三九已至，却和暖如春，着一层夹袄步出监牢的瞬间，已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,206评论 1赞 260
  • 情欲美人皮
    我被黑心中介骗来泰国打工， 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留，地道东北人。 一个月前我还...
    沈念sama阅读 45,092评论 2赞 351
  • 代替公主和亲
    正文 我出身青楼，却偏偏与公主长得像，于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子，可洞房花烛夜当晚...
    茶点故事阅读 42,510评论 2赞 343