深度解析滴滴开源分布式id生成服务tinyid源码

向右看齐 2022-09-08 13:54 416阅读 0赞

> 原创不易，转载请注明出处

### 文章目录 ###

*   *   *  前言
         *  1. 简单试用
         *   *  1.1 数据库准备
             *  2.2 修改配置启动server
             *  1.3 使用
         *  2. 号段模式原理
         *  3. 源码解析
         *   *  3.1 IdGenerator创建
             *  3.2 获取id
         *  总结

--------------------

### 前言 ###

tinyid 是滴滴开源的分布式id 生成服务，分布式id生成系统，简单易用、高性能、高可用的id生成系统。  
就现有情况来说，仅提供了一种分布式id生成方式，就是基于db的号段模式，与美团leaf分布式id 生成服务的号段模式一样，实现上差不多，但是比leaf 少了一种雪花生成方式。  
较leaf的优势：  
1.加入token校验  
2.客户端封装的不错，用户无感知。

### 1. 简单试用 ###

这里为了简单的试用下，我们就直接从github上将tinyid项目clone下来，然后导入到idea中，在idea中启动服务试用。  
tinyid 源码仓库地址：https://github.com/didi/tinyid

#### 1.1 数据库准备 ####

号段模式是基于db实现的，所以要新建个db，将一些初始化sql执行下。

CREATE TABLE `tiny_id_info` (
      `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '自增主键',
      `biz_type` varchar(63) NOT NULL DEFAULT '' COMMENT '业务类型，唯一',
      `begin_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '开始id，仅记录初始值，无其他含义。初始化时begin_id和max_id应相同',
      `max_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '当前最大id',
      `step` int(11) DEFAULT '0' COMMENT '步长',
      `delta` int(11) NOT NULL DEFAULT '1' COMMENT '每次id增量',
      `remainder` int(11) NOT NULL DEFAULT '0' COMMENT '余数',
      `create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '创建时间',
      `update_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新时间',
      `version` bigint(20) NOT NULL DEFAULT '0' COMMENT '版本号',
      PRIMARY KEY (`id`),
      UNIQUE KEY `uniq_biz_type` (`biz_type`)
    ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT 'id信息表';
    
    CREATE TABLE `tiny_id_token` (
      `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '自增id',
      `token` varchar(255) NOT NULL DEFAULT '' COMMENT 'token',
      `biz_type` varchar(63) NOT NULL DEFAULT '' COMMENT '此token可访问的业务类型标识',
      `remark` varchar(255) NOT NULL DEFAULT '' COMMENT '备注',
      `create_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '创建时间',
      `update_time` timestamp NOT NULL DEFAULT '2010-01-01 00:00:00' COMMENT '更新时间',
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT 'token信息表';
    
    INSERT INTO `tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`)
    VALUES
    	(1, 'test', 1, 1, 100000, 1, 0, '2018-07-21 23:52:58', '2018-07-22 23:19:27', 1);
    INSERT INTO `tiny_id_info` (`id`, `biz_type`, `begin_id`, `max_id`, `step`, `delta`, `remainder`, `create_time`, `update_time`, `version`)
    VALUES
    	(2, 'test_odd', 1, 1, 100000, 2, 1, '2018-07-21 23:52:58', '2018-07-23 00:39:24', 3);
    INSERT INTO `tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`)
    VALUES
    	(1, '0f673adf80504e2eaa552f5d791b644c', 'test', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48');
    INSERT INTO `tiny_id_token` (`id`, `token`, `biz_type`, `remark`, `create_time`, `update_time`)
    VALUES
    	(2, '0f673adf80504e2eaa552f5d791b644c', 'test_odd', '1', '2017-12-14 16:36:46', '2017-12-14 16:36:48');

在项目根路径下有个db.sql的文件。

#### 2.2 修改配置启动server ####

tinyid 项目分为server 与client，server 提供生成分布式id的能力，是使用springboot 写的，client就是封装http请求，将去server 获取id请求封装起来，用户无感知，方便使用。  
这里的配置主要是tinyid server的配置，数据库连接配置，服务端口配置等等。  
启动server，springboot 启动这里不用多说。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBAJOeggeWHuuacquadpQ_size_39_color_FFFFFF_t_70_g_se_x_16]

#### 1.3 使用 ####

tinyid server起来了，我们就使用client 请求一下，进去找到ClientTest 测试类  
![在这里插入图片描述][91b98029e4ae4155a6fad18631bd7da2.png]  
直接单元测试下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBAJOeggeWHuuacquadpQ_size_32_color_FFFFFF_t_70_g_se_x_16]

### 2. 号段模式原理 ###

建议先看下《[深度解析leaf分布式id生成服务源码（号段模式）][leaf_id]》

号段模式最核心的就是去数据库中拿一个id 区间，然后将id区间放在id生成服务本地内存中，客户端请求获取id的时候都是从id生成服务内存中获取，一旦id生成服务中id区间消耗光了，就再去数据库中获取一批id。  
我们举个列子：  
比如说我有一个表 generate\_id 里面有4个字段  
id 主键， biz是个业务标识，比如说我商品id 生成 与订单id 生成不能用同一条 数据，这样id就会乱了，所以每个业务有个biz标识。  
max\_id 是最大id ，step 表示每次获取多少id  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAJOeggeWHuuacquadpQ_size_20_color_FFFFFF_t_70_g_se_x_16]  
这个时候我们的客户端（业务系统）请求id 生成服务获取id ，我们id服务就会先看看本地有没有id区间可以用，如果没有的话，就去数据库申请一个id 区间  
这个时候我们就要仔细看看 id生成器是怎样向数据库申请id 区间的。  
先是发送一条更新sql： `update generate_id set max_id=max_id+step where biz=goods`  
然后发送一条查询sql ：`select max_id ,step from generate_id where biz=goods`  
需要注意的是，这两条sql需要在同一个是事务中，这样才能保证数据不会乱 (这块涉及到行锁 与 mvcc机制)  
这样我们的id生成服务就能获取一个 id 区间 就是 0-1000 （ min : max\_id -step , max: max\_id），以后客户端再来申请的时候，直接从内存中这个id区间拿就可以了，其实就是 min++ 操作，只要保证min++线程安全就可以了，最多不超过max\_id ，一旦超过再去 mysql申请号段。  
可以看到号段模式核心就是`预占号段` 预占一批id放到id生成服务本地中，客户端获取id就是去id生成服务那批id号段中获取，如果id用光了，再去请求数据库申请号段即可。

有几个问题 ：

1.  当id生成服务id号段用光了，去mysql 中申请号段慢的问题，会造成一卡一卡的感觉。
2.  这种预占号段，一旦id生成服务挂了/停了，再起来的时候，号段就丢了（毕竟是放在服务内存中的），而且是永久丢了。
3.  强依赖数据库，数据库单机问题，瓶颈问题。

解决：  
第一个问题解决方案就是 在id 生成服务中 对每个号段生成一个阈值，一旦号段使用到了这个阈值，就起个后台线程将下个号段先申请过来，这也就是双buffer 缓冲机制，不管是美团的leaf 还是滴滴的tinyid 都用了这种机制，保证高并发，高性能。  
还有就是 增加id生成服务实例数量， 加大step ，减少申请号段次数， 你由原来一次申请1000个id 变成一次申请10000个id ，减少db交互。

第二个问题 号段丢了，这个说实话，也没办法，不能保证完全连续，关键完全连续也没啥用。而且号段模式只是趋势递增的。

第三个问题 ，如果是性能瓶颈的话，还好说，拿biz 这个字段进行分库分表。 单机问题的话，只能就是主从了。

接下来就是源码解析了。其实明白了上面号段模式的原理，代码看不看也就是无所谓，因为你也能写出来。

### 3. 源码解析 ###

先来看看数据库表字段  
![在这里插入图片描述][62f2a2ffab244e3aa5d063c6fde7be8b.png]  
这个biz\_type 就是业务标识， max\_id ,step 就是我们介绍的那个， delta 是id 增长的步伐， version 乐观锁

看看源码：  
从server 的controller 开始

@RequestMapping("nextIdSimple")
    public String nextIdSimple(String bizType, Integer batchSize, String token) { 
       Integer newBatchSize = checkBatchSize(batchSize);
       // 类型 token的校验
       if (!tinyIdTokenService.canVisit(bizType, token)) { 
           return "";
       }
       String response = ""
       IdGenerator idGenerator = idGeneratorFactoryServer.getIdGenerator(bizType);
       Long id = idGenerator.nextId();
       return response;
    }

先是获取对应业务类型的IdGenerator ，然后调用idGenerator 的nextId 方法。  
怎样获取生成IdGenerator

#### 3.1 IdGenerator创建 ####

IdGeneratorFactoryServer 没有getIdGenerator 方法，需要看下它父类AbstractIdGeneratorFactory

private static ConcurrentHashMap<String, IdGenerator> generators = new ConcurrentHashMap<>();
    @Override
    public IdGenerator getIdGenerator(String bizType) { 
        if (generators.containsKey(bizType)) { 
            return generators.get(bizType);
        }
        synchronized (this) { 
            if (generators.containsKey(bizType)) { 
                return generators.get(bizType);
            }
            // 创建generator
            IdGenerator idGenerator = createIdGenerator(bizType);
            generators.put(bizType, idGenerator);
            return idGenerator;
        }
    }

从generators 这个缓存（map，key是业务类型biz\_type ，value就是对应的IdGenerator对象）中获取，如果存在的话，返回即可，没有点话就调用createIdGenerator 方法进行创建，然后塞入缓存中，这个createIdGenerator 方法是个抽象方法，也就是个模板方法，需要IdGeneratorFactoryServer子类来实现

@Override
    public IdGenerator createIdGenerator(String bizType) { 
        logger.info("createIdGenerator :{}", bizType);
        return new CachedIdGenerator(bizType, tinyIdService);
    }

可以看到创建了个CachedIdGenerator 对象。

public CachedIdGenerator(String bizType, SegmentIdService segmentIdService) { 
        this.bizType = bizType;
        this.segmentIdService = segmentIdService;
        // 加载当前的
        loadCurrent();
    }

有个loadCurrent 方法，这个方法其实就是初始化方法，去数据库中申请号段。

protected volatile SegmentId current;
    protected volatile SegmentId next;
    public synchronized void loadCurrent() { 
        if (current == null || !current.useful()) { 
            if (next == null) { 
                SegmentId segmentId = querySegmentId();
                this.current = segmentId;
            } else { 
                current = next;
                next = null;
            }
        }
    }

这里就出来双buffer 缓冲了。如果是初次创建的话也就是current是null，或者是 当前这个号段的id 用光了就会进入第一个if，如果next是null的话 ，调用querySegmentId 方法获取号段，然后将号段赋值给current ， 如果不是null的话，将next 赋值给current ， next 设置成0。总而言之，保证current 号段不是null 并且可用。而这个next 号段就是预加载的，当current消耗到一定阈值后，会起个后台任务去数据库中申请号段，赋值给next ，这样当current 用光了就可以直接无缝切换到next 持有的那个号段。

看看querySegmentId 方法

private SegmentId querySegmentId() { 
        String message = null;
        try { 
            SegmentId segmentId = segmentIdService.getNextSegmentId(bizType);
            if (segmentId != null) { 
                return segmentId;
            }
        } catch (Exception e) { 
            message = e.getMessage();
        }
        throw new TinyIdSysException("error query segmentId: " + message);
    }

/** * Transactional标记保证query和update使用的是同一连接 * 事务隔离级别应该为READ_COMMITTED,Spring默认是DEFAULT(取决于底层使用的数据库，mysql的默认隔离级别为REPEATABLE_READ) * <p> * 如果是REPEATABLE_READ，那么在本次事务中循环调用tinyIdInfoDAO.queryByBizType(bizType)获取的结果是没有变化的，也就是查询不到别的事务提交的内容 * 所以多次调用tinyIdInfoDAO.updateMaxId也就不会成功 * / @Override @Transactional(isolation = Isolation.READ_COMMITTED) public SegmentId getNextSegmentId(String bizType) { // 获取nextTinyId的时候，有可能存在version冲突，需要重试 for (int i = 0; i < Constants.RETRY; i++) { TinyIdInfo tinyIdInfo = tinyIdInfoDAO.queryByBizType(bizType); if (tinyIdInfo == null) { throw new TinyIdSysException("can not find biztype:" + bizType); } Long newMaxId = tinyIdInfo.getMaxId() + tinyIdInfo.getStep(); Long oldMaxId = tinyIdInfo.getMaxId(); int row = tinyIdInfoDAO.updateMaxId(tinyIdInfo.getId(), newMaxId, oldMaxId, tinyIdInfo.getVersion(), tinyIdInfo.getBizType()); if (row == 1) { tinyIdInfo.setMaxId(newMaxId); // 转换成SegmentId SegmentId segmentId = convert(tinyIdInfo); logger.info("getNextSegmentId success tinyIdInfo:{} current:{}", tinyIdInfo, segmentId); return segmentId; } else { logger.info("getNextSegmentId conflict tinyIdInfo:{}", tinyIdInfo); } } throw new TinyIdSysException("get next segmentId conflict"); }

这边它使用version 乐观锁保证数据安全，重试3次，而且注释上解释了为什么使用隔离级别READ\_COMMITTED 。  
它采用的方式是先查询，后更新数据库，计算出来新的max\_id ，设置到数据库中，并使用version 字段保证数据安全。

public SegmentId convert(TinyIdInfo idInfo) { 
        SegmentId segmentId = new SegmentId();
        segmentId.setCurrentId(new AtomicLong(idInfo.getMaxId() - idInfo.getStep()));
        segmentId.setMaxId(idInfo.getMaxId());
        segmentId.setRemainder(idInfo.getRemainder() == null ? 0 : idInfo.getRemainder());
        segmentId.setDelta(idInfo.getDelta() == null ? 1 : idInfo.getDelta());
        // 默认20%加载
        segmentId.setLoadingId(segmentId.getCurrentId().get() + idInfo.getStep() * Constants.LOADING_PERCENT / 100);
        return segmentId;
    }

currentId ： 是个 AtomicLong ， 它的起始值就是 max\_id -step  
maxId： 就是当前号段最大的那个id ，你这个号段不能超了这个数。  
delta： 步长， 如果我步长是2的话，第一次获取是1，第二次就是3了，就是这个意思。  
loadingId： 这个就是我们说的那个阈值。当使用当前号段20% id的时候，就后台任务申请下一个号段。

#### 3.2 获取id ####

接下来我们看下获取id 方法。

@Override
    public Long nextId() { 
       while (true) { 
           if (current == null) { 
               loadCurrent();
               continue;
           }
           Result result = current.nextId();
           if (result.getCode() == ResultCode.OVER) { 
               loadCurrent();
           } else { 
               if (result.getCode() == ResultCode.LOADING) { 
                   loadNext();
               }
               return result.getId();
           }
       }
    }

上来一个while循环。如果current 是null的话，就调用loadCurrent 方法获取号段。数据库中申请或者是拿next的。  
current.nextId() 调用号段的nextid 方法。

public Result nextId() { 
         init();
         long id = currentId.addAndGet(delta);
         if (id > maxId) { 
             return new Result(ResultCode.OVER, id);
         }
         if (id >= loadingId) { 
             return new Result(ResultCode.LOADING, id);
         }
         return new Result(ResultCode.NORMAL, id);
     }

这个init 不用管。调用 currentId.addAndGet 方法获取id 这个方法是AtomicLong的方法，保证线程安全，原子性， 如果是id >maxId 说明这个号段用完了，返回一个OVER。  
如果id 大于loadingId 这个加载阈值，返回 LOADING 。  
回到上面的nextId方法。如果是OVER 的话，调用loadCurrent 方法进行号段切换。如果是LOADING 的话，需要加载下一个号段了，调用loadNext 方法加载下一个号段。

public void loadNext() { 
        if (next == null && !isLoadingNext) { 
            synchronized (lock) { 
                if (next == null && !isLoadingNext) { 
                    isLoadingNext = true;
                    executorService.submit(new Runnable() { 
                        @Override
                        public void run() { 
                            try { 
                                // 无论获取下个segmentId成功与否，都要将isLoadingNext赋值为false
                                next = querySegmentId();
                            } finally { 
                                isLoadingNext = false;
                            }
                        }
                    });
                }
            }
        }
    }

如果next 是null 并且没在加载中，这个时候，向线程池提交一个任务，就是调用querySegmentId 方法向数据库申请号段，赋值给next 上面。最后将isLoadingNext 设置未false ，表示现在没有正在加载的任务了。

### 总结 ###

到这里，我们tinyid 源码解析就结束了，号段模式的原理，个人感觉很有意思。双buffer 缓冲机制，用的地方也很多，能够提高并发性能。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBAJOeggeWHuuacquadpQ_size_39_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/dcece946b49948458b9846b7dceedf70.png
[91b98029e4ae4155a6fad18631bd7da2.png]: /images/20220829/2ffcf59d618d4e15acacefb7175087e4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_Q1NETiBAJOeggeWHuuacquadpQ_size_32_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/af0ab78cb7884e4598760146bbb1c3be.png
[leaf_id]: https://inetyoung.blog.csdn.net/article/details/118423254
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAJOeggeWHuuacquadpQ_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220829/921dd78f6d2b495589f4a9888fce3897.png
[62f2a2ffab244e3aa5d063c6fde7be8b.png]: /images/20220829/1a0e982d0dc24e4ba82105cd8d5ac377.png