nginx重试机制导致系统雪崩

原创 已于 2024-03-05 16:37:59 修改 · 2.2k 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#nginx #mysql #java

于 2022-03-21 19:43:13 首次发布
本文讲述了在上线项目中由于一个GET请求导致数据库宕机的问题。问题源于Nginx的请求故障转移机制，当GET请求超时时，nginx会将请求转发至其他节点，造成请求重复执行，数据库压力剧增。优化措施包括缩短请求响应时间或改用POST请求。了解到nginx仅在GET请求中启用故障转移，而在POST请求中不转发，这为避免类似问题提供了思路。

         最近在上线项目的过程中遇到由于一个请求大量查询数据库，导致生产系统宕机。后期在把开发、dba、运维都拉在一起开会讨论时，按dba提供的数据库配置 性能后都无法相信这个请求会导致数据库宕机。后面重新复盘，在执行一次这个请求后仔细排查执行过程，才发现是由于nginx自带的请求故障转移导致了这次的宕机。

    我们系统是采用nginx作为负载均衡工具，负责转发请求到后端的应用节点。nginx有一个故障请求重试的机制。在后端节点请求超时时会把该请求自动转发到下一个节点，如果下一个节点返回结果则将该结果返回给用户，相关参数是proxy_next_upstream。但这次出现问题的请求需要大量查询数据库，性能无法优化，超过了nginx设定的超时时间。这种情况下雪崩开始了，nginx发现这个请求超时没有返回后将该请求转发到了其他的节点，相当于这个大请求执行了多次，这样更加加剧了数据库的压力，数据库宕机了，系统也无法响应了。

  优化措施：优化该请求，另起线程执行耗时任务，缩短该请求的响应时间。

   后面在网上看到这篇文章，Nginx upstream 失效转移机制研究，了解到nginx在get类型请求才会触发故障转移机制，在post类型则不会转发。而出问题的那个请求是get请求，如果是post发送该请求则不会导致上述问题。

    结论：在nginx做负载均衡下，get类型的耗时的请求容易导致系统雪崩。需要优化请求，减少请求的响应时间或者改成post类型提交该请求。

hwssz
关注
任务不断失败重试导致雪崩效应
海涛技术漫谈
03-20 1205
大家在开发工程中，一般都使用过类似Mq的消息中间件产品，或者自己开发处理数据的定时任务。 它们一般的流程都是：每隔一段时间，去数据库获取有效的任务，然后执行，执行完成之后，删除任务或者将任务设置为失效。 那么这就可能存在一个潜在的风险：“雪崩效应”。 试想一下如下场景：我有个定时任务，每隔1s去数据库获取最早创建的并且有效的任务，然后执行任务。之所以获取最早创建的，是因为如果获取最新的...
nginx重试机制
qq_40603125的博客
02-19 1008
一个新增数据的请求，在本地测试环境没有任何问题，但是部署到正式环境中，发现有的请求执行了两次。
什么是服务雪崩，如何解决这个问题
最新发布
m0_73794536的博客
10-14 719
熔断：快速失败，隔离故障点；限流：控制流量入口，防止过载；降级：牺牲非核心，保核心流程；隔离：资源独立，避免连锁耗尽；超时 + 缓存：减少无效等待和依赖压力。目的很一致，都是从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃，采用的技术手段最终表现类似，对于两者来说，最终让用户体验到的是某些功能暂时不可达或不可用粒度一般都是服务级别，当然，业界也有不少更细粒度的做法，比如做到数据持久层（允许查询，不允许增删改）
Nginx 中怎样实现请求的超时自动重试？
技术笔记
07-23 1481
在 Nginx 中实现请求的超时自动重试，就像是给我们的网络应用加上了一层“保险”，能够在遇到意外情况时自动进行补救，提高系统的稳定性和可靠性。但同时，我们也需要谨慎地设置相关参数，充分考虑业务需求和影响，结合监控和故障排查进行优化，确保这一功能能够真正为我们的业务带来价值。就像驾驭一辆汽车，我们要熟悉各种控制装置（超时设置和重试策略），根据路况（业务场景）灵活调整，才能让我们的旅程（网络应用）更加平稳、顺利。🎉相关推荐🍅关注博主🎗️带你畅游技术世界，不错过每一次成长机会！📘Nginx 技术专栏。
Nginx故障转移带来的雪崩问题
KevinLyz的博客
04-05 2616
一、nginx故障转移 我们都知道nginx可以用作负载均衡可以通过轮训、weight、ip_hash、url_hash、fair的方式很好的分散请求的压力。基于nginx阿里也有自己的tengin。 同时Nginx可以对故障转移进行配置，相关的配置项如下所示： server { listen 80; server_name www.yourdoma...
nginx的重试机制
Coding a Life
11-15 2万+
现在对外服务的网站，很少只使用一个服务节点，而是部署多台服务器，上层通过一定机制保证容错和负载均衡。 nginx就是常用的一种HTTP和反向代理服务器，支持容错和负载均衡。 nginx的重试机制就是容错的一种。 在nginx的配置文件中，proxy_next_upstream项定义了什么情况下进行重试，官网文档中给出的说明如下： Syntax: proxy_next_upstream
六、超时与重试机制——代理层超时与重试
流楚丶格念的博客
08-23 1105
在实际开发过程中，未设置或设置不当的超时机制常常导致故障。例如，应用未设置超时可能导致请求响应缓慢，慢请求累积引发连锁反应，甚至引发应用雪崩。中间件或框架有时会在超时后进行重试（如设置重试两次），读操作通常适合重试，但写操作（如订单写入）大多不能重试。重试次数过多可能引发请求流量激增，模拟DDoS攻击，因此需要合理设置重试机制，并与熔断和快速失败机制配合。在代码审查时，务必检查超时与重试机制。本章将从Web应用和服务化应用的角度，介绍如何设置超时与重试。系统层面的超时设置不在本文讨论范围内。
【Django数据库连接重试机制】：稳定系统，避免故障的5个技巧
[【Django数据库连接重试机制】：稳定系统，避免故障的5个技巧](https://global.discourse-cdn.com/business7/uploads/codewithmosh/optimized/2X/0/004d62b146e4fdb96d170f7da42594c51eee307f_2_1024x500.png) ...
API调用限制应对之道：mapLocation中频率控制与智能重试机制的7层设计模型
![API调用限制应对之道：mapLocation中频率控制与智能重试机制的7层设计模型](https://substackcdn.com/image/fetch/w_1200,h_600,c_fill,f_jpg,q_auto:good,fl_progressive:steep,g_auto/... # 摘要 ...
后端verify API调用报错4xx_5xx？详解响应码处理与重试机制
在现代分布式系统中，一次看似简单的API调用背后，往往隐藏着复杂的网络链路、中间件转发和多层服务依赖。当你看到一个`500 Internal Server Error`时，它可能源自数据库连接池耗尽；而一个`403 Forbidden`，也许...
网络波动中断升级？ESP-IDF中HTTP_HTTPS OTA重试机制设计的4种高可靠方案
为保障升级可靠性，系统需具备断点续传、自动重试、状态一致性保护等能力。尤其对于工业传感器、农业监控等远程部署设备，现场维护成本极高，一次升级失败可能引发严重后果。因此，构建高可靠的OTA机制不仅是技术...
Nginx失败重试中的HTTP协议幂等问题: non_idempotent
叉叉哥的BLOG
04-21 2683
Nginx通过反向代理做负载均衡时，如果被代理的其中一个服务发生错误或者超时的时候，通常希望Nginx自动重试其他的服务，从而实现服务的高可用性。实际上Nginx本身默认会有错误重试机制，并且可以通过proxy_next_upstream来自定义配置。 如果不了解HTTP协议以及Nginx的机制，就可能在使用过程中遇到各种各样的坑。例如服务出现了错误或超时却未重试，或者一些例如创建订单或发送短信这...
Nginx重试机制和可能引发的问题
qianghong000的博客
10-09 439
nginx作为反向代理服务器，后端有多台服务器，上层通过一定机制保证容错和负载均衡。nginx的重试机制就是容错的一种官方链接：http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstreamSyntax:proxy_next_upstream...
Nginx 失败重试机制(详细)
zhuchunyan_aijia的博客
01-28 5915
https://zhuanlan.zhihu.com/p/127959800 重试机制解析 Nginx 的失败重试，就是为了实现对客户端透明的服务器高可用。然而这部分失败重试机制比较复杂且官方文档没详细介绍，本文将对其解析，并配合实际场景例子使之更容易被理解。 基础失败重试 这部分介绍最常见、最基础的失败重试场景。 为了方便理解，使用了以下配置进行分析（proxy_next_upstream没有特殊配置）： upstream test { server 127.0.0.1:80..
Nginx之upstream被动式重试机制解读z
一个菜鸡的博客
09-30 1883
我们使用Nginx通过反向代理做负载均衡时，如果被代理的其中一个服务发生错误或者超时的时候，通常希望Nginx自动重试其他的服务，从而实现服务的高可用性。实际上Nginx本身默认会有错误重试机制，并且可以通过来自定义配置。Nginx 通过参数来定义什么情况下会被认为是 fails，从而触发失败重试机制。默认错误，包括 error、timeout选择定义错误，包含 invalid_header 以及各种异常 http 状态码错误等。
【原创】内存不足导致 nginx 崩溃的原因分析
sylan215的软件测试技术学习
06-20 5709
最近在 Centos7 上搭建 nginx 作为 web 服务器使用，但是使用过程中，nginx 总是莫名其妙的崩掉，使用命令 dmesg 检查错误信息如下： [6655217.659132] Out of memory: Kill process 11494 (lsof) score 10 or sacrifice child [6655217.659567] Killed process 11...
nginx 负载均衡时，一台tomcat宕机时的问题 自动切换
热门推荐
末路狂奔》》》》
11-10 4万+
如果Nginx没有仅仅只能代理一台服务器的话，那它也不可能像今天这么火，Nginx可以配置代理多台服务器，当一台服务器宕机之后，仍能保持系统可用。具体配置过程如下： 1. 在http节点下，添加upstream节点。 upstream linuxidc {       server 10.0.6.108:7080;       server 10.0.0.85:8980; }
Nginx 怎样处理请求的重试机制？
技术笔记
07-22 1761
Nginx 的重试机制就像是网络世界中的一道坚固防线，它在请求遇到挫折时挺身而出，为请求的成功送达保驾护航。通过合理的配置和优化，我们可以让 Nginx 的重试机制更好地适应各种复杂的网络环境和业务需求，为用户提供更加稳定、可靠的服务。就如同在人生的道路上，我们难免会遇到挫折和失败，但只要我们不放弃，不断尝试，总会迎来成功的曙光。Nginx 的重试机制也是如此，它在网络的海洋中不断探索、重试，只为将每一个请求安全、准确地送达目的地。🎉相关推荐🍅关注博主🎗️带你畅游技术世界，不错过每一次成长机会！
漫谈雪崩
mikeszhang的专栏
08-17 5415
雪崩是指平时正常调用和被调用的A系统和B系统，突然A系统对B系统的访问超出B系统的承受能力，造成B系统崩溃。 注意将雪崩效应与拒绝服务攻击相区别：两者都是因为B系统过载导致崩溃，但后者是人为的蓄意攻击。 注意将雪崩效应与访问量激增区别：如果A系统直接面对用户，那么激增的用户将直接带来A系统和B系统的流量激增，不过这种case可以通过预估而对A系统和B系统做扩容应对。 一种雪崩case 如果
上面第一种方式怎么限制重试次数
08-05
<think>我们讨论的是缓存击穿解决方案中如何限制请求的重试次数。在分布式互斥锁方案中，当线程未能获取到锁时，通常会等待一段时间后重试。为了避免重试无限制进行，我们需要限制重试次数。 参考用户提供的引用，特别是引用[1][2][3]中关于缓存击穿的定义和基本解决方案，以及引用[4]中提到的使用锁或队列的方式。 在分布式锁方案中，我们可以通过以下方式限制重试次数： 1. 设置最大重试次数 2. 设置重试等待时间（避免立即重试导致CPU竞争激烈） 3. 当重试次数达到上限后，可以采取降级策略（例如返回默认值、错误提示等） 修改之前的代码示例，加入重试次数限制： ```java public Object getDataWithRetryLimit(String key, int maxRetries) { Object value = redis.get(key); if (value == null) { int retryCount = 0; while (retryCount < maxRetries) { if (lockRedis.set(key, "lock", "PX", 100, "NX")) { // 尝试获取锁 try { value = getDataFromDb(key); // 查数据库 redis.set(key, value, "PX", 30000); // 更新缓存 break; // 成功获取数据，跳出循环 } finally { lockRedis.del(key); // 释放锁 } } else { // 未获取到锁，等待一段时间后重试 try { Thread.sleep(50); // 等待50ms } catch (InterruptedException e) { Thread.currentThread().interrupt(); break; // 中断则退出 } retryCount++; // 增加重试次数 } } // 如果重试次数达到上限仍未获取到数据，则执行降级策略 if (retryCount >= maxRetries) { return getFallbackData(key); // 降级方法 } } return value; } ``` 上述代码中，我们引入了： - `maxRetries`：最大重试次数 - `retryCount`：当前重试次数 - 循环条件：当重试次数小于最大重试次数时，继续尝试 - 达到最大重试次数后，调用降级方法`getFallbackData` 注意：为了避免无限循环，必须设置最大重试次数。同时，每次重试之间需要等待一段时间（如50ms），避免频繁重试给系统带来压力。 另外，降级策略可以根据业务场景设计，例如： 1. 返回一个默认值（比如空对象、静态提示信息等） 2. 抛出特定的异常 3. 使用备份缓存（如之前提到的双层缓存策略中的备用缓存） 结合引用[4]中提到的“设置过期标志更新缓存”的思想，我们还可以在降级策略中返回一个接近过期的缓存值（如果存在的话），但这需要额外的设计。 总结：限制重试次数的关键在于在循环条件中加入重试次数的判断，并在达到上限时执行降级策略，避免无限制重试导致线程阻塞或资源浪费。 相关问题： 1. 如何设置合理的重试次数和等待时间？ 2. 降级策略有哪些常见的设计模式？ 3. 在分布式锁方案中，锁等待超时应该如何处理？</think>### 缓存击穿解决方案中的重试次数控制 在缓存击穿解决方案中，限制重试次数是防止系统雪崩的关键环节。以下是具体实现方法（基于分布式锁方案）： #### 核心实现方案 ```java public Object getDataWithRetryLimit(String key) { final int MAX_RETRIES = 3; // 最大重试次数 int retryCount = 0; Object value = null; while (value == null && retryCount <= MAX_RETRIES) { value = redis.get(key); if (value != null) return value; // 尝试获取分布式锁 if (lockRedis.set(key, "lock", "PX", 100, "NX")) { try { value = getDataFromDb(key); // 查数据库 redis.set(key, value, "PX", 30000); // 更新缓存 } finally { lockRedis.del(key); // 释放锁 } } else { // 未获取锁时的重试逻辑 try { Thread.sleep(50 + (20 * retryCount)); // 退避策略：50ms, 70ms, 90ms... } catch (InterruptedException e) { Thread.currentThread().interrupt(); } retryCount++; } } // 重试次数耗尽后的降级处理 return (value != null) ? value : getFallbackData(key); } ``` #### 关键技术点 1. **指数退避策略**（关键优化） - 每次重试间隔增加：`50ms → 70ms → 90ms...` - 公式：$ \text{waitTime} = 50 + (20 \times \text{retryCount}) $ - 作用：避免集群同时重试造成惊群效应[^4] 2. **重试次数限制** ```java final int MAX_RETRIES = 3; // 可配置参数 while (retryCount <= MAX_RETRIES) { ... } ``` 3. **降级处理机制** ```java private Object getFallbackData(String key) { // 可选方案： // 1. 返回静态默认值 // 2. 返回本地缓存副本 // 3. 抛出业务友好异常 return DEFAULT_VALUE; } ``` 4. **熔断器模式**（进阶方案） ```java CircuitBreaker breaker = new CircuitBreaker( 3, // 失败阈值 5000 // 熔断时间(ms) ); if (breaker.allowRequest()) { // 执行数据库查询 } else { return getFallbackData(key); } ``` #### 配置建议 | 参数 | 推荐值 | 说明 | |--------------------|----------|-----------------------------| | 最大重试次数(MAX_RETRIES) | 2-5 | 过高会导致延迟累积 | | 基础等待时间 | 30-100ms | 根据网络延迟调整 | | 退避系数 | 20-50ms | 控制重试间隔增长幅度 | | 熔断时间 | 5-10s | 触发熔断后的恢复时间 | > **最佳实践**： > 1. 结合**监控系统**动态调整参数：当数据库负载 > 70% 时自动降低 MAX_RETRIES[^4] > 2. 采用**自适应退避算法**：$ \text{waitTime} = \text{base} \times 2^{\text{retryCount}} $ > 3. 在 Nginx 层添加**请求排队**机制，避免重试请求压垮应用层
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值