資訊專欄INFORMATION COLUMN
摘要：如果要對(duì)冪等操作重試請(qǐng)求優(yōu)先參考上面的回答，下面是的示例參考網(wǎng)站關(guān)于該參數(shù)的詳細(xì)解釋學(xué)習(xí)總結(jié)與模塊三
轉(zhuǎn)載請(qǐng)注明出處 http://www.paraller.com
原文排版地址 點(diǎn)擊跳轉(zhuǎn)
轉(zhuǎn)載請(qǐng)注明出處 來源: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 后端服務(wù)器連接的超時(shí)時(shí)間_發(fā)起握手等候響應(yīng)超時(shí)時(shí)間
proxy_read_timeout 連接成功后_等候后端服務(wù)器響應(yīng)時(shí)間_其實(shí)已經(jīng)進(jìn)入后端的排隊(duì)之中等候處理（也可以說是后端服務(wù)器處理請(qǐng)求的時(shí)間）
proxy_send_timeout :后端服務(wù)器數(shù)據(jù)回傳時(shí)間_就是在規(guī)定時(shí)間之內(nèi)后端服務(wù)器必須傳完所有的數(shù)據(jù)
nginx在某個(gè)版本更新之后，對(duì)非冪等的請(qǐng)求不會(huì)進(jìn)行重試處理。
如果要對(duì)冪等操作重試請(qǐng)求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
優(yōu)先參考上面的回答，下面是 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;
}
}
參考網(wǎng)站
https://stackoverflow.com/questions/12868683/nginx-proxy-next-upstream-doesnt-work
https://stackoverflow.com/questions/40661246/nginx-tries-to-proxy-pass-to-upstream-name
關(guān)于該參數(shù)的詳細(xì)解釋
nginx proxy_next_upstream
Nginx學(xué)習(xí)總結(jié)：proxy與rewrite模塊（三）
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://m.hztianpu.com/yun/39685.html
摘要：再次使用方式請(qǐng)求，再分別查看和兩個(gè)端口號(hào)對(duì)應(yīng)的服務(wù)日志，可以發(fā)現(xiàn)只有一個(gè)服務(wù)收到請(qǐng)求。常見的請(qǐng)求方法中，是冪等的，而是非冪等的。而一般對(duì)應(yīng)，如果執(zhí)行多次后，可能會(huì)造成數(shù)據(jù)重復(fù)插入的問題。 Nginx通過反向代理做負(fù)載均衡時(shí)，如果被代理的其中一個(gè)服務(wù)發(fā)生錯(cuò)誤或者超時(shí)的時(shí)候，通常希望Nginx自動(dòng)重試其他的服務(wù)，從而實(shí)現(xiàn)服務(wù)的高可用性。實(shí)際上Nginx本身默認(rèn)會(huì)有錯(cuò)誤重試機(jī)制，并且可以通過...
摘要：有些接口可以天然的實(shí)現(xiàn)冪等性，比如查詢接口，對(duì)于查詢來說，你查詢一次和兩次，對(duì)于系統(tǒng)來說，沒有任何影響但對(duì)于有寫庫操作的增刪改接口，多次調(diào)用就會(huì)對(duì)系統(tǒng)有多次影響。 寫在前面：之前在設(shè)計(jì)接口時(shí)因經(jīng)驗(yàn)尚淺，并未過多考慮冪等性，但這兩天出現(xiàn)的一個(gè)線上問題讓我認(rèn)識(shí)到了某些情況下接口冪等性的重要性； 非冪等場景：服務(wù)A將單據(jù)A信息通過RPC遠(yuǎn)程過程調(diào)用傳給下游服務(wù)B接口（非冪等接口）用于生成關(guān)聯(lián)...
摘要：在這篇文章中，我們描述了我們?nèi)绾卧诶镌O(shè)計(jì)重試，使能夠在最小化風(fēng)險(xiǎn)的同時(shí)，自動(dòng)提高系統(tǒng)可靠性。配置重試的最常用方法，是指定在放棄之前執(zhí)行的最大重試次數(shù)。超時(shí)時(shí)，將取消請(qǐng)求并返回響應(yīng)。但是在上面的服務(wù)配置文件中，我們將在服務(wù)器端指定重試政策。 showImg(https://segmentfault.com/img/bVbo113?w=4400&h=1007);作者：Alex Leong ...
摘要：解決冪等問題的三部曲，也是作者的思考框架。這是解決冪等問題的第二部曲列出并減少副作用的分析維度。所以在并發(fā)執(zhí)行的維度，將并發(fā)重復(fù)執(zhí)行變成串行重復(fù)執(zhí)行是最好的冪等解決方案。 綱要 文章目的：本文旨在提煉一套分布式冪等問題的思考框架，而非解決某個(gè)具體的分布式冪等問題。在這個(gè)框架體系內(nèi)，會(huì)有一些方案舉例說明。文章目標(biāo)：希望讀者能通過這套思考框架設(shè)計(jì)出符合自己業(yè)務(wù)的完備的冪等解決方案。文章內(nèi)容...
閱讀 3053·2021-11-24 09:39
閱讀 3693·2021-11-22 13:54
閱讀 3475·2021-11-16 11:45
閱讀 2549·2021-09-09 09:33
閱讀 3273·2019-08-30 15:55
閱讀 1355·2019-08-29 15:40
閱讀 991·2019-08-29 15:19
閱讀 3483·2019-08-29 15:14
