【分布式】聊聊分布式id实现方案和生产经验

对于分布式Id来说，在面试过程中也是高频面试题，所以主要针对分布式id实现方案进行详细分析下。

应用场景

对于无论是单机还是分布式系统来说，对于很多场景需要全局唯一ID，

数据库id唯一性
日志traceId 可以方便找到日志链，一般使用uuid 更多一点
幂等场景下，mq、api接口层面保证幂等下
业务系统订单id

UUID

最简单的就是使用UUID，UUID的规则是一组32位16进制数字构成，形式就是8-4-4-4-8，主要就是利用当前时间和时钟序列和全局唯一的IEEE机器识别。

csharp 复制代码

UUID uuid = UUID.randomUUID();

307e16d0-26d4-4fff-ab06-a9397b8369fb

优点：实现简单，全局唯一，缺点是不具有连续性，并且占用空间比较大，对于mysql主键来说不具备友好。

数据库自增ID

就目前公司内部，其实还是使用的数据库自增id进行处理，对于数据库来说的话，就是多个实例操作表自增id，对于业务来说使用自定义时间戳来实现。

还有一种方式就是创建一个单独的表，通过数据库本身的自增id来保证。

csharp 复制代码

CREATE TABLE `test_order_id`  (
  `id` bigint NOT NULL AUTO_INCREMENT,
  `title` char(1) NOT NULL,
  PRIMARY KEY (`id`),
    UNIQUE KEY `title` (`title`)
) ENGINE = InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET =utf8;

BEGIN;

REPLACE INTO test_order_id (title) values ('p') ;
SELECT LAST_INSERT_ID();

COMMIT;

这种方式的优点就是实现比较简单，但是缺点就是不具备高可用性，如果mysql是单节点部署的话，那么整体就不可用。

高可用数据库实例

部署多个数据库实例，通过设置不同的自增，比如mysql实例1，自增是2，从1开始，mysql实例2 从2开始，那么就是实例1 ： 1、3、5、7，实例2: 2、4、6、8。

对于并发量不高的场景来说，可以解决，但是对于高并发场景来说，数据库实例就是成为瓶颈。如果1秒1000个订单，那么就需要频繁访问1000次数据库，显然这个网络以及IO就成为短板。

号段模型

号段模式，其实就是通过在一个表中唯一一条记录，然后通过业务区分，每次获取一个区间的号，这样比如获取1-1000的号段，那么就只需要交互一次数据库，并且通过添加version来避免出现并发修改数据的问题。

Redis

除了借助于mysql，还可以通过redis的自增 incr命令来实现自增ID，并且可以部署一主多从的架构，来保证高可用性。

csharp 复制代码

    public long nextId(String item){
        // 1.生成时间戳
        LocalDateTime now = LocalDateTime.now();
        // 格林威治时间差
        long nowSecond = now.toEpochSecond(ZoneOffset.UTC);
        // 我们需要获取的 时间戳 信息
        long timestamp = nowSecond - BEGIN_TIMESTAMP;
        // 2.生成序号 --》 从Redis中获取
        // 当前当前的日期
        String date = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd"));
        // 获取对应的自增的序号
        Long increment = redisTemplate.opsForValue().increment("id:" + item + ":" + date);
        return timestamp << 32 | increment;
    }

具体原理其实就是当前时间戳-制定时间 << 32 | 自增的id 这样输出的就是连续的id了

雪花算法

雪花算法整体结构就是 64位 0-41位位毫秒值，5位是数据中心id，5位机器id，最后12位是毫秒级别内的自增id

分析源码可以大概了解其核心流程

雪花算法时钟回拨

在实际的生产环境中，分布式环境下，其实时钟是很难保证统一的，所以就可能实现时间不一样的情况，导致时钟回拨问题，我们来分析两类问题

情况1:UTC时间是8点01，实例机器是8点整

情况2:UTC时间是8点01 实例机器是8点03

对于情况1来说，其实就调整一下时间就好，1分钟内的id生成不用就可以。但是对于第二种情况，相当于需要从3分回退到01分，那么其中的2分钟的时间已经生成了对应的id，如果在次生成，就会出现id重复的问题？

如何解决呢

其实比较简单，大方向就是如果时间短，那么就等得阻塞对应的时间就可以，如果超过1S以上，服务直接下线，通过其他实例获取id就可以。

其他

业界有主流的其他方案，具体可以详细看

百度、美团对应的解决方案，这里自己查看对应文档就可以。

总结

从上面的分析可以知道目前业界主流的方案，我们来抽丝剥茧下，对于设计一个分布式id来说，需要哪些核心点

1.需要顺序这样可以简单清晰

2.依赖的服务需要高可用、高性能

3.全局唯一

4.有具体的业务含义，比如针对订单号：11xxx 开始，还款订单21xxx，借款订单31xxx。就比较清晰。