基于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序号。
