掌握MySQL分库分表（六）解决主键重复问题--Snowflake雪花算法

问题及需求

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

常用ID解决方案

数据库自增ID

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

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

缺点：

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

UUID

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

缺点：

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

Redis发号器

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

缺点：

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

Snowflake雪花算法

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

缺点：

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

分布式 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）

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

Snowflake必须注意的地方

全局唯⼀、不能重复

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

保证各个系统时间一致

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

什么时候会系统回拨？

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

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都行，缺点就是多了依赖

配置文件完整

spring.application.name=xdclass-sharding-jdbc
server.port=8080


# 打印执行的数据库以及语句
spring.shardingsphere.props.sql.show=true

# 数据源 db0
spring.shardingsphere.datasource.names=ds0,ds1

# 第一个数据库
spring.shardingsphere.datasource.ds0.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.ds0.driver-class-name=com.mysql.cj.jdbc.Driver
spring.shardingsphere.datasource.ds0.jdbc-url=jdbc:mysql://10.24.201.232:3306/xdclass_shop_order_0?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
spring.shardingsphere.datasource.ds0.username=root
spring.shardingsphere.datasource.ds0.password=root


# 第二个数据库
spring.shardingsphere.datasource.ds1.type=com.zaxxer.hikari.HikariDataSource
spring.shardingsphere.datasource.ds1.driver-class-name=com.mysql.cj.jdbc.Driver
spring.shardingsphere.datasource.ds1.jdbc-url=jdbc:mysql://10.24.201.232:3306/xdclass_shop_order_1?useUnicode=true&characterEncoding=utf-8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true
spring.shardingsphere.datasource.ds1.username=root
spring.shardingsphere.datasource.ds1.password=root

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



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

# 指定product_order表的数据分布情况，配置数据节点,行表达式标识符使用 ${...} 或 $->{...}，
# 但前者与 Spring 本身的文件占位符冲突，所以在 Spring 环境中建议使用 $->{...}
spring.shardingsphere.sharding.tables.product_order.actual-data-nodes=ds0.product_order_$->{0..1}

# 指定product_order表的分片策略，分片策略包括【分片键和分片算法】
spring.shardingsphere.sharding.tables.product_order.table-strategy.inline.sharding-column=user_id
spring.shardingsphere.sharding.tables.product_order.table-strategy.inline.algorithm-expression=product_order_$->{user_id % 2}

雪花算法测试结果

可以看出id全局不重复，并呈现出递增增长