负载均衡算法

简介: 本文介绍了多种负载均衡算法:随机、加权随机、轮询、加权轮询、最小活跃数、源地址哈希及一致性哈希。适用于不同场景,如性能均等或差异服务器、需保持会话一致等,提升系统稳定性与负载能力。

随机

调用关系如上图(简化了公网->防火墙处理),适合场景:所有服务器性能基本一致,且无超阈值流量。
private K doSelect(List nodes, String ip) {
// 在列表中随机选取一个节点
int index = random.nextInt(nodes.size());
return nodes.get(index);
}
如果存在部分机器性能更优,此时可以在随机基础上增加权重,升级为:随机权重算法。
private K doSelect(List nodes, String ip) {
int length = nodes.size();
AtomicInteger totalWeight = new AtomicInteger(0);
for (K node : nodes) {
Integer weight = node.getWeight();
totalWeight.getAndAdd(weight);
}

if (totalWeight.get() > 0) {
    int offset = random.nextInt(totalWeight.get());
    for (N node : nodes) {
        // 让随机值 offset 减去当前node权重值
        offset -= node.getWeight();
        if (offset < 0) {
            // 当前node大于随机值offset,返回此Node
            return node;
        }
    }
}
// 随机返回
return nodes.get(random.nextInt(length));

}
轮询

轮询不再是在多台服务器随机挑选,而是按照顺序一个个排队调用,调用完再插入队尾等待下一次调用
protected K doSelect(List nodes, String ip) {
int length = nodes.size();
// 如果位置值已经等于长度重置为0(走一轮了)
position.compareAndSet(length, 0);
N node = nodes.get(position.get());
// 数据原子增加,对应调用从1->2->3->4
position.getAndIncrement();
return node;
}
同加权随机,轮询也同样存在加权轮询的场景,此时流量调度将发生如下变化:

此处逻辑相对复杂,笔者在此说出主要思路,后续有时间补充伪代码,感兴趣的可以参照Dubbo的实现
如上有服务器servers=[A,B],对应权重weights=[3,1],总权重为4。我们可以理解为有4台服务器,3台A,1台B,一次调用过来的时候,需要按顺序访问。如有5次调用,调用顺序为AAABA。
选举思路如下:
次数 WeightedRoundRobin 选择结果 选择后的WeightedRoundRobin
1 3、1 A 2、1
2 2、1 A 1、1
3 1、1 A 0、1
4 0、1 B 0、0(等于0-0时复原成:3、1)
5 3、1 A 2、1
最小活跃数
指:将当前请求转发到连接数/请求数最少的机器上,其特点是根据服务器实时运行状态动态分配,保障服务负载不会过饱和。如下图当请求4过来时,Nginx判断目前服务器1连接数>服务器2,故4会请求到服务器2上:

源地址哈希
根据请求源IP哈希计算得到一个数值,用该数值在候选服务器列表的进行取模运算,得到的结果便是选中的服务器,此操作可以保证固定IP的请求总是到某一台服务器上,伪代码如下:
private K doSelect(List nodes, String ip) {
int length = nodes.size();
int index = hash(ip) % length;
return nodes.get(index);
}
一致性哈希
相同的请求尽可能落到同一个服务器上。一致性哈希解决稳定性问题,可以将所有的存储节点排列在首尾相接的 Hash 环上,每个 key 在计算 Hash 后会 顺时针找到临接的存储节点存放。而当有节点加入或退出时,仅影响该节点在 Hash环上顺时针相邻的后续节点。

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
相关文章
|
2月前
|
机器学习/深度学习 人工智能 前端开发
构建AI智能体:七十、小树成林,聚沙成塔:随机森林与大模型的协同进化
随机森林是一种基于决策树的集成学习算法,通过构建多棵决策树并结合它们的预测结果来提高准确性和稳定性。其核心思想包括两个随机性:Bootstrap采样(每棵树使用不同的训练子集)和特征随机选择(每棵树分裂时只考虑部分特征)。这种方法能有效处理大规模高维数据,避免过拟合,并评估特征重要性。随机森林的超参数如树的数量、最大深度等可通过网格搜索优化。该算法兼具强大预测能力和工程化优势,是机器学习中的常用基础模型。
539 165
|
22天前
|
机器学习/深度学习 人工智能 自然语言处理
构建AI智能体:九十、图解大模型核心三大件 — 输入编码、注意力机制与前馈网络层
本文深入解析了大模型三大核心技术:输入编码、多头自注意力机制和前馈网络层,从应用视角阐述了它们的工作原理和协同效应。输入编码负责将文本转换为富含语义和位置信息的数学表示;多头自注意力机制通过多专家团队模式建立全局依赖关系,解决长距离依赖问题;前馈网络层则通过非线性变换进行深度语义消歧。文章通过可视化示例展示了词向量的语义关系建模、注意力权重的分布模式以及前馈网络的语义过滤功能,形象地说明了大模型如何通过这三层架构实现"广泛联系-深度加工"的认知过程。
149 5
|
21天前
|
监控 搜索推荐 物联网
一文读懂LoRA微调原理:大模型高效适配的核心逻辑
通过冻结大模型参数、仅训练少量低秩矩阵,实现高效微调:成本低、周期短、不破坏通用能力。适配医疗、金融等垂直场景,支持多任务复用与边缘部署,成为大模型落地首选技术。
一文读懂LoRA微调原理:大模型高效适配的核心逻辑
|
2月前
|
数据采集 人工智能 监控
构建AI智能体:七十七、AI古典文学:基于LoRA微调Qwen1.5-0.5B打造唐诗生成器
本文介绍了基于LoRA微调技术实现AI创作唐诗的方法。通过使用Qwen1.5-0.5B-Chat作为基础模型,仅调整0.34%的参数(157万),在CPU上39分钟即可完成训练。文章详细展示了从模型选择、28首原创唐诗数据集构建、LoRA参数配置到训练评估的全过程。实验结果表明,模型能生成符合主题的原创唐诗,但在格律平仄、意境深度等方面仍需优化。这一实践验证了LoRA技术在古典文学创作领域的可行性,为轻量化AI创作提供了有价值的参考。
282 16
|
2月前
|
Java 调度
什么是分片广播任务
本文介绍XXL-JOB的分片广播机制,通过集群执行器动态分片处理任务。调度中心为每个执行器分配分片参数,实现任务并行处理,提升效率。适用于大数据量分布式场景,支持动态扩容,每台机器处理部分数据,显著降低耗时。开发时可通过`getShardIndex()`和`getShardTotal()`获取分片信息,灵活控制业务逻辑。
|
2月前
|
缓存 前端开发 安全
|
2月前
|
XML JSON Java
什么是RESTful
RESTful是一种基于资源的API设计规范,通过统一的HTTP方法(GET/POST/PUT/DELETE)对资源进行操作,提升接口的标准化与可维护性。它强调URI代表资源、使用名词而非动词、杜绝行为化路径,确保增删改查逻辑清晰、结构统一,便于理解和扩展,是现代Web API设计的最佳实践之一。
|
3月前
|
机器学习/深度学习 人工智能 物联网
大模型微调有必要做吗?全参数微调、LoRA还是RAG?看完这篇你就懂了
在人工智能时代,若想以最小成本、最高效率赋能通用大模型专业的行业能力,关键在于找到效果、成本与灵活性的黄金平衡点......
544 5
大模型微调有必要做吗?全参数微调、LoRA还是RAG?看完这篇你就懂了
|
2月前
|
存储 数据库
数据库设计三范式
数据库三范式是设计合理表结构的指导原则。第一范式要求字段原子性,不可再分;第二范式要求消除部分依赖,一张表只描述一件事;第三范式要求消除传递依赖。虽为优化数据冗余、更新异常等问题,但实际应用中需结合业务权衡,不必严格拘泥。