无限容量数据库架构设计
/本文是不同业务场景下，体系化的介绍“数据库水平切分”技术，和大家分享。
一、总起
内容：
单库体系架构
数据库分组架构
数据库分片架构
数据库垂直切分
一、用户中心
用户中心是一个常见业务，主要提供用户注册、登录、信息查询与修改的服务，其核心元数据为：
User(uid, uname, passwd, sex, age,nickname, …)
其中：
uid为用户ID，主键
uname, passwd, sex, age, nickname, …等为用户的属性
数据库设计上，一般来说在业务初期，单库单表就能够搞定这个需求。
二、图示说明
为了方便大家理解，后文图片说明较多，其中：
“灰色”方框，表示service，服务
“紫色”圆框，标识master，主库
“粉色”圆框，表示slave，从库
三、单库架构
user-service->user-db单库
最常见的架构设计如上：
user-service：用户中心服务，对调用者提供友好的RPC接口
user-db：一个库进行数据存储
四、分组架构
Read--user-db-Slave
user-service-Write->user-dbMaster
Read--user-db-Slave
什么是分组？
答：分组架构是最常见的一主多从，主从同步，读写分离数据库架构：
user-service：依旧是用户中心服务
user-db-M(master)：主库，提供数据库写服务
user-db-S(slave)：从库，提供数据库读服务
主和从构成的数据库集群称为“组”。
分组有什么特点？
答：同一个组里的数据库集群：
主从之间通过binlog进行数据同步
多个实例数据库结构完全相同
多个实例存储的数据也完全相同，本质上是将数据进行复制
分组架构究竟解决什么问题？
答：大部分互联网业务读多写少，数据库的读往往最先成为性能瓶颈，如果希望：
线性提升数据库读性能
通过消除读写锁冲突提升数据库写性能
通过冗余从库实现数据的“读高可用”
此时可以使用分组架构，需要注意的是，分组架构中，数据库的主库依然是写单点。
一句话总结，分组解决的是“数据库读写高并发量高”问题，所实施的架构设计。
五、分片架构
什么是分片？
答：分片架构是大伙常说的水平切分(sharding)数据库架构：
user-service：依旧是用户中心服务
user-db1：水平切分成2份中的第一份
user-db2：水平切分成2份中的第二份
分片后，多个数据库实例也会构成一个数据库集群。
水平切分，到底是分库还是分表？
答：强烈建议分库，而不是分表，因为：
分表依然公用一个数据库文件，仍然有磁盘IO的竞争
分库能够很容易的将数据迁移到不同数据库实例，甚至数据库机器上，扩展性更好
水平切分，用什么算法？
答：常见的水平切分算法有“范围法”和“哈希法”：
user-db1(0-1kw)
user-service
user-db2(1kw-2kw)
范围法如上图：以用户中心的业务主键uid为划分依据，将数据水平切分到两个数据库实例上去：
user-db1：存储0到1千万的uid数据
user-db2：存储0到2千万的uid数据
%2=1 user-db1
user-service
%2=0 user-db2
哈希法如上图：也是以用户中心的业务主键uid为划分依据，将数据水平切分到两个数据库实例上去：
user-db1：存储uid取模得1的uid数据
user-db2：存储uid取模得0的uid数据
这两种方法在互联网都有使用，其中哈希法使用较为广泛。
分片有什么特点？
答：同一个分片里的数据库集群：
多个实例之间本身不直接产生联系，不像主从间有binlog同步
多个实例数据库结构，也完全相同
多个实例存储的数据之间没有交集，所有实例间数据并集构成全局数据
分片架构究竟解决什么问题？
答：大部分互联网业务数据量很大，单库容量容易成为瓶颈，此时通过分片可以：
线性提升数据库写性能，需要注意的是，分组架构是不能线性提升数据库写性能的
降低单库数据容量
一句话总结，分片解决的是“数据库数据量大”问题，所实施的架构设计。
六、分组+分片架构
如果业务读写并发量很高，数据量也很大，通常需要实施分组+分片的数据库架构：
通过分片来降低单库的数据量，线性提升数据库的写性能
通过分组来线性提升数据库的读性能，保证读库的高可用
七、垂直切分
除了水平切分，垂直切分也是一类常见的数据库架构设计，垂直切分一般和业务结合比较紧密。
还是以用户中心为例，可以这么进行垂直切分：
User(uid, uname, passwd, sex, age, …)
User_EX(uid, intro, sign, …)
垂直切分开的表，主键都是uid
登录名，密码，性别，年龄等属性放在一个垂直表（库）里
自我介绍，个人签名等属性放在另一个垂直表（库）里
如何进行垂直切分？
答：根据业务对数据进行垂直切分时，一般要考虑属性的“长度”和“访问频度”两个因素：
长度较短，访问频率较高的放在一起
长度较长，访问频度较低的放在一起
这是因为，数据库会以行(row)为单位，将数load到内存(buffer)里，在内存容量有限的情况下，长度短且访问频度高的属性，内存能够load更多的数据，命中率会更高，磁盘IO会减少，数据库的性能会提升。
垂直切分有什么特点？
答：垂直切分和水平切有相似的地方，又不太相同：
多个实例之间也不直接产生联系，即没有binlog同步
多个实例数据库结构，都不一样
多个实例存储的数据之间至少有一列交集，一般来说是业务主键，所有实例间数据并集构成全局数据
垂直切分解决什么问题？
答：垂直切分即可以降低单库的数据量，还可以降低磁盘IO从而提升吞吐量，但它与业务结合比较紧密，并不是所有业务都能够进行垂直切分的。
八、总结
文章较长，希望至少记住这么几点：
业务初期用单库
读压力大，读高可用，用分组
数据量大，写线性扩容，用分片
属性短，访问频度高的属性，垂直拆分到一起
二、实践一
场景：单key业务，如何做到数据库无限容量
内容：
用户中心业务分析
用户中心水平切分方案
“前台与后台分离”架构设计思想
uid分库，name上的查询四种方案
本文将以“用户中心”为例，介绍“单KEY”类业务，随着数据量的逐步增大，数据库性能显著降低，数据库水平切分相关的架构实践：
如何来实施水平切分
水平切分后常见的问题
典型问题的优化思路及实践
一、用户中心
用户中心是一个非常常见的业务，主要提供用户注册、登录、信息查询与修改的服务，其核心元数据为：
User(uid, login_name, passwd, sex, age, nickname, …)
其中：
uid为用户ID，主键
login_name, passwd, sex, age, nickname, …等用户属性
数据库设计上，一般来说在业务初期，单库单表就能够搞定这个需求，典型的架构设计为：
user-center-->user-db
user-center：用户中心服务，对调用者提供友好的RPC接口
user-db：对用户进行数据存储
二、用户中心水平切分方法
当数据量越来越大时，需要对数据库进行水平切分，常见的水平切分算法有“范围法”和“哈希法”。
范围法，以用户中心的业务主键uid为划分依据，将数据水平切分到两个数据库实例上去：
user-db1(0-1kw)
user-center
user-db2 (1kw-2kw)
user-db1：存储0到1千万的uid数据
user-db2：存储1到2千万的uid数据
范围法的优点是：
切分策略简单，根据uid，按照范围，user- center很快能够定位到数据在哪个库上
扩容简单，如果容量不够，只要增加user-db3即可
范围法的不足是：
uid必须要满足递增的特性
数据量不均，新增的user-db3，在初期的数据会比较少
请求量不均，一般来说，新注册的用户活跃度会比较高，故user-db2往往会比user-db1负载要高，导致服务器利用率不平衡
哈希法，也是以用户中心的业务主键uid为划分依据，将数据水平切分到两个数据库实例上去：
user-db1：存储uid取模得1的uid数据
user-db2：存储uid取模得0的uid数据
哈希法的优点是：
切分策略简单，根据uid，按照hash，user-center很快能够定位到数据在哪个库上
数据量均衡，只要uid是均匀的，数据在各个库上的分布一定是均衡的
请求量均衡，只要uid是均匀的，负载在各个库上的分布一定是均衡的
哈希法的不足是：
扩容麻烦，如果容量不够，要增加一个库，重新hash可能会导致数据迁移，如何平滑的进行数据迁移，是一个需要解决的问题
三、用户中心水平切分后带来的问题
使用uid来进行水平切分之后，整个用户中心的业务访问会遇到什么问题呢？
对于uid属性上的查询可以直接路由到库，假设访问uid=124的数据，取模后能够直接定位db-user1：
%3=1 db-user1
uid=124-(user-center) db-user2
db-user3
对于非uid属性上的查询，例如login_name属性上的查询，就悲剧了：
假设访问login_name=shenjian的数据，由于不知道数据落在哪个库上，往往需要遍历所有库，当分库数量多起来，性能会显著降低。
如何解决分库后，非uid属性上的查询问题，是后文要重点讨论的内容。
四、用户中心非uid属性查询需求分析
任何脱离业务的架构设计都是耍流氓，在进行架构讨论之前，先来对业务进行简要分析，看非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中
login_name-随机基因生成函数-->login_name_gene(3bit=110)
uid(64bit)->生成->生成全局唯一id（61bit)->gene(5bit)
假设分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直接定位到库
七、用户中心-运营侧最佳实践
前台用户侧，业务需求基本都是单行记录的访问，只要建立非uid属性 login_name / phone / email 到uid的映射关系，就能解决问题。
后台运营侧，业务需求各异，基本是批量分页的访问，这类访问计算量较大，返回数据量较大，比较消耗数据库性能。
如果此时前台业务和后台业务公用一批服务和一个数据库，有可能导致，由于后台的“少数几个请求”的“批量查询”的“低效”访问，导致数据库的cpu偶尔瞬时100%，影响前台正常用户的访问（例如，登录超时）。
而且，为了满足后台业务各类“奇形怪状”的需求，往往会在数据库上建立各种索引，这些索引占用大量内存，会使得用户侧前台业务uid/login_name上的查询性能与写入性能大幅度降低，处理时间增长。
对于这一类业务，应该采用“前台与后台分离”的架构方案：
用户前台 运营后台
dbuser1 冗余 dbuser-x
用户侧前台业务需求架构依然不变，产品运营侧后台业务需求则抽取独立的web / service / db 来支持，解除系统之间的耦合，对于“业务复杂”“并发量低”“无需高可用”“能接受一定延时”的后台业务：
可以去掉service层，在运营后台web层通过dao直接访问db
不需要反向代理，不需要集群冗余
不需要访问实时库，可以通过MQ或者线下异步同步数据
在数据库非常大的情况下，可以使用更契合大量数据允许接受更高延时的“索引外置”或者“HIVE”的设计方案
八、总结
将以“用户中心”为典型的“单KEY”类业务，水平切分的架构点，本文做了这样一些介绍。
水平切分方式：
范围法
哈希法
水平切分后碰到的问题：
通过uid属性查询能直接定位到库，通过非uid属性查询不能定位到库
非uid属性查询的典型业务：
用户侧，前台访问，单条记录的查询，访问量较大，服务需要高可用，并且对一致性的要求较高
运营侧，后台访问，根据产品、运营需求，访问模式各异，基本上是批量分页的查询，由于是内部系统，访问量很低，对可用性的要求不高，对一致性的要求也没这么严格
这两类业务的架构设计思路：
针对用户侧，应该采用“建立非uid属性到uid的映射关系”的架构方案
针对运营侧，应该采用“前台与后台分离”的架构方案
用户前台侧，“建立非uid属性到uid的映射关系”最佳实践：
索引表法：数据库中记录login_name->uid的映射关系
缓存映射法：缓存中记录login_name->uid的映射关系
login_name生成uid
login_name基因融入uid
运营后台侧，“前台与后台分离”最佳实践：
前台、后台系统web/service/db分离解耦，避免后台低效查询引发前台查询抖动
可以采用数据冗余的设计方式
可以采用“外置索引”（例如ES搜索系统）或者“大数据处理”（例如HIVE）来满足后台变态的查询需求
三、实践二
场景：1对多业务，如何做到数据库无限容量
内容：
帖子中心业务分析
“索引外置”架构设计思想
基因法，uid分库还是tid分库不再纠结
本文将以“帖子中心”为例，介绍“1对多”类业务，随着数据量的逐步增大，数据库性能显著降低，数据库水平切分相关的架构实践：
如何来实施水平切分
水平切分后常见的问题
典型问题的优化思路及实践
一、什么是1对多关系
所谓的“1对1”，“1对多”，“多对多”，来自数据库设计中的“实体-关系”ER模型，用来描述实体之间的映射关系。
1对1
一个用户只有一个登录名，一个登录名只对应一个用户
一个uid对应一个login_name，一个login_name只对应一个uid
这是一个1对1的关系。
1对多
一个用户可以发多条微博，一条微博只有一个发送者
一个uid对应多个msg_id，一个msg_id只对应一个uid
这是一个1对多的关系。
多对多
一个用户可以关注多个用户
一个用户也可以被多个粉丝关注
这是一个多对多的关系。
二、帖子中心业务分析
user-tiezi(1:n)
帖子中心是一个典型的1对多业务。
一个用户可以发布多个帖子，一个帖子只对应一个发布者。
任何脱离业务的架构设计都是耍流氓，先来看看帖子中心对应的业务需求。
帖子中心，是一个提供帖子发布/修改/删除/查看/搜索的服务。
写操作：
发布(insert)帖子
修改(update)帖子
删除(delete)帖子
读操作：
通过tid查询(select)帖子实体，单行查询
通过uid查询(select)用户发布过的帖子，列表查询
帖子检索(search)，例如通过时间、标题、内容搜索符合条件的帖子
在数据量较大，并发量较大的时候，通常通过元数据与索引数据分离的架构来满足不同类型的需求：
tiezi-center->MQ->tiezi-search
tiezi_db->(tid,uid,time,title,content)...tiezi-index(索引树，倒排表
架构中的几个关键点：
tiezi-center：帖子服务
tiezi-db：提供元数据存储
tiezi-search：帖子搜索服务
tiezi-index：提供索引数据存储
MQ：tiezi-center与tiezi-search通讯媒介，一般不直接使用RPC调用，而是通过MQ对两个子系统解耦（为何这么解耦，请参见《到底什么时候该使用MQ？》）
其中，tiezi-center和tiezi-search分别满足两类不同的读需求：
tid,uid类查询 搜索类查询
tiezi-center tiezi-search
tiezi-db(tid,udi,time,title,content
如上图所示：
tid和uid上的查询需求，可以由tiezi-center从元数据读取并返回
其他类检索需求，可以由tiezi-search从索引数据检索并返回
对于写需求：
如上图所示：
增加，修改，删除的操作都会从tiezi-center发起
tiezi-center修改元数据
tiezi-center将信息修改通知发送给MQ
tiezi-search从MQ接受修改信息
tiezi-search修改索引数据
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字段取模来进行水平切分：
这个方法简单直接，优点：
100%写请求可以直接定位到库
90%的读请求可以直接定位到库
缺点：
一个用户发布的所有帖子可能会落到不同的库上，10%的请求通过uid来查询会比较麻烦
如上图，一个uid访问需要遍历所有库。
五、帖子中心水平切分-uid切分法
有没有一种切分方法，确保同一个用户发布的所有帖子都落在同一个库上，而在查询一个用户发布的所有帖子时，不需要去遍历所有的库呢？
答：使用uid来分库可以解决这个问题。
新出现的问题：如果使用uid来分库，确保了一个用户的帖子数据落在同一个库上，那通过tid来查询，就不知道这个帖子落在哪个库上了，岂不是还需要遍历全库，需要怎么优化呢？
答：tid的查询是单行记录查询，只要在数据库（或者缓存）记录tid到uid的映射关系，就能解决这个问题。
新增一个索引库：
t_mapping(tid, uid);
这个库只有两列，可以承载很多数据
即使数据量过大，索引库可以利用tid水平切分
这类kv形式的索引结构，可以很好的利用cache优化查询性能
一旦帖子发布，tid和uid的映射关系就不会发生变化，cache的命中率会非常高
使用uid分库，并增加索引库记录tid到uid的映射关系之后，每当有uid上的查询：
可以通过uid直接定位到库。
每当有tid上的查询：
先查询索引表，通过tid查询到对应的uid
再通过uid定位到库
这个方法的优点：
一个用户发布的所以帖子落在同一个库上
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）：
使用uid%16分库，决定这行数据要插入到哪个库中
分库基因是uid的最后4个bit，即1010
在生成tid时，先使用一种分布式ID生成算法生成前60bit（上图中绿色部分）
将分库基因加入到tid的最后4个bit（上图中粉色部分）
拼装成最终的64bit帖子tid（上图中蓝色部分）
（怎么生成60bit分布式唯一ID，请参见《分布式ID生成算法》）
这般，保证了同一个用户发布的所有帖子的tid，都落在同一个库上，tid的最后4个bit都相同，于是：
通过uid%16能够定位到库
通过tid%16也能定位到库
潜在问题一：同一个uid发布的tid落在同一个库上，会不会出现数据不均衡？
答：只要uid是均衡的，每个用户发布的平均帖子数是均衡的，每个库的数据就是均衡的。
潜在问题二：最开始分16库，分库基因是4bit，未来要扩充成32库，分库基因变成了5bit，那怎么办？
答：需要提前做好容量预估，例如事先规划好5年内数据增长256库足够，就提前预留8bit基因。
七、总结
将以“帖子中心”为典型的“1对多”类业务，在架构上，采用元数据与索引数据分离的架构设计方法：
帖子服务，元数据满足uid和tid的查询需求
搜索服务，索引数据满足复杂搜索寻求
对于元数据的存储，在数据量较大的情况下，有三种常见的切分方法：
tid切分法，按照tid分库，同一个用户发布的帖子落在不同的库上，通过uid来查询要遍历所有库
uid切分法，按照uid分库，同一个用户发布的帖子落在同一个库上，需要通过索引表或者缓存来记录tid与uid的映射关系，通过tid来查询时，先查到uid，再通过uid定位库
基因法，按照uid分库，在生成tid里加入uid上的分库基因，保证通过uid和tid都能直接定位到库
对于1对多的业务场景，分库架构不再是瓶颈。
四、实践三
场景：多对多业务，如何做到数据库无限容量
内容：
好友中心业务分析
数据冗余的三种方案
“最终一致性”架构设计思想
保证数据一致性的四种方案
本文将以“好友中心”为例，介绍“多对多”类业务，随着数据量的逐步增大，数据库性能显著降低，数据库水平切分相关的架构实践。
一、什么是多对多关系
所谓的“多对多”，来自数据库设计中的“实体-关系”ER模型，用来描述实体之间的关联关系，一个学生可以选修多个课程，一个课程可以被多个学生选修，这里学生与课程时间的关系，就是多对多关系。
二、好友中心业务分析
好友关系主要分为两类，弱好友关系与强好友关系，两类都有典型的互联网产品应用。
弱好友关系的建立，不需要双方彼此同意：
用户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
即可得到结果。
作业，为何不使用：
select * from friend uid1=2 or uid2=2
五、强好友关系-元数据实现二
强好友关系是弱好友关系的一个特例，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来分库，均只需要进行一次查询，就能找到对应的关注与粉丝，而不需要多个库扫描
数据冗余，是多对多关系，在数据量大时，数据水平切分的常用实践。
七、如何进行数据冗余
接下来的问题转化为，好友中心服务如何来进行数据冗余，常见有三种方法。
方法一：服务同步冗余
顾名思义，由好友中心服务同步写冗余数据，如上图1-4流程：
业务方调用服务，新增数据
服务先插入T1数据
服务再插入T2数据
服务返回业务方新增数据成功
优点：
不复杂，服务层由单次写，变两次写
数据一致性相对较高（因为双写成功才返回）
缺点：
请求的处理时间增加（要插入次，时间加倍）
数据仍可能不一致，例如第二步写入T1完成后服务重启，则数据不会写入T2
如果系统对处理时间比较敏感，引出常用的第二种方案
方法二：服务异步冗余
数据的双写并不再由好友中心服务来完成，服务层异步发出一个消息，通过消息总线发送给一个专门的数据复制服务来写入冗余数据，如上图1-6流程：
业务方调用服务，新增数据
服务先插入T1数据
服务向消息总线发送一个异步消息（发出即可，不用等返回，通常很快就能完成）
服务返回业务方新增数据成功
消息总线将消息投递给数据同步中心
数据同步中心插入T2数据
优点：
请求处理时间短（只插入1次）
缺点：
系统的复杂性增加了，多引入了一个组件（消息总线）和一个服务（专用的数据复制服务）
因为返回业务线数据插入成功时，数据还不一定插入到T2中，因此数据有一个不一致时间窗口（这个窗口很短，最终是一致的）
在消息总线丢失消息时，冗余表数据会不一致
如果想解除“数据冗余”对系统的耦合，引出常用的第三种方案
方法三：线下异步冗余
数据的双写不再由好友中心服务来完成，而是由线下的一个服务或者任务来完成，如上图1-6流程：
业务方调用服务，新增数据
服务先插入T1数据
服务返回业务方新增数据成功
数据会被写入到数据库的log中
线下服务或者任务读取数据库的log
线下服务或者任务插入T2数据
优点：
数据双写与业务完全解耦
请求处理时间短（只插入1次）
缺点：
返回业务线数据插入成功时，数据还不一定插入到T2中，因此数据有一个不一致时间窗口（这个窗口很短，最终是一致的）
数据的一致性依赖于线下服务或者任务的可靠性
上述三种方案各有优缺点，可以结合实际情况选取。
数据冗余固然能够解决多对多关系的数据库水平切分问题，但又带来了新的问题，如何保证正表T1与反表T2的数据一致性呢？
八、如何保证数据的一致性
上一节的讨论可以看到，不管哪种方案，因为两步操作不能保证原子性，总有出现数据不一致的可能，高吞吐分布式事务是业内尚未解决的难题，此时的架构优化方向，并不是完全保证数据的一致，而是尽早的发现不一致，并修复不一致。
最终一致性，是高吞吐互联网业务一致性的常用实践。更具体的，保证数据最终一致性的方案有三种。
方法一：线下扫面正反冗余表全部数据
如上图所示，线下启动一个离线的扫描工具，不停的比对正表T1和反表T2，如果发现数据不一致，就进行补偿修复。
优点：
比较简单，开发代价小
线上服务无需修改，修复工具与线上服务解耦
缺点：
扫描效率低，会扫描大量的“已经能够保证一致”的数据
由于扫描的数据量大，扫描一轮的时间比较长，即数据如果不一致，不一致的时间窗口比较长
有没有只扫描“可能存在不一致可能性”的数据，而不是每次扫描全部数据，以提高效率的优化方法呢？
方法二：线下扫描增量数据
每次只扫描增量的日志数据，就能够极大提高效率，缩短数据不一致的时间窗口，如上图1-4流程所示：
写入正表T1
第一步成功后，写入日志log1
写入反表T2
第二步成功后，写入日志log2
当然，我们还是需要一个离线的扫描工具，不停的比对日志log1和日志log2，如果发现数据不一致，就进行补偿修复
优点：
虽比方法一复杂，但仍然是比较简单的
数据扫描效率高，只扫描增量数据
缺点：
线上服务略有修改（代价不高，多写了2条日志）
虽然比方法一更实时，但时效性还是不高，不一致窗口取决于扫描的周期
有没有实时检测一致性并进行修复的方法呢？
方法三：实时线上“消息对”检测
这次不是写日志了，而是向消息总线发送消息，如上图1-4流程所示：
写入正表T1
第一步成功后，发送消息msg1
写入反表T2
第二步成功后，发送消息msg2
这次不是需要一个周期扫描的离线工具了，而是一个实时订阅消息的服务不停的收消息。
假设正常情况下，msg1和msg2的接收时间应该在3s以内，如果检测服务在收到msg1后没有收到msg2，就尝试检测数据的一致性，不一致时进行补偿修复
优点：
效率高
实时性高
缺点：
方案比较复杂，上线引入了消息总线这个组件
线下多了一个订阅总线的检测服务
however，技术方案本身就是一个投入产出比的折衷，可以根据业务对一致性的需求程度决定使用哪一种方法。
九、总结
文字较多，希望尽量记住如下几点：
好友业务是一个典型的多对多关系，又分为强好友与弱好友
数据冗余是一个常见的多对多业务数据水平切分实践
冗余数据的常见方案有三种
（1）服务同步冗余
（2）服务异步冗余
（3）线下异步冗余
数据冗余会带来一致性问题，高吞吐互联网业务，要想完全保证事务一致性很难，常见的实践是最终一致性
最终一致性的常见实践是，尽快找到不一致，并修复数据，常见方案有三种
（1）线下全量扫描法
（2）线下增量扫描法
（3）线上实时检测法
五、实践四
场景：多key业务，如何做到数据库无限容量
内容：
订单中心业务分析
“化繁为简”架构设计思想
订单ID，买家ID，卖家ID究竟应该如何分库
数据库水平切分是一个很有意思的话题，不同业务类型，数据库水平切分的方法不同。
本篇将以“订单中心”为例，介绍“多key”类业务，随着数据量的逐步增大，数据库性能显著降低，数据库水平切分相关的架构实践。
一、什么是“多key”类业务
所谓的“多key”，是指一条元数据中，有多个属性上存在前台在线查询需求。
订单中心业务分析
订单中心是一个非常常见的“多key”业务，主要提供订单的查询与修改的服务，其核心元数据为：
Order(oid, buyer_uid, seller_uid, time,money, detail…);
其中：
oid为订单ID，主键
buyer_uid为买家uid
seller_uid为卖家uid
time, money, detail, …等为订单属性
数据库设计上，一般来说在业务初期，单库单表就能够搞定这个需求，典型的架构设计为：
order-center：订单中心服务，对调用者提供友好的RPC接口
order-db：对订单进行数据存储
随着订单量的越来越大，数据库需要进行水平切分，由于存在多个key上的查询需求，用哪个字段进行切分，成了需要解决的关键技术问题：
如果用oid来切分，buyer_uid和seller_uid上的查询则需要遍历多库
如果用buyer_uid或seller_uid来切分，其他属性上的查询则需要遍历多库
总之，很难有一个完全之策，在展开技术方案之前，先一起梳理梳理查询需求。
二、订单中心属性查询需求分析
在进行架构讨论之前，先来对业务进行简要分析，看哪些属性上有查询需求。
前台访问，最典型的有三类需求:
订单实体查询：通过oid查询订单实体，90%流量属于这类需求
用户订单列表查询：通过buyer_uid分页查询用户历史订单列表，9%流量属于这类需求
商家订单列表查询：通过seller_uid分页查询商家历史订单列表，1%流量属于这类需求
前台访问的特点：吞吐量大，服务要求高可用，用户对订单的访问一致性要求高，商家对订单的访问一致性要求相对较低，可以接受一定时间的延时。
后台访问，根据产品、运营需求，访问模式各异:
按照时间，架构，商品，详情来进行查询
后台访问的特点：运营侧的查询基本上是批量分页的查询，由于是内部系统，访问量很低，对可用性的要求不高，对一致性的要求也没这么严格，允许秒级甚至十秒级别的查询延时。
这两类不同的业务需求，应该使用什么样的架构方案来解决呢？
三、前台与后台分离的架构设计
如果前台业务和后台业务公用一批服务和一个数据库，有可能导致，由于后台的“少数几个请求”的“批量查询”的“低效”访问，导致数据库的cpu偶尔瞬时100%，影响前台正常用户的访问（例如，订单查询超时）。
前台与后台访问的查询需求不同，对系统的要求也不一样，故应该两者解耦，实施“前台与后台分离”的架构设计。
前台业务架构不变，站点访问，服务分层，数据库水平切分。
后台业务需求则抽取独立的web/service/db来支持，解除系统之间的耦合，对于“业务复杂”“并发量低”“无需高可用”“能接受一定延时”的后台业务：
可以去掉service层，在运营后台web层通过dao直接访问数据层
可以不需要反向代理，不需要集群冗余
可以通过MQ或者线下异步同步数据，牺牲一些数据的实时性
可以使用更契合大量数据允许接受更高延时的“索引外置”或者“HIVE”的设计方案
解决了后台业务的访问需求，问题转化为，前台的oid，buyer_uid，seller_uid如何来进行数据库水平切分呢？
多个维度的查询较为复杂，对于复杂系统设计，可以逐步简化。
四、假设没有seller_uid
订单中心，假设没有seller_uid上的查询需求，而只有oid和buyer_uid上的查询需求，就蜕化为一个“1对多”的业务场景，对于“1对多”的业务，水平切分应该使用“基因法”。
再次回顾一下，什么是分库基因？
通过buyer_uid分库，假设分为16个库，采用buyer_uid%16的方式来进行数据库路由，所谓的模16，其本质是buyer_uid的最后4个bit决定这行数据落在哪个库上，这4个bit，就是分库基因。
也再次回顾一下，什么是基因法分库？
在订单数据oid生成时，oid末端加入分库基因，让同一个buyer_uid下的所有订单都含有相同基因，落在同一个分库上。
如上图所示，buyer_uid=666的用户下了一个订单：
使用buyer_uid%16分库，决定这行数据要插入到哪个库中
分库基因是buyer_uid的最后4个bit，即1010
在生成订单标识oid时，先使用一种分布式ID生成算法生成前60bit（上图中绿色部分）
将分库基因加入到oid的最后4个bit（上图中粉色部分），拼装成最终64bit的订单oid（上图中蓝色部分）
通过这种方法保证，同一个用户下的所有订单oid，都落在同一个库上，oid的最后4个bit都相同，于是：
通过buyer_uid%16能够定位到库
通过oid%16也能定位到库
五、假设没有oid
订单中心，假设没有oid上的查询需求，而只有buyer_uid和seller_uid上的查询需求，就蜕化为一个“多对多”的业务场景，对于“多对多”的业务，水平切分应该使用“数据冗余法”。
如上图所示：
当有订单生成时，通过buyer_uid分库，oid中融入分库基因，写入DB-buyer库
通过线下异步的方式，通过binlog+canal，将数据冗余到DB-seller库中
buyer库通过buyer_uid分库，seller库通过seller_uid分库，前者满足oid和buyer_uid的查询需求，后者满足seller_uid的查询需求
数据冗余的方法有很多种：
服务同步双写
服务异步双写
线下异步双写（上图所示，是线下异步双写）
不管哪种方案，因为两步操作不能保证原子性，总有出现数据不一致的可能，高吞吐分布式事务是业内尚未解决的难题，此时的架构优化方向，并不是完全保证数据的一致，而是尽早的发现不一致，并修复不一致。
最终一致性，是高吞吐互联网业务一致性的常用实践。保证数据最终一致性的方案有三种：
冗余数据全量定时扫描
冗余数据增量日志扫描
冗余数据线上消息实时检测
这些方案细节在“多对多”业务水平拆分的文章里详细展开分析过，便不再赘述。
六、oid/buyer_uid/seller_uid同时存在
通过上述分析：
如果没有seller_uid，“多key”业务会蜕化为“1对多”业务，此时应该使用“基因法”分库：使用buyer_uid分库，在oid中加入分库基因
如果没有oid，“多key”业务会蜕化为“多对多”业务，此时应该使用“数据冗余法”分库：使用buyer_uid和seller_uid来分别分库，冗余数据，满足不同属性上的查询需求
如果oid/buyer_uid/seller_uid同时存在，可以使用上述两种方案的综合方案，来解决“多key”业务的数据库水平切分难题
七、总结
任何复杂难题的解决，都是一个化繁为简，逐步击破的过程。
对于像订单中心一样复杂的“多key”类业务，在数据量较大，需要对数据库进行水平切分时，对于后台需求，采用“前台与后台分离”的架构设计方法：
前台、后台系统web/service/db分离解耦，避免后台低效查询引发前台查询抖动
采用前台与后台数据冗余的设计方式，分别满足两侧的需求
采用“外置索引”（例如ES搜索系统）或者“大数据处理”（例如HIVE）来满足后台变态的查询需求
对于前台需求，化繁为简的设计思路，将“多key”类业务，分解为“1对多”类业务和“多对多”类业务分别解决：
使用“基因法”，解决“1对多”分库需求：使用buyer_uid分库，在oid中加入分库基因，同时满足oid和buyer_uid上的查询需求
使用“数据冗余法”，解决“多对多”分库需求：使用buyer_uid和seller_uid来分别分库，冗余数据，满足buyer_uid和seller_uid上的查询需求
如果oid/buyer_uid/seller_uid同时存在，可以使用上述两种方案的综合方案，来解决“多key”业务的数据库水平切分难题。
数据冗余会带来一致性问题，高吞吐互联网业务，要想完全保证事务一致性很难，常见的实践是最终一致性。