upstream

## 指定共享内存 lua_shared_dict healthcheck 1m; ## 在worker初始化过程中，启动定时器，进行后端结点的检查 init_worker_by_lua_block { local hc = require "resty.upstream.healthcheck" local ok, err = hc.spawn_checker { -- shm 表示共享内存区的名称， shm = "healthcheck", -- type 表示健康检查的类型， HTTP or TCP （目前只支持http） type = "http", -- upstream 指定 upstream 配置的名称 upstream = "api.cargolist.xihuishou.bsdd.me", -- 如果是http类型，指定健康检查发送的请求的URL http_req = "GET /health.txt HTTP/1.0\r\nHost: api.cargolist.xihuishou.bsdd.me\r\n\r\n", -- 请求间隔时间，默认是 1 秒。最小值为 2毫秒 interval = 2000, -- 请求的超时时间。 默认值为：1000 毫秒 timeout = 5000, -- 失败多少次后，将节点标记为down。 默认值为 5 fall = 3,

一、关于Nginx的负载均衡 　　 在服务器集群中，Nginx起到一个代理服务器的角色（即反向代理），为了避免单独一个服务器压力过大，将来自用户的请求转发给不同的服务器。详情请查看我的 另一篇博客 。 二、Nginx负载均衡策略 　　 负载均衡用于从“upstream”模块定义的后端服务器列表中选取一台服务器接受用户的请求。一个最基本的upstream模块是这样的，模块内的server是服务器列表： #动态服务器组 upstream dynamic_zuoyu { server localhost:8080; #tomcat 7.0 server localhost:8081; #tomcat 8.0 server localhost:8082; #tomcat 8.5 server localhost:8083; #tomcat 9.0 } 　　 在upstream模块配置完成后，要让指定的访问反向代理到服务器列表： #其他页面反向代理到tomcat容器 location ~ .*$ { index index.jsp index.html; proxy_pass http://dynamic_zuoyu; } 　　 这就是最基本的负载均衡实例，但这不足以满足实际需求；目前Nginx服务器的upstream模块支持6种方式的分配： 负载均衡策略 轮询 默认方式 weight

nginx可以根据客户端IP进行负载均衡，在upstream里设置ip_hash，就可以针对同一个C类地址段中的客户端选择同一个后端服务器，除非那个后端服务器宕了才会换一个。 nginx的upstream目前支持的5种方式的分配 1、轮询（默认） 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除。 upstream backserver { server 192.168.0.14; server 192.168.0.15; } 2、指定权重 指定轮询几率，weight和访问比率成正比，用于后端服务器性能不均的情况。 upstream backserver { server 192.168.0.14 weight=10; server 192.168.0.15 weight=10; } 3、IP绑定 ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题。 upstream backserver { ip_hash; server 192.168.0.14:88; server 192.168.0.15:80; } 4、fair（第三方） 按后端服务器的响应时间来分配请求，响应时间短的优先分配。 upstream backserver { server server1; server

1. 摘要 （1） 结论 详细描述了nginx记录失效节点的6种状态(time out、connect refuse、500、502、503、504，后四项5XX需要配置proxy_next_upstream中的状态才可以生效)、失效节点的触发条件和节点的恢复条件、所有节点失效后nginx会进行恢复并进行重新监听。 （2） Nginx 负载均衡方式介绍 Nginx的负载均衡方式一共有4种：rr(轮询模式)、ip_hash、fair、url_hash。 （3） Ngxin负载均衡和相关反向代理配置内容 Nginx负载均衡和与容错相关的反向代理的配置。 （4） 获取后端流程 后端server的自动容错流程图。 （5） 测试环境和测试结果 针对几种错误方式进行自动容错测试。 2. 结论 （1） nginx 判断节点失效状态 Nginx 默认判断失败节点状态以connect refuse和time out状态为准，不以HTTP错误状态进行判断失败，因为HTTP只要能返回状态说明该节点还可以正常连接，所以nginx判断其还是存活状态；除非添加了proxy_next_upstream指令设置对404、502、503、504、500和time out等错误进行转到备机处理，在next_upstream过程中，会对fails进行累加，如果备用机处理还是错误则直接返回错误信息

在 nginx.conf 的http段，加入下面的配置： proxy_buffer_size 128k; proxy_buffers 32 32k; proxy_busy_buffers_size 128k; 重启后一般就可以解决，如果还是报502，再在host配置的php段加入下面配置： fastcgi_buffer_size 128k; fastcgi_buffers 4 256k; fastcgi_busy_buffers_size 256k; 重启nginx即可。 来源： https://www.cnblogs.com/xiaojf/p/11779752.html

可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试): 问题: UPDATE: if I don't use socket and use 127.0.0.1:3031 instead, everything works fine. Nginx version is 1.6.3, and uwsgi is 2.0.11.1 /etc/uwsgi.ini: [uwsgi] uid = uwsgi gid = uwsgi pidfile = /run/uwsgi/uwsgi.pid emperor = /etc/uwsgi.d stats = /run/uwsgi/stats.sock emperor-tyrant = true cap = setgid,setuid logto = /var/log/uwsgi.log /etc/uwsgi.d/daimaduan_preview.ini [uwsgi] plugin = python,http protocol = uwsgi chdir = /var/www/daimaduan/preview/current master = true processes = 4 threads = 20 socket = /tmp/daimaduan-preview.sock chmod-socket

12.17 Nginx负载均衡 要理解负载均衡，必须先搞清楚正向代理和反向代理 \ 注： 正向代理，代理的是用户。 反向代理，代理的是服务器。 一、什么是负载均衡 负载均衡是用反向代理的原理实现的，代理一台机器，叫做代理服务器，代理多台机器就叫做负载均衡。nginx通过proxy_pass_http 配置代理站点，upstream实现负载均衡 当一台服务器的单位时间内的访问量越大时，服务器压力就越大，大到超过自身承受能力时，服务器就会崩溃。为了避免服务器崩溃，让用户有更好的体验，我们通过负载均衡的方式来分担服务器压力。 我们可以建立很多很多服务器，组成一个服务器集群，当用户访问网站时，先访问一个中间服务器，在让这个中间服务器在服务器集群中选择一个压力较小的服务器，然后将该访问请求引入该服务器。如此以来，用户的每次访问，都会保证服务器集群中的每个服务器压力趋于平衡，分担了服务器压力，避免了服务器崩溃的情况。 二、负载均衡的几种常用方式（算法） （1）、轮询（默认） 每个请求按时间顺序逐一分配到不同的后端服务器，如果后端服务器down掉，能自动剔除 （2）、weight （权重） 指定轮询权重，weight和访问比率成正比，用于后端服务器性能不均的情况 （3）、ip_hash 每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，可以解决session的问题 （4）

项目组GitLab使用规范 Master 和 Developer 。主仓库中受保护的分支只有 Master 成员可以处理代码合并Merge Request和push。 ：位于服务器上代码主仓库，常驻分支master和hotfix，分支均受保护，只有从开发者个人远程仓库发起Merge Request（下文简称MR）才可以进行代码更新。 ：由MAIN fork而来，位于服务器上个人项目下。 ：由开发人员从ORIGIN clone而来，位于本地，用于代码开发。后续通过pull/push操作保持LOCAL与ORIGIN的同步。同时，在LOCAL中设置upstream为MAIN，然后通过fetch upstream来获取MAIN的代码。 Master 新建代码主仓库MAIN、添加项目成员。 Developer 从主仓库fork一份到自己的个人远程仓库ORIGIN。 Developer 从个人远程仓库clone代码到本地，建立本地仓库，同时将主仓库MAIN设置为本地仓库LOCAL的upstream 在本地仓库进行开发，需要提交代码时，按照如下步骤： Commit ：提交代码到本地仓库 Fetch ：获取主仓库的更新，同步到个人本地仓库 Merge ：合并主仓库的代码和本地的开发代码。代码会自动合并，但如果有冲突，需手动合并代码解决冲突 Push ：提交代码到个人远程仓库 Merge

项目组GitLab使用规范 1. 基本信息 （1） 项目组GitLab地址 （2） 协作开发模式 开发人员采用fork主仓库的方式进行开发。 为简化开发过程，方便代码集成。主仓库仅包括两个常驻分支master和hotfix。两个分支都是受保护的。master是代码主分支，主要的开发、代码集成、发布都在此分支上进行。hotfix用于临时bug修复或问题处理。 （3） 成员角色 项目组成员包含两种权限 Master 和 Developer 。主仓库中受保护的分支只有 Master 成员可以处理代码合并Merge Request和push。 （4） 代码仓库 开发过程中涉及的代码仓库包括：主仓库、个人远程仓库和本地仓库，它们之间的关系如下图所示： 主仓库MAIN ：位于服务器上代码主仓库，常驻分支master和hotfix，分支均受保护，只有从开发者个人远程仓库发起Merge Request（下文简称MR）才可以进行代码更新。 个人远程仓库ORIGIN ：由MAIN fork而来，位于服务器上个人项目下。 本地仓库LOCAL ：由开发人员从ORIGIN clone而来，位于本地，用于代码开发。后续通过pull/push操作保持LOCAL与ORIGIN的同步。同时，在LOCAL中设置upstream为MAIN，然后通过fetch upstream来获取MAIN的代码。 2. 协作流程 （1

应用场景 这里列举几个应用场景，下文会针对这几个场景并结合代码进行分析。 1：proxy_pass + upstream upstream foo.example.com { server 127.0.0.1:8001; } server { listen 80; server_name localhost; location /foo { #匹配/foo结尾的域名 proxy_pass http://foo.example.com; #反向代理到foo.example.com } } 访问 http://localhost/foo 时，proxy模块会将请求转发到127.0.0.1的8001端口上。 2：只有proxy_pass，没有upstream与resolver server { listen 80; server_name localhost; location /foo { proxy_pass http://foo.example.com; } } 实际上是隐式创建了upstream，upstream名字就是 foo.example.com 。upstream模块利用本机设置的DNS服务器（或/etc/hosts），将 foo.example.com 解析成IP，访问 http://localhost/foo ，proxy模块会将请求转发到解析后的IP上。