前言
相关系列
- 《分布式 & 目录》
- 《分布式 & CAP理论 & 总结》
- 《分布式 & CAP理论 & 问题》
分布式
分布式的核心是将大型业务拆解成多个子业务以使之在不同的机器上执行。分布式是用于解决单个物理机容量&性能瓶颈问题而采用的优化手段，服务之间通过远程调用进行交流，从而协同工作以对外提供服务。
CAP理论
- ++Consistency @ （强）一致性：系统的所有节点在相同时刻可以看到相同数据，即对于在多个节点中存在的变量而言，其在同一时刻的值必然是相同的；++
- ++Availability @ 可用性：无论响应结果如何，系统都可以"在合理的时间内"响应请求，即使节点因为各类故障（包含但不限于网络分区）而不可用；++
- ++Partition Tolerance @ 分区容错性：系统能够在发生（特指）网络分区时继续响应请求。++
所谓CAP理论指的是分布式系统无法在"读/写数据"时同时满足"一致性/可用性/分区容错性"三种特性，因此系统设计者必须在这三者之间做出权衡：
- ++CA策略 @ 一致性&可用性：牺牲分区容错性来保证一致性&可用性。CA策略不属于分布式系统的可用策略，因为以目前的技术能力而言网络分区是无法避免的。因此如果放弃了分区容错性，那么分布式系统在网络分区时将完全不可用。但该策略在单机部署&单点集群部署（服务虽然被多个部署为集群，但相互间没有交互）时是可用的，或者说单机部署&单点集群部署的程序默认就是CA策略，因为其内部不存在网络交互，因此也就无需在意网络分区的发生。所有程序&系统在服务未拆分/未集群的情况下采用的都是CA策略；++
- ++CP策略 @ 一致性&分区容错性：牺牲可用性来保证一致性&分区容错性，适用于对数据一致性要求较高的分布式系统。当网络分区发生时，如果节点A无法正常请求节点B以完成数据同步，那么其可以通过阻塞至网络恢复的方式（并非只有这一种方式）来保证分区容错性。这种方式同时还可保证一致性，因为其可保证数据的读/写一定是正确的。但与此同时该方法会牺牲可用性，因为阻塞可能会导致请求难以/无法被及时回应。在实际情况中，从节点A复制数据到节点B总是需要花费一定时间的。如果是跨地域（例如北京到广州）的机房，耗费的时间就可能是几十/几百毫秒。因此CAP理论中的C在实践中是不可能完美实现的，因为在数据复制的过程中节点A&B 的数据并不一致，但CAP理论并不在意这种延迟。ZooKeeper就是一个典型的CP系统，它采用分布式一致性算法（如Paxos/Raft等）来确保在不同节点之间就数据状态达成强一致。此外，分布式一致性算法通常都带有容错特性，即只追求多数一致而非完全一致，故而大多数CP系统可用性其实也相当可观；++
- ++AP策略 @ 可用性&分区容错性：牺牲一致性来保证可用性&分区容错性，适用于对可用性较高的场景。当节点故障/网络分区发生时，如果节点A无法正常请求节点B以完成数据同步，那么其可以通过放弃请求的方式（并非只有这一种方式）来保证分区容错性。这种方式同时还可保证可用性，因为其确保了回应必然是及时的。但与此同时该方法会牺牲一致性，因为请求将难以/无法正确地读/写数据。AP策略通常依赖"最终一致性"模型进行弥补，即虽然会有一定的延迟，但数据最终还是会在一定时间内会达成一致。++
CAP理论策略的选择不是一成不变的。在 CAP理论落地实践时，我们需要将系统数据按照不同的应用场景和要求进行分类，从而为每类数据选择不同的分布式策略，而不是直接限定整个系统的所有数据都使用同一策略。
CAP理论告诉我们必须"牺牲"三特性中的一个，但这里的"牺牲"其实有一定误导作用，因为"牺牲"让很多人理解成彻底放弃。但实际上CAP理论的"牺牲"只是说我们无法在节点故障/网络分区期间保证一致性/可用性，而现实情况是系统在整个生命周期的大部分时间里·都是正常的，发生节点故障/网络分区现象的时间并不长。例如4个9 @ 99.99%可用性的系统一年运行下来不可用的时间只有50分钟；而5个9 @ 99.999%可用性的系统一年运行下来不可用的时间更是只有5分钟而已。在节点故障/网络分区期间放弃一致性/可用性并不意味着永远放弃，我们可以在节点故障/网络分区期间进行一些操作，从而令分布式系统在故障解决后重新达到一致性&可用性的状态。
BASE理论
BASE理论是对CAP理论一致性&可用性进行权衡后的结果，其核心思想是即使无法做到Strong consistency @ 强一致性，但每个应用也该根据自身业务的特点采用适当的方式来使系统达到Eventual consistency @ 最终一致性。
BASE是Basically Available @ 基本可用/Soft state @ 软状态/Eventually consistent @ 最终一致三个短语的简写，其各自含义具体如下：
- ++基本可用：基本可用是指允许分布式系统在出现不可预知故障时候损失部分可用性。但注意！这绝不等价于系统不可用，以下两个就是"基本可用"的典型例子：++
++响应时间上的损失：正常情况下，一个在线搜索引擎需要0.5秒内返回给用户相应的查询结果，但由于出现异常（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1 ~ 2秒；++
++功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面。++ - ++软状态：软状态也称弱状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性。通俗的说就是允许系统在不同节点的数据副本之间进行同步的过程存在延时。++
- ++最终一致性：最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。最终一致性的本质是需要系统数据最终能够达到一致，而不需要实时保证系统数据的强一致性。++
BASE理论是对CAP理论AP策略的延伸&补充，是权衡一致性&可用性后的结果。BASE理论的诞生基础是CAP理论的AP/CP策略本质实现的也是最终一致性：例如CP策略虽然名义上保证了强一致性，但现实中数据副本的同步是有延迟的，但CAP理论直接忽视了这些延迟，因此绝对完美的CP策略是不存在的；而AP策略虽然牺牲了一致性，但这种牺牲实际上也只限于节点故障/网络分区期间，当故障恢复正常后数据同样会恢复至最终一致。