分布式系统架构基本理论：CAP理论以及BASE理论

一、概述

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值，即写操作之后的读操作，必须返回该值。（分为弱一致性、强一致性和最终一致性）
可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）
分区容错性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

二、取舍策略

CAP三个特性只能满足其中两个，那么取舍的策略就共有三种：

1、CA ：（不建议采用）
优点：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。
缺点：放弃了分区，违背了分布式的初衷。
举例：Mysql

2、CP ：
优点：如果不要求A（可用），相当于每个请求都需要在服务器之间保持强一致，
缺点：P（分区）会导致同步时间无限延长(也就是等待数据同步完才能正常访问服务)，一旦发生网络故障或者消息丢失等情况，就要牺牲用户的体验，等待所有数据全部一致了之后再让用户访问系统。
举例：Redis、HBase、zookeeper等

3、 AP ：
优点：高可用，保证集群的可用性
缺点：放弃了一致性，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。
举例：Eureka

三、主要矛盾-Consistency和Availability

分布式的主要矛盾就是 一致性 和 可用性的矛盾。

四、解决方案——BASE

BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，BASE是对CAP中一致性和可用性权衡的结果。

核心思想：无法强一致性的情况下，做到最终一致性。

1、基本可用 Basically Available

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用，比如可以损失部分性能 或者 部分功能，达到整体功能基本不受影响的状态。
损失的这部分可用性指的是什么？

• 响应时间上的损失：正常情况下的搜索引擎0.5秒即返回给用户结果，而基本可用的搜索引擎可以在2秒作用返回结果。
• 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单。但是到了大促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。

2、软状态 Soft state

允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。

3、最终一致性 Eventually consistent

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。

分布式一致性的 3 种级别：

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

业界比较推崇是最终一致性级别，但是某些对数据一致要求十分严格的场景比如银行转账还是要保证强一致性。

最终一致性怎么保证呢？

• 读时修复 : 在读取数据时，检测数据的不一致，进行修复。比如 Cassandra 的 Read Repair 实现，具体来说，在向 Cassandra 系统查询数据的时候，如果检测到不同节点 的副本数据不一致，系统就自动修复数据。
• 写时修复 : 在写入数据，检测数据的不一致时，进行修复。比如 Cassandra 的 Hinted Handoff 实现。具体来说，Cassandra 集群的节点之间远程写数据的时候，如果写失败 就将数据缓存下来，然后定时重传，修复数据的不一致性。
• 异步修复 : 这个是最常用的方式，通过定时对账检测副本数据的一致性，并修复。