互联网大厂的分布式ID解决方案(中)

上一篇分析了百度的UidGenerator源码，这篇将继续分析滴滴的TinyId的源码。对于TinyId的使用和介绍请参考官网，本篇文章侧重点在于对源码的分析。

01

—

号段算法

号段算法指的是预先生成一段数字号码，然后调用者在调用的时候，直接从预先生成好的号段中获取id，这个思想和百度UidGenerator中第二种策略相似。滴滴的TinyId是基于MySQL的自增长主键来预生成号段。

上图中0到1000是一个号段，如果这些号段在MySQL中生成的话会影响性能，占用资源，MySQL中可以只存储end_index，然后通过步长来计算下一个号段，例如：end_id=1000，step=1000，下一个号段是从end_id = 1000开始，结束是end_id + step = 2000。然后JVM拿到这两个字段之后就开始加载这个号段的数据，这个就是号段的大概原理。TinyId在这个基础上面又做了一些优化，上篇文章提到百度的UidGenerator是使用双循环数组，然后采用了启动填充、定时填充、超过50%的阈值填充，TinyId也是类似的思路，做了两个号段，也就是双号段，就是提前再生成一个号段，这样就会尽可能的保证生产者速度高于消费者，总结一下滴滴的TinyId。

• 全局唯一的long型id

• 提供http和javaclient方式接入

• 支持批量获取id

• 支持生成1,3,5,7,9…序列的id

• 支持多个db的配置，无单点

• 适用场景:只关心id是数字，趋势递增的系统，可以容忍id不连续，有浪费的场景不适用场景:类似订单id的业务(因为生成的id大部分是连续的，容易被扫库、或者测算出订单量)

02