引入任何一种技术都是存在风险的,分库分表当然也不例外,除非库、表数据量持续增加,大到一定程度,以至于现有高可用架构已无法支撑,否则不建议大家做分库分表,因为做了数据分片后,你会发现自己踏上了一段踩坑之路,而分布式主键 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# 工作机器 idspring.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 序列号位。 符号位(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年 …