前述的基于Ignite的分布式ID生成器,优点是实现简单,将一个jar包嵌入应用后ID生成系统和应用生命周期一致,设置了备份后不存在单点故障,数值线性递增可比较大小,规则按照业务定制后可以做得更短,如果转成十六进制后,会非常短,不依赖数据库,不对数据库产生压力,缺点可能就是性能以及一些特定的业务需求了。
生成全局唯一ID的需求是刚性的,尤其是分布式环境中,问题显得尤为复杂。当前,这方面的实现方案非常多,通用的不通用的,本文不做详细的论述,只做简单的列举:
- UUID
优点是性能好,缺点是比较长,128位,无规则,无法比较大小。
- ID分发中心
比如twitter的snowflake服务,可以做到高性能,高可用,低延迟,时间上有序,缺点就是使整个系统变得复杂,维护工作量加大。
- MongoDB的ObjectID(类似UUID)
MongoDB的驱动中提供了objectId的生成功能,优点是相对于UUID要短些,时间上有序,而且这个id包含了很多有用的信息,解码后就可以获得。
- 数据库生成
有很多的基于数据库的方案,比如基于Oracle和PostgreSQL的序列,Flickr和Instagram也有基于数据库的比较复杂的方案。
- 其他
根据不同的业务场景,可以做出各种各样的、满足各种需求的ID生成方案,需求越多,实现也会越复杂