JAVA平台分布式自增长ID 的解决方案分析对比

全局ID解决方案一: redis

Redis的incr自增函数来维护全局ID,设计的关键地方:

1. key的长度;长度影响效率和存储容量

2. key的命名规则:无规则,维护困难,不能见名知意,了解所属业务板块

3. 需要人工干预机制:为了性能,redis设计为无状态,非持久化,遇到机器故障,重启redis会丢失所有的当前ID值,需要提供人工init操作,读取业务
MAXID,同步ID。

优点:不受限js的number类型最大值。位数控制在16位以内。Restful API 开发不需要数据类型转化,减少不必要的代码量,提高了维护性和开发效率。

缺点:key随着业务的扩展,越来越难维护,为了效率,不能持久化,故障重启需要人工干预,提供人工干预机制。

全局ID解决方案二:JAVA

64位ID (42(毫秒)+5(机器ID)+5(业务编码)+12(重复累加))

优点:效率高,支持高并发,ID几乎无重复值。

缺点:受限js的number类型最大值。超过此值,精度丢失。

原因:js的number类型有个最大值(安全值)。即2的53次方,为9007199254740992。如果超过这个值,那么js会出现不精确的问题。这个值为16
位。超过16位的数值需要在后端转化成字符串类型,传递到前端使用,增加了代码开发量,降低了开发效率。最优方案就是设计一个不超过16位数值型的分布式自增ID。

 

 

 

 

友情链接
ioDraw流程图
API参考文档
OK工具箱
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:637538335
关注微信