Database Sharding-02-分库分表实战 in action

单 key 业务

用户中心

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

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

其中：

uid 为用户ID，主键

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

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

+-------------+
| user-center |
+-------------+
  |
  |
  v
+-------------+
|   user-db   |
+-------------+

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

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

用户中心水平切分方法

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

范围法

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

+----------+  (1kW-2kW)   +-------------+
| user-db2 | <----------- | user-center |
+----------+              +-------------+
                            |
                            | (0-1kW)
                            v
                          +-------------+
                          |  user-db1   |
                          +-------------+

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

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

• 优点

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

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

• 不足

1. uid 必须要满足递增的特性

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

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

Hash 法

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

+----------+    (%2==1)   +-------------+
| user-db2 | <----------- | user-center |
+----------+              +-------------+
                            |
                            | (%2==0)
                            v
                          +-------------+
                          |  user-db1   |
                          +-------------+

user-db1：存储uid取模得1的uid数据

user-db2：存储uid取模得0的uid数据

• 优点

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

2. 数据量均衡，只要uid是均匀的，数据在各个库上的分布一定是均衡的

3. 请求量均衡，只要uid是均匀的，负载在各个库上的分布一定是均衡的

• 不足

扩容麻烦，如果容量不够，要增加一个库，重新 hash 可能会导致数据迁移，如何平滑的进行数据迁移，是一个需要解决的问题

水平切分问题

使用uid来进行水平切分之后，整个用户中心的业务访问会遇到什么问题呢？

对于uid属性上的查询可以直接路由到库，假设访问 uid=124 的数据，取模后能够直接定位db-user1：

但是对于 login_name='test' 的无法定位，则必须全表扫描，很麻烦。

如何解决分库后，非uid属性上的查询问题，是后文要重点讨论的内容。

需求分析

用户中心非 uid 属性上经常有两类业务需求：

（1）用户侧，前台访问，最典型的有两类需求

用户登录：通过login_name/phone/email查询用户的实体，1%请求属于这种类型

用户信息查询：登录之后，通过uid来查询用户的实例，99%请求属这种类型

用户侧的查询基本上是单条记录的查询，访问量较大，服务需要高可用，并且对一致性的要求较高。

（2）运营侧，后台访问，根据产品、运营需求，访问模式各异，按照年龄、性别、头像、登陆时间、注册时间来进行查询。

运营侧的查询基本上是批量分页的查询，由于是内部系统，访问量很低，对可用性的要求不高，对一致性的要求也没这么严格。

这两类不同的业务需求，应该使用什么样的架构方案来解决呢？

用户中心水平切分架构思路

用户中心在数据量较大的情况下，使用uid进行水平切分。

对于非uid属性上的查询需求，架构设计的核心思路为：

• 针对用户侧，应该采用“建立非uid属性到uid的映射关系”的架构方案

• 针对运营侧，应该采用“前台与后台分离”的架构方案

用户中心-用户侧最佳实践

索引表法

• 思路

uid能直接定位到库，login_name不能直接定位到库，如果通过login_name能查询到uid，问题解决

• 解决方案

建立一个索引表记录login_name->uid的映射关系

用login_name来访问时，先通过索引表查询到uid，再定位相应的库

索引表属性较少，可以容纳非常多数据，一般不需要分库

如果数据量过大，可以通过login_name来分库

• 潜在不足

多一次数据库查询，性能下降一倍

缓存映射法

• 思路

访问索引表性能较低，把映射关系放在缓存里性能更佳

• 解决方案：

login_name查询先到cache中查询uid，再根据uid定位数据库

假设cache miss，采用扫全库法获取login_name对应的uid，放入cache

login_name到uid的映射关系不会变化，映射关系一旦放入缓存，不会更改，无需淘汰，缓存命中率超高

如果数据量过大，可以通过login_name进行cache水平切分

潜在不足：多一次cache查询

login_name 生成 uid

• 思路

不进行远程查询，由login_name直接得到uid

• 解决方案

在用户注册时，设计函数login_name生成uid，uid=f(login_name)，按uid分库插入数据

用login_name来访问时，先通过函数计算出uid，即uid=f(login_name)再来一遍，由uid路由到对应库

• 潜在不足

该函数设计需要非常讲究技巧，有uid生成冲突风险

login_name 基因融入 uid

• 思路

不能用login_name生成uid，可以从login_name抽取“基因”，融入uid中

假设分8库，采用uid%8路由，潜台词是，uid的最后3个bit决定这条数据落在哪个库上，这3个bit就是所谓的“基因”。

• 解决方案

在用户注册时，设计函数login_name生成3bit基因，login_name_gene=f(login_name)。

同时，生成61bit的全局唯一id，作为用户的标识

接着把3bit的login_name_gene也作为uid的一部分

生成64bit的uid，由id和login_name_gene拼装而成，并按照uid分库插入数据

用login_name来访问时，先通过函数由login_name再次复原3bit基因，login_name_gene=f(login_name)，通过login_name_gene%8直接定位到库

ps: 这种方法非常之巧妙。

用户中心-运营侧最佳实践

前台用户侧，业务需求基本都是单行记录的访问，只要建立非uid属性 login_name / phone / email 到uid的映射关系，就能解决问题。

后台运营侧，业务需求各异，基本是批量分页的访问，这类访问计算量较大，返回数据量较大，比较消耗数据库性能。

如果此时前台业务和后台业务公用一批服务和一个数据库，有可能导致，由于后台的“少数几个请求”的“批量查询”的“低效”访问，导致数据库的cpu偶尔瞬时100%，影响前台正常用户的访问（例如，登录超时）。

而且，为了满足后台业务各类“奇形怪状”的需求，往往会在数据库上建立各种索引，这些索引占用大量内存，会使得用户侧前台业务uid/login_name上的查询性能与写入性能大幅度降低，处理时间增长。

前台与后台分离

对于这一类业务，应该采用“前台与后台分离”的架构方案：

用户侧前台业务需求架构依然不变，产品运营侧后台业务需求则抽取独立的web/service/db 来支持，解除系统之间的耦合。

对于“业务复杂”“并发量低”“无需高可用”“能接受一定延时”的后台业务：

可以去掉service层，在运营后台web层通过dao直接访问db

不需要反向代理，不需要集群冗余

不需要访问实时库，可以通过MQ或者线下异步同步数据

在数据库非常大的情况下，可以使用更契合大量数据允许接受更高延时的“索引外置”或者“HIVE”的设计方案

1 对多业务

1 对多关系

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

1 对 1

一个用户只有一个登录名，一个登录名只对应一个用户

一个uid对应一个login_name，一个login_name只对应一个uid

这是一个1对1的关系。

1对多

一个用户可以发多条微博，一条微博只有一个发送者

一个uid对应多个msg_id，一个msg_id只对应一个uid

这是一个1对多的关系。

多对多

一个用户可以关注多个用户

一个用户也可以被多个粉丝关注

这是一个多对多的关系。

帖子中心业务分析

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

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

• 写操作

发布(insert)帖子

修改(update)帖子

删除(delete)帖子

• 读操作

通过tid查询(select)帖子实体，单行查询

通过uid查询(select)用户发布过的帖子，列表查询

帖子检索(search)，例如通过时间、标题、内容搜索符合条件的帖子

元数据与索引数据分离

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

写需求

+------------------+  CUD   +----+     +--------------+  Modify Index   +-------------+
|   tiezi center   | -----> | MQ | --> | tiezi-search | --------------> | tiezi-index |
+------------------+        +----+     +--------------+                 +-------------+
  |
  | Modify Metadata
  v
+------------------+
|     tiezi db     |
+------------------+

如上图所示：

增加，修改，删除的操作都会从tiezi-center发起

tiezi-center 修改元数据

tiezi-center 将信息修改通知发送给MQ

tiezi-search 从MQ接受修改信息

tiezi-search 修改索引数据

ps: tiezi-search，搜索架构不是本文的重点（外置索引架构设计，请参见《100亿数据1万属性数据架构设计》）。

帖子中心元数据设计

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

Tiezi(tid, uid, time, title, content, …);

其中：

tid为帖子ID，主键

uid为用户ID，发帖人

time, title, content … 等为帖子属性

初期单库

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

tiezi-center：帖子中心服务，对调用者提供友好的RPC接口

tiezi-db：对帖子数据进行存储

• 索引

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

帖子记录查询，通过tid查询，约占读请求量90%

select * from t_tiezi where tid=$tid

帖子列表查询，通过uid查询其发布的所有帖子，约占读请求量10%

select * from t_tiezi where uid=$uid

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

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

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

比如 hash 或者范围法。

优点

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

100%写请求可以直接定位到库

90%的读请求可以直接定位到库

不足

一个用户发布的所有帖子可能会落到不同的库上，10%的请求通过uid来查询会比较麻烦

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

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

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

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

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

• 索引库

新增一个索引库：

t_mapping(tid, uid);

这个库只有两列，可以承载很多数据

即使数据量过大，索引库可以利用tid水平切分

这类kv形式的索引结构，可以很好的利用cache优化查询性能

一旦帖子发布，tid和uid的映射关系就不会发生变化，cache的命中率会非常高

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

查询场景

• uid

直接 hash 定位到对应的库

• tid

1. 先查询索引表，通过tid查询到对应的uid

2. 同上

优缺点

• 优点

一个用户发布的所以帖子落在同一个库上

10%的请求过过uid来查询列表，可以直接定位到库

索引表cache命中率非常高，因为tid与uid的映射关系不会变

• 缺点

90%的tid请求，以及100%的修改请求，不能直接定位到库，需要先进行一次索引表的查询，当然这个查询非常块，通常在5ms内可以返回

数据插入时需要操作元数据与索引表，可能引发潜在的一致性问题

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

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

什么是分库基因？

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

什么是基因法分库？

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

uid=666的用户发布了一条帖子（666的二进制表示为：1010011010）：

1. 使用uid%16分库，决定这行数据要插入到哪个库中

2. 分库基因是uid的最后4个bit，即1010

3. 在生成tid时，先使用一种分布式ID生成算法生成前60bit

4. 将分库基因加入到tid的最后4个bit

5. 拼装成最终的64bit帖子tid

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

• 通过uid%16能够定位到库

• 通过tid%16也能定位到库

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

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

最开始分16库，分库基因是4bit，未来要扩充成32库，分库基因变成了5bit，那怎么办？

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

多对多业务

好友中心业务分析

好友关系主要分为两类，弱好友关系与强好友关系，两类都有典型的互联网产品应用。

弱好友关系的建立，不需要双方彼此同意

用户A关注用户B，不需要用户B同意，此时用户A与用户B为弱好友关系，对A而言，暂且理解为“关注”；

用户B关注用户A，也不需要用户A同意，此时用户A与用户B也为弱好友关系，对A而言，暂且理解为“粉丝”；

微博粉丝是一个典型的弱好友关系应用。

强好友关系的建立，需要好友关系双方彼此同意

用户A请求添加用户B为好友，用户B同意，此时用户A与用户B则互为强好友关系，即A是B的好友，B也是A的好友；

QQ好友是一个典型的强好友关系应用。

好友中心

好友中心是一个典型的多对多业务，一个用户可以添加多个好友，也可以被多个好友添加，其典型架构为：

friend-service：好友中心服务，对调用者提供友好的RPC接口

db：对好友数据进行存储

弱好友关系-元数据简版实现

通过弱好友关系业务分析，很容易了解到，其核心元数据为：

guanzhu(uid, guanzhu_uid);

fensi(uid, fensi_uid);

其中：

guanzhu表，用户记录uid所有关注用户guanzhu_uid

fensi表，用来记录uid所有粉丝用户fensi_uid

需要强调的是，一条弱关系的产生，会产生两条记录，一条关注记录，一条粉丝记录。

例如：用户A(uid=1)关注了用户B(uid=2)，A多关注了一个用户，B多了一个粉丝，于是：

guanzhu表要插入{1, 2}这一条记录，1关注了2

fensi表要插入{2, 1}这一条记录，2粉了1

• 如何查询一个用户关注了谁呢？

回答：在guanzhu的uid上建立索引：

select * from guanzhu where uid=1;

即可得到结果，1关注了2。

• 如何查询一个用户粉了谁呢？

如何查询一个用户粉了谁呢？

回答：在fensi的uid上建立索引：

select * from fensi where uid=2;

即可得到结果，2粉了1。

强好友关系-元数据实现一

通过强好友关系业务分析，很容易了解到，其核心元数据为：

friend(uid1, uid2);

其中：

uid1，强好友关系中一方的uid

uid2，强好友关系中另一方的uid

uid=1的用户添加了uid=2的用户，双方都同意加彼此为好友，这个强好友关系，在数据库中应该插入记录{1, 2}还是记录{2,1}呢？

回答：都可以

为了避免歧义，可以人为约定，插入记录时uid1的值必须小于uid2。

• 例子

例如：有uid=1,2,3三个用户，他们互为强好友关系，那边数据库中可能是这样的三条记录

{1, 2}

{2, 3}

{1, 3}

• 如何查询一个用户的好友呢？

回答：假设要查询uid=2的所有好友，只需在uid1和uid2上建立索引，然后：

select * from friend where uid1=2
union
select * from friend where uid2=2

即可得到结果。

ps: 此处 union 是为了命中索引。

强好友关系-元数据实现二

强好友关系是弱好友关系的一个特例，A和B必须互为关注关系（也可以说，同时互为粉丝关系），即也可以使用关注表和粉丝表来实现：

guanzhu(uid, guanzhu_uid);

fensi(uid, fensi_uid);

实例

例如：用户A(uid=1)和用户B(uid=2)为强好友关系，即相互关注：

用户A(uid=1)关注了用户B(uid=2)，A多关注了一个用户，B多了一个粉丝，于是：

guanzhu表要插入{1, 2}这一条记录

fensi表要插入{2, 1}这一条记录

同时，用户B(uid=2)也关注了用户A(uid=1)，B多关注了一个用户，A多了一个粉丝，于是：

guanzhu表要插入{2, 1}这一条记录

fensi表要插入{1, 2}这一条记录

数据冗余

数据冗余是实现多对多关系水平切分的常用实践

对于强好友关系的两类实现：

friend(uid1, uid2)表

数据冗余guanzhu表与fensi表（后文称正表T1与反表T2）

在数据量小时，看似无差异，但数据量大时，数据冗余的优势就体现出来了：

friend表，数据量大时，如果使用uid1来分库，那么uid2上的查询就需要遍历多库

正表T1与反表T2通过数据冗余来实现好友关系，{1, 2}{2,1}分别存在于两表中，故两个表都使用uid来分库，均只需要进行一次查询，就能找到对应的关注与粉丝，而不需要多个库扫描

• 经验

数据冗余，是多对多关系，在数据量大时，数据水平切分的常用实践。

如何进行数据冗余

接下来的问题转化为，好友中心服务如何来进行数据冗余，常见有三种方法。

服务同步冗余

               4
  +--------------------+
  v                    |
+-------------+  1   +-----------+  3   +-------+
| Application | ---> | f-service | ---> | DB-T2 |
+-------------+      +-----------+      +-------+
                       |
                       | 2
                       v
                     +-----------+
                     |   BD-T1   |
                     +-----------+

顾名思义，由好友中心服务同步写冗余数据，如上图1-4流程：

1. 业务方调用服务，新增数据

2. 服务先插入T1数据

3. 服务再插入T2数据

4. 服务返回业务方新增数据成功

• 优点

不复杂，服务层由单次写，变两次写

数据一致性相对较高（因为双写成功才返回）

• 缺点

请求的处理时间增加（要插入次，时间加倍）

数据仍可能不一致，例如第二步写入T1完成后服务重启，则数据不会写入T2

如果系统对处理时间比较敏感，引出常用的第二种方案

方法二：服务异步冗余

               4
  +--------------------+
  v                    |
+-------------+  1   +-----------+  2   +-------------+
| Application | ---> | f-service | ---> |    BD-T1    |
+-------------+      +-----------+      +-------------+
                       |
                       | 3
                       v
                     +-----------+  5   +-------------+  6   +-------+
                     |    esb    | ---> | data-center | ---> | DB-T2 |
                     +-----------+      +-------------+      +-------+

流程

数据的双写并不再由好友中心服务来完成，服务层异步发出一个消息，通过消息总线发送给一个专门的数据复制服务来写入冗余数据，如上图1-6流程：

1. 业务方调用服务，新增数据

2. 服务先插入 T1 数据

3. 服务向消息总线发送一个异步消息（发出即可，不用等返回，通常很快就能完成）

4. 服务返回业务方新增数据成功

5. 消息总线将消息投递给数据同步中心

6. 数据同步中心插入 T2 数据

• 优点

请求处理时间短（只插入1次）

• 缺点

系统的复杂性增加了，多引入了一个组件（消息总线）和一个服务（专用的数据复制服务）

因为返回业务线数据插入成功时，数据还不一定插入到T2中，因此数据有一个不一致时间窗口（这个窗口很短，最终是一致的）

在消息总线丢失消息时，冗余表数据会不一致

如果想解除“数据冗余”对系统的耦合，引出常用的第三种方案

线下异步冗余

数据的双写不再由好友中心服务来完成，而是由线下的一个服务或者任务来完成，如上图1-6流程：

                3
  +--------------------+
  v                    |
+-------------+  1   +-----------+  2   +---------+
| Application | ---> | f-service | ---> |  BD-T1  |
+-------------+      +-----------+      +---------+
                       |
                       | 4
                       v
                     +-----------+  5   +---------+  6   +-------+
                     |    log    | ---> | service | ---> | DB-T2 |
                     +-----------+      +---------+      +-------+

1. 业务方调用服务，新增数据

2. 服务先插入T1数据

3. 服务返回业务方新增数据成功

4. 数据会被写入到数据库的log中

5. 线下服务或者任务读取数据库的log

6. 线下服务或者任务插入T2数据

• 优点

数据双写与业务完全解耦

请求处理时间短（只插入1次）

• 缺点

返回业务线数据插入成功时，数据还不一定插入到T2中，因此数据有一个不一致时间窗口（这个窗口很短，最终是一致的）

数据的一致性依赖于线下服务或者任务的可靠性

上述三种方案各有优缺点，可以结合实际情况选取。

数据冗余固然能够解决多对多关系的数据库水平切分问题，但又带来了新的问题，如何保证正表T1与反表T2的数据一致性呢？

如何保证数据的一致性

上一节的讨论可以看到，不管哪种方案，因为两步操作不能保证原子性，总有出现数据不一致的可能，高吞吐分布式事务是业内尚未解决的难题。

此时的架构优化方向，并不是完全保证数据的一致，而是尽早的发现不一致，并修复不一致。

最终一致性，是高吞吐互联网业务一致性的常用实践。更具体的，保证数据最终一致性的方案有三种。

线下扫描正反冗余表全部数据

线下启动一个离线的扫描工具，不停的比对正表T1和反表T2，如果发现数据不一致，就进行补偿修复。

• 优点

比较简单，开发代价小

线上服务无需修改，修复工具与线上服务解耦

• 缺点

扫描效率低，会扫描大量的“已经能够保证一致”的数据

由于扫描的数据量大，扫描一轮的时间比较长，即数据如果不一致，不一致的时间窗口比较长

ps: 有没有只扫描“可能存在不一致可能性”的数据，而不是每次扫描全部数据，以提高效率的优化方法呢？

线下扫描增量数据

每次只扫描增量的日志数据，就能够极大提高效率，缩短数据不一致的时间窗口：

1. 写入正表T1

2. 第一步成功后，写入日志log1

3. 写入反表T2

4. 第二步成功后，写入日志log2

5. 当然，我们还是需要一个离线的扫描工具，不停的比对日志log1和日志log2，如果发现数据不一致，就进行补偿修复

• 优点：

虽比方法一复杂，但仍然是比较简单的

数据扫描效率高，只扫描增量数据

• 缺点：

线上服务略有修改（代价不高，多写了2条日志）

虽然比方法一更实时，但时效性还是不高，不一致窗口取决于扫描的周期

有没有实时检测一致性并进行修复的方法呢？

实时线上“消息对”检测

这次不是写日志了，而是向消息总线发送消息：

1. 写入正表T1

2. 第一步成功后，发送消息msg1

3. 写入反表T2

4. 第二步成功后，发送消息msg2

这次不是需要一个周期扫描的离线工具了，而是一个实时订阅消息的服务不停的收消息。

假设正常情况下，msg1和msg2的接收时间应该在3s以内，如果检测服务在收到msg1后没有收到msg2，就尝试检测数据的一致性，不一致时进行补偿修复

• 优点

效率高

实时性高

• 缺点

方案比较复杂，上线引入了消息总线这个组件

线下多了一个订阅总线的检测服务

however，技术方案本身就是一个投入产出比的折衷，可以根据业务对一致性的需求程度决定使用哪一种方法。

拓展阅读

分布式 id 生成策略

大众点评订单系统分库分表实践

参考资料

• 58

数据库扩展性架构设计

无限容量数据库架构设计

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

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

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

数据库分库分表的应用场景及解决方案

• 单 key 业务
  • 用户中心
  • 用户中心水平切分方法
    • 范围法
    • Hash 法
  • 水平切分问题
  • 需求分析
  • 用户中心水平切分架构思路
  • 用户中心-用户侧最佳实践
    • 索引表法
    • 缓存映射法
    • login_name 生成 uid
    • login_name 基因融入 uid
  • 用户中心-运营侧最佳实践
    • 前台与后台分离
• 1 对多业务
  • 1 对多关系
    • 1 对 1
    • 1对多
    • 多对多
  • 帖子中心业务分析
  • 元数据与索引数据分离
    • 写需求
  • 帖子中心元数据设计
    • 初期单库
  • 帖子中心水平切分-tid切分法
    • 优点
    • 不足
  • 帖子中心水平切分-uid切分法
    • 查询场景
    • 优缺点
  • 帖子中心水平切分-基因法
    • 什么是分库基因？
    • 什么是基因法分库？
    • 潜在问题一：同一个uid发布的tid落在同一个库上，会不会出现数据不均衡？
    • 最开始分16库，分库基因是4bit，未来要扩充成32库，分库基因变成了5bit，那怎么办？
• 多对多业务
  • 好友中心业务分析
    • 弱好友关系的建立，不需要双方彼此同意
    • 强好友关系的建立，需要好友关系双方彼此同意
    • 好友中心
  • 弱好友关系-元数据简版实现
  • 强好友关系-元数据实现一
  • 强好友关系-元数据实现二
    • 实例
  • 数据冗余
  • 如何进行数据冗余
  • 服务同步冗余
  • 方法二：服务异步冗余
    • 流程
    • 线下异步冗余
  • 如何保证数据的一致性
    • 线下扫描正反冗余表全部数据
    • 线下扫描增量数据
    • 实时线上“消息对”检测
• 拓展阅读
• 参考资料