主键重复问题

虽然使用MySQL自带的主键自增很简单，但是完全无法满足实际生产环境中的要求，这就是分布式系统中经典的全局唯一ID（Globally Unique Identifier，GUID）问题。

目前为止，这个问题的解决办法归纳起来有七、八种，包括UUID、单库自增、集群自增、号段自增、Redis自增、雪花算法、国内开源算法等诸多方案。

每一种都有其自身的适用场景和优缺点，不过使用得较为普遍的还是Twitter开源的SnowFlake算法。

而ShardingSphere则支持使用SnowFlake算法生成主键。

修改配置文件application.properties，加入如下内容（其他地方不用修改）。

......

# 指定workId
spring.shardingsphere.sharding.tables.t_order.key-generator.props.worker.id=1

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

......

修改实体类，注释掉Order中的ID生成方式。

......

// 指定逻辑表名
@TableName("t_order")
public class Order {
    // 注释掉ID生成注解，由ShardingSphere来生成
    // @TableId(value = "id", type = IdType.ASSIGN_ID)
    private Long id;

    ......
}

修改之后再次执行ShardingJDBCTest类中的测试方法，从结果可以看到：itechthink_order_0、itechthink_order_1和itechthink_order_2这三个数据库中每一张表的id字段都是由SnowFlake算法生成的全局唯一ID（GUID）。

mysql> select * from t_order_0;
+---------------------+--------+------------------------------+-------+--------+---------------------+
| id                  | userid | tradeno                      | state | money  | createtime          |
+---------------------+--------+------------------------------+-------+--------+---------------------+
| 1822924422558851073 |      0 | 81af932f78064244a03a441f8996 |     1 | 168.00 | 2023-06-08 22:13:45 |
| 1822924425557778434 |      2 | fc426bd41af242abb705d1d0417f |     1 | 168.00 | 2023-06-08 22:13:46 |
| 1822924425637470210 |      4 | 2332b4705ec14a8e9a8caba0927e |     1 | 168.00 | 2023-06-08 22:13:46 |
| 1822924425708773378 |      6 | eada6f116efd4dd88429ac6dfcde |     1 | 168.00 | 2023-06-08 22:13:46 |
| 1822924425788465153 |      8 | 84d45c5645b3481396402649e301 |     1 | 168.00 | 2023-06-08 22:13:46 |
+---------------------+--------+------------------------------+-------+--------+---------------------+
5 rows in set (0.00 sec)

---

感谢支持

更多内容，请移步《超级个体》。