单KEY业务，数据库水平切分架构实践 | 架构师之路

提醒，本文较长，可提前收藏/转发。

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

• 如何来实施水平切分

• 水平切分后常见的问题

• 典型问题的优化思路及实践

 

一、用户中心

用户中心是一个非常常见的业务，主要提供用户注册、登录、信息查询与修改的服务，其核心元数据为：

User(uid, login_name, passwd, sex, age, nickname, …)

其中：

• uid为用户ID，主键

• login_name, passwd, sex, age, nickname, …等用户属性

数据库设计上，一般来说在业务初期，单库单表就能够搞定这个需求，典型的架构设计为：

• user-center：用户中心服务，对调用者提供友好的RPC接口

• user-db：对用户进行数据存储

 

二、用户中心水平切分方法

当数据量越来越大时，需要对数据库进行水平切分，常见的水平切分算法有“范围法”和“哈希法”。

 

范围法，以用户中心的业务主键uid为划分依据，将数据水平切分到两个数据库实例上去：

• user-db1：存储0到1千万的uid数据

• user-db2：存储1到2千万的uid数据

 

范围法的优点是：

• 切分策略简单，根据uid，按照范围，user- center很快能够定位到数据在哪个库上

• 扩容简单，如果容量不够，只要增加user-db3即可

范围法的不足是：

• uid必须要满足递增的特性

• 数据量不均，新增的user-db3，在初期的数据会比较少

• 请求量不均，一般来说，新注册的用户活跃度会比较高，故user-db2往往会比user-db1负载要高，导致服务器利用率不平衡

 

哈希法，也是以用户中心的业务主键uid为划分依据，将数据水平切分到两个数据库实例上去：