我要评论一、先说结论：为什么要做健康检查？
想象一下，你是一个前台接待员（nginx），后面有三个办公室（后端服务器）处理业务。
如果有间办公室着火了，你还在不停地往那间办公室派人，结果人又跑回来告诉你去不了，这不就浪费了时间吗？
健康检查的目的就是：及时发现哪间办公室出问题了，暂时别往那里派人，等修好了再恢复。
二、nginx自带的“基础版”健康检查
1. 默认配置是什么样？
nginx最基础的配置长这样：
- nginx
upstream myapp1 {
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}但其实默认背后隐藏着这些参数：
- nginx
upstream myapp1 {
server srv1.example.com weight=1 max_fails=1 fail_timeout=10;
server srv2.example.com weight=1 max_fails=1 fail_timeout=10;
server srv3.example.com weight=1 max_fails=1 fail_timeout=10;
}2. 自带健康检查怎么工作？
有两个关键机制：
① 故障转移（proxy_next_upstream）
当nginx发现后端服务器连接不上、超时或者返回502、503等错误时
它会自动把这个请求转发给另一台正常的服务器
默认情况下，连接错误和超时都会触发转移
② 健康检查（max_fails + fail_timeout）
max_fails=1：允许1次失败fail_timeout=10：在10秒内如果失败次数达到1次，就认为这个服务器挂了接下来10秒内，nginx不会再往这台服务器发请求
10秒后，会再尝试一下，如果好了就恢复
3. 自带模块有什么问题？
举个生活中的例子：
你派一个人去a办公室，等了60秒（超时时间）才确认没人，然后才转去b办公室
这个过程浪费了60秒
而且每10秒（fail_timeout）才会尝试恢复a办公室，不够智能
总结缺点：
- 反应慢：要等超时时间到了才知道出问题
- 浪费请求：总会先试一下有问题的服务器，失败后才转移
- 不够灵活：只能检查连接，不能检查业务是否正常
三、淘宝的“进阶版”健康检查
1. 这是什么？
淘宝团队开发了一个专门的模块：nginx_upstream_check_module，可以更智能地做健康检查。
在tengine（淘宝的nginx版本）里自带这个功能，普通nginx需要打补丁安装。
2. 配置示例
- nginx
upstream cluster {
server 192.168.0.1:80;
server 192.168.0.2:80;
# 重点在这里：主动健康检查
check interval=5000 rise=1 fall=3 timeout=4000 type=http;
check_http_send "head / http/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}3. 参数都是什么意思？
- interval=5000：每5秒检查一次
- rise=1：连续成功1次，就认为服务器好了
- fall=3：连续失败3次，才认为服务器真挂了
- timeout=4000：等待响应的超时时间（4秒）
- type=http：用http协议检查（不只是检查tcp连接）
- check_http_send：发送什么请求去检查（一般用head减少数据量）
- check_http_expect_alive：什么响应码算正常（默认2xx和3xx）
4. 进阶版好在哪？
还是那个例子：
- 你不只是派人去敲门，而是隔5秒就打个电话问问"你还好吗？"
- 如果连续3次没人接，才认定真的出问题了
- 一旦有人接了一次，马上恢复服务
优势：
- 主动检查：不用等用户请求来才发现问题
- 反应快：毫秒级的检查间隔
- 可定制：可以检查具体某个页面，甚至发送自定义请求
- 监控页面：可以查看所有后端节点的健康状态
四、还可以直接使用tengine
如果不想打补丁，可以直接安装淘宝的tengine：
- nginx
./configure --prefix=/usr/local/tengine --add-module=/path/to/ngx_http_upstream_check_module
配置是一样的，而且更稳定。
五、总结对比
| 对比项 | nginx原生 | 淘宝check模块 |
|---|---|---|
| 检查方式 | 被动（靠用户请求触发） | 主动（定时检查） |
| 发现问题的速度 | 慢（等超时） | 快（几秒内） |
| 是否浪费请求 | 会先发给坏节点 | 完全避开坏节点 |
| 检查内容 | 只能检查连接 | 可检查具体页面 |
| 监控界面 | 无 | 有（/status页面） |
| 配置灵活度 | 一般 | 高 |
一句话总结：
- 小项目、对可用性要求不高：用nginx自带的就够了
- 正式环境、要求高可用：建议用淘宝的check模块或直接上tengine
以上为个人经验，希望能给大家一个参考，也希望大家多多支持代码网。
发表评论