关于负载均衡的一切

本文涉及的产品
应用型负载均衡 ALB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
简介:

什么是负载均衡?

负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据均匀分摊到多个操作单元上执行,负载均衡的关键在于均匀

常见的负载均衡方案有哪些?

fac09610931023191235764ed83e4866b8609a41
常见互联网分布式架构如上,分为:  ●  客户端层
 ●  反向代理层
 ●  站点层
 ●  服务层
 ●  数据层

可以看到,每一个下游都有多个上游调用,只需要做到,每一个上游都均匀访问每一个下游,就能实现整体的均匀分摊

第一层:客户端层到反向代理层

f086ae19a2bb56e6937bf73b8e84bb62b9c94acf
客户端层到反向代理层的负载均衡,是通过“DNS轮询”实现的。

DNS-server对于一个域名配置了多个解析ip,每次DNS解析请求来访问DNS-server,会轮询返回这些ip,保证每个ip的解析概率是相同的。这些ip就是nginx的外网ip,以做到每台nginx的请求分配也是均衡的。

第二层:反向代理层到站点层

5042cc83413e86d0368faed52debfd9f8efb79fd
反向代理层到站点层的负载均衡,是通过“nginx”实现的。

画外音:nginx是反向代理的泛指。

修改nginx.conf,可以实现多种均衡策略:

(1) 请求轮询:和DNS轮询类似,请求依次路由到各个web-server;

(2) 最少连接路由:哪个web-server的连接少,路由到哪个web-server;

(3) ip哈希:按照访问用户的ip哈希值来路由web-server,只要用户的ip分布是均匀的,请求理论上也是均匀的,ip哈希均衡方法可以做到,同一个用户的请求固定落到同一台web-server上,此策略适合有状态服务,例如session;

画外音:站点层可以存储session,但强烈不建议这么做,站点层无状态是分布式架构设计的基本原则之一,session最好放到数据层存储。

(4) …

第三层:站点层到服务层

48df6c720234b85f2bba550bc152ce754e1bed3e
站点层到服务层的负载均衡,是通过“服务连接池”实现的。

上游连接池会建立与下游服务多个连接,每次请求会“随机”选取连接来访问下游服务。除了负载均衡,服务连接池还能够实现故障转移超时处理限流限速ID串行化等诸多功能。

第四层:访问数据层

在数据量很大的情况下,由于数据层(db/cache)涉及数据的水平切分,所以数据层的负载均衡更为复杂一些,它分为“数据的均衡”,与“请求的均衡”。

数据的均衡是指:水平切分后的每个服务(db/cache)数据量是均匀的

请求的均衡是指:水平切分后的每个服务(db/cache)请求量是均匀的

业内常见的水平切分方式有这么几种:

一、按照range水平切分

18de87cdd966c1adde122b17e639d4781cd2c94f
每一个数据服务,存储一定范围的数据  ●  user0服务:存储uid范围1-1kw
 ●  user1服务:存储uid范围1kw-2kw

这个方案的好处是:

 ●  规则简单 ,service只需判断一下uid范围就能路由到对应的存储服务
 ●  数据均衡 性较好
 ●  比较容易扩展 ,可以随时加一个uid[2kw,3kw]的数据服务

不足是:

 ●  请求的负载不一定均衡 ,一般来说,新注册的用户会比老用户更活跃,大range的服务请求压力会更大

二、按照id哈希水平切分

490030a9b499e1f24f2716520c7c35d6e1570cf2
每一个数据服务,存储某个key值hash后的部分数据:  ●  user0服务:存储偶数uid数据
 ●  user1服务:存储奇数uid数据

这个方案的好处是:

 ●  规则简单 ,service只需对uid进行hash能路由到对应的存储服务
 ●  数据均衡 性较好
 ●  请求均匀 性较好

不足是:

 ●  不容易扩展 ,扩展一个数据服务,hash方法改变时候,可能需要进行数据迁移

总结

负载均衡(Load Balance)是分布式系统架构设计中必须考虑的因素之一,它通常是指,将请求/数据均匀分摊到多个操作单元上执行,其的关键在于均匀:

 ●  反向代理层 的负载均衡,是通过“ DNS轮询 ”实现的
 ●  站点层 的负载均衡,是通过“ nginx ”实现的
 ●  服务层 的负载均衡,是通过“ 服务连接池 ”实现的
 ●  数据层 的负载均衡,要考虑“数据的均衡”与“请求的均衡”两个点,常见的方式有“ 按照范围水平切分 ”与“ hash水平切分

希望大家有收获。


原文发布时间为:2018-11-19

本文作者: 58沈剑

本文来自云栖社区合作伙伴“架构师之路”,了解相关信息可以关注“架构师之路”。

相关实践学习
每个IT人都想学的“Web应用上云经典架构”实战
本实验从Web应用上云这个最基本的、最普遍的需求出发,帮助IT从业者们通过“阿里云Web应用上云解决方案”,了解一个企业级Web应用上云的常见架构,了解如何构建一个高可用、可扩展的企业级应用架构。
相关文章
|
SQL 存储 关系型数据库
SQL优化之Explain详解(mysql)
`Explain`是MySQL中用于分析SQL查询执行计划的工具。它可以帮助我们了解MySQL如何执行SQL语句,包括如何使用索引、预计的行数以及查询的顺序。以下是`Explain`输出的关键列及其含义的简要摘要: 1. **id**:查询的序列号,表示查询中的子句层次,id越大优先级越高。 2. **select_type**:表示查询的类型,如SIMPLE(简单查询)、PRIMARY(主查询,多表查询中的第一个查询)、SUBQUERY(子查询)、DERIVED(派生表)或UNION(UNION操作的查询部分)。 3. **table**:查询涉及的表名,如果是子查询,可能显示为衍生表
430 0
|
负载均衡 监控 算法
实现负载均衡策略:优化系统性能与可用性
实现负载均衡策略:优化系统性能与可用性
|
5月前
|
缓存 移动开发 网络协议
Netty基础—5.Netty的使用简介
本文详细介绍了Netty服务端和客户端的启动流程、IO事件处理类及TCP粘包拆包问题。服务端启动通过ServerBootstrap配置线程模型、IO模型等,客户端通过Bootstrap完成连接配置。IO事件处理类关注关键方法如channelRead、channelActive等。针对TCP粘包拆包,分析了其原因与解决策略,包括消息定长、加分割符和带上长度字段等方式,并介绍了多种解码器如LineBasedFrameDecoder、DelimiterBasedFrameDecoder等。最后对比了Netty组件与传统BIO模型的对应关系,以及Java序列化的不足。
|
SQL 关系型数据库 数据库
学习分布式事务Seata看这一篇就够了,建议收藏
学习分布式事务Seata看这一篇就够了,建议收藏
17541 2
|
前端开发 网络协议 Dubbo
超详细Netty入门,看这篇就够了!
本文主要讲述Netty框架的一些特性以及重要组件,希望看完之后能对Netty框架有一个比较直观的感受,希望能帮助读者快速入门Netty,减少一些弯路。
91510 32
超详细Netty入门,看这篇就够了!
|
消息中间件 存储 中间件
【消息中间件】详解三大MQ:RabbitMQ、RocketMQ、Kafka
【消息中间件】详解三大MQ:RabbitMQ、RocketMQ、Kafka
10641 1
|
5月前
|
消息中间件 架构师 Java
美团面试:对比分析 RocketMQ、Kafka、RabbitMQ 三大MQ常见问题?
美团面试:对比分析 RocketMQ、Kafka、RabbitMQ 三大MQ常见问题?
美团面试:对比分析 RocketMQ、Kafka、RabbitMQ 三大MQ常见问题?
|
10月前
|
存储 Java 程序员
【JVM】——JVM运行机制、类加载机制、内存划分
JVM运行机制,堆栈,程序计数器,元数据区,JVM加载机制,双亲委派模型
240 10
|
SQL 安全 网络安全
SQL注入(SQL Injection)
【8月更文挑战第11天】
596 3
|
SQL 数据库
springCloud之seata
springCloud之seata
322 1