《sharding-jdbc 分库分表的 4种分片策略》 中我们介绍了 sharding-jdbc 4种分片策略的使用场景，可以满足基础的分片功能开发，这篇我们来看看分库分表后，应该如何为分片表生成全局唯一的主键 ID。

引入任何一种技术都是存在风险的，分库分表当然也不例外，除非库、表数据量持续增加，大到一定程度，以至于现有高可用架构已无法支撑，否则不建议大家做分库分表，因为做了数据分片后，你会发现自己踏上了一段踩坑之路，而分布式主键 ID 就是遇到的第一个坑。

不同数据节点间生成全局唯一主键是个棘手的问题，一张逻辑表 t_order 拆分成多个真实表 t_order_n，然后被分散到不同分片库 db_0、db_1… ，各真实表的自增键由于无法互相感知从而会产生重复主键，此时数据库本身的自增主键，就无法满足分库分表对主键全局唯一的要求。

db_0–
|-- t_order_0
|-- t_order_1
|-- t_order_2
db_1–
|-- t_order_0
|-- t_order_1
|-- t_order_2
尽管我们可以通过严格约束，各个分片表自增主键的 初始值 和 步长 的方式来解决 ID 重复的问题，但这样会让运维成本陡增，而且可扩展性极差，一旦要扩容分片表数量，原表数据变动比较大，所以这种方式不太可取。

步长 step = 分表张数

db_0–
|-- t_order_0 ID: 0、6、12、18…
|-- t_order_1 ID: 1、7、13、19…
|-- t_order_2 ID: 2、8、14、20…
db_1–
|-- t_order_0 ID: 3、9、15、21…
|-- t_order_1 ID: 4、10、16、22…
|-- t_order_2 ID: 5、11、17、23…
目前已经有了许多第三放解决方案可以完美解决这个问题，比如基于 UUID、SNOWFLAKE算法 、segment号段，使用特定算法生成不重复键，或者直接引用主键生成服务，像美团（Leaf）和 滴滴（TinyId）等。

而sharding-jdbc 内置了两种分布式主键生成方案，UUID、SNOWFLAKE，不仅如此它还抽离出分布式主键生成器的接口，以便于开发者实现自定义的主键生成器，后续我们会在自定义的生成器中接入 滴滴（TinyId）的主键生成服务。

前边介绍过在 sharding-jdbc 中要想为某个字段自动生成主键 ID，只需要在 application.properties 文件中做如下配置:

主键字段

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

主键ID 生成方案

spring.shardingsphere.sharding.tables.t_order.key-generator.type=UUID

工作机器 id

spring.shardingsphere.sharding.tables.t_order.key-generator.props.worker.id=123
key-generator.column 表示主键字段，key-generator.type 为主键 ID 生成方案（内置或自定义的），key-generator.props.worker.id 为机器ID，在主键生成方案设为 SNOWFLAKE 时机器ID 会参与位运算。

在使用 sharding-jdbc 分布式主键时需要注意两点：

一旦 insert 插入操作的实体对象中主键字段已经赋值，那么即使配置了主键生成方案也会失效，最后SQL 执行的数据会以赋的值为准。
不要给主键字段设置自增属性，否则主键ID 会以默认的 SNOWFLAKE 方式生成。比如：用 mybatis plus 的 @TableId 注解给字段 order_id 设置了自增主键，那么此时配置哪种方案，总是按雪花算法生成。
下面我们从源码上分析下 sharding-jdbc 内置主键生成方案 UUID、SNOWFLAKE 是怎么实现的。

UUID
打开 UUID 类型的主键生成实现类 UUIDShardingKeyGenerator 的源码发现，它的生成规则只有 UUID.randomUUID() 这么一行代码，额~ 心中默默来了一句卧槽。

UUID 虽然可以做到全局唯一性，但还是不推荐使用它作为主键，因为我们的实际业务中不管是 user_id 还是 order_id 主键多为整型，而 UUID 生成的是个 32 位的字符串。

它的存储以及查询对 MySQL 的性能消耗较大，而且 MySQL 官方也明确建议，主键要尽量越短越好，作为数据库主键 UUID 的无序性还会导致数据位置频繁变动，严重影响性能。

public final class UUIDShardingKeyGenerator implements ShardingKeyGenerator {
private Properties properties = new Properties();

public UUIDShardingKeyGenerator() {
}public String getType() {return "UUID";
}public synchronized Comparable<?> generateKey() {return UUID.randomUUID().toString().replaceAll("-", "");
}public Properties getProperties() {return this.properties;
}public void setProperties(Properties properties) {this.properties = properties;
}

}

SNOWFLAKE
SNOWFLAKE（雪花算法）是默认使用的主键生成方案，生成一个 64bit的长整型（Long）数据。

sharding-jdbc 中雪花算法生成的主键主要由 4部分组成，1bit符号位、41bit时间戳位、10bit工作进程位以及 12bit 序列号位。

雪花算法ID组成

符号位（1bit位）
Java 中 Long 型的最高位是符号位，正数是0，负数是1，一般生成ID都为正数，所以默认为0

时间戳位（41bit）
41位的时间戳可以容纳的毫秒数是 2 的 41次幂，而一年的总毫秒数为 1000L * 60 * 60 * 24 * 365，计算使用时间大概是69年，额~，我有生之间算是够用了。

Math.pow(2, 41) / (365 * 24 * 60 * 60 * 1000L) = = 69年
工作进程位（10bit）
表示一个唯一的工作进程id，默认值为 0，可通过 key-generator.props.worker.id 属性设置。

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 TianL
  */
  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 递增的自增主键该怎么实现呢？别急，后边已经会给出了解决办法！

SNOWFLAKE 主键ID

自定义
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
自定义主键 SPI 配置

上面这些弄完我们测试一下，配置定义好的主键生成类型 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),
UNIQUE KEY uniq_biz_type (biz_type)
) ENGINE = INNODB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8 COMMENT ‘id信息表’;

CREATE TABLE tiny_id_token (
id INT (11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT ‘自增id’,
token VARCHAR (255) NOT NULL DEFAULT ‘’ COMMENT ‘token’,
biz_type VARCHAR (63) NOT NULL DEFAULT ‘’ COMMENT ‘此token可访问的业务类型标识’,
remark VARCHAR (255) NOT NULL DEFAULT ‘’ 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 ‘更新时间’,
PRIMARY KEY (id)
) ENGINE = INNODB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8 COMMENT ‘token信息表’;

INSERT INTO tiny_id_token (id, token, biz_type, remark, create_time, update_time) VALUES (‘1’, ‘0f673adf80504e2eaa552f5d791b644c’, ‘order’, ‘1’, ‘2017-12-14 16:36:46’, ‘2017-12-14 16:36:48’);

INSERT INTO tiny_id_info (id, biz_type, begin_id, max_id, step, delta, remainder, create_time, update_time, version) VALUES (‘1’, ‘order’, ‘1’, ‘1’, ‘100000’, ‘1’, ‘0’, ‘2018-07-21 23:52:58’, ‘2018-07-22 23:19:27’, ‘1’);

并在 Tinyid 服务中配置上边表所在数据源信息

datasource.tinyid.primary.url=jdbc:mysql://47.93.6.e:3306/ds-0?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8
datasource.tinyid.primary.username=root
datasource.tinyid.primary.password=root
最后项目 maven install ，右键 TinyIdServerApplication 启动服务， Tinyid 分布式ID生成服务就搭建完毕了。

自定义 Tinyid 主键类型
Tinyid 服务搭建完下边在项目中引入它，新建个 tinyid_client.properties 文件其中添加 tinyid.server 和 tinyid.token 属性，token 为之前 SQL 预先插入的用户数据。

tinyid 分布式ID

服务地址

tinyid.server=127.0.0.1:9999

业务token

tinyid.token=0f673adf80504e2eaa552f5d791b644c
代码中获取 ID更简单，只需一行代码，业务类型 order 是之前 SQ L 预先插入的数据。

Long id = TinyId.nextId(“order”);
我们开始自定义 Tinyid 主键生成类型的实现类 TinyIdShardingKeyGenerator 。

/**

• @Author: xiaofu

• @Description: 自定义主键生成器
  */
  @Component
  public class TinyIdShardingKeyGenerator implements ShardingKeyGenerator {

  /**

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

  /**

  • 核心方法-生成主键ID
    */
    @Override
    public Comparable<?> generateKey() {

    Long id = TinyId.nextId(“order”);

    return id;
    }

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

  @Override
  public void setProperties(Properties properties) {

  }
  }
  并在配置文件中启用 Tinyid 主键生成类型，到此配置完毕，赶紧测试一下。

主键字段

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

主键ID 生成方案

spring.shardingsphere.sharding.tables.t_order.key-generator.type=tinyid
测试 Tinyid 主键
向数据库插入订单记录测试发现，主键ID字段 order_id 已经为趋势递增的了， Tinyid 服务成功接入，完美！

在这里插入图片描述

总结
后续的八种生成方式大家参考 《9种 分布式ID生成方案》 按需接入吧，整体比较简单这里就不依次实现了。

分库分表的 9种分布式主键ID 生成方案相关推荐

1. 分库分表的 9种分布式主键ID 生成方案，挺全乎的

   <sharding-jdbc 分库分表的 4种分片策略> 中我们介绍了 sharding-jdbc 4种分片策略的使用场景,可以满足基础的分片功能开发,这篇我们来看看分库分表后,应该如何为 ...

2. 如何用分库分表的9种分布式主键ID生成方案？完整PDF

   前言 前段时间,我向一位在阿里的朋友寻求进大厂的秘诀,他分享给我一份阿里内部资料--JAVA核心进阶手册,仔细翻阅一番才知道里面收纳整理的知识可真是齐全,不得不来感叹一番- 我将JAVA核心进阶手册大 ...

3. 如何用分库分表的9种分布式主键ID生成方案？附小技巧

   1. 前言 大家都知道,Postman是一个非常受欢迎的API接口调试工具,提供有Chrome扩展插件版和独立的APP,不过它的很多高级功能都需要付费才能使用. 如果你连Postman都还没有用过,不 ...

4. Mysql系列七：分库分表技术难题之分布式全局唯一id解决方案

   Mysql系列七:分库分表技术难题之分布式全局唯一id解决方案 参考文章: (1)Mysql系列七:分库分表技术难题之分布式全局唯一id解决方案 (2)https://www.cnblogs.com/ ...

5. 数据库分库分表的几种方式

   随着业务的不断增长,数据库中的数据也会越来越多,数据库的压力也会越来越大,我们会发现,在业务繁忙的时候,数据库的性能会直线下降,这时为了保证良好的性能,不得不想办法来分担数据库的压力,前面在介绍数据库 ...

6. 分库分表的几种常见形式以及可能遇到的难题--转

   原文地址:http://chuansong.me/n/720045751960 在谈论数据库架构和数据库优化的时候,我们经常会听到"分库分表"."分片".&qu ...

7. 分库分表的几种常见形式以及可能遇到的难

   在谈论数据库架构和数据库优化的时候,我们经常会听到"分库分表"."分片"."Sharding"-这样的关键词.让人感到高兴的是,这些朋友所服 ...

8. 分库分表的几种常见形式以及可能遇到的难题

   前言 在谈论数据库架构和数据库优化的时候,我们经常会听到"分库分表"."分片"."Sharding"-这样的关键词.让人感到高兴的是,这些朋 ...

9. sharding-jdbc 分库分表的 4种分片策略，还蛮简单的

   上文<快速入门分库分表中间件 Sharding-JDBC (必修课)>中介绍了 sharding-jdbc 的基础概念,还搭建了一个简单的数据分片案例,但实际开发场景中要远比这复杂的多,我 ...

最新文章

1. URL和URI的区别 【转】
2. 【PHPWord】TitleTOC
3. 客户端程序初步加入网络通讯的功能
4. android覆盖扩散动画,[Android]多层波纹扩散动画——自定义View绘制
5. pip命令安装pygeme后 IDLE import pygame报错
6. lambda表达式学习（详细理解 ） 重点在最后
7. [转载] Java 方法(方法重载)与数组
8. numpy - np.reshape：将二维数组转变三维数组
9. DevExpress ChartControl 绘制圆滑曲线
10. js 对中文字符的 解码 与 编码
11. sci计算机论文发表论文格式,SCI论文发表的格式以及字体的要求是什么？
12. 浏览器默认主页被篡改（chrome,IE）
13. 无线路由器DNS服务器异常,fast无线路由器dns异常的解决方法
14. 案牍写作中要留意的问题
15. poj 1815 最小点割集
16. Proguard 常用规则
17. 金融机构的反洗钱(AML)合规工作和系统建设
18. ctf的web题目php,32C3 CTF 两个Web题目的Writeup
19. 把SubText1.9.4(类似.Text单用户)免安装源码发给大家
20. 撑起个人信息安全“保护伞”

热门文章

1. Python爬虫 爬取豆瓣电影TOP250
2. 产品经理也能动手实践的AI（四）- 多标签识别，图像分割
3. 边拆边聊——简单了解DLP投影结构与成像原理
4. 不一样的视角，不一样的VR
5. 工业镜头基础知识整理
6. studing（来自转载）
7. 利用PyQt5制作本地音乐播放器
8. 测量标准误(Standard Error of Measurement；SEm)
9. 导致联想拯救者y7000触控板失灵的一种可能
10. 多元线性回归分析spss结果解读_SPSS经典线性回归分析之一——线性回归分析