1、引言

52im_qr_即时通讯技术圈_400px.png (17.47 KB, 下载次数: 1407)

下载附件  保存到相册

4 年前 上传

2、专题目录

• 《IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
• 《IM消息ID技术专题(二)：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
• 《IM消息ID技术专题(三)：解密融云IM产品的聊天消息ID生成策略》
• 《IM消息ID技术专题(四)：深度解密美团的分布式ID生成算法》
• 《IM消息ID技术专题(五)：开源分布式ID生成器UidGenerator的技术实现》
• 《IM消息ID技术专题(六)：深度解密滴滴的高性能ID生成器(Tinyid)》（* 本文）
• 《IM消息ID技术专题(七)：深度解密vivo的自研分布式ID服务(鲁班)》
  

3、什么是Tinyid？

• 主地址：https://github.com/didi/tinyid
• 备地址：https://github.com/52im/tinyid
  

4、Tinyid的主要技术特性

• 1）全局唯一的long型ID：即id极限数量是2的64次方；
• 2）趋势递增的id：趋势递增的意思是，id是递增但不一定是连续的（这跟微信的ID生成策略类似）；
• 3）提供 http 和 java-client 方式接入；
• 4）支持批量获取ID；
• 5）支持生成1,3,5,7,9…序列的ID；
• 6）支持多个db的配置。
  

5、Tinyid的技术优势

• 1）http方式：访问性能取决于http server的能力，网络传输速度；
• 2）java-client方式：id为本地生成，号段长度(step)越长，qps越大，如果将号段设置足够大，则qps可达1000w+。
  

• 1）当db不可用时，因为server有缓存，所以还可以使用一段时间；
• 2）如果配置了多个db，则只要有1个db存活，则服务可用；
• 3）使用tiny-client时，只要server有一台存活，则理论上server全挂，因为client有缓存，也可以继续使用一段时间。
  

6、Tinyid的技术原理详解

6.1ID生成系统的技术要点

• 1）唯一性：无论怎样都不能重复，id全局唯一是最基本的要求；
• 2）高性能：基础服务尽可能耗时少，如果能够本地生成最好；
• 3）高可用：虽说很难实现100%的可用性，但是也要无限接近于100%的可用性；
• 4）易用性：能够拿来即用，接入方便，同时在系统设计和实现上要尽可能的简单。
  

6.2Tinyid的实现原理

号段模式就是从数据库批量的获取自增ID，每次从数据库取出一个号段范围，例如 (1,1000] 代表1000个ID，业务服务将号段在本地生成1~1000的自增ID并加载到内存。

6.3DB号段算法描述

2.png (6.46 KB, 下载次数: 1418)

下载附件  保存到相册

4 年前 上传

3.png (7.42 KB, 下载次数: 1391)

下载附件  保存到相册

4 年前 上传

• 1）我们增加了biz_type，这个代表业务类型，不同的业务的id隔离；
• 2）max_id则是上面的end_id了，代表当前最大的可用id；
• 3）step代表号段的长度，可以根据每个业务的qps来设置一个合理的长度；
• 4）version是一个乐观锁，每次更新都加上version，能够保证并发更新的正确性 。
  

• A、查询当前的max_id信息：select id, biz_type, max_id, step, version from tiny_id_info where biz_type='test';
• B、计算新的max_id: new_max_id = max_id + step；
• C、更新DB中的max_id：update tiny_id_info set max_id=#{new_max_id} , verison=version+1 where id=#{id} and max_id=#{max_id} and version=#{version}；
• D、如果更新成功，则可用号段获取成功，新的可用号段为(max_id, new_max_id]；
• E、如果更新失败，则号段可能被其他线程获取，回到步骤A，进行重试。
  

6.4号段生成方案的简单架构

x1.png (11.66 KB, 下载次数: 1377)

下载附件  保存到相册

4 年前 上传

• 1）如果tinyid-server如果重启了，那么号段就作废了，会浪费一部分id；
• 2）同时id也不会连续；
• 3）每次请求可能会打到不同的机器上，id也不是单调递增的，而是趋势递增的（不过这对于大部分业务都是可接受的）。
  

6.5简单架构的问题

• 1）当id用完时需要访问db加载新的号段，db更新也可能存在version冲突，此时id生成耗时明显增加；
• 2）db是一个单点，虽然db可以建设主从等高可用架构，但始终是一个单点；
• 3）使用http方式获取一个id，存在网络开销，性能和可用性都不太好。
  

6.6优化办法及最终架构

4.png (9.97 KB, 下载次数: 1383)

下载附件  保存到相册

4 年前 上传

x2.png (18.37 KB, 下载次数: 1377)

下载附件  保存到相册

4 年前 上传

1.png (33.01 KB, 下载次数: 1417)

下载附件  保存到相册

4 年前 上传

• 1）nextId和getNextSegmentId是tinyid-server对外提供的两个http接口；
• 2）nextId是获取下一个id，当调用nextId时，会传入bizType，每个bizType的id数据是隔离的，生成id会使用该bizType类型生成的IdGenerator；
• 3）getNextSegmentId是获取下一个可用号段，tinyid-client会通过此接口来获取可用号段；
• 4）IdGenerator是id生成的接口；
• 5）IdGeneratorFactory是生产具体IdGenerator的工厂，每个biz_type生成一个IdGenerator实例。通过工厂，我们可以随时在db中新增biz_type，而不用重启服务；
• 6）IdGeneratorFactory实际上有两个子类IdGeneratorFactoryServer和IdGeneratorFactoryClient，区别在于，getNextSegmentId的不同，一个是DbGet,一个是HttpGet；
• 7）CachedIdGenerator则是具体的id生成器对象，持有currentSegmentId和nextSegmentId对象，负责nextId的核心流程。nextId最终通过AtomicLong.andAndGet(delta)方法产生。
  

• 主地址：https://github.com/didi/tinyid
• 备地址：https://github.com/52im/tinyid
  

7、Tinyid的最佳实践

• 多机房部署可用性更高，http方式访问需使用方考虑延迟问题。
  

• a、id为本地生成(调用AtomicLong.addAndGet方法)，性能大大增加；
• b、client对server访问变的低频，减轻了server的压力；
• c、因为低频，即便client使用方和server不在一个机房，也无须担心延迟；
• d、即便所有server挂掉，因为client预加载了号段，依然可以继续使用一段时间
  

• db配置多个时，只要有1个db存活，则服务可用 多db配置，如配置了两个db，则每次新增业务需在两个db中都写入相关数据。
  

8、Tinyid该怎么调用？

9、参考资料

附录：更多IM开发热门技术文章