可扩展数据库（上）

数据库层的扩展是典型云应用五层架构中的第四层，也是最复杂的一层（有人认为可扩展存储系统更为复杂，笔者以为，取决于业务应用模式。对于存在复杂交易处理类型的应用，其数据库层实现的挑战显然更高；而对于单纯的海量数据简单事件处理型应用，数据库层甚至不需要存在，而云存储层的实现则更为复杂）。

数据库扩展大体有如下四类解决方案：

·Scale-Up

·Master-Slaves（一主多仆）读代理模式

·Master-Master模式

·Sharding模式

（1）Scale-Up：垂直扩展

垂直扩展法除了通过升级硬件配置让数据库系统的吞吐率更高，在软件层面上主要是优化表结构，例如合理使用索引，避免多表间关联查询（如多表join）。此类方法被看作第二平台应用中的典型“扩展”模式。在第三平台云应用当中，这种Scale-up only的做法显然不能实现足够高的可扩展性。

（2）主仆读代理模式

数据库层的水平可扩展（Scale-Out）方法有多种，其中最基础（简洁）的是Master-Slave（主-仆）模式，如图4-3所示。通常是由一个Master节点负责读写操作，而由一个或多个Slave节点负责只读操作。这样的设计相当于数倍提高数据的读性能（而写性能因为Master节点的负载相对下降而相应提高）。我们知道大多数数据库系统的读操作数量远远超过写操作（如更改、删除、添加），因此对读操作的加速能有效解决这类系统的效能瓶颈。

图：数据库扩展实现之Read-Proxy

主-仆数据库设计的一个要点是只有单一节点执行写操作，这样的设计可以避免出现多点写数据而造成的数据同步、复制的复杂性。当然，Master节点依然需要负责把更新的数据集同步、复制到所有的只读节点上去。因此，在主-仆节点间通常需要高带宽、低延迟以避免出现数据复制不够及时而造成的数据读写非一致性。

通常，在主-仆数据库架构中我们需要加入负载均衡组件来确保应用服务器层能充分利用Slave节点提升读操作效率。需要指出的是，这一层的负载均衡操作通常工作在TCP/UDP层，并且多为定制数据库操作通信协议，而非应用层之上的LB层的标准HTTP/S协议。

（3）Master-Master模式

前面的Master-Slave模式解决了系统读可扩展问题，那么有没有可以解决写操作可扩展性的方法呢？答案是确切的，有。但是复杂度会高很多。回顾在之前的章节中我们讨论过的CAP理论，强一致性的数据库系统（ACID系统）强调CAP中的数据一致性（Consistency），而多节点同时支持并发读写操作极易造成节点间出现数据非一致性。因此，这样的系统最大的挑战是如何保证各节点间采用何种架构设计来实现数据一致性。

以下图为例，MySQL数据库支持多个Master节点模式，它们之间的数据同步方式是环状复制（Circular Replication）。也就是说，在三个数据库服务器集群中，第一集群中的Master节点向第二集群的对应节点（Slave）同步数据，第二集群的该节点再以Master节点的身份向第三集群Slave节点传输同步数据，最后是第三集群的该节点向第一集群的同一节点同步数据。这样设计的主要原因是避免发生time-order conflict（时序冲突），也就是说当两个或更多的节点同时向另外一个节点发送更新数据集时，当数据集存在overlapping（交集）时，极易造成最终的数据不一致。

图：MySQL数据库的多主节点间的环状数据复制（同步）

避免在多Master节点数据库系统中发生数据一致性冲突的解决方案无外乎4条

·彻底避免多节点写操作（这样又回到了Master-Slaves模式）

·在应用层逻辑上严格区分不同Master节点的写入区域，确保之间无交集（例如，不出现同时间内更改同一行的操作）

·保证不同Master节点在不重叠的时间段内对同一区域进行操作

·同步复制（Synchronous Replication），所有的节点上会同时进行写操作，并且当所有节点都成功完成后，整个操作才会返回。这种模式显然对于网络带宽的要求极高，并且为了满足数据的一致性（C），而牺牲了可用性（Availability）