负载均衡
轮询
默认的负载均衡策略, 常用于多台服务器,资源配置一样的情况, 这样可以把流量均匀的分配到每台服务器
加权轮询
一把来说, 可能第一次部署的服务器配置都是一样的, 但是到了后期, 业务快速拓展, 就需要增加服务器, 并且购买的也是性能更高的服务器, 这个时候轮询,策略就不太好了, 这个时候就需要用到加权轮询了
upstream tomcats {
# 默认weight=1 也就是轮询, weight 值越高, 分配的流量就越多
# 老服务器
server 192.168.247.136:8001 weight=1;
# 中间购买的服务器 配置比老服务器好一些
server 192.168.247.136:8002 weight=3;
# 最新购买的服务器 配置最好
server 192.168.247.136:8003 weight=5;
}
server{
listen 80;
server_name www.tomcat.com;
location / {
proxy_pass http://tomcats;
}
}ip_hash
图解
hash算法
使用Hash算法可以保证用户的每一次请求都是访问到同一台服务器的, 如果是有状态请求, 可以保持状态的不丢失, 比如session, 当然现在基本没有人用有状态请求了, 现在都是讲究无状态请求的
设置方式
代码语言：javascript复制upstream tomcats {
# 使用ip_hash负载均衡策略
ip_hash;
server 192.168.247.136:8001;
server 192.168.247.136:8002;
server 192.168.247.136:8003;
}
server{
listen 80;
server_name www.tomcat.com;
location / {
proxy_pass http://tomcats;
}
}ip_hash算法
hash算法带来的问题
无论节点增加或者减少, 都会带来所有的请求ip重新计算问题, 并且如果是有状态请求, 那么所有的会话都会丢失, 那么如何解决呢? 一致性hash算法
一致性HASH算法
会从0-232-1形成一个环, 然后将服务器节点通过HASH计算后放到环上的某个节点, 然后用户在访问的时候,也通过HASH计算落在环上的某个节点, 然后顺时针落在最近的服务器上,来达到分流的效果
一旦减少了某台服务器, 比如减少了节点3, 那么节点3的用户会顺时针落到节点4上, 并且只有这一部分用户会重新计算并失去会话状态
如果是新增加了服务器5, 那么只会是更少的用户重新计算, 然后落到服务器5上,并不会所有用户全部重新计算, 解决了hash算法带来的问题
url_hash
图解
设置方式
代码语言：javascript复制upstream tomcats {
# 使用url_hash负载均衡策略
hash $request_uri;
server 192.168.247.136:8001;
server 192.168.247.136:8002;
server 192.168.247.136:8003;
}
server{
listen 80;
server_name www.tomcat.com;
location / {
proxy_pass http://tomcats;
}
}使用url_hash的时候需要注意, 因为是根据uri计算的, 所以固定的uri会落在固定的服务器上, 如果是比较热点的uri, 那么就需要再挂载Nginx了, 不然扛不住
浏览器访问Nginx, 应为是url_hash算法, 所以固定的路径会匹配到固定的服务器, 因为search搜索的压力最大,也是最常用的, 所以不直接挂Tomcat, 而是继续挂载Nginx, 采用轮序分发流量给下面的search集群, 用于分发压力, 避免宕机问题
least_conn
图解
根据最少的连接数分配请求
设置方式
代码语言：javascript复制upstream tomcats {
# 使用least_conn负载均衡策略
least_conn;
server 192.168.247.136:8001;
server 192.168.247.136:8002;
server 192.168.247.136:8003;
}
server{
listen 80;
server_name www.tomcat.com;
location / {
proxy_pass http://tomcats;
}
}
