1对多业务，数据库水平切分架构一次搞定

发布时间：2025-11-04 20:18:07 来源：云智核 作者：人工智能

本文将以“帖子中心”为例，对多介绍“1对多”类业务，业务随着数据量的数据逐步增大，数据库性能显著降低，库水数据库水平切分相关的平切架构实践：

一、什么是分架1对多关系

所谓的“1对1”，“1对多”，构次搞定“多对多”，对多来自数据库设计中的业务“实体-关系”ER模型，用来描述实体之间的数据映射关系。

1对1

这是分架一个1对1的关系。

1对多

这是一个1对多的关系。

多对多

这是一个多对多的关系。

二、帖子中心业务分析

帖子中心是一个典型的源码下载1对多业务。

一个用户可以发布多个帖子，一个帖子只对应一个发布者。

任何脱离业务的架构设计都是耍流氓，先来看看帖子中心对应的业务需求。

帖子中心，是一个提供帖子发布/修改/删除/查看/搜索的服务。

写操作：

读操作：

在数据量较大，并发量较大的时候，通常通过元数据与索引数据分离的架构来满足不同类型的需求：

架构中的几个关键点：

其中，tiezi-center和tiezi-search分别满足两类不同的读需求：

如上图所示：

对于写需求：

如上图所示：

tiezi-search，搜索架构不是本文的重点(外置索引架构设计，请参见《100亿数据1万属性数据架构设计》)，后文将重点描述帖子中心元数据这一块的水平切分设计。

三、帖子中心元数据设计

通过帖子中心业务分析，很容易了解到，其核心元数据为：

其中：

数据库设计上，在业务初期，单库就能满足元数据存储要求，其典型的架构设计为：

在相关字段上建立索引，就能满足相关业务需求：

四、帖子中心水平切分-tid切分法

当数据量越来越大时，需要对帖子数据的存储进行线性扩展。

既然是IT技术网帖子中心，并且帖子记录查询量占了总请求的90%，很容易想到通过tid字段取模来进行水平切分：

这个方法简单直接，优点：

缺点：

如上图，一个uid访问需要遍历所有库。

五、帖子中心水平切分-uid切分法

有没有一种切分方法，确保同一个用户发布的所有帖子都落在同一个库上，而在查询一个用户发布的所有帖子时，不需要去遍历所有的库呢?

答：使用uid来分库可以解决这个问题。

新出现的问题：如果使用uid来分库，确保了一个用户的帖子数据落在同一个库上，那通过tid来查询，就不知道这个帖子落在哪个库上了，岂不是还需要遍历全库，需要怎么优化呢?

答：tid的查询是单行记录查询，只要在数据库(或者缓存)记录tid到uid的映射关系，就能解决这个问题。

新增一个索引库：

使用uid分库，并增加索引库记录tid到uid的映射关系之后，每当有uid上的查询：

可以通过uid直接定位到库。

每当有tid上的查询：

这个方法的优点：

缺点：

六、帖子中心水平切分-基因法

有没有一种方法，既能够通过uid定位到库，又不需要建立索引表来进行二次查询呢，这就是本文要叙述的“1对多”业务分库***实践，基因法。

什么是分库基因?

通过uid分库，假设分为16个库，采用uid%16的方式来进行数据库路由，这里的uid%16，其本质是uid的***4个bit决定这行数据落在哪个库上，这4个bit，就是分库基因。

什么是基因法分库?

在“1对多”的业务场景，使用“1”分库，在“多”的数据id生成时，id末端加入分库基因，就能同时满足“1”和“多”的分库查询需求。

如上图所示，uid=666的用户发布了一条帖子(666的二进制表示为：1010011010)：

(怎么生成60bit分布式唯一ID，请参见《分布式ID生成算法》)

这般，保证了同一个用户发布的所有帖子的tid，都落在同一个库上，tid的***4个bit都相同，于是：

潜在问题一：同一个uid发布的tid落在同一个库上，会不会出现数据不均衡?

答：只要uid是均衡的，每个用户发布的平均帖子数是均衡的，每个库的数据就是均衡的。

潜在问题二：最开始分16库，分库基因是4bit，未来要扩充成32库，分库基因变成了5bit，那怎么办?

答：需要提前做好容量预估，例如事先规划好5年内数据增长256库足够，就提前预留8bit基因。

七、总结

将以“帖子中心”为典型的“1对多”类业务，在架构上，采用元数据与索引数据分离的架构设计方法：

对于元数据的存储，在数据量较大的情况下，有三种常见的切分方法：

对于1对多的业务场景，分库架构不再是瓶颈。

【本文为专栏作者“58沈剑”原创稿件，转载请联系原作者】

戳这里，看该作者更多好文

相关文章