CAP理论和BASE理论

CAP理论和BASE理论

前言

在日常开发中，大量的请求直接打到数据库上会占用大量的硬盘资源，系统极短的时间内完成成千上万次的读/写操作，容易造成数据库系统瘫痪。可以引入 redis 缓存来阻挡大部分的请求，请求先访问缓存，如果有查询的数据，则缓存直接返回对应的数据。如果没有查询的数据，则查询数据库后返回并缓存到缓存中，避免了大量的请求涌入数据库，减缓了数据库的压力。

分布式系统的一致性（3种级别）

● 强一致性：系统写什么，读出来就是什么。
● 弱一致性：不一定可以读取到最新写入的值，也不保证多少时间后读取到的数据是最新的，只能尽量保证某个时刻达到数据一致性状态。
● 最终一致性：弱一致性的升级版，系统会保证在一定时间内达到数据一致性的状态。

CAP理论（Mysql主从同步，Redis+Mysql同步类似）

概念

CAP理论，指的是在一个分布式系统中，Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），这三个特性中，最多只能满足其中的两个。

一致性

写操作后的读操作可以读取到最新的数据状态，当数据分布在多个结点上，从任意结点读取到的数据都是最新状态，数据在多个副本之间能够保持一致的特性。
① 系统满足一致性要实现的目标
（1）写入主库成功，则向从库查询数据也成功。
（2）写入主库失败，则向从库查询数据也失败。
② 如何实现一致性
（1）写入主库后要将数据同步到从库。
（2）写入主库后，在向从库同步期间要将从库进行锁定，待同步完成后释放锁，以避免新数据的写入成功，导致数据不一致的问题。
③ 一致性的特点
（1）由于存在数据同步的过程，写操作的响应会有一定的延迟。
（2）为了保证数据一致性会对资源暂时锁定，待数据同步完成释放锁定资源。
（3）如果请求数据同步失败的结点则会返回错误信息，一定不会返回旧数据。
因此，在同步的过程中，写操作的响应会有一定的延迟以及同步失败返回的错误信息，保证系统的一致性的同时，系统的可用性也会降低。

可用性

系统提供的服务一直处于可用的状态，每次请求都能获得正确的响应，且不会出现响应超时或响应错误。
① 系统满足可用性要实现的目标
（1）从数据库接收到数据查询的请求则立即能够响应数据查询结果。
（2）从数据库不允许出现响应超时或响应错误的结果。
② 如何实现可用性
（1）写入主库后要将数据同步到从库。
（2）由于要保证从库的可用性， 不可以将从库资源进行锁定，必须保证从库的数据能立即得到相应（这和实现系统的可用性资源锁定违背）。
（3）即使数据还没有同步，从库也要返回要查询的数据，哪怕是旧的数据，但是不能返回错误或响应超时。
③ 分布式系统可用性的特点
（1）所有请求都有响应，且不会出现响应超时或响应错误。

分区容错性

通常分布式系统的各个结点部署在不同的子网，这就是网络分区，不可避免的会出现由于网络问题导致结点之间的通讯失败，在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务就是分区容错性。
① 系统满足分区容错性要实现的目标
（1）主库向从库同步数据失败不影响读写操作。
（2）其中一个结点宕机也不影响另外一个结点对外服务。
② 如何实现分区容错性
（1）尽量使用异步取代同步操作，例如使用异步方式将数据从主库同步到从库，这样结点之间能有效的实现松耦合。
（2）添加从库结点，其中一个结点宕机其他从结点也能提供服务。
③ 分布式系统分区容错性的特点
（1）分区容错性是分布式系统具备的基本能力。

分布式下的CAP

在所有的分布式系统中不会同时具备CAP三个特性，因为在具备了P的前提下C和A是不能共存的（分布式系统一般默认满足P，部署在不同的分区，依靠网络同步数据）。
分布式系统：1）主库通过网络向从库同步数据，可以认为主从数据库部署在不同的分区，通过网络进行交互。2）当主库和从库之间的网路出现问题不影响主库和从库对外服务。3）其中一个结点宕机不影响另外一个结点对外提供服务。
如果要实现C则必须保证数据的一致性，在数据同步的时候为了防止从库查询不一致的数据则需要将从库数据锁定，待同步完成后解锁，如果同步失败从库返回错误信息或超时信息。
如果要实现A则必须保证数据的可用性，不管任何时候都可以向从库查询数据，则不会响应超时或返回错误信息。
A和P之间存在矛盾，可能同时实现。
1. CAP的组合方式
① AP：
放弃一致性，追求分区容错性和可用性，大多数分布式系统设计的选择。
系统实现AP，前提是只要满足系统l不会返回错误或超时，立即做出相应，查询到的数据在一定时间内不是最新的即可。通常实现AP都会保证最终的一致性。
② CP：
放弃可用性，追求一致性和分区容错性，在zookeeper中就是追求的强一致性，一些需要数据强一致性的业务。
③ CA：
放弃分区容忍性，即不进行分区，不考虑由于网络不通或结点挂掉的问题，实现系统的一致性和可用性。这种情况系统不是一个标准的分布式系统，单机应用可以满足CA。

CAP理论的实际应用

在微服务中注册中心的组件有：Zookeeper、Eureka、Nacos…

1. Zookeeper 保证的是CP，任何时候对Zookeeper的读请求都能得到一致性的结果，但是Zookeeper 不保证每次请求的可用性比如在Leader 选举的过程中或者半数以上的机器不可用的时候服务就是不可用的。
2. Eureka 保证的是AP，Eureka 不会像zk一样出现选举过程中或半数以上的机器不可用的时候服务就不可用的情况。Eureka 保证即使大部分结点挂掉也不影响正常提供服务，只要有一个结点可用就行，只不过这个结点上的数据可能不是最新的。

BASE理论

概念

BASE 是 Basically Available（基本可用）、Soft-state（软状态）、Eventually Consistent（最终一致性）三个短语的缩写。
BASE理论是对CAP中一致性C和可用性A权衡的结果，是大规模互联网系统分布式实践的总结，是基于CAP理论逐步演化而来的，大大降低了对系统的要求。
BASE理论的核心思想：
即使无法保证强一致性，但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终的一致性。

BASE理论的三个特性

基本可用

假如系统出现不可预知的故障，允许损失部分可用性，当然也不能完全不可用。
损失部分可用性指的是：1）响应时间上的损失：正常情况下搜索引擎0.5秒即返回用户结果，而基本可用的搜索引擎可以在2秒左右返回结果，2）功能上的损失：在正常情况下，系统可以顺利完成一个业务，但是在高并发环境下，为了保护系统的稳定性，部分消费者可能会被引导到一个降级页面。

软状态

软状态指允许系统中的数据存在中间状态（CAP理论中的数据不一致），并认为这种中间状态的存在不会影响系统的整体可用性，即允许系统在不同结点的数据副本之间进行数据同步存在延时。

最终一致性

最终一致性强调的是系统中所有的数据副本，在经过一段时间的数据同步后，最终能达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。

如何保证最终一致性

1. 读时修复
在读取数据时，检测数据的不一致，进行修复。比如 Cassandra（一个来自 Apache 的分布式数据库，具有高度可扩展性，可用于管理大量的结构化数据） 的 Read Repair 实现，具体来说，在向 Cassandra 系统查询数据的时候，如果检测到不同结点的副本数据不一致，系统就自动修复数据。
2. 写时修复
在写入数据时，检测数据的不一致性，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说， Cassandra 集群的结点之间远程写数据的时候，如果写失败就将数据缓存起来，如何重新定时重传，修复数据的不一致性。
3. 异步修复
常用的修复方式，通过定时检测副本数据的一致性，并修复。

CAP理论和BASE理论总结

CAP 理论是分布式系统设计理论，BASE 理论是 CAP 理论中 AP方案的延伸。
CAP 理论严格来讲不是三个特性保证其中两个，而是 CP 、AP 两个选一个，因为在分布式系统中 P（分区容错性）是必须得到保证的。
BASE 理论面向的是大型高可用、可扩展的分布式系统，与传统的 ACID 特性相反，不是强一致性的模型，BASE 理论提出通过牺牲强一致性来获得可用性，并允许数据一段时间内的不一致，但最终需要达到一致性的效果。