负载均衡负责访问流量分发并提高系统横向扩展能力,避免系统单点故障。下面是某个项目组负载均衡问题分析和优化思路:
负载均衡算法:
随机(Random):即从pool地址里随机选择一台,好处:算法简单、性能高,请求耗时差别不大时能基本保持后端是均衡的;缺点:如果请求耗时差别较大那么后端机器容易不均衡。
Round-Robin:根据pool地址列表顺序选择,好处:算法简单、性能高,缺点:和随机一样如果请求耗时差别较大那么后端机器容易不均衡。
按权重:可以给pool中的主机分配权重,之后按照权重分配请求,好处:可以利旧特别是运行多年生产环境积累了不同配置的主机时需要此算法,但随着虚拟化该问题已经在IAAS层解决了。
Hash:即对请求信息做hash后分派到pool中的机器上(一般对静态资源的加载使用),好处:增加缓存命中率;缺点:因为需要读取请求信息并做hash,所以需要消耗更多的CPU资源。
按照响应时间:按照响应时间来分配,好处:可以将请求分配给性能好的主机;缺点:如果请求耗时差别较大那么后端机器容易不均衡。
按照最小连接数:根据主机连接数多少来分配,好处:均衡请求资源;缺点:新增服务器或重启某一台会因为瞬间请求量过大而出现性能问题。
加群获取更多架构资料:694549689 欢迎一年以上开发经验的进群交流学习,谁还没有一个架构梦呢~
会话保持:
无会话保持:每次请求当认为新的请求重新按照负载均衡算法分配给后端主机。好处:简单、性能高;缺点:需要后端服务做无状态处理;
基于接入ip保持:同一个IP第一次按照负载均衡算法分配后,第二次请求还是分配给上次的主机,好处:回话保持比较稳定;缺点:导致部分网络内用户都连入一台服务器;
基于cookie保持:第一次请求负载均衡器在HTTP请求头部insert cookie,第二次请求根据请求的HTTP头中的cookie分配给上次的主机。好处:相对稳定、可以灵活切换;缺点:偶尔因为清除cookie导致回话丢失。
健康检查:
基于TCP端口:监听端口是否启用,如果未监听到则将该主机冲pool中剔除,好处:简单、缺点:有可能容器启动、应用未启动就有请求分发过来
基于Http get/TCP请求:定期向服务器发送请求并判断的返回串与约定的是否一致,如果不一致则将该主机冲pool中剔除,好处:可以精准确定应用是否正常启动,可以动态控制服务是否在线,缺点:需要编写脚本。