㈠ nginx 负载均衡之一致性hash，普通hash
哈希负载均衡原理
ngx_http_upstream_hash_mole支持普通的hash及一致性hash两种负载均衡算法，默认的是普通的hash来进行负载均衡。
nginx 普通的hash算法支持配置http变量值作为hash值计算的key，通过hash计算得出的hash值和总权重的余数作为挑选server的依据；nginx的一致性hash(chash)算法则要复杂一些。这里会对一致性hash的机制原理作详细的说明。
一致性hash算法的原理
一致性hash用于对hash算法的改进，后端服务器在配置的server的数量发生变化后，同一个upstream server接收到的请求会的数量和server数量变化之间会有变化。尤其是在负载均衡配置的upstream server数量发生增长后，造成产生的请求可能会在后端的upstream server中并不均匀，有的upstream server负载很低，有的upstream server负载较高，这样的负载均衡的效果比较差，可能对upstream server造成不良的影响。由此，产生了一致性hash算法来均衡。
那么为什么一致性hash算法能改善这种情况呢？这里引用网上资料的一致性hash算法的图例。
因为对于hash(k)的范围在int范围，所以我们将0~2^32作为一个环。其步骤为：
1，求出每个服务器的hash（服务器ip）值，将其配置到一个 0~2^n 的圆环上（n通常取32）。
2，用同样的方法求出待存储对象的主键 hash值，也将其配置到这个圆环上，然后从数据映射到的位置开始顺时针查找，将数据分布到找到的第一个服务器节点上。
其分布如图：
除了上边的优点，其实还有一个优点：对于热点数据，如果发现node1访问量明显很大，负载高于其他节点，这就说明node1存储的数据是热点数据。这时候，为了减少node1的负载，我们可以在热点数据位置再加入一个node，用来分担热点数据的压力。
雪崩效应
接下来我们来看一下，当有节点宕机时会有什么问题。如下图：
如上图，当B节点宕机后，原本存储在B节点的k1，k2将会迁移到节点C上，这可能会导致很大的问题。如果B上存储的是热点数据，将数据迁移到C节点上，然后C需要承受B+C的数据，也承受不住，也挂了。。。。然后继续CD都挂了。这就造成了雪崩效应。
上面会造成雪崩效应的原因分析：
如果不存在热点数据的时候，每台机器的承受的压力是M/2(假设每台机器的最高负载能力为M)，原本是不会有问题的，但是，这个时候A服务器由于有热点数据挂了，然后A的数据迁移至B，导致B所需要承受的压力变为M（还不考虑热点数据访问的压力），所以这个失败B是必挂的，然后C至少需要承受1.5M的压力。。。。然后大家一起挂。。。
所以我们通过上面可以看到，之所以会大家一起挂，原因在于如果一台机器挂了，那么它的压力全部被分配到一台机器上，导致雪崩。
怎么解决雪崩问题呢，这时候需要引入虚拟节点来进行解决。
虚拟节点
虚拟节点，我们可以针对每个实际的节点，虚拟出多个虚拟节点，用来映射到圈上的位置，进行存储对应的数据。如下图：
如上图：A节点对应A1，A2，BCD节点同理。这时候，如果A节点挂了，A节点的数据迁移情况是:A1数据会迁移到C2，A2数据迁移到D1。这就相当于A的数据被C和D分担了，这就避免了雪崩效应的发送，而且虚拟节点我们可以自定义设置，使其适用于我们的应用。
ngx_http_upstream_consistent_hash
该模块可以根据配置参数采取不同的方式将请求均匀映射到后端机器，比如：
指令
语法：consistent_hash variable_name
默认值：none
上下文：upstream
配置upstream采用一致性hash作为负载均衡算法，并使用配置的变量名作为hash输入。
参考文档：
https://www.cnblogs.com/FengGeBlog/p/10615345.html
http://www.ttlsa.com/nginx/nginx-upstream-consistent-hash-mole/
㈡ 13《Nginx 入门教程》Nginx负载均衡(下)
这一小节中，我们将实战 Nginx 的四层和七层负载均衡功能。条件有限，使用一台公网主机，在上面搭建好 Nginx 服务。公网 IP 为 180.76.152.113。
首先会进行简单的四层负载均衡实验，不会涉及多种负载均衡算法，只使用默认的 Round-Robin算法。在后续的七层负载均衡实验中，会重点测试不同的负载均衡策略，完成相关实验。
首先在 nginx.conf 中添加如下 stream 指令块配置:
上述配置用端口3000和3001模拟两个上游服务器，然后在 upstream 指令块中指定这两个上游服务器的地址，同时给第一个设置权重为2。由于默认采用的是加权的 Round-Robin 算法，默认服务器的权重为1。设置为2，表明3次请求中，2次会转发到3000端口，一次会转发到3001端口，下面的测试也验证了这一点。
和四层的配置其实差不多，在七层中除了告亩测试最基本的，我们还将测试前面提到的几种负载均衡策略，进一步熟悉 Nginx 中的负载均衡配置。
在 nginx.conf 中添加如下的 http 指令块:
上述配置中，我们用8000，8001和8002三个端口模拟了3个上游服务器，默认使用轮询负载均衡算法，而且三个的权重均为1。进行如下的 http 请求操作，可以看到 Nginx 转发 http 请求会均匀地分配到3个服务器上。
我们打开 ip_hash 指令的注释，这个时候默认是使用客户端的 ip 地址作为 hash 的 key，然后重启 Nginx 服务并进行如下的命令行操作：
接下来，注释 ip_hash 指令，我们打开 hash user_$arg_username 这行配置的注释， hash 指令可以让我们根据我们设置的 key 进行 hash，然后根据 hash 值选择上游的服务器。具体测试参看下面的 Linux 命令：
这里我们可以看到，在请求中带上 username 参数，Nginx 中配置敬友亩的 hash 算法会根据请求中带的 username 参数作为 key 去进行 hash，然后在根据 hash 结果映射上游服务器。username 相同时，选择的上游亮森服务器肯定是一样的，只有在 username 的值发生变化时，返回的响应才可能有变化。
今天我们完成了几个测试实验，主要是针对 Nginx 的四层和七层的负载均衡功能进行了测试。这个功能在微服务部署中会有较多的应用。因为高流量企业为保证服务的高可用性，往往会水平扩展多个相同功能的服务，部署在多台主机上，这个时候负载均衡技术就能派上用场了，而 Nginx 提供了完善的负载均衡功能以及多种负载均衡算法，能满足大部分企业的需求，如果还不够，可以通过编写内部开发模块并集成到 Nginx，实现相应的需求。所以说 Nginx 是非常值得学习和深入研究的。
㈢ 负载均衡器技术Nginx和F5的优缺点对比
这是网上摘抄的文章，正好想了解一下负载均衡，看这篇文章写隐搜的比较易懂，就。。。。
对于数据流量过大的网络中，往往单一设备无法承担，需要多台设备进行数据分流，而负载均衡器就是用来将数据分流到多台设备的一个转发器。
目前有许多不同的负载均衡技术用以满足不同的应用需求，如软/硬件负载均衡、本地/全局负载均衡、更高网络层负载均衡，以及链路聚合技术。
腾讯、淘宝、新浪等大型门户及商业网站使用的是软负载均衡器Nginx，而农行用的是F5硬负载均衡器，这里就简单介绍下这两种技术：
一.软件负载均衡解决方案
在一台服务器的操作系统上，安装一个附加软件来实现负载均衡，如Nginx负载均衡（我们管理系统平台使用的也是这款均衡器）。它的优点是基于特定环境、配置简单、使用灵活、成本低廉，可以满足大部分的负载均衡需求。
1.什么是Nginx
Nginx ("engine x") 是一个高性能的HTTP和反向代理服务器，也是一个IMAP/POP3/SMTP代理服务器。可以说Nginx是目前使用最为广泛的HTTP软负载均衡器，其将源代码以类BSD许可证的形式发布（商业友好），同时因高效的性能、稳定性、丰富的功能集、示例配置文件和低系统资源的消耗而闻名于业界。像腾讯、淘宝、新浪等大型门户及商业网站都采用Nginx进行HTTP网站的数据分流。
2.Nginx的功能特点
a.工作在网络的7层之上，可以针对http应用做一些分流的策略，比如针对域名、目录结构；
b.Nginx对网络的依赖比较小含或；
c.Nginx安装和配置比较简单，测试起来比较方便；
d.也可以承担高的负载压力且稳定，一般能支撑超过1万次的并发；
e.Nginx可以通过端口检测到服务器内部的故障，比如根据服务器处理网页返回的状态码、超时等等，并且会把返回错误的请求重新提交到另一个节点，不过其中缺点就是不支持url来检测；
f.Nginx对请求的异步处理可以帮助节点服务器减轻负载；
g.Nginx能支持http和Email，这样就在适用范围上面小很多；
h.不支持Session的保持、对Big request header的支持不是很好，另外默认的只有Round-robin和IP-hash两种负载均衡算法。
3.Nginx的原理
Nginx采用的是反向代理技术，代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。反向代理负载均衡技术是把将来自internet上的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的。
二.硬件负载均衡解决方案
直接在服务器和外部网络间安装负载均衡设备，这种设备我们通常称之为负载均衡器。由于专门的设备完成专门的任务，独立于操作系统，整体性能得到大量提高，加上多样化的负载均衡策略，智能化的流量管理，可达到最佳的负载均衡需求。一般而言，硬件负载均衡在功能、谈携伍性能上优于软件方式，不过成本昂贵，比如最常见的就是F5负载均衡器。
1.什么是F5 BIG-IP
F5负载均衡器是应用交付网络的全球领导者F5 Networks公司提供的一个负载均衡器专用设备，F5 BIG-IP LTM 的官方名称叫做本地流量管理器，可以做4-7层负载均衡，具有负载均衡、应用交换、会话交换、状态监控、智能网络地址转换、通用持续性、响应错误处理、IPv6网关、高级路由、智能端口镜像、SSL加速、智能HTTP压缩、TCP优化、第7层速率整形、内容缓冲、内容转换、连接加速、高速缓存、Cookie加密、选择性内容加密、应用攻击过滤、拒绝服务(DoS)攻击和SYN Flood保护、防火墙—包过滤、包消毒等功能。
2.F5 BIG-IP用作HTTP负载均衡器的主要功能
a.F5 BIG-IP提供12种灵活的算法将所有流量均衡的分配到各个服务器，而面对用户，只是一台虚拟服务器。
b.F5 BIG-IP可以确认应用程序能否对请求返回对应的数据。假如F5 BIG-IP后面的某一台服务器发生服务停止、死机等故障，F5会检查出来并将该服务器标识为宕机，从而不将用户的访问请求传送到该台发生故障的服务器上。这样，只要其它的服务器正常，用户的访问就不会受到影响。宕机一旦修复，F5 BIG-IP就会自动查证应用已能对客户请求作出正确响应并恢复向该服务器传送。
c.F5 BIG-IP具有动态Session的会话保持功能。
d.F5 BIG-IP的iRules功能可以做HTTP内容过滤，根据不同的域名、URL，将访问请求传送到不同的服务器。
三.方案优缺点对比
1.基于硬件的方式(F5)
优点：能够直接通过智能交换机实现,处理能力更强，而且与系统无关，负载性能强更适用于一大堆设备、大访问量、简单应用。
缺点：成本高，除设备价格高昂，而且配置冗余，很难想象后面服务器做一个集群，但最关键的负载均衡设备却是单点配置；无法有效掌握服务器及应用状态。
硬件负载均衡，一般都不管实际系统与应用的状态，而只是从网络层来判断，所以有时候系统处理能力已经不行了，但网络可能还来 得及反应（这种情况非常典型，比如应用服务器后面内存已经占用很多，但还没有彻底不行，如果网络传输量不大就未必在网络层能反映出来）。
2.基于软件的方式(Nginx)
优点：基于系统与应用的负载均衡，能够更好地根据系统与应用的状况来分配负载。这对于复杂应用是很重要的，性价比高，实际上如果几台服务器，用F5之类的硬件产品显得有些浪费，而用软件就要合算得多，因为服务器同时还可以跑应用做集群等。
缺点：负载能力受服务器本身性能的影响，性能越好，负载能力越大。
国内据说迪普和深信服做的不错，手头没有啥资料，就不介绍了。
㈣ 负载均衡基本介绍
【负载均衡架构部分转自】 58沈剑 [架构师之路]( https://mp.weixin.qq.com/s
负载均衡： 是分布式系统架构设计中必须考虑的因素之一，它通常是指，将请求/数据【均匀】分摊到多个操作单元上执行，负载均衡的关键在于【均匀】
常见的负载均衡方案：
【客户端层】到【反向代理层】的负载均衡，是通过“DNS轮询”实现的：DNS-server对于一个域名配置了多个解析ip，每次DNS解析请求来访问DNS-server，会轮询返回这些ip，保证每个ip的解析概率是相同的。这些ip就是nginx的外网ip，以做到每台nginx的请求分配也是均衡的。
【反向代理层】到【站点层】的负载均衡，是通过“nginx”实现的。通过修改nginx.conf，可以实现多种负载均衡策略：
【站点层】到【服务层】的负载均衡，是通过“服务连接池”实现的。
上游连接池会建立与下游服务多个连接，每次请求会“随机”选取连接来访问下游服务。（也即是rpc框架实现的）
在数据量很大的情况下，由于数据层（db，cache）涉及数据的水平切分，所以数据层的负载均衡更为复杂一些，它分为“数据的均衡”，与“请求的均衡”。
数据的均衡是指 ：水平切分后的每个服务（db，cache），数据量是差不多的。
请求的均衡是指 ：水平切分后的每个服务（db，cache），请求量是差不多的。
（1）按照range水平切分
（2）按照id哈希水平切分
[图片上传中...(-6b2508-1561902875888-0)]
常见的负载均衡系统包括 3 种：DNS 负载均衡、硬件负载均衡和软件负载均衡。
硬件负载均衡是通过单独的硬件设备来实现负载均衡功能，这类设备和路由器、交换机类似，可以理解为一个用于负载均衡的基础网络设备。比如业界非常出名的F5
缺点：
（1）价格实在非常昂贵
（2）扩展性不强
软件负载均衡通过负载均衡软件来实现负载均衡功能，常见的有 Nginx 和 LVS。
nginx和F5： https://blog.csdn.net/chabale/article/details/8956717
nginx和lvs比较： https://blog.51cto.com/hzcto/2086691
lvs： https://www.cnblogs.com/liwei0526vip/p/6370103.html
ELB： https://aws.amazon.com/cn/elasticloadbalancing/
SLB： https://help.aliyun.com/proct/27537.html
题目：日活跃用户 1000 万的论坛的负载均衡集群，该如何设计呢？
（1）评估流量
1000万DAU，换算成秒级（一天12小时），平均约等于232。
考虑每个用户操作次数，假定10，换算成平均QPS=2320。
考虑峰值是均值倍数，假定5，换算成峰值QPS=11600。
考虑静态资源、图片资源、服务拆分等，流量放大效应，假定10，QPS 10=116000。
（2）容量规划
考虑高可用、异地多活，QPS 2=232000。
考虑未来半年增长，QPS*1.5=348000。
（3）方案设计
可以用三级导流：
第一级，DNS，确定机房，以目前量级，可以不考虑。
第二级，确定集群，扩展优先，则选Haproxy/LVS，稳定优先则选F5。
第三级，Nginx+KeepAlived，确定实例。
（4）架构图
接入层技术：
缺点：
优点：
缺点：
优点：
缺点：
缺点：
nginx毕竟是软件，性能比tomcat好，但总有个上限，超出了上限，还是扛不住。lvs就不一样了，它实施在操作系统层面；f5的性能又更好了，它实施在硬件层面；它们性能比nginx好很多，例如每秒可以抗10w，这样可以利用他们来扩容。
99.9999%的公司到这一步基本就能解决接入层高可用、扩展性、负载均衡的问题。 假设还扛不住的话，就要考虑使用硬件设备f5等。如果还是扛不住，那么只有DNS来扩容了。
水平扩展，才是解决性能问题的根本方案，能够通过加机器扩充性能的方案才具备最好的扩展性。 facebook，google，的PV是不是超过80亿呢，它们的域名只对应一个ip么，终点又是起点，还是得通过DNS轮询来进行扩容：
比如购买了阿里云或者aws。那么基本会使用云厂商提供的负载均衡中间件，比如aws（elb）、阿里云（slb）。这个负载均衡软件可以认为是 lvs+keepalived的高可用负载均衡服务
后端的service有可能部署在硬件条件不同的服务器上：
1）如果对标最低配的服务器“均匀”分摊负载，高配的服务器的利用率不足；
2）如果对标最高配的服务器“均匀”分摊负载，低配的服务器可能会扛不住；
（1）通过“静态权重”标识service的处理能力
优点： 简单，能够快速的实现异构服务器的负载均衡。
缺点： 权重是固定的，无法自适应动态调整，而很多时候，服务器的处理能力是很难用一个固定的数值量化。
（2）通过“动态权重”标识service的处理能力
提问：通过什么来标识一个service的处理能力呢？
回答：其实一个service能不能处理得过来，能不能响应得过来，应该由调用方说了算。调用服务，快速处理了，处理能力跟得上；调用服务，处理超时了，处理能力很有可能跟不上了。
动态权重设计：
例如：
（1）设置一个阈值，超过阈值直接丢弃
（2）借助“动态权重”来实施过载保护
案例策略：
1）service的负载均衡、故障转移、超时处理通常是RPC-client连接池层面来实施的
2）异构服务器负载均衡，最简单的方式是静态权重法，缺点是无法自适应动态调整
3）动态权重法，可以动态的根据service的处理能力来分配负载，需要有连接池层面的微小改动
4）过载保护，是在负载过高时，service为了保护自己，保证一定处理能力的一种自救方法
5）动态权重法，还可以用做service的过载保护