本文主要想通过两个案例来分享下，以下实践的经验
- 合理的配置以及配置的有效性，需要通过有效的测试来保障，任何理论上的推导都是 “靠不住”
- 不建议在一些关键配置上采用默认配置，即便值是一样的，也需要 “显式” 的配置和测验
案例 1:nginx upstream health check 配置失效
故障背景
X 项目所在宿主机 A-内网光口网卡硬件故障，导致网络故障，服务不可达，简要架构如下
故障现象
业务接口请求持续有一定比例超时失败
故障复现
1.python+Flask 快速构建服务，两台主机上分别部署，修改 retDescp 为 “helloA” 和 “helloB”，请求路径保持一致
from flask import Flask, jsonify
app = Flask(__name__)
@app.route("/hello")
def say_hi():
return jsonify(retCode=200, retDescp="helloA")
if __name__ == '__main__':
app.run(debug=True)
2.采用 uwsgi 启动 A、B 两台机器服务
uwsgi --chdir=$WORKSPACE --wsgi-file=hello.py --master --pidfile=$PIDPATH --socket=0.0.0.0:$PORT --http-socket=127.0.0.1:$LOCAL_HTTP_PORT --processes=4 --enable-threads --threads=8 --harakiri=600 --max-requests=5000 --vacuum --post-buffering=32768 --buffer-size=32768 --wsgi-disable-file-wrapper
3.测试环境模拟线上 nginx 配置，采用 uwsgi_pass 进行代理转发
uwsgi_pass xx-server;
upstream xx-server {
server A:8088 max_fails=3 fail_timeout=30s;
server B:8088 max_fails=3 fail_timeout=30s;
}
4.发起请求流量
for i in {1..2000}; do curl -X GET --connect-timeout 5 -m 5 "http://xx-test.xx.com/hello" >> log.txt 2>&1; done
5.中断宿主机 A 网络，复现线上故障场景
分析结果
宿主机 A 网络中断，客户端侧 5 秒超时会主动关闭连接，实际 nginx 侧 max_fails 不会计数失败，导致异常节点一直不会被触发 “下线” fail_timeout 长度的时间
经过沟通，发现此处存在 2 种 “失效”
- 一是认知偏差，对于 max_fails、fail_timeout 的理解不到位，导致应用预期失效，一种误解是认为 fail_timeout 是业务请求超时，max_fails 达到失败次数后会 “下线” 节点
- 二是功能失效，max_fails、fail_timeout 正确的一句话解释是：在 fail_timeout 时间窗口内业务请求失败 max_fails 次数，临时下线节点 fail_timeout 时长，但是 fail 的定义不同的协议中会有差异（故障中服务网络中断 ，客户端侧主动关闭连接的情况，对于 nginx 侧未识别到计数为 fail，所以导致失效）
官方解释：
fail_timeout – Sets the time during which a number of failed attempts must happen for the server to be marked unavailable, and also the time for which the server is marked unavailable (default is 10 seconds).
max_fails – Sets the number of failed attempts that must occur during the fail_timeout period for the server to be marked unavailable (default is 1 attempt).
延伸测试
一个链路 A 到 B 可能出现的故障场景可以简单分为以下 4 种，对于 health check 配置需要覆盖这 4 种可能出现的故障，前三种可以走 4 层 TCP CHECK，第 4 种 “服务进程假死” 需要真正的业务请求可达，需要走 7 层 HTTP CHECK
- B 服务进程挂掉
- B 所在宿主机挂掉
- A 到 B 网络中断（这里可以细分）
- 服务进程假死
优化建议
- 添加 4 层 TCP CHECK，upstream 中添加 CHECK
check interval=3000 rise=2 fall=3 timeout=5000 type=tcp default_down=false;
- 添加 7 层 HTTP CHECK，目前后台服务基于 uwsgi 协议，配置的是 socket，走的是 4 层，无法通过 HTTP CHECK 实现，需要变更 uwsgi 启动通过 http-socket 方式目前已知的性能损耗是多一次 http 解析，对于高性能要求、大并发流量的业务，这个是需要考虑的
案例 2:Redis 集群主从机制失效
问题现象
Redis 集群三主三从，挂掉从节点后，应用请求出现大量的超时
问题原因
从理论上来讲，挂掉从节点不会对业务造成任何影响，Redis 集群主 1 从 1 之前发生过一次主从切换，下线所谓的 “从” 节点时（之前的主 1），由于集群拓扑未刷新，连接请求仍然会请求到主 1，导致应用持续大量请求超时
问题分析
在分析问题的过程中，存在两个配置失效的问题，一是 spring.redis.timeout=100000 设置的超时时间过长，导致需要 100 秒后才会刷新集群拓扑，这期间会有大量的业务请求失败；二是集群拓扑刷新失效，redis 的客户端（lettuce、Jedis、redisson）对拓扑刷新的处理不同，spring-data-redis 包中实现的 Lettuce 客户端时，默认没有开启客户端刷新功能，需要 SpringBoot 版本>=2.3.0 后有属性配置支持开启自动刷新
spring:
application:
name: xxx
#***********************redis***********************
redis: #redis配置
lettuce:
cluster:
refresh:
adaptive: true #自动刷新集群 默认false关闭
period: 30000