一、总起
文章：《每每谈到数据库架构，我们在讨论什么》
内容：
-
单库体系架构
-
数据库分组架构
-
数据库分片架构
-
数据库垂直切分
二、实践一
场景：单key业务，如何做到数据库无限容量
文章：《用户中心，数据库架构优化与实践》
内容：
-
用户中心业务分析
-
用户中心水平切分方案
-
“前台与后台分离”架构设计思想
对于“业务复杂”“并发量低”“无需高可用”“能接受一定延时”的后台业务：
-
可以去掉service层，在运营后台web层通过dao直接访问db
-
不需要反向代理，不需要集群冗余
-
不需要访问实时库，可以通过MQ或者线下异步同步数据
-
在数据库非常大的情况下，可以使用更契合大量数据允许接受更高延时的“索引外置”或者“HIVE”的设计方案
-
uid分库，name上的查询四种方案
【login_name基因融入uid】
思路：不能用login_name生成uid，可以从login_name抽取“基因”，融入uid中
解决方案：
-
在用户注册时，设计函数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直接定位到库
三、实践二
场景：1对多业务，如何做到数据库无限容量
文章：《帖子中心，数据库架构优化与实践》
内容：
-
帖子中心业务分析
-
“索引外置”架构设计思想
-
基因法，uid分库还是tid分库不再纠结
uid=666的用户发布了一条帖子（666的二进制表示为：1010011010）：
-
使用uid%16分库，决定这行数据要插入到哪个库中
-
分库基因是uid的最后4个bit，即1010
-
在生成tid时，先使用一种分布式ID生成算法生成前60bit（上图中绿色部分）
-
将分库基因加入到tid的最后4个bit（上图中粉色部分）
-
拼装成最终的64bit帖子tid（上图中蓝色部分）
（怎么生成60bit分布式唯一ID，请参见《分布式ID生成算法》）
四、实践三
场景：多对多业务，如何做到数据库无限容量
文章：《好友中心，数据库架构优化与实践》
内容：
-
好友中心业务分析
-
数据冗余的三种方案
-
“最终一致性”架构设计思想
-
保证数据一致性的四种方案
实时线上“消息对”检测
这次不是写日志了，而是向消息总线发送消息，如上图1-4流程所示：
-
写入正表T1
-
第一步成功后，发送消息msg1
-
写入反表T2
-
第二步成功后，发送消息msg2
这次不是需要一个周期扫描的离线工具了，而是一个实时订阅消息的服务不停的收消息。
假设正常情况下，msg1和msg2的接收时间应该在3s以内，如果检测服务在收到msg1后没有收到msg2，就尝试检测数据的一致性，不一致时进行补偿修复
五、实践四
场景：多key业务，如何做到数据库无限容量
文章：《订单中心，如何做到数据库无限容量》
内容：
-
订单中心业务分析
-
“化繁为简”架构设计思想
-
订单ID，买家ID，卖家ID究竟应该如何分库