博客:cbb777.fun
全平台账号: 安妮的心动录
github: https://github.com/anneheartrecord
下文中我说的可能对，也可能不对，鉴于笔者程度无限，请君自辨。有问题欢送大家找我探讨
CAP 实践
CAP 是分布式系统方向中的一个十分重要的实践，能够粗略的将它看成是分布式系统的终点，CAP 别离代表的是分布式系统中的三种性质，别离是 Consistency（可用性）、Availability（一致性）、Partition tolerance（网络分区容忍性），它们的第一个字母别离是 C A P，于是这个实践被称为 CAP 实践
实践上来说，CAP 三者同时最多满足两者，然而并不是必须满足两个，许多零碎最多只能同时满足 0、1 个
为什么 CAP 最多只能满足两个呢?
咱们能够以电商零碎的两个集群来当做例子
C: 谋求的是数据一致性 当有一个申请来了之后 它会期待网络隔离的状况完结之后 向另一个机器进行数据的同步
A: 谋求的是可用性 也就是尽可能提供无效服务 当一个申请来了之后 它会立刻返回 哪怕数据是古老的 也得优先提供服务，其余分区的节点返回的后果（数据）可能是不一样
留神：这里的 AP 不可同时满足指的是当整个分布式系统中呈现网络隔离的时候，咱们不能既想着保证数据的实时强一致性，又去谋求服务的可用性。
然而当没有网络隔离的时候，其实这两个性质是能够同时满足的，因为『同步数据』和『返回后果』这两个操作都是在同一个网络中，只有先后关系，不会因为某个操作导致另一个操作的『死等』
在分布式系统中，P 是会必然产生的，造成 P 的起因可能是网络隔离，也可能是节点宕机。
咱们无奈保障分布式系统每一时刻都不呈现网络隔离，如果不满足 P 的个性，一旦产生分区谬误，那么分布式系统就无奈工作，这显然违反了分布式的理念，连最根本的分布式系统条件都没有满足
典型的 CP 和 AP 的产品
CP：Zookeeper 当零碎在产生分区故障之后 客户端的所有申请都会被卡死或者超时 然而零碎总会返回统一的数据
AP：Eureka 分区产生故障之后 客户端仍然能够拜访零碎 然而获取的数据有的是新数据 有的是老数据
当然 CAP 这几个个性不是 BOOL 类型的，而是一个范畴类型，齐全是看零碎具体须要什么样的要求。
比方分区容错，有的零碎一台机器出错，零碎会认为不影响业务的话，认为分区不存在。只有多台机器都出问题了，零碎受到重大影响才认为呈现分区
PACELC 实践
PACELC 实践是对 CAP 实践的扩大，在维基百科上的定义是
It states that in case of network partitioning (P) in a distributed computer system, one has to choose between availability (A) and consistency (C) (as per the CAP theorem), but else (E), even when the system is running normally in the absence of partitions, one has to choose between latency (L) and consistency (C).
如果有分区（P），那么零碎就必须在可用性（A）和一致性（C）之间获得均衡，否则（E），当零碎运行在无分区的状况下，零碎须要在提早（L）和一致性（C）之间获得均衡
它相比于 CAP，多引入了一个提早 Latency 的概念，在呈现分区谬误的时候，取前半部分 PAC，实践和 CAP 的内容统一。没有呈现分区谬误的时候取 LC，也就是 Latency 与 Consistency
以后分布式系统领导实践更代替 CAP 实践，理由如下
- PACELC 更能满足实际操作中分布式系统的工作场景，是更好的工程实现策略
- 当 P 存在的场景下，须要在 A C 之间做取舍，然而实际上分布式系统大部分工夫里 P 是不存在的，那么在 L 和 C 之间做取舍是一个更好的抉择
- PACELC 能够在 latency 与 consistency 之间取得均衡
要保证系统的高可用，那么就得采纳冗余的思维，我的其余博文有提到 4 个 9 的异地多活策略，也是采纳的数据冗余思维，而一旦波及到了复制数据，在分布式中就肯定会在 Consistency 和 Latency 之间做一个取舍
举个例子
在强一致性的场景下，须要三个从节点都落盘数据，能力给客户端返回 OK，这个时候当 master 向 slave 同步数据的时候，超过 20ms 触发超时了，整个零碎还是会一直的重试这个过程，这显然造成了零碎的可用性比拟低
所以咱们个别都会在数据一致性和申请时延之间做一个 balance
当同步超过五次之后，认为这个节点故障，抉择间接返回，能够打消写时的长尾抖动，同时给节点打上故障标签，进行后续的解决
BASE 实践
base 实践是 Basically Avaliable(根本可用)、Soft State（软状态）、Eventually Consistent（最终一致性）三个短语的缩写，核心思想如下
即便无奈做到强一致性，但每个利用都能够依据本身的业务特点，采纳适当的形式来使零碎达到最终一致性
BA：根本可用指的是当零碎呈现了不可预知的故障，零碎仍旧可用，不过可用度兴许会升高，比方响应工夫上呈现损失，性能上只能满足基本功能等等
S：基于原子性而言的话，当要求多个节点数据统一时，咱们认为这是一种『硬』状态，而容许零碎中的数据存在中间状态，并认为其不影响零碎的整体可用性，即容许零碎在多个不同节点的数据正本存在数据时延
E：最终一致性，零碎不可能始终都处于一个软状态中，必须有个工夫期限。在期限过后，应该保障所有正本保持数据一致性，从而达到数据的最终一致性。这个工夫期限取决于时延、负载、计划等等
在工程实际中，有这么几种最终一致性的实现策略，通常都是多种策略混合实现
- 因果一致性：如果节点 A 在更新完某个数据后告诉了节点 B，那么节点 B 之后对该数据的拜访和批改都是基于 A 更新后的值。与此同时，与节点 A 无因果关系的节点 C 的数据拜访没有这样的限度
- 读已知所写：节点 A 更新一个数据之后，本身总是能拜访到更新过的最新值，而不会拜访旧值
- 会话一致性：将对系统数据的拜访过程框定在了一个会话当中，零碎能保障同一个无效的会话中实现客户端在一个会话中读取到该数据项永远是最新值
- 枯燥读一致性：如果一个节点从零碎中读取出一个数据项的某个值之后，那么零碎对于该节点后续的任何数据拜访都不该返回更旧的值
-
枯燥写一致性：一个零碎要可能保障来自同一个节点的写操作被程序的执行。
NWR 多数派实践
NWR 多数派实践指的是在少数正本的一致性模型中，只有大多数正本确认了某个操作，才认为这个操作曾经实现。
这个实践是分布式系统中一种常见的一致性模型，被广泛应用于保证数据的一致性和可靠性，以及零碎的可用性。
NWR 中 N 代表的是正本数量，W 代表写入的正本数量，R 则为读取的正本数量。在少数的一致性模型中，个别要求 W +R>N，以保障读写操作的一致性。
在写入操作的时候，只有 W 个正本被胜利写入才返回胜利，而在读取操作时，只有 R 个正本胜利返回雷同的数据才返回胜利。这样，只有大多数正本胜利确认了操作，就能够认为这个操作曾经实现。
NWR 在现有组件的利用还是很宽泛的，比方 Raft 选主判断逻辑为投票数量 >=n/ 2 则胜利选主，比方 Redis 的哨兵机制，有哨兵标记下线则为主观下线，>=n/ 2 标记下线则为主观下线。