Java 分布式主键策略

背景

随着业务的增长,文章表可能要占用很大的物理存储空间,为了解决该问题,后期使用数据库分片技术。

将一个数据库进行拆分,通过数据库中间件连接。如果数据库中该表选用ID自增策略,则可能产生重复的ID,

此时应该使用分布式ID生成策略来生成ID。

技术选型

方案 优势 劣势
Redis (INCR)生成一个全局连续递增的类型主键 增加了一个外部组件的依赖,Redis不可用,则整个(INCR)生成一个全局连续递增的数字类数据库将无法在插入
UUID 全局唯一,Mysql也有UUID实现 36个字符组成,占用空间大
Snowflake算法 全局唯一,数字类型,存储成本低 机器规模大于1024台无法支持

雪花算法

snowflake是Twitter开源的分布式ID生成算法,结果是一个ong型的ID。

其核心思想是: 使用41bit作为毫秒数,10bit作为机器的ID(5个bit是数据中心,5个bit的机器ID),12bt作为毫秒内的流水号(意味着每个节点在每毫秒可以产生4096个ID),最后还有一个符号位,永远是0

设置雪花算法

实体类上添加注解@TableId(value = "id",type =IdType.ASSIGN_ID )

kotlin 复制代码
@TableId(value = "id",type =IdType.ASSIGN_ID )
private Long id;

此外,还可以指定机房id和机器id

yaml 复制代码
mybatis-plus:
    global-config:
        # 机房id 0-31
        datacenter-id: 1
        # 机器id
        workerId: 1

小结

数据库的索引是由id进行组织的一个b+树,而b+树这种数据结构,本身是一种有序的多叉树,使用自增id可以减少维护b+带来的性能开销;其次自增id通常使用个id类型的自增类型,而uuid是字符串,字符串所占用的内存空间比long大得多;同时在非聚簇索引每一个非叶子节点存储的就是主键,这也就意味着如果使用uuid每一页能存储的数量会变少,层高可能会变高,性能下降。

但是实际上我们的业务并没有特别高的并发量,并不会要求极致的性能,人员成本、开发周期等因素怎么也需要考虑;很多场景快速的当主键,也是不错的选择。

相关推荐
你三大爷15 分钟前
Safepoint的秘密探寻
java·后端
福大大架构师每日一题30 分钟前
2025-10-02:不同 XOR 三元组的数目Ⅰ。用go语言,给你一个长度为 n 的数组 nums,数组恰好包含 1 到 n 这 n 个整数(每个数出现一次)
后端
王嘉俊9251 小时前
Django 入门:快速构建 Python Web 应用的强大框架
前端·后端·python·django·web·开发·入门
拾忆,想起1 小时前
RabbitMQ死信交换机:消息的“流放之地“
开发语言·网络·分布式·后端·性能优化·rabbitmq
IT_陈寒2 小时前
Redis性能翻倍的5个冷门技巧,90%的开发者从不知道第3点!
前端·人工智能·后端
uhakadotcom3 小时前
入门教程:常用的 Python 第三方库:python-logstash
后端·面试·github
掘金一周3 小时前
🍏让前端去做 iPhone 的液态玻璃❓ | 掘金一周 10.2
前端·人工智能·后端
9号达人3 小时前
Java19 新特性详解与实践
java·后端·面试
银剑3 小时前
微服务安全认证演进之路:增强型Bearer Token架构实战
后端
绝无仅有3 小时前
资深面试之MySQL 问题及解答(一)
后端·面试·github