分布式系统概念

欢迎你来读这篇博客，这篇博客主要是关于分布式系统概念。
其中包括了关于我的见解和收集的知识分享。

序言

分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。

通俗的理解，所谓分布式系统，就是一个业务拆分成多个子业务，分布在不同的服务器节点，共同构成的系统称为分布式系统，同一个分布式系统中的服务器节点在空间部署上是可以随意分布的，这些服务器可能放在不同的机柜中，也可能在不同的机房中，甚至分布在不同的城市。

系统架构

  • 单体
    • 服务器：服务A、服务B、服务C
  • 集群
    • 服务器1：服务A、服务B、服务C
    • 服务器2：服务A、服务B、服务C
  • 分布式
    • 服务器1：服务A
    • 服务器2：服务B
    • 服务器3：服务C
  • 分布式集群
    • 服务器1：服务A
    • 服务器2：服务B、服务C
    • 服务器3：服务C、服务E、服务D
    • 服务器4：服务D、服务E、服务B
    • 服务器5：服务A

分布式系统

分布式系统的特点

  • 分布性：空间中随机分布。这些计算机可以分布在不同的机房，不同的城市，甚至不同的国家。
  • 对等性：分布式系统中的计算机没有主/从之分，组成分布式系统的所有节点都是对等的。
  • 并发性：同一个分布式系统的多个节点，可能会并发地操作一些共享的资源，诸如数据库或分布式存储。
  • 缺乏全局时钟：既然各个计算机之间是依赖于交换信息来进行相互通信，很难定义两件事件的先后顺序，缺乏全局始终控制序列
  • 故障总会发生：组成分布式的计算机，都有可能在某一时刻突然间崩掉。分的计算机越多，可能崩掉一个的几率就越大。如果再考虑到设计程序时的异常故障，也会加大故障的概率。
  • 处理单点故障：单点SPoF（Single Point of Failure）：某个角色或者功能只有某一台计算机在支撑，在这台计算机上出现的故障是单点故障。

分布式系统面临的问题

  • 通信异常
  • 网络分区
  • 节点故障
  • 三态：分布式系统每一次请求与响应存在特有的“三态”概念，即成功、失败和超时。
  • 重发
  • 幂等：任意多次执行对资源本身所产生的影响均与一次执行的影响相同
    • update t set age=18 where id=1 幂等的
    • update t set age=age+1 where id=1 非幂等的

分布式理论

数据一致性

数据一致性：分布式数据一致性，指的是数据在多份副本中存储时，各副本中的数据是一致的。

副本一致性：分布式系统当中，数据往往会有多个副本。多个副本就需要保证数据的一致性。这就带来了同步的问题，因为网络延迟等因素,
我们几乎没有办法保证可以同时更新所有机器当中的包括备份所有数据. 就会有数据不一致的情况

总得来说，我们无法找到一种能够满足分布式系统中数据一致性解决方案。因此，如何既保证数据的一致性，同时又不影响系统运行的性能，是每一个分布式系统都需要重点考虑和权衡的。于是，一致性级别由此诞生。

一致性分类

  • 强一致性：这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大。但是强一致性很难实现。
  • 弱一致性：这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。

最终一致性：最终一致性也是弱一致性的一种，它无法保证数据更新后，所有后续的访问都能看到最新数值，而是需要一个时间，在这个时间之后可以保证这一点（就是在一段时间后，节点间的数据会最终达到一致状态），而在这个时间内，数据也许是不一致的，这个系统无法保证强一致性的时间片段被称为「不一致窗口」。不一致窗口的时间长短取决于很多因素，比如备份数据的个数、网络传输延迟速度、系统负载等。

  • 因果一致性：如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。
  • 读己之所写一致性：当进程A自己更新一个数据项之后，它总是访问到更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。
  • 会话一致性：它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统的保证不会延续到新的会话。
  • 单调读一致性：如果一个进程已经读取到一个特定值，那么该进程不会读取到该值以前的任何值。
  • 单调写一致性：系统保证对同一个进程的写操作串行化。

一致性模型图：

CAP定理

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

  • 一致性（Consistency）：所有节点访问时都是同一份最新的数据副本
  • 可用性（Availability）：每次请求都能获取到非错的响应，但是不保证获取的数据为最新数据
  • 分区容错性（Partition tolerance）：分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障

一致性（C-Consistency) - 强一致性：在写操作完成后开始的任何读操作都必须返回该值，或者后续写操作的结果.
也就是说，在一致性系统中，一旦客户端将值写入任何一台服务器并获得响应，那么之后client从其他任何服务器读取的都是刚写入的数据

可用性（A-Availability)：系统中非故障节点收到的每个请求都必须有响应.
在可用系统中，如果我们的客户端向服务器发送请求，并且服务器未崩溃，则服务器必须最终响应客户端，不允许服务器忽略客户的请求

分区容错性（P-Partition tolerance）：允许网络丢失从一个节点发送到另一个节点的任意多条消息，即不同步.
也就是说，G1和G2发送给对方的任何消息都是可以放弃的，也就是说G1和G2可能因为各种意外情况，导致无法成功进行同步，分布式系统要能容忍这种情况。

CAP三者不可能同时满足论证

  • 假设确实存在三者能同时满足的系统
  • 那么我们要做的第一件事就是分区我们的系统，由于满足分区容错性，也就是说可能因为通信不佳等情况，G1和G2之间是没有同步
  • 接下来，我们的客户端将v1写入G1，但G1和G2之间是不同步的，所以如下G1是v1数据，G2是v0数据。
  • 由于要满足可用性，即一定要返回数据，所以G1必须在数据没有同步给G2的前提下返回数据给client
  • 接下去，client请求的是G2服务器，由于G2服务器的数据是v0，所以client得到的数据是v0
  • 结论: 很明显，G1返回的是v1数据，G2返回的是v0数据，两者不一致。其余情况也有类似推导，也就是说CAP三者不能同时出现。

CAP三者如何权衡

  • CA (Consistency + Availability)：关注一致性和可用性，它需要非常严格的全体一致的协议。CA
    系统不能容忍网络错误或节点错误，一旦出现这样的问题，整个系统就会拒绝写请求，因为它并不
    知道对面的那个结点是否挂掉了，还是只是网络问题。唯一安全的做法就是把自己变成只读的。
  • CP (consistency + partition tolerance)：关注一致性和分区容忍性。它关注的是系统里大多数人
    的一致性协议。这样的系统只需要保证大多数结点数据一致，而少数的结点会在没有同步到最新版
    本的数据时变成不可用的状态。这样能够提供一部分的可用性。
  • AP (availability + partition tolerance)：这样的系统关心可用性和分区容忍性。因此，这样的系统
    不能达成一致性，需要给出数据冲突，给出数据冲突就需要维护数据版本。

如何进行三选二

放弃了一致性，满足分区容错，那么节点之间就有可能失去联系，为了高可用，每个节点只能用本
地数据提供服务，而这样会容易导致全局数据不一致性。对于互联网应用来说，机器数量庞大，节点分
散，网络故障再正常不过了，那么此时就是保障AP，放弃C的场景，而从实际中理解，像网站这种偶尔
没有一致性是能接受的，但不能访问问题就非常大了。

对于银行来说，就是必须保证强一致性，也就是说C必须存在，那么就只用CA和CP两种情况，当保
障强一致性和可用性（CA），那么一旦出现通信故障，系统将完全不可用。另一方面，如果保障了强一
致性和分区容错（CP），那么就具备了部分可用性。实际究竟应该选择什么，是需要通过业务场景进行
权衡的（并不是所有情况都是CP好于CA，只能查看信息但不能更新信息有时候还不如直接拒绝服务）

BASE 理论

BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一
致性）三个短语的缩写，Base 理论是对 CAP 中一致性和可用性权衡的结果，其来源于对大型互联网分布
式实践的总结，是基于 CAP 定理逐步演化而来的。

其核心思想是： 既是无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

  • Basically Available(基本可用)
    • 假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言：
    • 响应时间上的损失：正常情况下的搜索引擎 0.5 秒即返回给用户结果，而基本可用的搜索引擎
      可以在 1 秒返回结果。
    • 功能上的损失：在一个电商网站上，正常情况下，用户可以顺利完成每一笔订单，但是到了大
      促期间，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面
  • Soft state（软状态）
    • 相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。
    • 软状态指的是：允许系统中的数据存在中间状态，并认为该状态不会影响系统的整体可用性，即允
      许系统在多个不同节点的数据副本存在数据延时。
  • Eventually consistent（最终一致性）
    • 上面说软状态，然后不可能一直是软状态，必须有个时间期限。在期限过后，应当保证所有副本保
      持数据一致性。从而达到数据的最终一致性。这个时间期限取决于网络延时，系统负载，数据复制
      方案设计等等因素。

分布式一致性协议

分布式事务: 事务提供一种操作本地数据库的不可分割的一系列操作“要么什么都不做，要么做全套(All or Nothing)
”的机制,而分布式事务就是为了操作不同数据库的不可分割的一系列操作“要么什么都不做，要么做全套(Allor Nothing)“的机制

2PC

两阶段提交协议，简称2PC(2 Prepare Commit)
，是比较常用的解决分布式事务问题的方式，要么所有参与进程都提交事务，要么都取消事务，即实现ACID中的原子性(A)的常用手段。

  • 准备阶段（Prepare
    Phase）：协调者（通常是事务的发起者）向所有参与者节点发送准备请求，询问它们是否可以提交事务。如果所有参与者都可以提交事务，它们会返回“准备好”的响应。如果任何一个参与者无法提交，协调者会收到相应的拒绝信息或者超时。

  • 提交阶段（Commit Phase）：如果所有参与者都同意提交，协调者会发出提交请求，参与者执行提交操作；如果上一阶段有任何一个参与者拒绝，协调者会发送回滚请求，所有参与者都执行回滚操作，确保事务不会部分完成，避免数据不一致。

2PC的优缺点

  • 优点
    • 简单
  • 缺点
    • 同步阻塞
    • 单点问题，协调者出问题，集体歇菜
    • 数据不一致，二阶段如果出问题就没办法了
    • 太过保守

3PC

基于2PC的优化升级。

  • can-commit：
    • 协调者（Coordinator）向所有参与者发送“CanCommit？”请求，询问它们是否准备好提交事务。
    • 参与者在收到请求后，会检查是否能够提交事务。如果参与者能够提交事务，它会返回一个Yes响应，表示它准备好了；如果不能提交，它会返回No响应，表示拒绝提交。
    • 如果所有参与者都返回Yes，则进入下一阶段；如果有任何参与者返回No，则直接进入回滚阶段。
  • pre-commit：
    • 一旦所有参与者都返回Yes，协调者会发出PreCommit请求，通知所有参与者可以进行事务的预提交。
    • 参与者收到PreCommit请求后，会执行准备提交的操作，但不会最终提交数据。此时，参与者处于预提交状态，等待协调者的最终确认。
    • 如果在此阶段发生了问题，比如协调者崩溃或失联，参与者仍然保持预提交状态，等待协调者的恢复。
  • do-commit：
    • 如果协调者在预提交阶段没有发生故障，它会向所有参与者发送Commit请求，确认提交事务。
    • 参与者收到Commit请求后，才会实际提交事务，完成整个事务的操作。
    • 如果协调者崩溃或失联，在此阶段，所有参与者会等待协调者恢复并决定是否提交。

与2PC相比

  • 给参与者引入超时机制，2PC仅协调者有超时机制。防止一直阻塞，不提交事务。
  • 三阶段，多一个阶段，相当于做了缓冲，保证最后数据一致性。
  • 并没有完全解决数据一致性问题

3PC的优缺点

  • 优点
    • 通过引入预提交阶段，3PC可以在协调者崩溃或网络分区时避免死锁。
    • 在预提交阶段，参与者已做出准备，能够在协调者恢复后根据状态决定是否提交或回滚。
  • 缺点
    • 3PC协议依然可能因为网络分区导致阻塞，虽然它比2PC更具容错性，但在极端情况下仍可能遇到死锁和一致性问题。
    • 协调者和参与者之间的消息传递增加了系统的复杂性和开销。

NWR协议

NWR是一种在分布式存储系统中用于控制一致性级别的一种策略。在亚马逊的云存储系统中，就应用NWR来控制一致性。

  • N:在分布式存储系统中，有多少份备份数据
  • W:代表一次成功的更新操作要求至少有w份数据写入成功
  • R:代表一次成功的读数据操作要求至少有R份数据成功读取

原理：NWR值的不同组合会产生不同的一致性效果，当W+R>N的时候，整个系统对于客户端来讲能保证强致性。

  • 以常见的N=3、W=2、R=2为例:
  • N=3，表示，任何一个对象都必须有三个副本
  • W=2表示，对数据的修改操作只需要在3个副本中的2个上面完成就返回
  • R=2表示，从三个对象中要读取到2个数据对象，才能返回
  • 在分布式系统中，数据的单点是不允许存在的。即线上正常存在的备份数量N设置1的情况是非常危险的，因为一旦这个备份发生错误，就
    可能发生数据的永久性错误。假如我们把N设置成为2，那么，只要有一个存储节点发生损坏，就会有单点的存在。所以N必须大于2。N越高，系统的维护和整体
    成本就越高。工业界通常把N设置为3。
  • 当W是2、R是2的时候，W+R>N，这种情况对于客户端就是强一致性的。
  • 当R+W<=N，无法保证数据的强一致性
    • 因为成功写和成功读集合可能不存在交集，这样读操作无法读取到最新的更新数值，也就无法保证数据的强一致性。

Gossip协议

Gossip 协议也叫 Epidemic 协议(流行病协议)。原本用于分布式数据库中节点同步数据使用后被广泛用于数据库复制、信息扩散、集群成员身份确认、故障探测等。

从 gossip 单词就可以看到，其中文意思是八卦、流言等意思，我们可以想象下绯闻的传播(或者流行病的传播);gossip
协议的工作原理就类似于这个。gossip 协议利用一种随机的方式将信息传播到整个网络中，并在一定时间内使得系统内的所有节点数据一致。Gossip
其实是一种去中心化思路的分布式协议，解决状态在集群中的传播和状态一致性的保证两个问题。

  • 反熵传播
    • 是以固定的概率传播所有的数据。所有参与节点只有两种状态:Suspective(病原)、Infective(感染)
      。过程是种子节点会把所有的数据都跟其他节点共享，以便消除节点之间数据的任何不一致，它可以保证最终、完全的一致。缺点是消息数量非常庞大，且无限制;通常只用于新加入节点的数据初始化。
  • 谣言传播
    • 是以固定的概率仅传播新到达的数据。所有参与节点有三种状态:Suspective(病原)、Infective(感染)、Removed(愈除)。过程是消息只包含最新
      update，谣言消息在某个时间点之后会被标记为 removed，并且不再被传播。缺点是系统有一定的概率会不一致，通常用于节点间数据增量同步。

通信方式

  • push：a推送给b
  • pull：a把key和version推送给b，b去a拉数据
  • push/pull：与 Pull 类似，只是多了一步，再将本地比B新的数据推送给 B，B 则更新本地

Gossip 是一种去中心化的分布式协议，数据通过节点像病毒一样逐个传播。因为是指数级传播，整体传播速度非常快。

gossip协议的优缺点

  • 优点
    • 扩展性
    • 容错
    • 去中心化
    • 最终一致性
  • 缺点
    • 消息延迟
    • 消息冗余

Gossip 协议由于以上的优缺点，所以适合于 AP 场景的数据一致性处理，常见应用有:P2P 网络通信Redis Cluster、 Consul.

Paxos协议

Paxos协议其实说的就是Paxos算法,Paxos算法是基于消息传递且具有高度容错特性的一致性算法，是目前公认的解决分布式一致性问题最有效的算法之一。

Paxos由 莱斯利·兰伯特(Leslie Lamport)于1998年在《The Part-Time
Parliament》论文中首次公开，最初的描述使用希腊的一个小岛Paxos，描述了Paxos小岛中通过决议的流程，并以此命名这个算法，但是这个描述理解起来比较有挑战性。后来在2001年，莱斯利·兰伯特重新发表了朴实的算法描述版本《Paxos
Made Simple》

自Paxos问世以来就持续垄断了分布式一致性算法，Paxos这个名词几乎等同于分布式一致性。Google的很多大型分布式系统都采用了Paxos算法来解决分布式一致性问题，如Chubby、Megastore以及Spanner等。开源的ZooKeeper，以及MySQL5.7推出的用来取代传统的主从复制的MySQL
GroupReplication等纷纷采用Paxos算法解决分布式一致性问题。然而，Paxos的最大特点就是难，不仅难以理解，更难以实现。

Google Chubby的作者Mike Burrows说过这个世界上只有一种一致性算法，那就是Paxos，其它的算法都是残次品。

在常见的分布式系统中，总会发生诸如机器宕机或网络异常(包括消息的延迟、丢失、重复、乱序，还有网络分区)
等情况。Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致，并且保证不论发生以上任何异常，都不会破坏整个系统的一致性。

注:这里某个数据的值并不只是狭义上的某个数，它可以是一条日志，也可以是一条命令(command)。。。根据应用场景不同，某个数据的值有不同的含义。

  • 在之前讲解2PC和 3PC的时候在一定程度上是可以解决数据一致性问题的.但是并没有完全解决就是协调者宕机的情况.
  • 如何解决：引入多个协调者
  • 引入主从：主负责协调，从负责跟随
  • 这就是一个简单的paxos实现

Paxos的版本有:BasicPaxos,Multi Paxos，Fast-Paxos,具体落地有Raft 和zk的ZAB协议（均属于multi paxos算法）

basic paxos
  • 角色
    • client 客户端
    • proposer 提案发起者
    • acceptor 决策者
    • learner 最终决策学习者
  • 流程
    • prepare：Proposer提出一个提案,编号为N,此N大于这个Proposer之前提出所有提出的编号,请求Accpetor的多数人接受这个提案
    • promise：如果编号N大于此Accpetor之前接收的任提案编号则接收,否则拒绝
    • accept：如果达到多数派,Proposer会发出accept请求,此请求包含提案编号和对应的内容
    • accepted：如果此Accpetor在此期间没有接受到任何大于N的提案,则接收此提案内容,否则忽略
multi paxos

相比basic 多一个选举流程

Raft协议

演示
github raft

lease机制

Lease机制，翻译过来即是租约机制，是一种在分布式系统常用的协议，是维护分布式系统数据一致性的一种常用工具。

  • Lease是颁发者对一段时间内数据一致性的承诺;
  • 颁发者发出Lease后，不管是否被接收，只要Lease不过期，颁发者都会按照协议遵守承诺;
  • Lease的持有者只能在Lease的有效期内使用承诺，一旦Lease超时，持有者需要放弃执行，重新申请Lease。

分布式系统设计策略

心跳检测

高可用HA设计

  • 主备
  • 互备
  • 脑裂问题解决
    • 冗余心跳线
    • 仲裁
    • lease机制
    • 隔离Fencing机制
      • 共享存储fencing:确保只有一个Master往共享存储中写数据
      • 客户端fencing:确保只有一个Master可以响应客户端的请求
      • Slave fencing:确保只有一个Master可以向Slave下发命令

容错

负载均衡

分布式架构服务调用

  • HTTP
    • HttpURLConnection
    • Apache Common HttpClient
    • OKhttp3
    • RestTemplate
  • RPC
    • Java RMI
    • Hessian
    • Dubbo
    • gRPC

跨域调用解决方案

  • jsonp
  • httpclient内部转发
  • 允许跨域
  • 网关
    • nginx网关
    • zuul网关
    • gateway网关
    • 云原生网关

分布式服务治理

服务协调

分布式锁

  • 基于缓存实现
  • 基于zk实现

服务削峰

  • 消息队列
  • 漏斗层层削峰

服务降级

电商平台在高并发时，可能会关闭某些推荐服务、评论显示等非核心功能，确保用户仍然能够浏览商品、下单等核心功能。

降级策略

  • 页面降级 – 可视化界面禁用点击按钮、调整静态页面
  • 延迟服务 – 如定时任务延迟处理、消息入MQ后延迟处理
  • 写降级– 直接禁止相关写操作的服务请求
  • 读降级 – 直接禁止相关读的服务请求
  • 缓存降级 – 使用缓存方式来降级部分读频繁的服务接口

分级降级

服务限流

多维限流

限流算法

  • 固定窗口 计数器
  • 滑动窗口 细分计数器
  • 漏桶 FIFO定时取
  • 令牌桶

服务熔断

服务熔断主要是为了防止系统在出现故障时陷入“雪崩效应”，即一个服务的故障可能导致一系列其他服务的故障。

特性 服务熔断 (Circuit Breaker) 服务降级 (Service Degradation)
目的 防止故障蔓延，保护系统免受级联故障影响。 保证核心功能正常运行，减少系统的压力。
原理 通过监控错误率，超限时自动停止请求，避免系统过载。 在负载过高或某服务出现问题时，减少非核心功能，保证核心服务。
触发机制 当服务的失败率超过阈值时，熔断器打开，停止请求。 系统压力过大或某个服务不可用时，主动关闭部分功能。
影响范围 降低故障蔓延的影响，避免请求进一步失败。 降低非核心功能的可用性，保证核心功能不受影响。
示例 请求超时超过某个阈值，熔断器打开，停止请求。 降低页面加载速度，关闭非关键服务（如推荐、评论等）。

熔断关注失败的控制，而降级侧重于负载和功能的控制

服务链路追踪

分布式链路追踪(Distributed Tracing)，也叫 分布式链路跟踪，分布式跟踪，分布式追踪
等等.其实就是将一次分布式请求还原成调用链路。显示的在后端查看一次分布式请求的调用情况，比如各个节点上的耗时、请求具体打到了哪台机器上、每个服务节点的请求状态等等

  • 故障快速定位
  • 各个调用环节的性能分析
  • 数据分析
  • 生成服务调用拓扑图

链路追踪设计原则

  • 设计目的
    • 低侵入应用透明、低损耗、大范围部署扩展性
  • 埋点和生成日志
  • 抓取和存储日志
  • 分析和统计调用链数据
  • 计算和展示

trace模型

  • trace：一次完整的调用链路
  • span：调用的基本结构 多span组成的树状结构，组合成一次trace记录
  • annotation：span中的标注点
  • BinaryAnnotation：特殊的Annotation，用户自定义事件

架构设计基本原则 SOLID原则

开闭原则

单一职责原则

接口隔离原则

里氏替换原则

依赖倒置原则

迪米特法则

合成复用原则

参考资料

启示录

富贵岂由人，时会高志须酬。

能成功于千载者，必以近察远。

杂谈
#杂谈 #Java #分布式
分布式系统概念
https://allendericdalexander.github.io/2025/03/05/distributed_sys_guide/
作者
AtLuoFu
发布于
2025年3月5日
许可协议