数据库CAP分析
文章目录
前言
CAP 理论是针对分布式数据库而言的，它是指在一个分布式系统中，一致性（Consistency, C）、可用性（Availability, A）、分区容错性（Partition Tolerance, P）三者中一致性和可用性不可兼得，但是一定要保证分区容错性。
一、CAP是什么？
一致性是指“all nodes see the same data at the same time”，即更新操作成功后，所有节点在同一时间的数据完全一致。一致性可以分为客户端和服务端两个不同的视角：
1.从客户端角度来看，一致性主要指多个用户并发访问时更新的数据如何被其他用户获取的问题；
2.从服务端来看，一致性则是用户进行数据更新时如何将数据复制到整个系统，以保证数据的一致。
一致性是在并发读写时才会出现的问题，因此在理解一致性的问题时，一定要注意结合考虑并发读写的场景。
可用性是指“reads and writes always succeed”，即用户访问数据时，系统是否能在正常响应时间返回结果。好的可用性主要是指系统能够很好地为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。在通常情况下，可用性与分布式数据冗余、负载均衡等有着很大的关联。
分区容错性是指“the system continues to operate despite arbitrary message loss or failure of part of the system”，即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。分区容错性和扩展性紧密相关。在分布式应用中，可能因为一些分布式的原因导致系统无法正常运转。分区容错性高指在部分节点故障或出现丢包的情况下，集群系统仍然能提供服务，完成数据的访问。分区容错可视为在系统中采用多副本策略。
我们上面说到三者中一致性和可用性不可兼得，但是一定要保证分区容错性也是可以证明的。
证明连接如下：
https://mwhittaker.github.io/blog/an_illustrated_proof_of_the_cap_theorem/
二、CAP分析
1.水平扩展应用+单数据库实例的 CAP 分析
同一个应用启动了多个实例，连接着相同的数据库，如下图所示：
这样的系统天然具有的就是 AP（可用性和分区容忍性）：
一方面解决了单点导致的低可用性问题。
另一方面无论这些水平扩展的机器间网络是否出现分区，这些服务器都可以各自提供服务，因为他们之间不需要进行沟通。
2.水平扩展应用+主从数据库集群的CAP分析
从上图我可以看到三个数据库实例中只有一个是主库，其他是从库。一定程度上，这种架构极大的缓解了”读可用性”问题，而这样的架构一般会做读写分离来达到更高的”读可用性”，幸运的是大部分互联网场景中读都占了 80% 以上，所以这样的架构能得到较长时间的广泛应用。写可用性可以通过 Keepalived 这种 HA（高可用）框架来保证主库是活着的，但仔细一想就可以明白，这种方式并没有带来性能上的可用性提升。还好，至少系统不会因为某个实例挂了就都不可用了。
可用性勉强达标了，这时候的 CAP 分析如下：
分区容忍性：依旧先看分区容忍性，主从结构的数据库存在节点之间的通信，他们之间需要通过心跳来保证只有一个 Master。然而一旦发生分区，每个分区会自己选取一个新的 Master，这样就出现了脑裂，常见的主从数据库（MySQL，Oracle 等）并没有自带解决脑裂的方案。所以分区容忍性是没考虑的。
一致性：不考虑分区，由于任意时刻只有一个主库，所以一致性是满足的。
可用性：不考虑分区，HA 机制的存在可以保证可用性，所以可用性显然也是满足的。
关于脑裂情况我们暂不讨论，脑裂情况是比较复杂的，如果大家需求比较旺盛，我们可以出一期关于脑裂的状态。
总结
一致性和可用性不可兼得，但是一定要保证分区容错性。因为现在互联网企业追求大数据，势必会触及分区这个领域，数据一致性和可用性可以利用一些方式妥善的安排，虽然损耗了部分特性，但是却能保证优化。