使用宝塔很长时间了，导致很多原生的nginx的配置都搞忘记了。
恰逢需要原生安装和配置，特此记录：
1：负载均衡配置：
配置服务组：
upstream xxx{
server xxx.com:xx weight=2; #weight权重
server ccc.com:xx backup; #backup 备用服务（前面服务器正常访问是不会发生请求，只有前面服务器请求失败时才会触发）
server ccc.com:xx down; #如果需要暂时从负载平衡轮换中删除其中一台服务器，则可以使用down参数对其进行标记，以保留客户端 IP 地址的当前散列
}
使用 可以在
localtion / {
proxy_pass http://xxx;
}
进行配置使用。
平衡方法：
1：默认均匀分布
2：least_conn;根据连接数进行请求（向具有最少活动连接数的服务器发送请求，再次考虑服务器权重）
3：IP_HASH: 比较常用的均衡方式，根据IP限定每次访问相同的IP。
4：hash $request_uri consistent; （备注：若有consistent参数，则Hash一致性将选择 ketama算法。这个算法保障，如果有server被摘除掉。从server group里，只有少数的key会重新映射到其他的server上去，也即大多数的key不受server摘除的影响，还走原来的server。这对提高缓存server命中率有很大帮助。这个方法跟Perl的Cache:Memcached:Fast库保持一致（该库的ketama_points参数须设置为160））
只有少数的key会重新映射到其他的server上去，也即大多数的key不受server摘除的影响，还走原来的server。这对提高缓存server命中率有很大帮助。这个方法跟Perl的Cache:Memcached:Fast库保持一致
通用哈希– 请求发送到的服务器由用户定义的键确定，该键可以是文本字符串、变量或组合。例如，密钥可能是配对的源 IP 地址和端口
5:least_time header（选择具有最低平均延迟和最少活动连接数的服务器，其中最低平均延迟是根据指令中包含的以下参数计算得出的：least_time）; 最少时间请求：
header– 从服务器接收第一个字节的时间
last_byte– 从服务器接收完整响应的时间
last_byte inflight– 考虑到不完整的请求，从服务器接收完整响应的时间
6：随机- 每个请求将被传递到随机选择的服务器。如果two指定了参数，首先 NGINX 会根据服务器权重随机选择两台服务器，然后使用指定的方法选择其中一台服务器：
least_conn– 最少的活动连接数
least_time=header(NGINX Plus) – 从服务器接收响应头的最短平均时间 ( $upstream_header_time)
least_time=last_byte(NGINX Plus) – 从服务器接收完整响应的最短平均时间 ( $upstream_response_time)
（随机负载平衡方法应用于多个负载平衡器将请求传递到同一组后端的分布式环境。对于负载均衡器可以全面了解所有请求的环境，请使用其他负载均衡方法，例如循环、最少连接和最少时间。）
需要注意：random two least_time=last_byte; 配置轮询以外的任何方法时，将相应的指令（hash、ip_hash、least_conn、least_time或）放在块中指令random列表的上方。serverupstream {}
2：服务器慢启动
upsteam xxx{
server http://xxx slow_start=30s;
}
防止服务器因为请求超限而重新被标记为失败。
慢启动允许上游服务器在恢复或可用后逐渐将其权重从其标称值恢复。这可以通过指令的slow_start参数来完成。
总结一句话，对于相关配置还是需要经常练习，或者尽量少的使用集成环境。
