1.1.1　数据库集群的CAP理论

提到数据库集群，大部分人的第一印象就是由一堆服务器共同部署的数据库，最终统一对外提供数据库服务。多个节点协同部署数据库软件形成集群效应，在很多场合也可称为分布式数据库，但数据库集群和分布式数据库在概念和应用上仍存在差别，在某些领域也存在重合的应用场景，因此其适用范围并不相同。

在物理分布上，数据库集群相对集中，一般需要构建专用高速网络进行互联；分布式数据库并没有明确限定各服务器节点部署在一起，也可以多机器远程互联、异地部署。在运行环境上，集群节点对运行环境的要求较高，一般要求同构的系统软件环境；分布式数据库一般支持异构系统，满足不同底层操作系统和不同数据库系统的要求。在数据分布上，数据库集群没有严格规定数据的分布模型，一般会根据不同的需求构建实际的数据库运行模式；分布式数据库则需要严格考虑各节点之间数据的一致性，并通过特定算法或机制来满足数据库的实际性能需求。

从以上几点分析来看，数据库集群偏向于物理形态上的描述，侧重多台机器设备的联合部署，更强调中心化管理；而分布式数据库更偏向于工作机制的协同，侧重分散化部署，因此会重点考虑数据的一致性需求。数据库集群和分布式系统是各自面向不同场景的术语表达，在一些基本理论上具有共性。分布式系统或分布式数据库经常提到的CAP定理，在数据库集群构建过程中仍然适用。

CAP中的3个字母分别代表一致性（Consistency）、可用性（Availability）、分区容忍性（Partition Tolerance）。一致性要求所有用户在访问数据库时能够访问同一份最新的数据副本；可用性指的是用户在访问数据库时能够获得数据库的响应；分区容忍性指的是数据库系统在发生分区的情况下，对数据通信的时限要求。CAP定理指出，一个分布式系统不可能同时满足一致性、可用性和分区容忍性要求，只能满足其中的两项。在数据库集群部署到多台服务器上时，数据库发生了网络分区，这种分区属性要求数据库在设计时必须在一致性和可用性上进行取舍。

可用性主要由不同数据副本同步的时延决定，因而会影响数据的并发性能。为了提高系统的可用性，系统一般需要牺牲一定程度的并发性能。在实际部署过程中，数据库集群一般在物理部署环境上相对集中，通常具备高速网络直连环境，因此对可用性的要求比较高。同时，可用性与一致性相互影响，数据库集群对数据一致性的需求将直接影响系统的可用性。一致性就是在各个节点中保持数据一致，可以分为强一致性、弱一致性等。

从用户角度讲，一致性指的是当多用户并发访问数据时，实时更新的数据在不同副本间的同步状态。这取决于数据访问的一致性策略。对于服务器而言，最初的数据更新只发生在其中的某个服务器节点上，一致性需求指的是如何将数据更新复制到所有其他节点上。从客户访问端来看，不同的一致性访问策略，也由客户端业务流程中访问数据的紧迫程度所决定。一致性问题是由多节点并发读写引出的，因此在理解一致性问题时，一定要综合考虑并发读写的场景。单节点关系型数据库要求数据更新后能被同一用户的后续访问实时获取，也能够被其他用户实时获取，这是强一致性。对于数据库集群，如果能够容忍其他用户延迟访问或无法访问数据，则其具有弱一致性。在强一致性和弱一致性之间，还有其他一致性类型，如单调一致性、会话一致性、最终一致性等。

（1）强一致性：所有用户在任何时刻访问任何一个节点，读取到的数据都是一致的。这就要求当任意节点上的数据更新时，其他节点必须进行数据同步，使用户访问最新的数据。

（2）弱一致性：弱一致性是一个统称，它不保证数据的最终一致性，最终一致性是弱一致性的特例。一般来讲，数据库系统在定义自身的一致性时，最终一致性是最基本的要求。

（3）单调一致性：当用户读到某个数据时，这个用户不会再读到比这个值更旧的值。从用户使用方面来讲，用户一般只从自己的视角观察数据的一致性，而不会关注其他用户的数据访问情况。

（4）会话一致性：任何一个用户在某次会话中读到某个数据时，这个用户在这次会话过程中不会再读到比这个数据更旧的值。

（5）最终一致性：某个节点数据更新后，在一定时间内无法同步到其他节点，但最终成功更新的数据能够被所有用户访问。

对于单节点关系型数据库，插入一条数据后立刻查询肯定是能够读取这条数据的。对于数据库集群，由于多节点部署存在时延，为了保证并发性能，有时会在强一致性和最终一致性方面进行权衡。例如，新闻订阅类的Web应用并不要求非常高的实时性，在发出一条新闻消息后，数据库其他节点在几秒甚至十几秒之后才能访问到这条新闻消息是能够接受的；对于银行用户，通常对金额的实时性要求比较高，在所有节点同步数据之后才能供用户访问，从而让用户访问各节点间强一致性的数据。数据库集群部署方案有很多种，不同的部署方案对数据的一致性要求并不一样，这与实际业务相关，需要根据实际业务情况来选择相应的数据库集群架构方案。