在互联网工程项目中，当销售业务规模愈来愈大，统计数据也愈来愈多，接踵而至的是资料库阻力会愈来愈大。
他们可能会采行各种形式去强化，比如说以后该文提及的内存计划，SQL 强化之类，除那些形式之外，这里再撷取几个特别针对资料库强化的常规性方式：「统计数据随机存取分立」与「资料库 Sharding」。这点大体上是特大型互联网工程项目中应用领域的非常两极化的计划了。
下面他们来详尽看看，
一、从随机存取分立到 CQRS
由于互联网销售业务情景，绝大多数是读多写少，因此展开资料库的随机存取分立是两件比较单纯且简便的计划。
随机存取分立单纯点而言是把对统计数据的读操作形式和写操作形式展开合二为一来，让这三种操作形式去出访不同的资料库，如此一来，就能减低资料库的阻力了。
比如左图中，资料库会有两个「主示例」，那个主要用以提供写操作形式的（偶而也会分担一点读操作形式），除「主示例」之外，还会有数个「从示例」（在图中显示的是 黎贞示例），「从示例」的机能只是用以分担读操作形式的。
那下面就出现了数个资料库了，在数个资料库间的统计数据是怎么确保连续性的呢？
只不过，他们常见的资料库就便携式这类并行机能，比如说 Mysql，它自己有两个 master-slave 机能，能同时实现主库与从库统计数据的手动并行，是如前所述十进制笔记拷贝来同时实现的。在主库展开的写操作形式，会形成十进制笔记，然后 Mysql 会把那个笔记触发器的并行到从库上，从库再手动继续执行两遍那个十进制笔记，那么统计数据就跟主库完全一致了。
除 Mysql 之外，像 Oracle 等商业性资料库都有类似于的机能，甚至是互联网上除了许多开放源码的服务器端统计数据并行辅助工具，也有许多成形称心的。
好了，「主示例」与「从示例」间的统计数据并行问题化解了，那现在除了两个问题是，工程项目中是怎样让 写请求 去出访「主示例」，让 读请求 去出访「从示例」的，那个路由规则是怎么同时实现的呢？
常规性的有 2 种形式：
使用编码形式
那个形式主要是靠开发同学在编码的时候，根据随机存取不同的操作需求，去调用不同的统计数据源。比如在统计数据操作形式层（DAO 层）将读统计数据与写统计数据合二为一为两个方法（函数），然后为这两个方法分别指定不同的资料库即可。
但是这种形式有点硬编码的味道了，而且对开发同学而言还得额外关注那个事情，多了两个编码成本且容易不小心忽略掉。
使用中间件
这种形式是在后端资料库的前面，前置两个 资料库代理服务，如下图的：MySQL-Proxy 是 Mysql 提供的两个中间件，用于同时实现随机存取分立请求，但那个组件实际用的人不多，他们能选择其它的一些开放源码的组件替代，比如：Mycat、ProxySQL 之类，但大致的原理比较类似于，通过那个图很容易理解那个模式。
好了，基础的随机存取分立就讲完了，但感觉那个形式虽然实用是实用，是不怎么有逼格。
OK，想要有逼格是吧，满足你，那他们就来聊一聊另两个有逼格的随机存取分立概念: 「 CQRS 」
CQRS：Command Query Responsibility Segregation
命令（增删改）和查询的责任分立
他们还是先看图，通过左图能单纯的理解一下 CQRS
CQRS 重点强调的是 Query（读） 和 Command（写）的分立，在销售业务上将职责分立清晰，Command 主要做销售业务逻辑的继续执行，Query 来负责统计数据查询和展示。同时 这三种操作形式是如前所述不同的统计数据源，甚至是两个是资料库，另外两个是 NoSQL 都能，Query 去查询的统计数据源能直接按照领域模型展开存储，而并不是按照统计数据模型去存储，这样查询出来就立即能展示，而不用转换，且查询效率高。
只不过 CQRS 是由鼎鼎大名的 Martin Fowler 提出，搞计算机的应该都认识。想要更深入的去学习 CQRS，能翻看 Martin Fowler 公开的资料。
二、Sharding（分库分表）
下面讲完了资料库的随机存取分立，现在他们来聊一下资料库的 Sharding。
随着资料库里的统计数据愈来愈大，单表查询的操控性已经不能满足销售业务要求了，那个时候就需要展开分表处理了，将大表拆分为若干个小表，不同的分表中统计数据也不一样，这样能分散查询阻力，提高处理效率。
然而，当表愈来愈多，所有的统计数据都在两个统计数据库上时，互联网 IO 以及文件 IO 也都会集中在两个资料库上，可能会超过单台服务器的容量， CPU、内存、文件 IO、互联网 IO 都会成为系统的瓶颈，QPS/TPS 也会超过单资料库示例的处理极限。那么那个时候就需要对资料库展开分片处理。
因为分表和分库的思路类似于，因此下面统一来聊技术计划。
只不过分库分表只是他们通俗的便于理解的说话，正确的描述应该是：统计数据分片
统计数据的分片主要有 2 种模式：
垂直拆分
水平拆分
三种拆分应用领域的情景是不同的：
垂直拆分，是指按照销售业务模块展开拆分。单纯来讲，是把销售业务紧密的模块的字段 / 表放在一起，放在同两个资料库或者服务器上。将不同销售业务的字段 / 表展开独立，拆到不同的统计数据库或者服务器上。比如说两个游戏系统中，能将玩家基本信息与道具公会等信息展开拆分。
如图示例：
水平拆分，是指纯粹的按照某种统计数据规则 / 格式展开拆分。比如 按照统计数据 ID 的哈希散列拆分、按照统计数据的日期拆分、按照某种范围拆分之类。水平拆分需要注意的是，随着统计数据动态的变化，分片数量可能需要随之动态调整，另外是水平分片是没有考虑销售业务特征的，因此在展开销售业务汇总查询或者分片中事物处理的时候就比较麻烦一些。
如图示例：
另外，在实际应用领域中，三种拆分模式一般会结合在一起使用，效果更佳。
