摘要:如果要对幂等操作重试请求优先参考上面的回答,下面是的示例参考网站关于该参数的详细解释学习总结与模块三
转载请注明出处 http://www.paraller.com
原文排版地址 点击跳转
转载请注明出处 来源:paraller"s blog
upstream www.paraller.com { server 10.29.209.14*:3810; server 10.24.225.11*:3810; server 10.25.208.38*:3810; } server { server_name www.paraller.com; listen 80 ; access_log /var/log/nginx/access.log vhost; return 301 https://$host$request_uri; } server { server_name www.paraller.com; listen 443 ssl http2 ; access_log /var/log/nginx/access.log vhost; add_header Strict-Transport-Security "max-age=31536000"; location ^~ /socket.io/ { return 301; } location / { proxy_pass http://www.paraller.com; proxy_connect_timeout 20; proxy_read_timeout 20; proxy_send_timeout 20; proxy_ignore_client_abort on; } }
proxy_connect_timeout 后端服务器连接的超时时间_发起握手等候响应超时时间
proxy_read_timeout 连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理(也可以说是后端服务器处理请求的时间)
proxy_send_timeout :后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据
nginx在某个版本更新之后,对非幂等的请求不会进行重试处理。
如果要对幂等操作重试请求In case of upstream returning 429, I"d like to have nginx retry next upstream server. Since nginx by default won"t retry non-idempotent requests, how do I force nginx to retry when receiving 429? I imagine this should be the default behavior anyway, or does nginx not care about returning code and will never retry non-idempotent?
If you want nginx to retry non-idempotent requests, you can do so with "proxy_next_upstream non-idempotent;", see http://nginx.org/r/proxy_next...
http://nginx.2469901.n2.nabble.com/upstream-429-and-non-idempotent-request-td7600353.html
优先参考上面的回答,下面是 stackflow的示例:
upstream backends { server 192.2.0.1; server 192.2.0.2; ... } server { ... location / { proxy_pass http://backends; proxy_next_upstream error timeout http_404; } }参考网站
https://stackoverflow.com/questions/12868683/nginx-proxy-next-upstream-doesnt-work
https://stackoverflow.com/questions/40661246/nginx-tries-to-proxy-pass-to-upstream-name
关于该参数的详细解释
nginx proxy_next_upstream
Nginx学习总结:proxy与rewrite模块(三)
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/39685.html
摘要:再次使用方式请求,再分别查看和两个端口号对应的服务日志,可以发现只有一个服务收到请求。常见的请求方法中,是幂等的,而是非幂等的。而一般对应,如果执行多次后,可能会造成数据重复插入的问题。 Nginx通过反向代理做负载均衡时,如果被代理的其中一个服务发生错误或者超时的时候,通常希望Nginx自动重试其他的服务,从而实现服务的高可用性。实际上Nginx本身默认会有错误重试机制,并且可以通过...
摘要:有些接口可以天然的实现幂等性,比如查询接口,对于查询来说,你查询一次和两次,对于系统来说,没有任何影响但对于有写库操作的增删改接口,多次调用就会对系统有多次影响。 写在前面:之前在设计接口时因经验尚浅,并未过多考虑幂等性,但这两天出现的一个线上问题让我认识到了某些情况下接口幂等性的重要性; 非幂等场景:服务A将单据A信息通过RPC远程过程调用传给下游服务B接口(非幂等接口)用于生成关联...
摘要:在这篇文章中,我们描述了我们如何在里设计重试,使能够在最小化风险的同时,自动提高系统可靠性。配置重试的最常用方法,是指定在放弃之前执行的最大重试次数。超时时,将取消请求并返回响应。但是在上面的服务配置文件中,我们将在服务器端指定重试政策。 showImg(https://segmentfault.com/img/bVbo113?w=4400&h=1007);作者:Alex Leong ...
摘要:解决幂等问题的三部曲,也是作者的思考框架。这是解决幂等问题的第二部曲列出并减少副作用的分析维度。所以在并发执行的维度,将并发重复执行变成串行重复执行是最好的幂等解决方案。 纲要 文章目的:本文旨在提炼一套分布式幂等问题的思考框架,而非解决某个具体的分布式幂等问题。在这个框架体系内,会有一些方案举例说明。文章目标:希望读者能通过这套思考框架设计出符合自己业务的完备的幂等解决方案。文章内容...
阅读 2921·2021-11-24 09:39
阅读 3598·2021-11-22 13:54
阅读 3408·2021-11-16 11:45
阅读 2431·2021-09-09 09:33
阅读 3193·2019-08-30 15:55
阅读 1289·2019-08-29 15:40
阅读 919·2019-08-29 15:19
阅读 3395·2019-08-29 15:14