学习路线

（1）分布式系统基础理论

（2）分布式共识算法

（3）分布式系统通信方式RPC

（4）分布式系统负载均衡

分布式基础理论

CAP理论

一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availablity）和分区容错性（Partition tolerance）这三项中的两项。

（1）一致性：在CAP理论中的一致性表示强一致性，即线性一致性。

（2）可用性：要求系统内的节点们收到无论是写请求还是读请求，都要能处理并给回响应结果。他有两点必须满足的条件：（1）返回结果必须在合理的时间以内。这个合理的时间根据不同业务来进行确定。（2）需要系统内能正常接收请求的所有节点都返回结果，即如果节点不能正常接收请求（宕机，崩溃等情况），而其他节点依然能正常接收请求，那么，系统依然是可用的（部分宕机不影响可用性指标）；如果节点能正常接收请求，但发现节点内部数据有问题，但也必须返回结果。

（3）分区容错性：分布式存储系统中存在有许多节点，节点之间的通信依靠网络，网络是不可靠的，当节点和节点之间的通信出现了问题，此时，就称当前的分布式存储系统出现了分区。分区不一定是由网络故障引起的，也可能是因为机器故障引起的。综上所述，在分布式系统中，节点通信出现了问题，那么就出现了分区。

分区容错性是指，如果出现了分区问题，分布式系统不能因为分区问题而崩溃罢工，即分布式系统在出现分区后在各个分区依然要提供正常的服务。

一般情况下，在分布式系统中，P是必然选择，因此开源的分布式系统往往划分为CP系统和AP系统，但注意，CP并不是舍弃了A，AP也并非舍弃了C，其只是根据实际需要在这两者中选择更偏向于哪一个。

CAP理论的不足：

（1）其没有考虑网络延迟的问题。

（2）A和C并不是二选一的问题，只是一些重要性的区别。

大厂面试题：

（1）什么是CAP理论？

（2）CAP理论中的P的涵义？

（3）为什么说分布式系统，只能在C和A中二选一？

（4）结合实际应用，CP、AP该如何选择？

参考：一文看懂｜分布式系统之CAP理论-腾讯云开发者社区-腾讯云

PACELC理论

CAP理论是分布式应用的基础理论。其中，C：要求所有节点同一时刻保持数据一致；A：要求应用在某些节点发生异常时，应用本身是可用的；P：分布式应用存在有多个节点，节点之间通过网络通信，当存在网络中断或超时时，分区依旧能够正常提供服务。

分布式系统用下，P是必然的，因此，只能在AC之间进行权衡。CP牺牲了可用性（如zk分布式锁）、AP牺牲了一致性（如mysql主从复制）。

CP追求强一致性，但在真实世界中，完全的强一致性是不存在的，也就是说，节点之间的同步会存在延迟，因此，有了PACELC理论。PAC即CAP理论，E表示Else，L是latency延迟，C依然为Consisteny。简单来说，当出现分区异常时，需要在A和C之间做权衡；当不存在分区异常，需要在L和C之间做权衡。

典型案例：

（1）mysql主从复制 mysql主从复制带来了高可用，但即使在网络通信正常的情况下，主从同步还是存在延迟，所以此时就需要权衡是否可以接受延迟，如果不接受可以直接去读主库。当然，主从同步发生异常时，并不影响从库数据的读取，即从库是可用的。 

（2）zk分布式锁 使用zk的临时节点可以实现分布式锁，zk和客户端通过heartbeat保持live连接，如连接失效，则自动删除临时节点从而释放锁。但是这个连接保持就存在很多情况，如果因为网络超时或应用假死，那么就会存在两个进程获取到锁，导致分布式锁失效，redis分布式锁也存在类似的问题，所以使用分布式锁一定要小心。

参考：

分布式应用：从CAP理论到PACELC理论开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第1天 1 - 掘金

BASE理论

Base available、soft state、eventually consistent。

BASE 理论是对 CAP 理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。

BASE 理论是实践工程的理论，它弥补了CAP 理论过于抽象的问题，也同时解决了 AP 系统的总体工程实践思想，是分布式系统的核心理论之一。

参考：(6 封私信) 分布式基础-BASE理论 - 知乎

NWR多数派理论

说了PACELC可以补充一个这个的例子

一致性理论

参考：

（1）https://tanxinyu.work/consistency-and-consensus/（一致性模型与共识算法）

（2）https://segmentfault.com/a/1190000022248118（共识、线性一致性与顺序一致性）

（3）https://mp.weixin.qq.com/s/qnvl_msvw0XL7hFezo2F4w（条分缕析分布式：到底什么是一致性？）

（4）https://mp.weixin.qq.com/s/3odLhBtebF4cm58hl-87JA（条分缕析分布式：浅析强弱一致性）

（4）https://mp.weixin.qq.com/s/wkXsRufVsbKqTwjzTgNqYQ（条分缕析分布式：因果一致性和相对论时空）

一致性hash算法

普通一致性hash算法

一致性hash算法底层数据结构

一致性hash算法的具体实现

数据倾斜

虚拟节点

参考：图解一致性哈希算法，看这一篇就够了！ -阿里云开发者社区

分布式共识算法

2PC & 3PC

参考：分布式事务之深入理解什么是2PC、3PC及TCC协议？ - 无敌的码农 - 博客园

Paxos协议

参考：(6 封私信) Paxos算法详解 - 知乎

活锁

Raft共识算法

共识是可容错系统中的一个基本问题：即使面对故障，服务器也可以在共享状态上达成一致。共识算法允许一组节点像一个整体一样一起工作，即使其中的一些节点出现故障也能够继续工作下去，其正确性主要源于复制状态机的性质：一组Server（寄点）的状态机计算相同状态的副本，即使有一部分的Server（节点）宕机了它们仍然能够继续运行。

一般通过复制日志来实现复制状态机，每个Server（节点）存储着一份包含命令序列的日志文件，状态机会按照顺序执行这些命令，因为每个日志包含相同的命令，并且顺序也相同，所以每个状态机处理相同的命令序列。由于状态机是确定性的，所以处理相同的状态，得到相同的输出。

在分布式系统中有一种常见复制状态机的抽象，就是把具有一定顺序的一系列action抽象成一条日志(log)，每个action都是日志中的一个条目（entry）。如果想使每个节点的服务状态相同，则要把日志中的所有entry按照记录顺序执行一遍。

所以复制状态机的核心问题就变成了让每个节点都具有相同的日志的问题，也就是把日志复制到每个节点上的问题。因此，这个问题也被称为复制日志（replicated log）问题。

↑解

↑决

↑方

↑案

共识算法的工作就是保持复制日志的一致性。服务器上的共识模块从客户端接收命令并将它们添加到日志中。它与其他服务器上的共识模块进行通信，以确保即使某些服务器发生故障。每个日志最终包含相同顺序的请求，一旦命令被正确的复制，它们就被称为已提交。每个服务器的状态机按照日志顺序处理已提交的命令，并将输出返回给客户端，因此，这些服务器形成了一个单一的、高度可靠的状态机。

适用于实际系统的共识算法通常具有以下特性：

• 安全。确保在非拜占庭条件（也就是上文中提到的简易版拜占庭）下的安全性，包括网络延迟、分区、包丢失、复制和重新排序。
• 高可用。只要大多数服务器都是可操作的，并且可以相互通信，也可以与客户端进行通信，那么这些服务器就可以看作完全功能可用的。因此，一个典型的由五台服务器组成的集群可以容忍任何两台服务器端故障。假设服务器因停止而发生故障；它们稍后可能会从稳定存储上的状态中恢复并重新加入集群。
• 一致性不依赖时序。错误的时钟和极端的消息延迟，在最坏的情况下也只会造成可用性问题，而不会产生一致性问题。
• 在集群中大多数服务器响应，命令就可以完成，不会被少数运行缓慢的服务器来影响整体系统性能

Raft就是用来实现复制日志的一种算法，该算法会：

（1）生成一条日志（log）

（2）把这条日志复制到所有节点上

（3）把日志的entry应用到状态机上

每个状态机都以相同的顺序执行相同的命令，最终每个状态机都会达到相同的状态。Raft实现了节点之间的复制日志，每条日志（log）的内容就是一个命令（action/entry:<term,index,cmd>），如下图所示：

一个 Raft 集群包括若干服务器，在正常的情况下，只有一个服务器是 Leader，剩下的服务器是 Follower。Follower 是被动的，它们不会发送任何请求，只是响应来自 Leader 和 Candidate 的请求。在任意的时间，每个服务器一定会处于以下三个状态中的一个：

• Leader：负责发起心跳，响应客户端，创建日志，同步日志。
• Candidate：Leader 选举过程中的临时角色，由 Follower 转化而来，发起投票参与竞选。
• Follower：接受 Leader 的心跳和日志同步数据，投票给 Candidate。

Raft算法可分解为复制日志、选举和异常处理三个部分。Raft采用RPC来实现节点之间的通信，包括复制日志过程、选举过程和异常处理都通过RPC来实现。

复制日志过程

leader负责接收客户端的请求，根据请求生成日志，把日志复制到所有节点上，并且判断是否适合把日志应用到状态机中。我们将这个过程称作复制（replication）过程。

具体复制过程如下：

（1）当leader收到客户端的请求后，它会将这个请求作为一个entry记录到日志中。leader会将新entry记录到日志的最后，或者说追加到末尾（append）。

日志中的每个entry都有一个索引（index），index是一个连续整数，每追加一个entry，index就会加一。

（2）leader在完成append操作后，会并行向所有的follower发起AppendEntries RPC，follower收到AppendEntries调用后，将请求中的entry追加到自己的本地日志中，并回复leader成功。

（3）leader收到大多数follower的成功回复后，这个entry就被leader认为达到提交（committed）状态。leader将这个entry应用到状态机中，并且leader会回复客户端这次请求成功。对于没有回复的follower，leader会不断地重试，直到调用成功。

此时，follower只是把这个entry追加到日志中，并没有应用到状态机中（只有leader将其应用到状态机中了）。

Raft在下面两个时机会通知follower这个entry已经处于committed状态：

（1）当leader处理下一个客户端请求时，leader会将下一个entry复制到所有follower的请求中，带上committed状态的entry的index，follower将下一个entry追加到日志中，同时会将这个entry应用到状态机中。

（2）如果暂时没有新的客户端请求，则Raft会将committed状态的entry的index信息随着心跳发送给所有follower。

当follower通过上面两种方式知道entry已经提交后，它会把entry应用到状态机中。

这样的复制过程有一个特性：即使少数节点变慢或者网络拥堵，也不会导致这个过程变慢。

选举过程

当leader发生宕机等异常 ，此时其他节点需要成为新的leader，继续履行leader的职责。我们将这个过程称作选举（election）过程。

选举的基本条件是：在一定时间内，没有收到leader的日志复制请求，包括心跳请求，即发生超时（timeout）。

raft 使用心跳机制来触发 Leader 的选举。

如果一台服务器能够收到来自 Leader 或者 Candidate 的有效信息，那么它会一直保持为 Follower 状态，并且刷新自己的 electionElapsed，重新计时。

Leader 会向所有的 Follower 周期性发送心跳来保证自己的 Leader 地位。如果一个 Follower 在一个周期内没有收到心跳信息，就叫做选举超时，然后它就会认为此时没有可用的 Leader，并且开始进行一次选举以选出一个新的 Leader。

raft 算法将时间划分为任意长度的任期（term），任期用连续的数字表示，看作当前 term 号。每一个任期的开始都是一次选举，在选举开始时，一个或多个 Candidate 会尝试成为 Leader。如果一个 Candidate 赢得了选举，它就会在该任期内担任 Leader。如果没有选出 Leader，将会开启另一个任期，并立刻开始下一次选举。Raft 算法保证在给定的一个任期最少要有一个 Leader。

为了开始新的选举，Follower 会自增自己的 term 号并且转换状态为 Candidate。然后他会向所有节点发起 RequestVoteRPC 请求， Candidate 的状态会持续到以下情况发生：

• 赢得选举
• 其他节点赢得选举
• 一轮选举结束，无人胜出

赢得选举的条件是：一个 Candidate 在一个任期内收到了来自集群内的多数选票（N/2+1），就可以成为 Leader。

Leader 需要保证自己存储全部已经提交的日志条目。这样才可以使日志条目只有一个流向：从 Leader 流向 Follower，Leader 永远不会覆盖已经存在的日志条目。

每个 Candidate 发送 RequestVoteRPC 时，都会带上最后一个 entry 的信息。所有follower收到投票信息时，会对该 entry 进行比较，如果发现自己的更新，则拒绝投票给该 Candidate。

判断日志新旧的方式：如果两个日志的 term 不同，term 大的更新；如果 term 相同，更长的 index 更新。

在 Candidate 等待选票的时候，它可能收到其他节点声明自己是 Leader 的心跳，此时有两种情况：

（1）该 Leader 的 term 号大于等于自己的 term 号，说明对方已经成为 Leader，则自己回退为 Follower。

（2）该 Leader 的 term 号小于自己的 term 号，那么会拒绝该请求并让该节点更新 term。

在实际的选举过程要处理下面两个问题：

问题一：leader宕机无法收到多数follower选举

问题一：所有follower都发现leader宕机因此都转变状态为candidate，多个candidate都在抢夺leader的地位。因为多个candidate同一时刻发起投票，瓜分follower（每个follower只能投一个candidate），甚至大家都是candidate，没有follower。

多个candidate都想成为leader，剩下处在follower状态的节点形成不了大多数，这时candidate会一直等待，直到超过一定时间后，最后选举失败。为了选出新的leader，需要重新选举，并区分新旧选举的请求。

问题二：脑裂问题

问题二：除了发生leader宕机，还有其他情况要处理。比如：leader宕机后又恢复了，发生网络分区，这种情况要比leader宕机复杂，因为在宕机恢复和网络分区恢复后，集群中可能会出现两个leader，也就是出现脑裂问题。

我们需要区分出新旧两个leader，并且阻止旧的leader参与集群活动。

↑解

↑决

↑方

↑案

Raft共识算法采用任期（term）来解决上面的两个问题（脑裂和少数follower问题）。每个节点都用一个整形数字来保护任期，每次开始新的选举，任期都加一。

leader宕机问题解决

我们先通过一个例子来说明任期的作用。假如有两个节点A和B，它们的任期都为1，这两个节点都转变为candidate，开始选举，两个candidate都没有达到大多数同意，

这时节点A先发生超时，节点A会把它的任期加1，成为2，重新开始一次选举。各节点都会无条件优先接受更大的任期的请求，所以节点A这次会得到大多数节点的同意，成功成为leader。

同时超时同时开始选举：

但是存在一种特殊的情况，就是节点A和B同时开始选举，都没有达到大多数同意，节点A和B同时超时，又同时开始新的选举，又都没有达到大多数同意，又同时失败，这样就会反复地进行下去，没有休止。

Raft通过一种非常简单的方法解决了这个问题，就是在选举失败后、开始新的选举前，随机等待一段时间再重新选举(该方法被称为随机回退），那么节点A和B再次同时开始选举的可能性就大大降低了。

活锁：

然而，采用随机回退方法仍然可能存在一种特殊的情况，就是节点A被选举成为leader，节点B在选举中失败，节点B把自己的任期加1，开始新的选举，成功地成为leader，节点A连续两次新的选举后，以更大的任期成为新的leader，节点B也再次连续两次新的选举后成为新的leader，节点A和B就这样无限地循环下去。

虽然出现这种情况的可能性非常小，但是理论上是存在的，称之为活锁。

实际这种情况发生的概率很小，所以会被忽略不计。

脑裂问题的解决

leader的任期会被包含在所有的请求(包括复制请求和心跳请求)中，其他节点收到请求，如果请求中的任期比自己的大，则用请求中的任期更新自己的任期。

在选举结束后，所有节点的任期最终都会统一成leader的任期。如果收到的请求中的任期比自己的小，则会拒绝这个请求。

对于leader宕机后又恢复或者网络分区恢复这样的情况：

由于联系不上leader，follower会转变成candidate，把自己的任期加1，开始选举，并且成为新的leader，新的leader具有更大的任期，所有投票给新的leader的节点的任期和leader的任期是一样的。

当旧leader宕机恢复或者网络分区恢复后，旧的leader仍然在运行，但是它给其他节点发送请求不会形成大多数，因为大多数节点都具有更大的任期。一旦新的leader发送请求给旧的leader，旧的leader就会发现有更大的任期存在，它会主动转变为follower，并且更新自己的任期为新的leader的任期。

如上图所示，完整选举过程为：

节点启动时处于follower状态。

该节点在一段时间内没有收到任何请求，则发生超时，其转变为candidate。

candidate增加自己的任期，开始新的选举，向所有节点发送投票请求。candidate发出投票请求后，会有三种结果:

（3.1）没有得到大多数节点的同意，本次选举超时，开始新的选举。

（3.2）得到大多数节点的同意，成为新的leader。

（3.3）收到其他节点的请求，其任期与自己的相同，说明其他candidate已经在这次选举中得到大多数follower的同意，成为leader，这时这个candidate会退回到follower状态；或者请求中包含更大的任期，这个candidate也退回到follower状态。

（4）在leader收到的请求中包含更大的任期，leader转变为follower状态。

异常处理

在选举后，还需要处理由leader宕机异常带来的各种影响（各个节点的一致性问题），也就是进行异常处理。

一般情况下，Leader 和 Follower 的日志保持一致，然后，Leader 的崩溃会导致日志不一样，这样一致性检查会产生失败。Leader 通过强制 Follower 复制自己的日志来处理日志的不一致。这就意味着，在 Follower 上的冲突日志会被领导者的日志覆盖。

为了使得 Follower 的日志和自己的日志一致，Leader 需要找到 Follower 与它日志一致的地方，然后删除 Follower 在该位置之后的日志，接着把这之后的日志发送给 Follower。

Leader 给每一个Follower 维护了一个 nextIndex，它表示 Leader 将要发送给该追随者的下一条日志条目的索引。当一个 Leader 开始掌权时，它会将 nextIndex 初始化为它的最新的日志条目索引数+1。如果一个 Follower 的日志和 Leader 的不一致，AppendEntries 一致性检查会在下一次 AppendEntries RPC 时返回失败。在失败之后，Leader 会将 nextIndex 递减然后重试 AppendEntries RPC。最终 nextIndex 会达到一个 Leader 和 Follower 日志一致的地方。这时，AppendEntries 会返回成功，Follower 中冲突的日志条目都被移除了，并且添加所缺少的Leader 的日志条目。一旦 AppendEntries 返回成功，Follower 和 Leader 的日志就一致了，这样的状态会保持到该任期结束

参考：

（1）Raft 算法详解 | JavaGuide

（2）分布式与一致性——Raft算法详解_raft脑裂-CSDN博客

Zab协议

zab选举过程

zab崩溃恢复过程

脑裂

参考：https://www.bilibili.com/video/BV14Y411g7ok

分布式系统通信方式RPC

RPC组件组成：

（1）客户端（服务消费端）：调用远程方法的一端。

（2）客户端 Stub（桩）：这其实就是一代理类。代理类主要做的事情很简单，就是把你调用方法、类、方法参数等信息传递到服务端。

（3） 网络传输：网络传输就是你要把你调用的方法的信息比如说参数啊这些东西传输到服务端，然后服务端执行完之后再把返回结果通过网络传输给你传输回来。网络传输的实现方式有很多种比如最基本的 Socket 或者性能以及封装更加优秀的 Netty（推荐）。

（4） 服务端 Stub（桩）：这个桩就不是代理类了。我觉得理解为桩实际不太好，大家注意一下就好。这里的服务端 Stub 实际指的就是接收到客户端执行方法的请求后，去执行对应的方法然后返回结果给客户端的类。

（5）服务端（服务提供端）：提供远程方法的一端。

    调用过程：

（1）服务消费端（client）以本地调用的方式调用远程服务；

（2）客户端 Stub（client stub） 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体（序列化）：RpcRequest；（途中用到protobuf协议）

（3）客户端 Stub（client stub） 找到远程服务的地址，并将消息发送到服务提供端；（依赖于底层的socket通信即muduo协议（底层为基于linux的epoll和线程池））

（4） 服务端 Stub（桩）收到消息将消息反序列化为 Java 对象: RpcRequest；

（5）服务端 Stub（桩）根据RpcRequest中的类、方法、方法参数等信息调用本地的方法；（protobuf协议中的反序列化）

（6）服务端 Stub（桩）得到方法执行结果并将组装成能够进行网络传输的消息体：RpcResponse（序列化）发送至消费方；（重新序列化protobuf）

（7）客户端 Stub（client stub）接收到消息并将消息反序列化为 Java 对象:RpcResponse ，这样也就得到了最终结果。（客户端桩进行反序列化protobuf）

RPC算法与HTTP算法具有相同的功能，相较于HTTP1.0算法而言，RPC算法存在的意义为：

（1）纯裸 TCP 是能收发数据，但它是个无边界的数据流，上层需要定义消息格式用于定义 消息边界 。于是就有了各种协议，HTTP 和各类 RPC 协议就是在 TCP 之上定义的应用层协议。

（2）RPC 本质上不算是协议，而是一种调用方式，而像 gRPC 和 Thrift 这样的具体实现，才是协议，它们是实现了 RPC 调用的协议。目的是希望程序员能像调用本地方法那样去调用远端的服务方法。同时 RPC 有很多种实现方式，不一定非得基于 TCP 协议。

（3）从发展历史来说，HTTP 主要用于 B/S 架构，而 RPC 更多用于 C/S 架构。但现在其实已经没分那么清了，B/S 和 C/S 在慢慢融合。 很多软件同时支持多端，所以对外一般用 HTTP 协议，而内部集群的微服务之间则采用 RPC 协议进行通讯。

（4）RPC 其实比 HTTP 出现的要早，且比目前主流的 HTTP1.1 性能要更好，所以大部分公司内部都还在使用 RPC。

（5）HTTP2.0 在 HTTP1.1 的基础上做了优化，性能可能比很多 RPC 协议都要好，但由于是这几年才出来的，所以也不太可能取代掉 RPC。

对于主流的 HTTP1.1，虽然它现在叫超文本协议，支持音频视频，但 HTTP 设计 初是用于做网页文本展示的，所以它传的内容以字符串为主。Header 和 Body 都是如此。在 Body 这块，它使用JSON来序列化结构体数据。

可以看到这里面的内容非常多的冗余，显得非常啰嗦。最明显的，像 Header 里的那些信息，其实如果我们约定好头部的第几位是 Content-Type，就不需要每次都真的把 Content-Type 这个字段都传过来，类似的情况其实在 Body 的 JSON 结构里也特别明显。

而 RPC，因为它定制化程度更高，可以采用体积更小的 Protobuf 或其他序列化协议去保存结构体数据，同时也不需要像 HTTP 那样考虑各种浏览器行为，比如 302 重定向跳转啥的。因此性能也会更好一些，这也是在公司内部微服务中抛弃 HTTP，选择使用 RPC 的最主要原因。

 参考：

（1）RPC基础知识总结 | JavaGuide

（2）有了 HTTP 协议，为什么还要有 RPC ？ | JavaGuide

分布式系统的负载均衡

负载均衡是一种技术解决方案，用来在多个资源（一般是服务器）中分配负载，达到最优化资源使用，避免过载。

衡量系统是否满足高可用，就是当一台或多台服务器宕机时，系统整体和服务依旧正常可用。

其核心价值体现在三方面：

1. 资源利用率最大化
2. 系统可用性保证
3. 响应延迟优化

负载均衡系统通常包含三个核心组件：请求接收层（如nginx、HAProxy），调度算法层（轮询/权重/最少连接等）和健康检查层（心跳检测、服务探活）。三者协同合作，构成分布式系统的第一道防火墙。

调度算法层

分为三种调度算法：

静态调度算法

轮询调度：按顺序循环分配请求，适用于节点性能相近的场景。某Web服务测试显示，在10个等陪节点中，轮询算法可使各节点请求量偏差不超过5%.

加权轮询：为不同性能节点分配权重，如为高性能节点设置权重2，普通节点权重1.在实际部署中，该算法可使高端机型利用率替身30%

IP哈希：基于客户端IP计算哈希值，确保同一用户始终访问同一节点。适用于需要回话保持的场景，但可能导致节点负载不均，此时可采用一致性哈希环的方法，为了预防实施过程中的数据倾斜问题，可以使用虚拟节点的方法。

动态调度算法

最少连接：实时统计各节点活跃连接数，将新请求分配给连接最少的节点。在突发流量场景下，该算法可使系统吞吐量提升25%

加权最少连接：结合节点性能与连接数，计算公式为某节点活跃连接数/权重再处于所有节点活跃连接数除权重的总和。

最短响应时间：通过持续监测节点响应时间，优先分配给响应最快的节点。某微服务架构测试显示，该算法可使平局响应时间降低22%。=0.22

智能调度算法

基于机器学习的调度：通过历史数据训练预测模型，提前预判节点负载趋势。某大型电商采用LSTM模型预测后，资源预分配准确率达92%，资源浪费减少30%。=0.3

自适应阈值调度：动态调整节点负载阈值，当节点负载超过阈值时自动降权。在实际部署中，该机制可使系统在流量突增是保持99.9%的可用性。

负载均衡器选型与部署策略

硬件负载均衡器

F5 Big-Ip等硬件设备提供高性能（百万级QPS），低延迟（微妙级）的转发能力，单台设备成本高达数十万元。

软件负载均衡器

Nginx：支持七层负载均衡，配置灵活，社区生态完善。通过upsrtream模块可轻松实现轮询、权重、IP哈希等算法。

HAProxy：专注4层负载均衡，性能由于Nginx，支持TCP/UDP协议。

Envoy：云原生时代的负载均衡器，支持服务发现、熔断、限流等高级特性。

云服务负载均衡

AWS ALB，阿里云SLB等云服务提供全自动化的负载均衡解决方案，支持贪心伸缩、健康检查、SSL卸载等功能。

免责声明

此文章内容仅为个人总结记录所用，内容来源于网络，可能存在错误，敬请批评指正。