关于后端:Redis分布式理论基础篇系列二

Redis 的一些特点和数据结构咱们在上一篇中曾经理解到了，那么这篇咱们来理解一下分布式实践 CAP+BASE。

前言

说 Redis，那么 Redis 跟 CAP 和 BASE 实践有什么关系呢？
那是因为 CAP 和 BASE 实践是 Redis、MongoDB 等泛滥 NoSQL 数据库管理系统的实践根底；而 ACID 才是传统关系型数据库的设计理念，ACID 和 BASE 代表截然不同的两种设计哲学，强一致性 - 可用性的两端。

CAP 实践

CAP 定理（CAP theorem）, 又被称作 布鲁尔定理（Brewer’s theorem）, 它指出对于一个 分布式计算零碎 来说，不可能同时满足以下三点：

Consistency(一致性)：所有节点在同一时间具备雷同的数据
Availability(可用性)：保障每个申请不论胜利或者失败都有响应（也就是只有收到用户的申请，服务器都要在正当的工夫内给出正当的响应）
Partition tolerance(分区容错)：零碎中任意信息的失落或失败不会影响零碎的持续运作（也就是分布式系统遇到任何网络分区故障时，依然能够对外提供一致性、可用性的服务）

上面咱们来具体理解一下这三个准则：
C：Consistency（一致性）
在分布式环境中，一致性是指数据在多个正本之间是否可能保持一致的个性（这点跟 ACID 中的一致性含意不同）。
对于一个将数据正本散布在不同节点上的分布式系统来说，如果对第一个节点的数据进行了更新操作并且更新胜利后，却没有使得第二个节点上的数据失去相应的更新，于是在对第二个节点的数据进行读取操作时，获取的仍然是更新前的数据（称为脏数据），这就是典型的分布式数据不统一状况。在分布式系统中，如果可能做到针对一个数据项的更新操作执行胜利后，所有的用户都能读取到最新的值，那么这样的零碎就被认为具备强一致性（或严格的一致性）。

A：Availability（可用性）
可用性是指零碎提供的服务必须始终处于可用的状态，对于用户的每一个操作申请总是可能在无限的工夫内返回后果，如果超过了这个工夫范畴，那么零碎就被认为是不可用的。
『无限的工夫内』是一个在零碎设计之初就设定好的运行指标，不同的零碎会有很大的差异。比方对于一个在线搜索引擎来说，通常在 0.5 秒内须要给出用户搜寻关键词对应的检索后果。而对应 Hive 来说，一次失常的查问工夫可能在 20 秒到 30 秒之间。
『返回后果』是可用性的另一个十分重要的指标，它要求零碎在实现对用户申请的解决后，返回一个失常的响应后果。失常的响应后果通常可能明确地反映出对申请的处理结果，及胜利或失败，而不是一个让用户感到困惑的返回后果。
让咱们再来看看下面提到的在线搜索引擎的例子，如果用户输出指定的搜寻关键词后，返回的后果是一个零碎谬误，比方 ”OutOfMemoryErroe” 或 ”System Has Crashed” 等提醒语，那么咱们认为此时零碎是不可用的。

P：Partition tolerance（分区容错性）

分区容错性要求一个分布式系统须要具备如下个性：分布式系统在遇到任何网络分区故障的时候，依然可能保障对外提供满足一致性或可用性的服务，除非是整个网络环境都产生了故障。
网络分区是指在分布式系统中，不同的节点散布在不同的子网络（机房或异地网络等）中，因为一些非凡的起因导致这些子网络之间呈现网络不连通的情况，但各个子网络的外部网络是失常的，从而导致整个零碎的网络环境被切分成了若干个孤立的区域。

CAP 实践的外围是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需要，最多只能同时较好的满足两个。
因而，依据 CAP 原理将 NoSQL 数据库分成了满足 CA 准则、满足 CP 准则和满足 AP 准则三大类：
CA – 单点集群，满足一致性，可用性的零碎，通常在可扩展性上不太强大。比方传统的 Oracle 数据库。
CP – 满足一致性，分区容错性的零碎，通常性能不是特地高。比方Redis、MongoDB。
AP – 满足可用性，分区容错性的零碎，通常可能对一致性的要求低一些，满足最终一致性即可。大多数网站架构的抉择。

CAP 实践提出就是针对分布式数据库环境的，所以，P 这个属性是必须具备的；那么这时候 C 和 A 能同时满足吗？答案是不能的：
Consistency 和 Availability 的矛盾
一致性和可用性，为什么不可能同时成立？答案很简略，因为可能通信失败（即呈现分区容错）。

假如数据库一和数据库二同时为客户端服务，这两个库的数据是统一的。

如果保障 数据库二 的一致性，那么数据库一必须在写操作时，锁定 数据库二 的读操作和写操作。只有数据同步后，能力从新凋谢读写。锁定期间，数据库二 不能读写，没有可用性不。
如果保障 数据库二 的可用性，那么势必不能锁定 数据库二，所以一致性不成立。
综上所述，数据库二 无奈同时做到一致性和可用性。零碎设计时只能抉择一个指标。如果谋求一致性，那么无奈保障所有节点的可用性；如果谋求所有节点的可用性，那就没法做到一致性。

综上所述，因为网络的起因，必定会呈现提早和丢包等问题，所以：
分区容错性（Partition tolerance）是咱们必须要实现的。
所以只能在一致性和可用性之间进行衡量，没有 NoSQL 零碎能同时保障这三点。

BASE 实践

BASE 是 Basically Available(根本可用）、Soft state(软状态）和 Eventually consistent(最终一致性）三个短语的简写。BASE 是对 CAP 中一致性和可用性衡量的后果，其来源于对大规模互联网零碎分布式实际的总结，是基于 CAP 定理逐渐演变而来的，其核心思想是即便无奈做到强一致性，但每个利用都能够依据本身的业务特点，采纳适当的办法来使零碎达到最终一致性。接下来，咱们着重对 BASE 中的三要素进行解说。

根本可用
根本可用是指分布式系统在呈现不可预知故障的时候，容许损失局部可用性——但请留神，这绝不等价于零碎不可用。以下举例两个 ” 根本可用 ” 的例子：

（1）响应工夫上的损失：失常状况下，一个在线搜索引擎须要在 0.5 秒之内返回给用户相应的查问后果，但因为呈现故障（比方零碎局部机房产生断电或断网故障），查问后果的响应工夫减少到了 1 - 2 秒。

（2）性能上的损失：失常状况下，在电商平台上购物，消费者齐全可能顺利地实现每一笔订单。但在双十一期间，因为消费者的购物行为激增，为了爱护系统核心性能的可用性，通常会采取服务降级的策略，比方敞开评论等非核心性能。

软状态
软状态是指容许零碎中的数据存在中间状态，并认为该中间状态的存在不会影响零碎的整体可用性，即容许零碎在不同的数据正本之间进行数据同步的过程存在延时。

最终一致性
最终一致性强调的是零碎中所有的数据正本，在通过一段时间的同步后，最终可能达到一个统一的状态。因而，最终一致性的实质是须要零碎保障最终数据可能达到统一，而不须要实时保证系统数据的强一致性。

最终一致性是一种非凡的弱一致性：零碎可能保障在没有其余新的更新操作的状况下，数据最终肯定可能达到统一的状态，因而所有客户端对系统的数据拜访都可能获取到最新的值。同时，在没有产生故障的前提下，数据达到统一状态的时间延迟，取决于网络提早、零碎负载和数据复制方案设计等因素。

在理论工程实际中，最终一致性存在以下五类次要变种：
（1）因果一致性(Causal consistency)
（2）读己之所写(Read your writes)
（3）会话一致性(Session consistency)
（4）枯燥读一致性(Monotonic read consistency)
（5）枯燥写一致性(Monotonic write consistency)

以上就是最终一致性的五种常见的变种，在理论零碎实际中，能够将其中的若干个变种相互联合起来，以构建一个具备最终一致性个性的分布式系统。
事实上，最终一致性并不是只有那些大型分布式系统才波及的个性，许多古代的关系型数据库都采纳了最终一致性模型。在古代关系型数据库中（比方 MySQL 和 PostgreSQL），大多都会采纳同步或异步形式来实现主备数据复制技术。在同步形式中，数据的复制过程通常是更新事务的一部分，因而在事务实现后，主备数据库的数据就会达到统一。而在异步形式中，备库的更新往往会存在延时，这取决于事务日志在主备数据库之间传输的工夫长短。如果传输工夫过长或者甚至在日志传输过程中出现异常导致无奈及时将事务利用到备库上，那么很显然，从备库中读取的数据将是旧的，因而就呈现了数据不统一的状况。当然，无论是采纳多次重试还是人为数据勘误，关系型数据库还是可能保障最终数据达到统一，这就是零碎提供最终一致性保障的经典案例。

总的来说，BASE 实践面向的是大型高可用可扩大的分布式系统，和传统事务的 ACID 个性使相同的，它齐全不同于 ACID 的强一致性模型，而是提出通过就义强一致性来取得可用性，并容许数据在一段时间内是不统一的，但最终达到统一状态。但同时，在理论的分布式场景中，不同业务单元和组件对数据一致性的要求是不同的，因而在具体的分布式系统架构设计过程中，ACID 个性与 BASE 实践往往又会联合在一起应用。