讲了很多可扩展性（scalability）理论，却不知道实际有啥用。今天就结合数据库架构设计，来聊聊这些理论在实践中的应用。还是那句话，理解思路比记住结论更重要。
一、单机数据库的局限：“Shared Everything” 架构
最早的数据库都是单机部署的。这类架构最大的痛点是无法线性扩展—— 磁盘的处理能力、内存的承载能力、计算的运算能力，都没办法随着业务需求增长而同步提升。
架构师们把这种架构叫做 “Shared Everything（全共享）” 架构。在这种架构里，磁盘（DISK）、内存（MEM）、CPU 都紧紧耦合在同一个数据库管理系统（DBMS）进程内，而且必须部署在一台服务器上。由于所有资源都处于相互竞争的状态，不仅没办法线性扩展，并行处理的能力也很差。简单来说，数据库单机部署，就是 “Shared Everything” 架构最典型的例子。
二、第一次优化：“计算与存储分离” 的 “Shared Disk” 架构
既然单机架构存在资源竞争、扩展性不足的问题，那怎么提升系统的并行能力呢？
最容易想到的办法是：把无状态的逻辑计算部分，从 DBMS 进程里拆分出来，做成可以扩展的微服务集群，从而实现“计算与存储分离”。
这种架构被称为 “Shared Disk（共享磁盘）” 架构。在这个架构下，和 CPU 相关的逻辑计算被拆分成了独立的进程，这些进程能以集群的方式部署，进而实现线性扩展；
不过，磁盘（DISK）和内存（MEM）仍然耦合在一个进程内，还是处于资源竞争的状态，没办法线性扩展。像 Oracle Rac 就是典型的 “Shared Disk” 架构，它的核心思路就是 “计算与存储分离”。
三、更进一步的优化：“资源完全隔离” 的 “Shared Nothing” 架构
“Shared Disk” 架构解决了计算部分的扩展问题，但存储部分的磁盘 IO 仍然存在集中的资源竞争，还有没有进一步优化的空间呢？
答案是有的。最直接的思路是：把数据打散，分布到不同的数据库实例上，让每一部分数据都能拥有独立的资源。
这就是 “Shared Nothing（无共享）” 架构，也被称为 “水平切分” 架构。在这种架构下：
-
整体的数据存储被分成了 N 份，每一份数据之间没有交集； -
每一份数据的磁盘（DISK）、内存（MEM）、CPU 都在单独的 DBMS 进程内，而且部署在不同的服务器上； -
每一份数据的资源之间不存在竞争关系。
四、数据库扩展性架构总结
- Shared Everything
属于数据库单机系统，所有资源（磁盘、内存、CPU）高度耦合且相互竞争，扩展性很差。 - Shared Disk
以 Oracle Rac 为代表，核心是 “计算与存储分离”，解决了计算部分的扩展问题，但存储资源仍然存在竞争。 - Shared Nothing
通过 “水平切分” 或者 “复制集群” 来实现，各个部分的数据资源完全隔离，是扩展性最强的架构。