问题及需求

单库下⼀般使用Mysql自增ID，但是分库分表后，会造成不同分片上的数据表主键会重复
需求：性能强劲、全局唯一、防止恶意用户规矩id的规则来获取数据

常用ID解决方案

数据库自增ID

利用自增id, 设置不同的⾃增步长：auto_increment_offset、auto-increment-increment

DB1: 单数
//从1开始、每次加2
DB2: 偶数
//从2开始，每次加2

缺点：

依靠数据库系统的功能实现，但是未来扩容麻烦
主从切换时的不⼀致可能会导致重复发号
性能瓶颈存在单台sql上

UUID

性能非常高，没有网络消耗

缺点：

无序的字符串，不具备趋势自增特性
UUID太长，不易于存储，浪费存储空间，很多场景不适用

Redis发号器

利用Redis的INCR和INCRBY来实现，原子操作，线程安全，性能比Mysql强劲

缺点：

需要占用网络资源，增加系统复杂度

Snowflake雪花算法

twitter 开源的分布式 ID生成算法，代码实现简单、不占用宽带、数据迁移不受影响
生成的 id 中包含有时间戳，所以生成的 id按照时间递增
部署了多台服务器，需要保证系统时间⼀样，机器编号不⼀样

缺点：

依赖系统时钟（多台服务器时间⼀定要⼀样）

分布式 ID 生成算法Snowflake原理

关于bit与byte

bit(位)：电脑中存储的最小单位，可以存储⼆进制中的0或1
byte(字节)：⼀个byte由8个bit组成
常规64位系统⾥⾯java数据类型存储字节大小

int：4 个字节
short：2 个字节
long：8 个字节
byte：1 个字节
float：4 个字节
double：8 个字节
char：2 个字节

科普：数据类型在不同位数机器的平台下长度不同

16位平台 int 2个字节16位
32位平台 int 4个字节32位
64位平台 int 4个字节32位

雪花算法的位数

雪花算法生成的数字，long类，所以是：8个byte，64bit
表示的值 -9223372036854775808（-2的63次方）~9223372036854775807（2的63次⽅-1）
生成的唯⼀值⽤于数据库主键，不能是负数，所以值为0~9223372036854775807（2的63次方-1）

第一个bit位代表符号位，正数是0，负数是1，ID为正数，所以固定为0
毫秒级时间戳部分占41bit，不是存储当前时间的时间截，服务上线的时间毫秒级的时间戳(为当前时间-服务第一次上线时间)
工作机器 id占10bit，可支持2¹⁰ =1024个节点
序列号部分占12bit，可允许同一毫秒生成2¹² =4096个Id，则理论上一秒就可生成4096*1000 = 400万个ld
组合起来刚好是64位，Long类型

Snowflake必须注意的地方

全局唯⼀、不能重复

分布式部署就需要分配不同的workId, 如果workId相同，
可能会导致⽣成的id相同

保证各个系统时间一致

分布式情况下，需要保证各个系统时间⼀致，如果服务器的时钟回拨，就会导致⽣成的 id 重复

什么时候会系统回拨？

人工去生产环境做了系统时间调整
业务需求，代码里面做了系统时间同步

Snowflake雪花算法实现

配置文件
增加：

#配置workId
spring.shardingsphere.sharding.tables.product_order.key-generator.props.worker.id=1

方式一：订单id使用MybatisPlus的配置，ProductOrder类配置

@TableId(value = "id", type = IdType.ASSIGN_ID)
默认实现类为DefaultIdentifierGenerator雪花算法

方式二：使用Sharding-Jdbc配置文件，注释DO类里面的id分配策略

#id⽣成策略
spring.shardingsphere.sharding.tables.product_order.key-generator.column=id
spring.shardingsphere.sharding.tables.product_order.key-generator.type=SNOWFLAKE

方式三进阶：动态指定sharding jdbc 的雪花算法中的属性work.id属性
使用sharding-jdbc中的使用IP后几位来做workId，但在某些情况下会出现生成重复ID的情况
解决办法： 在启动时给每个服务分配不同的workId, 引⼊redis/zk都行，缺点就是多了依赖