背景
在复杂的分布式系统中,往往需要对大量的数据和消息进行唯一标识。
如对大量的订单做分库分表后,需要有一个唯一的ID来标识一条数据或消息,数据库的自增ID显然不能满足需求。
业务系统对分布式唯一ID的要求:
①:全局唯一性,不能重复
②:趋势递增,在MySQL InnoDB引擎中使用的是聚集索引,由于多数RDMS使用B-tree的数据结构来存储索引数据,在主键的选择上面应该尽量使用有序的主键保证写入性能
③:单调递增,保证下一个ID一定大于上一个ID
④:信息安全,如果ID是连续的,恶意用户的扒取工作就非常容易做了,直接按照顺序下载指定URL即可;如果是订单号就更危险了,竞对可以直接知道我们一天的单量。所以在一些应用场景下,会需要ID无规则、不规则
常用方案
1、UUID
优点:生成简单,本地生成,没有网络消耗,性能非常高
缺点:
1)每次生成的ID是无序的,无法保证趋势递增,不能作为数据库主键,否则会引起索引数据位置频繁变动,严重影响性能
2)UUID的字符串存储,查询效率慢
3)存储空间大
4)ID本事无业务含义,不可读
2、Redis
利用redis的原子性自增,具体实现为:
年份 + 当天距当年第多少天 + 天数 + 小时 + redis自增
优点:
有序递增,可读性强
缺点:
占用带宽,每次要向redis进行请求
3、雪花snowflake算法
snowflake是Twitter开源的分布式ID生成算法,结果是一个long型的ID。
其核心思想是:使用41bit作为毫秒数,10bit作为work ID(5个bit是数据中心,5个bit的机器ID),12bit作为毫秒内的流水号(意味着每个节点在每毫秒可以产生 4096 个 ID),最后还有一个符号位,永远是0。
snowflake算法生成64位的二进制正整数,然后转换成10进制的数。
64位二进制数组成部分如下:
优点:
1)此方案每秒能够产生409.6万个ID,性能快
2)时间戳在高位,自增序列在低位,整个ID是趋势递增的,按照时间有序递增
3)灵活度高,可以根据业务需求,调整bit位的划分,满足不同的需求
缺点:
只能保证work id相同的情况下生成的id是递增的
依赖机器的时钟,如果服务器时钟回拨,会导致重复ID生成
时钟回拨问题的解决方案:
1)回拨之后更换work id
2)等时间追上来再去生成id
4、美团Leaf
https://tech.meituan.com/2017/04/21/mt-leaf.html
参考:https://juejin.cn/post/6844903562007314440
END.