基于Redis生成全局ID策略
单机版
因为Redis是单线程,天生保证原子性,可以使用原子操作INCR和INCRBY来实现
INCRBY:设置增长步长
集群分布式
注意:在Redis集群情况下,同样和MySQL一样需要设置不同的增长步长,同时key一定要设置有效期,可以使用Redis集群来获取更高的吞吐量。
假设一个集群中有5台Redis,可以初始化每台Redis的值分别是 1,2,3,4,5 , 然后设置步长都是5
各个Redis生成的ID为:
A:1 6 11 16 21 B:2 7 12 17 22 C:3 8 13 18 23 D:4 9 14 19 24 E:5 10 15 20 25
但是存在的问题是,就是Redis集群的维护和保养比较麻烦,配置麻烦。因为要设置单点故障,哨兵值守
但是主要是的问题就是,为了一个ID,却需要引入整个Redis集群,有种杀鸡焉用牛刀的感觉
雪花算法
是什么
Twitter的分布式自增ID算法,Snowflake
最初Twitter把存储系统从MySQL迁移到Cassandra(由Facebook开发一套开源分布式NoSQL数据库系统)因为Cassandra没有顺序ID生成机制,所有开发了这样一套全局唯一ID生成服务。
Twitter的分布式雪花算法SnowFlake,经测试SnowFlake每秒可以产生26万个自增可排序的ID
- twitter的SnowFlake生成ID能够按照时间有序生成
- SnowFlake算法生成ID的结果是一个64Bit大小的整数,为一个Long型(转换成字符串后长度最多19)
- 分布式系统内不会产生ID碰撞(由datacenter 和 workerID做区分)并且效率较高
分布式系统中,有一些需要全局唯一ID的场景,生成ID的基本要求
- 在分布式环境下,必须全局唯一性
- 一般都需要单调递增,因为一般唯一ID都会存在数据库,而InnoDB的特性就是将内容存储在主键索引上的叶子节点,而且是从左往右递增的,所有考虑到数据库性能,一般生成ID也最好是单调递增的。为了防止ID冲突可以使用36位UUID,但是UUID有一些缺点,首先是它相对比较长,并且另外UUID一般是无序的
- 可能还会需要无规则,因为如果使用唯一ID作为订单号这种,为了不让别人知道一天的订单量多少,就需要这种规则
结构
雪花算法的几个核心组成部分
在Java中64bit的证书是long类型,所以在SnowFlake算法生成的ID就是long类存储的
第一部分
二进制中最高位是符号位,1表示负数,0表示正数。生成的ID一般都是用整数,所以最高位固定为0。
第二部分
第二部分是41bit时间戳位,用来记录时间戳,毫秒级
41位可以表示 2^41 -1 个数字
如果只用来表示正整数,可以表示的范围是:0 - 2^41 -1,减1是因为可以表示的数值范围是从0开始计算的,而不是从1。
也就是说41位可以表示 2^41 - 1 毫秒的值,转换成单位年则是 69.73年
第三部分
第三部分为工作机器ID,10Bit用来记录工作机器ID
可以部署在2^10 = 1024个节点,包括5位 datacenterId(数据中心,机房) 和 5位 workerID(机器码)
5位可以表示的最大正整数是 2 ^ 5 = 31个数字,来表示不同的数据中心 和 机器码
第四部分
12位bit可以用来表示的正整数是 2^12 = 4095,即可以用0 1 2 … 4094 来表示同一个机器同一个时间戳内产生的4095个ID序号。