ID生成器选型

背景

 

支付服务准备在海外部署，这引入了新的需求，一个是需要保证id全局唯一，另外一个是需要通过id拿到机房等信息，而公司现有的id生成器并不能保证多中心生成的id唯一，这还不是主要问题，这个可以重构一下就好了，但是要通过id拿到机房等信息这个需求要在现有的id生成器上改则是代价太大，几乎是改不动，因此我们部门决定搞一套新的ID生成器。

 

备选方案

 

到了一定规模，市面上开源的方案，基本就 两类，一类是基于 “号段模式” 做的增强，一类是 基于“雪花算法”做的增强，大体整理出如下三个备选方案

方案	算法分类	优点	缺点	原理
自己造轮子	雪花算法/号段模式	可以完全根据团队需求定制开发	1、需要投入较多开发、测试资源 2、没有大规模生产验证，容易引入bug	基于雪花算法或号段模式做增强
美团Leaf	雪花算法/号段模式	全局唯一，绝对不会出现重复的ID，且ID整体趋势递增。 高可用，服务完全基于分布式架构，即使MySQL宕机，也能容忍一段时间的数据库不可用。 高并发低延时，在CentOS 4C8G的虚拟机上，远程调用QPS可达5W+，TP99在1ms内。 接入简单，直接通过公司RPC服务或者HTTP调用即可接入。	1、中心化架构，id生产由一个服务集群来提供，需要一定的运维能力保证其高可用，一旦出问题影响较大
滴滴Tinyid	号段模式	1、支持本地生成模式 2、其它同Leaf	1、相对而言有点复杂	基于美团Leaf做了一些优化升级，大体原理参考Leaf
百度Uidgenerator	雪花算法	1、全局唯一，整体趋势递增 2、高性能，QPS可达600万 3、去中心化架构，id本地生成，无需担忧互相影响，出问题影响范围也就是当前实例	1、机器id，默认最多只支持约420w次机器启动。内置实现为在启动时由数据库分配，默认分配策略为用后即弃，这个点对服务规模极大的公司估计就有问题	workId由mysql表自增分配

 

选中方案

 

选择百度Uidgenerator，虽然从能力看滴滴Tinyid是最强的，但是它也是最复杂的，自己造轮子虽然是最贴合需求的，但是它又是最耗时最不靠谱的，而百度Uidgenerator虽然能力不是最强的，但是相对简单，也经过了百度大规模线上验证，我们基于它做二次开发是最容易上手，综合讲性价比最高。