无限容量数据库架构设计

前言和荐言：文中提及的每种实践都值得仔细阅读和体会，尤其一对多中提及的“基因分库法”，结合‘一’和‘多’中的元素巧妙地组合成新ID，很好地达到了按‘一’ 和‘多’入同库和高效查询的目的。回想先前项目中的实践，也不自觉地使用过这个技巧。真是“良好的技巧和实践”都是相似的。

--------------------------正文------------------------------

花了不少时间，把自己曾经做过的系统，曾经遇到到的问题，曾经实践过的架构方案，梳理总结和沉淀，尽量“系统的”记录成文字，和大家一起讨论。

本文是不同业务场景下，体系化的介绍“数据库水平切分”技术，和大家分享。

一、总起

文章：《每每谈到数据库架构，我们在讨论什么》

内容：

• 单库体系架构

• 数据库分组架构

• 数据库分片架构

• 数据库垂直切分

二、实践一

场景：单key业务，如何做到数据库无限容量

文章：《用户中心，数据库架构优化与实践》

内容：

• 用户中心业务分析

• 用户中心水平切分方案

• “前台与后台分离”架构设计思想

• uid分库，name上的查询四种方案

三、实践二

场景：1对多业务，如何做到数据库无限容量

文章：《帖子中心，数据库架构优化与实践》

内容：

• 帖子中心业务分析

• “索引外置”架构设计思想

• 基因法，uid分库还是tid分库不再纠结

四、实践三

场景：多对多业务，如何做到数据库无限容量

文章：《好友中心，数据库架构优化与实践》

内容：

• 好友中心业务分析

• 数据冗余的三种方案

• “最终一致性”架构设计思想

• 保证数据一致性的四种方案

五、实践四

场景：多key业务，如何做到数据库无限容量

文章：《订单中心，如何做到数据库无限容量》

内容：

• 订单中心业务分析

• “化繁为简”架构设计思想

• 订单ID，买家ID，卖家ID究竟应该如何分库

5篇文章超过1万字，架构图超过50副，有点长，建议先收藏，再转发，再细细品味。

From: https://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651960378&idx=1&sn=971a8db3251a232e3feeb7ff6235c96b&chksm=bd2d01e68a5a88f0f05c184340bcda81125ed1de772b35ef12b34c1f5f81c7b5a60cb8047f3c&scene=21#wechat_redirect