Redis分布式理论(基础篇系列二)

Posted 2021-09-14 雨落花下c

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理论往往又会结合在一起使用。