2.4　GoldenDB数据库与CAP理论

2000年，加州大学伯克利分校的Eric Brewer教授在PODC（Principles Of Distributed Computing）座谈会上首次提出了CAP设想。2002年，麻省理工学院的Seth Gilbert和Nancy Lynch证明了CAP设想的可行性，从此CAP理论成为分布式系统的定理。

CAP指的是一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）。根据分布式系统中的CAP理论，当分区故障发生时，只能在一致性和可用性之间二选一。

2.4.1　什么是CAP理论

CAP定理指出一个分布式系统在一次操作中不可能同时满足一致性、可用性和分区容错性，最多只能同时满足其中的两项。为了更好地理解CAP定理，下面分别介绍一致性、可用性和分区容错性。

一致性（Consistency）：一致性服务最为经典的理论就是原子化数据对象。原子一致性或者线性一致性是当今Web服务的基本要求。根据一致性的要求，所有的操作必须如同在一个单独的实例中一样，按照线性的顺序依次执行。这相当于要求分布式共享内存的请求必须如同访问一个独立节点一样，在一个时间响应一个操作。一个最重要的特性就是，对于一个支持原子化读写请求的共享内存，当读请求发生在写请求成功以后，读请求的返回值必须反映出前面写请求操作后的结果。这种一致性约束，为使用者提供了最容易理解的模型。同时对于那些尝试设计使用分布式服务的客户端应用程序用户而言，也是最方便的。

可用性（Availability）：对于一个分布式系统来说，持续可用就是指系统中没有宕机的节点接到请求都必须产生应答。换句话说，任何服务执行的程序必须要有一个终态。在某些方面，以上对于可用性的定义要求并不高：对于程序需要执行多长时间到终态没有限制，因此允许程序无限期地执行下去。另一方面，当系统同时具备分区容错性时，这个要求又变得很高：当分布式系统内部的网络崩溃了，每个请求仍然需要一个应答。

分区容错性（Partition Tolerance）：以上关于一致性和可用性的定义都是基于系统具备分区容错性的基础上的。为了解释什么是分区容错性，将允许节点之间的网络传输存在消息随机丢失。当网络被分区，处在该分区的一个组件的节点发往另一组件中节点的所有消息都会丢失。因此，原子性要求意味着即使作为程序执行的一部分而发送的任意消息可能没有传递过去，每个响应都将是原子的。可用性要求意味着即使发送的消息可能会丢失，接收到客户端请求的每个节点也必须响应。这类似于要求一个运行在纯内存共享的系统中完成wait-free的程序直到终止：即使网络中的每个其他节点都出现故障也必须生成有效的原子响应。不允许少于总网络故障的故障导致系统响应不正确。

与集中式系统相比，分布式系统无法避免网络故障。当分布式系统出现网络故障时，基于CAP理论，为确保分区容错性，只能从一致性和可用性中二者择其一。当选择一致性时，系统要么直接返回错误，要么不返回任何结果，等待触发超时。当选择可用性时，系统会及时给接收到的请求返回结果，但不保证结果数据是最新的。

与分布式系统不同，传统关系数据库遇到网络故障时，优先选择一致性。如图2-22所示，Db2、Oracle和MySQL，由于没有网络分区，不存在分区容错性，属于CA类系统；又如Cassandra，通过配置副本之间策略，保证写操作可用性，但降低了写操作一致性，属于AP类系统；而GoldenDB分布式数据库，优先保证数据一致性与分区容错性，属于CP类系统。

2.4.2　GoldenDB保证一致性

分布式事务中的一致性和CAP理论中的一致性虽然含义不完全对等，但仍然面临相同的问题，一致性和可用性就像是鱼与熊掌不可兼得。

互联网公司普遍采用的异步事务方案，则是另外一种选择，采用最终一致性，牺牲事务的实时一致性，来提升系统的可用性。按照前面对金融级分布式数据库的定义，必须优先选择一致性，要确保数据的实时一致性，就要在系统的可用性上做一些牺牲。

2.4.3　GoldenDB最大程度保证可用性

在分布式环境下，当服务器、网络出现故障时，为保证一致性，数据库服务会不可用，导致可用性下降。在无法完全保证可用性的情况下，需尽可能缩短系统不可用时间，为此GoldenDB通过主从切换、HA切换自动恢复系统可用性，通过高低数值设置能够最大程度地保障系统的可用性。

高于最高数值会有告警，低于最低数值会触发只读。系统可用性会有一个从正常到异常告警，再到异常不可用的一个衰减过程。如能及时响应告警、处理故障，可以保证较高的系统可用性。

2.4.4　GoldenDB保证分区容错性

在分布式环境中，涉及的组件众多，由于环境相较单机环境复杂，根据不同组件可分为数据节点、计算节点、全局事务管理器节点和管理节点。

1．数据节点容错性

在分布式环境下，事务执行中发生主节点异常，未提交数据不会被同步到从节点。若出现部分提交，则进行已提交事务回滚。之后进行主从切换，在从节点切换成主节点之前，该安全组不提供读写服务，主从切换完成后自动恢复。

2．计算节点容错性

计算节点本身无状态，发生异常仅导致当前业务失败，并且负载均衡自动屏蔽该节点，保证后续交易发往其他计算节点。对于需要进行已提交事务回滚的事务，计算节点故障无法执行。计算节点部署的监控会重启进程，执行回滚操作。若计算节点重启失败，则根据配置由其他计算节点发起对等回滚操作。

3．全局事务管理器节点容错性

一般GTM按照主从部署，通常采用一主多从模式。主机异常时会自动触发主从切换，在从节点切换成主节点之前，不提供申请释放GTID服务，主从切换完成后自动恢复。

4．管理节点容错性

管理节点分为管理组件与集群元数据两部分，通过部署双机HA软件搭建主从关系，管理组件安装在主从服务器上，集群元数据存储在主从数据库中。若主机管理组件发生故障，双机软件会自动切换到从机。若主机数据库发生故障，双机软件会自动切换到从机，并完成主备切换操作。