别说我不告诉你！如何用分库分表的-9种分布式主键ID-生成方案？挺全乎的

最新推荐文章于 2024-08-06 14:41:33 发布

2401_83641392

最新推荐文章于 2024-08-06 14:41:33 发布

阅读量919

点赞数 30

分类专栏：程序员文章标签：分布式

本文链接：https://blog.csdn.net/2401_83641392/article/details/137213557

版权

程序员专栏收录该内容

506 篇文章 3 订阅

订阅专栏

spring.shardingsphere.sharding.tables.t_order.key-generator.props.worker.id=0000

序列号位（12bit）

同一毫秒内生成不同的ID。

时钟回拨

了解了雪花算法的主键 ID 组成后不难发现，这是一种严重依赖于服务器时间的算法，而依赖服务器时间的就会遇到一个棘手的问题：时钟回拨。

为什么会出现时钟回拨呢？

互联网中有一种网络时间协议 ntp 全称 (Network Time Protocol) ，专门用来同步、校准网络中各个计算机的时间。

这就是为什么，我们的手机现在不用手动校对时间，可每个人的手机时间还都是一样的。

我们的硬件时钟可能会因为各种原因变得不准（ 快了 或 慢了 ），此时就需要 ntp 服务来做时间校准，做校准的时候就会发生服务器时钟的 跳跃 或者 回拨 的问题。

雪花算法如何解决时钟回拨

服务器时钟回拨会导致产生重复的 ID，SNOWFLAKE 方案中对原有雪花算法做了改进，增加了一个最大容忍的时钟回拨毫秒数。

如果时钟回拨的时间超过最大容忍的毫秒数阈值，则程序直接报错；如果在可容忍的范围内，默认分布式主键生成器，会等待时钟同步到最后一次主键生成的时间后再继续工作。

最大容忍的时钟回拨毫秒数，默认值为 0，可通过属性 max.tolerate.time.difference.milliseconds 设置。

最大容忍的时钟回拨毫秒数

spring.shardingsphere.sharding.tables.t_order.key-generator.max.tolerate.time.difference.milliseconds=5

下面是看下它的源码实现类 SnowflakeShardingKeyGenerator，核心流程大概如下：

最后一次生成主键的时间 lastMilliseconds 与当前时间currentMilliseconds 做比较，如果 lastMilliseconds > currentMilliseconds则意味着时钟回调了。

那么接着判断两个时间的差值（timeDifferenceMilliseconds）是否在设置的最大容忍时间阈值 max.tolerate.time.difference.milliseconds内，在阈值内则线程休眠差值时间 Thread.sleep(timeDifferenceMilliseconds)，否则大于差值直接报异常。

/**

@author xiaofu
*/
public final class SnowflakeShardingKeyGenerator implements ShardingKeyGenerator{
@Getter
@Setter
private Properties properties = new Properties();

public String getType() {
return “SNOWFLAKE”;
}

public synchronized Comparable<?> generateKey() {
/**

当前系统时间毫秒数
/
long currentMilliseconds = timeService.getCurrentMillis();
/*
判断是否需要等待容忍时间差，如果需要，则等待时间差过去，然后再获取当前系统时间
/
if (waitTolerateTimeDifferenceIfNeed(currentMilliseconds)) {
currentMilliseconds = timeService.getCurrentMillis();
}
/*
如果最后一次毫秒与当前系统时间毫秒相同，即还在同一毫秒内
/
if (lastMilliseconds == currentMilliseconds) {
/*
&位与运算符：两个数都转为二进制，如果相对应位都是1，则结果为1，否则为0
当序列为4095时，4095+1后的新序列与掩码进行位与运算结果是0
当序列为其他值时，位与运算结果都不会是0
即本毫秒的序列已经用到最大值4096，此时要取下一个毫秒时间值
/
if (0L == (sequence = (sequence + 1) & SEQUENCE_MASK)) {
currentMilliseconds = waitUntilNextTime(currentMilliseconds);
}
} else {
/*
上一毫秒已经过去，把序列值重置为1
*/
vibrateSequenceOffset();
sequence = sequenceOffset;
}
lastMilliseconds = currentMilliseconds;

/**

XX…XX XX000000 00000000 00000000 时间差 XX
```
  XXXXXX XXXX0000 00000000	机器ID XX
```

             XXXX XXXXXXXX	序列号 XX

三部分进行|位或运算：如果相对应位都是0，则结果为0，否则为1
*/
return ((currentMilliseconds - EPOCH) << TIMESTAMP_LEFT_SHIFT_BITS) | (getWorkerId() << WORKER_ID_LEFT_SHIFT_BITS) | sequence;
}

/**

判断是否需要等待容忍时间差
/
@SneakyThrows
private boolean waitTolerateTimeDifferenceIfNeed(final long currentMilliseconds) {
/*
如果获取ID时的最后一次时间毫秒数小于等于当前系统时间毫秒数，属于正常情况，则不需要等待
/
if (lastMilliseconds <= currentMilliseconds) {
return false;
}
/*
===>时钟回拨的情况（生成序列的时间大于当前系统的时间），需要等待时间差
/
/*
获取ID时的最后一次毫秒数减去当前系统时间毫秒数的时间差
/
long timeDifferenceMilliseconds = lastMilliseconds - currentMilliseconds;
/*
时间差小于最大容忍时间差，即当前还在时钟回拨的时间差之内
/
Preconditions.checkState(timeDifferenceMilliseconds < getMaxTolerateTimeDifferenceMilliseconds(),
“Clock is moving backwards, last time is %d milliseconds, current time is %d milliseconds”, lastMilliseconds, currentMilliseconds);
/*
线程休眠时间差
*/
Thread.sleep(timeDifferenceMilliseconds);
return true;
}

// 配置的机器ID
private long getWorkerId() {
long result = Long.valueOf(properties.getProperty(“worker.id”, String.valueOf(WORKER_ID)));
Preconditions.checkArgument(result >= 0L && result < WORKER_ID_MAX_VALUE);
return result;
}

private int getMaxTolerateTimeDifferenceMilliseconds() {
return Integer.valueOf(properties.getProperty(“max.tolerate.time.difference.milliseconds”, String.valueOf(MAX_TOLERATE_TIME_DIFFERENCE_MILLISECONDS)));
}

private long waitUntilNextTime(final long lastTime) {
long result = timeService.getCurrentMillis();
while (result <= lastTime) {
result = timeService.getCurrentMillis();
}
return result;
}
}

但从 SNOWFLAKE 方案生成的主键ID 来看，order_id 它是一个18位的长整型数字，是不是发现它太长了，想要 MySQL 那种从 0 递增的自增主键该怎么实现呢？别急，后边已经会给出了解决办法！

自定义

sharding-jdbc 利用 SPI 全称（ Service Provider Interface）机制拓展主键生成规则，这是一种服务发现机制，通过扫描项目路径 META-INF/services 下的文件，并自动加载文件里所定义的类。

实现自定义主键生成器其实比较简单，只有两步。

第一步，实现 ShardingKeyGenerator 接口，并重写其内部方法，其中 getType() 方法为自定义的主键生产方案类型、generateKey() 方法则是具体生成主键的规则。

下面代码中用 AtomicInteger 来模拟实现一个有序自增的 ID 生成。

/**

@Author: xiaofu
@Description: 自定义主键生成器
*/
@Component
public class MyShardingKeyGenerator implements ShardingKeyGenerator {

private final AtomicInteger count = new AtomicInteger();

/**

自定义的生成方案类型
*/
@Override
public String getType() {
return “XXX”;
}

/**

核心方法-生成主键ID
*/
@Override
public Comparable<?> generateKey() {
return count.incrementAndGet();
}

@Override
public Properties getProperties() {
return null;
}

@Override
public void setProperties(Properties properties) {

}
}

第二步，由于是利用 SPI 机制实现功能拓展，我们要在 META-INF/services 文件中配置自定义的主键生成器类路劲。

com.xiaofu.sharding.key.MyShardingKeyGenerator

上面这些弄完我们测试一下，配置定义好的主键生成类型 XXX，并插入几条数据看看效果。

spring.shardingsphere.sharding.tables.t_order.key-generator.column=order_id
spring.shardingsphere.sharding.tables.t_order.key-generator.type=XXX

通过控制台的SQL 解析日志发现，order_id 字段已按照有序自增的方式插入记录，说明配置的没问题。

举一反九

既然可以自定义生成方案，那么实现分布式主键的思路就很多了，又想到之前我写的这篇《9种分布式ID生成方案》，发现可以完美兼容，这里挑选其中的滴滴（Tinyid）来实践一下，由于它是个单独的分布式ID生成服务，所以要先搭建环境了。

Tinyid 的服务提供Http 和 Tinyid-client 两种接入方式，下边使用 Tinyid-client 方式快速使用，更多的细节到这篇文章里看吧，实在是介绍过太多次了。

Tinyid 服务搭建

先拉源代码 https://github.com/didi/tinyid.git。

由于是基于号段模式实现的分布式ID，所以依赖于数据库，要创建相应的表 tiny_id_info 、tiny_id_token 并插入默认数据。

CREATE TABLE tiny_id_info (
id BIGINT (20) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT ‘自增主键’,
biz_type VARCHAR (63) NOT NULL DEFAULT ‘’ COMMENT ‘业务类型，唯一’,
begin_id BIGINT (20) NOT NULL DEFAULT ‘0’ COMMENT ‘开始id，仅记录初始值，无其他含义。初始化时begin_id和max_id应相同’,
max_id BIGINT (20) NOT NULL DEFAULT ‘0’ COMMENT ‘当前最大id’,
step INT (11) DEFAULT ‘0’ COMMENT ‘步长’,
delta INT (11) NOT NULL DEFAULT ‘1’ COMMENT ‘每次id增量’,
remainder INT (11) NOT NULL DEFAULT ‘0’ COMMENT ‘余数’,
create_time TIMESTAMP NOT NULL DEFAULT ‘2010-01-01 00:00:00’ COMMENT ‘创建时间’,
update_time TIMESTAMP NOT NULL DEFAULT ‘2010-01-01 00:00:00’ COMMENT ‘更新时间’,
version BIGINT (20) NOT NULL DEFAULT ‘0’ COMMENT ‘版本号’,
PRIMARY KEY (id),
自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

分享一些系统的面试题，大家可以拿去刷一刷，准备面试涨薪。

这些面试题相对应的技术点：

JVM
MySQL
Mybatis
MongoDB
Redis
Spring
Spring boot
Spring cloud
Kafka
RabbitMQ
Nginx
…

大类就是：

Java基础
数据结构与算法
并发编程
数据库
设计模式
微服务
消息中间件

程序员，每个月给你发多少工资，你才会想老板想的事？

程序员，每个月给你发多少工资，你才会想老板想的事？
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！
外链图片转存中…(img-hyM466Tk-1711902497010)]

[外链图片转存中…(img-eMULNF0m-1711902497011)]

[外链图片转存中…(img-Pn2dRh6T-1711902497011)]

[外链图片转存中…(img-7wkeZjib-1711902497011)]

[外链图片转存中…(img-nhEFLzOC-1711902497011)]
《一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码》，点击传送门即可获取！

2401_83641392

关注

30
点赞
踩
17

收藏

觉得还不错? 一键收藏
0
评论
别说我不告诉你！如何用分库分表的-9种分布式主键ID-生成方案？挺全乎的

利用SPI全称（）机制拓展主键生成规则，这是一种服务发现机制，通过扫描项目路径下的文件，并自动加载文件里所定义的类。实现自定义主键生成器其实比较简单，只有两步。第一步，实现接口，并重写其内部方法，其中getType()方法为自定义的主键生产方案类型、方法则是具体生成主键的规则。下面代码中用来模拟实现一个有序自增的 ID 生成。/**@Description: 自定义主键生成器*/@Component/**自定义的生成方案类型*/@Override/**
复制链接

扫一扫