分布式与一致性协议之CAP和Paxos算法(一)

news2024/12/28 14:27:05

CAP 理论

如何使用BASE理论

以InfluxDB系统中DATA节点的集群实现为例。DATA节点的核心功能是读和写，所以基本可用是指读和写的基本可用。我们可以通过分片和多副本实现读和写的基本可用。也就是说，将同一业务的数据先分片，再以多份副本的形式分布在不同的节点上。如图所示。除非这个3节点2副本的DATA集群超过一半的节点都发生故障，否则是能保障所有数据的读写的。
在这里插入图片描述

那么，如何实现最终一致性呢？就像上文提到的，我们可以通过写时修复和异步修复实现最终一致性。另外可以同时实现自定义写一致性级别，如支持All、Quorum、One、Any4种写一致性级别，用户在写数据的时候，可以根据业务数据特点，设置不同的写一致性级别。

注意

对于任何集群而言，不可预知的故障的最终后果都是系统过载，所以，如何设计过载保护，实现系统在过载时的基本可用，时开发和运营互联网后天的分布式系统的重中之重。建议在开发实现分布式系统前就要充分考虑如何实现基本可用

Paxos算法

概述

提到分布式算法，就不得不提Paxos算法，在过去几十年里，它基本上时分布式共识的代名词，当前最常用的一批共识算法都是基于它改进的。比如， Fast Paxos算法、Cheap Paxos算法、Raft算法等。但是，很多人都会在准确和系统理解Paxos算法上踩坑，比如，只知道它可以用来达成共识，却不知道它是如何达成共识的。
这其实从侧面说明了Paxos算法有一定的难度，可分布式算法本身就很复杂，Paxos算法自然也不会例外。当然，除了这一点，还与Paxos算法的提出者莱斯利兰伯特有关。
兰伯特提出的Paxos算法包含两个部分:

1.一个是Basic Paxos算法，描述的是多节点之间如何就某个值(提案Value)达成共识
2.另一个是Multi_Paxos思想，描述的是执行多个Basic Paxos示例，就一系列值达成共识。
但是，因为兰伯特提到的Multi-Paxos思想缺少代码实现的必要细节(比如怎么选举领导者)，所以我们理解起来比较困难

Basic Paxos:如何在多个节点间确定某变量的值。

在我看来，Basic Paxos是Multi-Paxos思想的核心，说白了，Multi-Paxos就是多执行几次Basic Paxos。所以掌握了Basic Paxos，我们便能更好地理解后面基于Multi-Paxos思想的共识算法(比如Raft算法)，还能掌握分布式共识算法的最核心内容，当现有算法不能满足业务需求时，可以权衡折中，设计自己的算法。

假设我们要实现一个分布式集群，这个集群由节点A、B、C组成，提供只读KV存储服务。你应该知道，创建只读变量的时候必须要对它进行赋值，而且后续不能对该值进行修改。也就是说，一个节点创建只读变量后，就不能再修改它了，所以，所有节点必须要先对只读变量的值达成共识，然后再由所有节点一起创建这个只读变量。那么，当有多个客户端(比如客户端1、2)访问这个系统，试图创建同一个只读变量(比如X)时，例如客户端1试图创建值为3的X,客户端2试图创建值为7的X，该如何达成共识，实现各节点上X值的一致呢？如图所示
在这里插入图片描述

在一些经典的算法种，你会看到一些既形象又独有的概念(比如二阶段提交协议种的协调者)，Basic Paxos算法也不例外。为了帮助人们
更好地理解Basic Paxos算法，兰伯特在讲解时也使用了一些独有而且比较重要的概念，如提案(Propose)、准备(Prepare)请求、接受(Accept)请求
、角色等，其中最重要的就是"角色"。因为角色时对Basic Paxos中最核心的3个功能的抽象，比如，由接受者(Acceptor)对提议的值进行投票，
并存储接受的值

你需要了解的3种角色

在Basic Paxos中有提议者(Proposer)、接收者(Acceptor)、学习者(Learner)3种角色，它们之间的关系如图所示。
在这里插入图片描述

提议者: 提议一个值，用于投票表决。为了方便理解，你可以把上图中的客户端1和客户端2看作提议者。但在绝大多数场景中，集群中收到客户端请求的节点菜是提议者，这样做的好处是，对业务代码没有入侵性，也就是说，我们不需要在业务代码中实现算法逻辑，就可以像使用数据库一样访问后端的数据
接受者:对每个提议的值进行投票，并存储接受的值，比如A、B、C3个节点，一般来说，集群中的所有节点，都在扮演接受者的角色，参与共识协商，并接受和存储数据
学习者:被告知投票的结果，接受达成共识的值并存储该值，不参与投票的过程，一般来说，学习者是数据备份节点，比如
Master-Slave模型中的Slave，被动地接受数据，容灾备份。

你可能会疑惑:前面不是说接收客户端请求的节点是提议者吗？这里怎么又说该节点是接受者呢？这是因为一个节点(或进程)可以身兼多个角色。想象一下，一个3节点的集群，1个节点收到了请求，那么该节点将作为提议者发起二阶段提交，然后这个节点还会和另外两个节点一起作为接受者进行共识协商，如图所示。
在这里插入图片描述