mysql分库分表,分布式id生成器的意义

  • 可以使用主键进行删改查

大型系统架构时,最推荐的就是使用主键查询,和以前在猫眼的同事聊过,他们使用数据库有规定,只能通过主键删改查数据,稍微复杂点的sql是不允许使用的,甚至连连接查询都被禁止使用的。

  • 绝对不能使用自增id

绝大多数程序员在使用mysql时都会使用自增主键,但是它的自增仅仅是适合单机版的,如果项目后期要涉及到分库分表,自增Id的维护成本会非常大,所以在设计数据库之初,分库分表的需求一定要考虑进去

比如,在开始你做2个分表,那么这个自增长id的步长设置为2

第一个表,它的id可以是:1,3,5,7,9

第二个表,它的id可以是:2,4,6,8

mysql分库分表,分布式id生成器的意义_第1张图片

这样看起来是可以玩的,但是数据库表再进行扩展,加2张表,你的id怎么做,改变步长?修改数据?等等都会是非常头疼的事

  • 分库分表时,主键应该怎么处理

首先,分库分表,我们一般考虑的是 Hash 键,它不一定要用表的主键,但是,很多时候直接就拿主键来用了。

其次,“自增”这东西,只是现象,不是实现方式。正常点的关系数据库(Postgresql,Oracle之类的),都有 sequence ,序列这个机制,“自增”只是帮你定义了一个 sequence ,每次取值都从序列当中取一个,值是什么,就是序列怎么实现的事了。 MySQL 没有序列,问题就麻烦了。

在有序列机制的情况下,分表根本不是事,当要让多表使用同一个序列就可以了,对吧。

分库的话,就一定需要引入外部的“序列生成器”了。

Hash 键的处理是分库分表的基础,不是一个用不用自增 ID 这么简单的一个点的了。而且,一个专门的解决方案,暴露给使用者的,主键上其实也是“自增 ID”,只是它这个的“序列生成器”肯定不是系统默认自带的那套了嘛

  • 最幸福的主键

在大型电商架构中,订单id都是由订单系统生成,然后下游系统接消息,对订单处理,比如仓储系统,会通过调度系统接收到订单及订单详情,这时候的Id已经由上游系统生成完成,我们只需要做消息幂等性处理,就可以很easy的将订单数据分别入到对应的数据库中

mysql分库分表,分布式id生成器的意义_第2张图片

你可能感兴趣的:(mysql分库分表,分布式id生成器的意义)