负载均衡算法代码怎么写，常见的负载均衡算法有哪些？

负载均衡是构建高可用、高并发分布式系统的基石，其核心在于将网络流量智能且均匀地分发到后端服务器集群，从而避免单点过载，提升整体系统的吞吐量与稳定性，在实际架构设计中，选择合适的负载均衡算法并理解其底层代码实现逻辑，对于优化系统性能至关重要，不同的业务场景——如无状态Web服务、长连接应用或分布式缓存——需要匹配不同的算法策略，本文将深入剖析四种核心负载均衡算法的原理、代码实现及适用场景,为架构选型提供专业的技术决策依据。

轮询算法：基础且公平的流量分发

轮询是最基础且应用最广泛的算法，其核心逻辑在于按照服务器列表的顺序，依次将请求分发到每一台服务器，当分配到列表末尾时，再从头开始循环,这种算法假设所有服务器的硬件配置和处理能力是相同的。

代码实现逻辑通常维护一个原子计数器或索引指针，在并发环境下，为了保证线程安全,必须使用锁或原子操作来更新索引。

# 伪代码示例
servers = ['A', 'B', 'C']
current_index = 0
def get_server_round_robin():
    global current_index
    server = servers[current_index % len(servers)]
    current_index += 1
    return server

专业见解：轮询算法的优点是实现简单、计算量小，且在请求耗时差异不大的情况下能实现绝对的负载均衡，它忽略了服务器当前的实时负载和性能差异，如果集群中存在性能较弱的服务器，轮询会导致其积压大量请求，从而成为系统的瓶颈,该算法最适合服务器同构且请求处理时间短且均匀的场景。

加权轮询算法：应对异构服务器的智能调度

在生产环境中，服务器往往是非同构的，新扩容的服务器可能配置更高，加权轮询通过为每台服务器分配权重，将流量按比例分发，从而实现“能者多劳”。

核心实现难点在于如何处理权重的平滑过渡，简单的加权轮询可能导致某一台权重高的服务器连续处理大量请求，造成瞬间突发压力。平滑加权轮询是更优的解决方案。

代码实现逻辑中，每个节点维护一个current_weight，每次选择时，将所有节点的current_weight加上其静态weight，选出current_weight最大的节点返回，并将其current_weight减去所有节点的总权重。

# 平滑加权轮询核心逻辑
servers = [
    {'name': 'A', 'weight': 5, 'current_weight': 0},
    {'name': 'B', 'weight': 1, 'current_weight': 0},
    {'name': 'C', 'weight': 1, 'current_weight': 0}
]
total_weight = 7
def get_server_smooth_weighted():
    best_server = None
    max_current_weight = -1
    for server in servers:
        server['current_weight'] += server['weight']
        if server['current_weight'] > max_current_weight:
            max_current_weight = server['current_weight']
            best_server = server
    best_server['current_weight'] -= total_weight
    return best_server['name']

专业见解：这种算法在Nginx等成熟负载均衡器中被广泛采用，它不仅保证了请求分发的比例符合权重设定，还避免了请求在时间维度上的剧烈抖动,对于需要平滑扩容或缩容的集群非常关键。

最少连接数算法：长连接场景的最佳选择

对于处理耗时较长或连接保持时间较长的业务（如数据库连接池、RPC调用、FTP服务），轮询或加权算法并不适用，因为它们无法感知服务器当前的活跃连接数。最少连接数算法优先将请求分发给当前活跃连接数最少的服务器。

代码实现逻辑需要记录每个服务器的active_connections，每当有新请求到达时，遍历列表找到该值最小的节点；请求处理完成后,计数器减一。

# 伪代码示例
servers = [
    {'name': 'A', 'active_connections': 10},
    {'name': 'B', 'active_connections': 5},
    {'name': 'C', 'active_connections': 8}
]
def get_server_least_connections():
    # 按活跃连接数排序，取第一个
    best = min(servers, key=lambda s: s['active_connections'])
    best['active_connections'] += 1
    return best['name']

专业见解：该算法能动态感知后端压力，是处理长连接任务的首选，但需要注意，它要求负载均衡器与后端服务器之间保持紧密的状态同步，这会增加一定的系统开销，为了防止某台服务器故障导致连接数堆积,必须配合健壮的健康检查机制使用。

一致性哈希算法：解决分布式缓存的数据雪崩

在分布式缓存、Session共享等有状态服务中，普通的哈希算法会导致当服务器节点增删时，大量的哈希键值失效，引发缓存雪崩。一致性哈希算法通过将服务器节点和数据Key映射到同一个闭合的哈希环上，保证了只有受影响节点相邻的数据才会发生迁移。

代码实现逻辑通常使用排序的二叉树来模拟哈希环，为了解决数据倾斜问题，引入了虚拟节点的概念,即每个物理节点在环上映射多个虚拟位置。

# 一致性哈希简化逻辑
import hashlib
class ConsistentHashing:
    def __init__(self, nodes, virtual_nodes=100):
        self.ring = {}
        self.sorted_keys = []
        self.virtual_nodes = virtual_nodes
        for node in nodes:
            self.add_node(node)
    def add_node(self, node):
        for i in range(self.virtual_nodes):
            key = self._hash(f"{node}:{i}")
            self.ring[key] = node
            self.sorted_keys.append(key)
        self.sorted_keys.sort()
    def get_node(self, key):
        hash_key = self._hash(key)
        # 查找顺时针第一个节点
        for ring_key in self.sorted_keys:
            if ring_key >= hash_key:
                return self.ring[ring_key]
        return self.ring[self.sorted_keys[0]] # 回环
    def _hash(self, key):
        return int(hashlib.md5(key.encode()).hexdigest(), 16)

专业见解：一致性哈希是分布式系统设计中极其实用的算法，通过调整虚拟节点的数量，可以在数据均匀性和内存消耗之间取得平衡，通常情况下，150-200个虚拟节点足以实现较好的均匀度，该算法能有效解决水平扩展时的数据迁移难题，是Memcached、Redis Cluster等分布式存储组件的核心技术之一。

相关问答

Q1：在微服务架构中，为什么推荐使用加权轮询而不是普通的轮询算法？
A1：微服务架构通常涉及动态扩缩容，新加入的服务器节点往往配置相同，但在金丝雀发布或灰度发布场景下，可能需要给新版本服务分配少量流量进行验证，加权轮询允许通过设置极小的权重（如1:99）来实现精细的流量控制，而普通轮询只能均分流量,无法满足这种渐进式发布的业务需求。

Q2：一致性哈希算法中的虚拟节点数量应该如何设定？
A2：虚拟节点的数量取决于数据分布的均匀度要求与内存开销的权衡，经验法则建议设置为100至200个，数量过少会导致数据分布不均，出现“热点”节点；数量过多则会增加计算哈希值和维护哈希环的CPU及内存开销，在实际测试中，可以观察各节点承载的键值数量方差,当方差趋于稳定时的虚拟节点数即为最佳值。

互动环节：
您的团队目前在生产环境中主要使用哪种负载均衡算法？是否遇到过因算法选择不当导致的性能瓶颈？欢迎在评论区分享您的实战经验与见解,我们一起探讨更优的架构方案。