目录
01从集中式到分布式
系统特点
集中式特点
集中式系统通常是单一服务器或单一数据中心的架构。在集中式系统中，每个终端或客户端机器仅仅负责数据的录入和输出，而数据的存储与控制处理完全交由主机完成。但是，随着业务不断发现，加上单一大型主机进行系统扩容又比较困难。以阿里集团的“去IOE”计划启动，电商系统开始正式迈入分布式系统时代。
分布式特点
分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。不难理解，分布式系统都会有如下几个特征:
-
分布性：多台计算机在空间上随意分布
-
对等性：没有主/从之分，既没有控制整个系统的主机，也没有被控制的从机，所有计算机节点是对等的。
-
并发性：多个节点可能会并发地操作一些共享的资源，如数据库或分布式存储等。
-
缺乏全局时钟：分布式系统由空间上随意分布的多个进程组成的，在系统中，很难定义谁先谁后。
-
故障总会发生：系统中的所有计算机，都有可能发生任何形式的故障。
事务处理差异
事务具有四个特征：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability），简称为事务的ACID特性。
-
原子性（Atomicity）：原子性表示事务是一个不可分割的工作单元。这意味着事务中的所有操作要么全部成功，要么全部失败。如果事务的任何部分失败，整个事务将被回滚，以确保数据库状态不会处于不一致的状态。
-
一致性（Consistency）：一致性确保事务在执行前和执行后，数据库的状态保持一致。这意味着事务必须遵循数据库的完整性约束和业务规则，以确保数据的正确性。如果事务违反了完整性约束，它将被回滚。
-
隔离性（Isolation）：隔离性指的是多个并发事务之间的独立性。即使多个事务同时访问数据库，它们也不应相互干扰。数据库管理系统必须确保每个事务以独立的方式访问数据，以防止数据竞争和不一致性。
-
持久性（Durability）：持久性确保一旦事务成功提交，其影响将持久保存在数据库中，即使在系统发生故障时也是如此。这意味着数据的更改不会因系统崩溃而丢失。
在单机数据库中，我们很容易能够实现一套满足ACID特性的事务处理系统，但是分布式的事务处理中问题却层出不穷。其中最为突出的问题是在可用性和一致性之间永远无法存在一个两全其美的方案，针对这个难题的讨论，出现了CAP和BASE这样的分布式系统经典理论。
-
CAP 定理（CAP Theorem）：
-
一致性（Consistency）：所有节点看到的数据是一致的。这意味着无论对于系统的任何部分，如果读取操作返回了某个值，那么后续的读操作都应该返回相同的值。
-
可用性（Availability）：系统能够响应读取和写入请求，即系统在有限时间内响应每个非故障请求。
-
分区容忍性（Partition Tolerance）：系统在面临网络分区（节点之间的通信中断）的情况下仍能继续运行。
CAP 定理指出，分布式系统无法同时满足这三个特性，最多只能同时满足其中两个。这意味着在面对网络分区时，分布式系统需要在一致性和可用性之间做出权衡。不同的系统可以选择不同的策略，具体取决于应用程序的需求。
-
-
BASE 模型：
-
基本可用性（Basically Available）：系统保持基本的可用性，即使出现故障，也能继续运行。系统可以放宽一些一致性要求，以保持可用性。
-
柔性状态（Soft state）：系统的状态可以随时发生变化，而不一定要保持强一致性。在某些时刻，系统的部分数据可能会处于不一致状态，但这并不妨碍系统的正常运行。
-
最终一致性（Eventually Consistent）：最终一致性意味着系统最终会在某个时刻达到一致状态，尽管在某些时刻可能不是一致的。系统通过异步复制等机制来逐渐将数据带入一致状态。
BASE 模型强调了在分布式系统中放宽一致性要求，以提高可用性和性能。它适用于一些大规模、高并发、高可用性的系统，如互联网应用和分布式数据库。
-
02一致性协议与Paxos算法
在对分布式系统进行架构设计的过程中，往往需要在一致性和可用性之间反复权衡，于是产生了一系列的一致性协议和算法，其中最著名的就是二阶段提交协议(2PC)、三阶段提交协议(3PC)和Paxos算法了。
2PC（Two-Phase Commit）
整个事务是分为两个阶段提交，二阶段提交是一种强一致性的算法。
阶段一：提交事务请求
-
事务询问
协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
-
执行事务
各个参与者节点执行事务操作，并将 Undo 和 Redo 信息记录到事务日志中，尽量把提交过程中所有消耗时间的操作和准备都提前完成确保后面100%成功提交事务。
-
各个参与者向协调者反馈事务询问的响应
如果各个参与者成功执行了事务操作，那么就反馈给参与者 yes 的响应，表示事务可以执行； 如果参与者没有成功执行事务，就反馈给协调者 no 的响应，表示事务不可以执行。
阶段二：执行事务提交
在阶段二中，协调者会根据反馈的情况决定最终是否可以进行事务提交操作。
-
执行事务提交(都返回yes)
-
发送提交请求
协调者向所有参与者节点发出Commit请求。
-
事务提交
参与者接收到Commit请求后，正式执行事务提交操作，并在完成提交后释放事务执行期间占用的资源
-
反馈事务提交结果。
参与者完成事务提交之后，向协调者发送Ack消息。
-
完成事务
协调者收到所有参与者反馈的Ack消息后，完成事务
-
-
中断事务(任何一个返回了no或者等待超时)
-
发送回滚请求
协调者向所有参与者发出RollBack请求。
-
事务回滚
参与者接收到RollBack请求后，利用阶段一的Undo信息执行回滚，在回滚完成后释放事务执行期间占用的资源。
-
反馈事务回滚结果
参与者在完成事务回滚之后，向协调者发送Ack消息。
-
中断事务
协调者接收到所有参与者反馈的Ack消息后，完成事务中断。
-
优缺点
-
优点：原理简单，实现方便。
-
缺点：同步阻塞，单点问题，脑裂。
3PC（Three-Phase Commit）
3PC是2PC的改进版，将二阶段提交协议的“提交事务请求”过程一分为二，形成由CanCommit、PreCommit和do Commit三个阶段组成的事务处理协议，如下所示：
阶段一：CanCommit
-
事务询问
协调者向所有参与者发送一个包含事务内容的CanCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
-
各参与者向协调者反馈事务询问的响应
参与者在接收到来自协调者的CanCommit请求后，正常情况下，如果自身认为能顺利执行事务，会反馈yes，进入预备状态，否则反馈no。
阶段二：PreCommit
根据阶段一的反馈情况，包含两种可能：
-
执行事务预提交(都返回yes)
-
发送预提交请求
协调者向所有参与者发出PreCommit的请求，进入Prepared阶段。
-
事务预提交
参与者收到PreCommit请求后，执行实务操作，记录Undo和Redo信息到事务日志中。
-
各参与者向协调者反馈事务执行的响应
如果参与者成功执行了事务操作，反馈给协调者Ack响应，等待最终指令：提交(commit)或中止(abort)
-
-
中断事务(任何一个返回了no或者等待超时)
-
发送中断请求
协调者向所有参与者发出abort请求。
-
中断事务
无论是收到协调者的abort请求，还是等待协调者请求过程中出现超时，参与者都会中断事务。
-
阶段三：doCommit
该阶段会进行真正的提交，可能包含两种情况。
-
执行提交
-
发送提交请求
假设协调者正常，并且收到所有的参与者的Ack响应，将从“预提交”转为“提交”状态，向所有参与者发送doCommit请求。
-
事务提交
参与者收到doCommit请求，正式执行事务提交，并在完成事务提交后释放资源。
-
反馈事务提交结果
参与者完成事务提交之后，向协调者发送Ack消息。
-
完成事务
协调者收到所有参与者反馈的Ack消息，完成事务。
-
-
中断事务
-
发送中断请求
假设协调者正常，向所有参与者节点发送abort请求。
-
事务回滚
参与者收到abort请求，利用阶段二中的Undo信息执行事务回滚，回滚完成后释放资源。
-
反馈事务回滚结果
参与者完成事务回滚后，向协调者发送Ack消息。
-
中断事务
协调者收到所有参与者反馈的Ack消息后，中断事务。
-
一旦进入阶段三，可能会存在一下两种故障：
-
协调者出现问题
-
协调者与参与者之间网络出现问题
无论哪种情况，最终参与者都会在等待超时后，继续进行事务提交。
优缺点
-
优点：降低了参与者的阻塞范围，在单点故障之后继续达成一致。
-
缺点：网络分区的出现会导致协调者和参与者无法正常地网络通信，参与者仍会提交事务，会导致数据的不一致性。
Paxos算法
Paxos算法是1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。它需要解决的问题是如何在一个可能发生异常的分布式系统中快速且正确地在集群内部对某个数据的值达成一致，且不会破坏系统的一致性。
拜占庭将军问题
在拜占庭帝国，有一位将军领导一支军队，他需要协调攻城的计划。将军的军队分布在城市周围，而城市之间的通信需要通过信使传递消息。然而，帝国中存在叛变的将军，他们可能会传递虚假的消息以迷惑其他将军。问题的目标是找到一种方法，使得忠诚的将军能够在叛变的将军存在的情况下达成共识，以决定是否进攻城市。
Paxos 算法概述
是一种用于分布式系统中的共识算法，它的主要目标是使多个节点在分布式环境中达成一致的决策。
Paxos 算法解决了拜占庭将军问题中的信任问题和共识问题。它具有以下基本概念：
-
提议者（Proposers）：这些是节点，它们提出值（决策）并试图说服其他节点接受这个值。
-
接受者（Acceptors）：这些是节点，它们接受提议并投票赞成或反对提议。
-
学习者（Learners）：这些是节点，它们学习提议的结果并在需要时应用它们。
Paxos 算法的基本流程
-
提议阶段：
-
提议者向接受者提出提议（值）。
-
接受者根据一定规则投票赞成或反对提议。规则包括：一个接受者只能投票一次，接受者可以投赞成或反对票，如果一个接受者已经接受了一个提议，它不能再接受其他提议。
-
-
批准阶段：
-
如果提议者获得了多数接受者的赞成票，提议被批准。
-
提议者通知所有节点提案已被批准，节点学习(获取)这个值。
-
-
学习阶段：
-
学习者学习提案的结果，并在需要时应用它。
-
03Google Chubby对Paxos的实现
Google Chubby 是 Google 内部使用的分布式锁服务，它基于 Paxos 算法实现。Chubby 允许分布式系统在多个节点之间协同工作，以确保数据一致性和强一致性。Google Chubby 不是开源的。
Chubby 本来应该被设计成一个包含Paxos算法的协议库，应用程序可以基于这个库方便地使用Paxos算法，但是它并没有这么做，而是把Chubby设计成了一个需要访问中心化节点的分布式锁服务。既然是一个服务，那么它肯定需要是一个高可靠的服务。所以 Chubby 被构建为一个集群，集群中存在一个中心节点（MASTER），采用Paxos协议，通过投票的方式来选举一个获得过半票数的服务器作为 Master，在 chubby 集群中，每个服务器都会维护一份数据的副本，在实际的运行过程中， 只有 master 服务器能执行事务操作，其他服务器都是使用paxos协议从master节点同步最新的数据。
以下是关于 Google Chubby 和其对 Paxos 的实现的一些简要信息：
-
Paxos 算法实现：Chubby 使用 Paxos 算法作为其核心共识算法。Paxos 用于确保 Chubby 中的数据一致性。这意味着 Chubby 使用多个 Paxos 实例来处理不同类型的数据，例如锁、配置信息等。
-
领导者选举：Chubby 中有一个特殊的节点称为 "master" 或 "leader"，它负责协调锁服务并维护一致性。Chubby 使用 Paxos 来选择 leader。Leader 选举是 Paxos 的一个实例，用于确保只有一个节点成为 leader。
-
分布式锁管理：Chubby 提供了分布式锁服务，使得多个客户端可以竞争获取锁。这些锁的管理也基于 Paxos，确保锁的一致性和互斥性。
-
配置管理：Chubby 用于存储和维护配置信息，如服务的地址、节点信息等。这也是一个使用 Paxos 来维护一致性的应用。
-
故障容忍性：Chubby 具有一定的故障容忍性。即使一些节点出现故障，Chubby 仍然能够继续工作。Paxos 的特性使得 Chubby 在节点失效和网络分区的情况下能够维护一致性。
-
性能优化：Chubby 做了一些性能优化，以提高 Paxos 算法的效率。这包括缓存机制和快速恢复机制。
参考书籍：从Paxos到Zookeeper 分布式一致性原理与实践 [倪超著]
2588
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
