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每一页能存储的数量会变少,层高可能会变高,性能下降。

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

相关推荐
bobz9656 分钟前
ovs patch port 对比 veth pair
后端
Asthenia041216 分钟前
Java受检异常与非受检异常分析
后端
uhakadotcom30 分钟前
快速开始使用 n8n
后端·面试·github
JavaGuide37 分钟前
公司来的新人用字符串存储日期,被组长怒怼了...
后端·mysql
bobz9651 小时前
qemu 网络使用基础
后端
Asthenia04121 小时前
面试攻略:如何应对 Spring 启动流程的层层追问
后端
Asthenia04121 小时前
Spring 启动流程:比喻表达
后端
Asthenia04122 小时前
Spring 启动流程分析-含时序图
后端
ONE_Gua2 小时前
chromium魔改——CDP(Chrome DevTools Protocol)检测01
前端·后端·爬虫
致心2 小时前
记一次debian安装mariadb(带有迁移数据)
后端