2. 程式人生 > >nginx 重發機制導致的重復扣款問題

nginx 重發機制導致的重復扣款問題

阿新 • • 發佈：2019-01-11
str err 服務器 機制 停止 建立連接 head 後端服務 發送請求

問題：

nginx 重發機制導制重復提交(客戶還款，被扣倆筆款，前端調用一次，後端執行2次)

proxy_next_upstream

語法: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 |http_404 | off ...; 
默認值: proxy_next_upstream error timeout; 上下文: http, server, location

error # 和後端服務器建立連接時，或者向後端服務器發送請求時，或者從後端服務器接收響應頭時，出現錯誤 
 

timeout # 和後端服務器建立連接時，或者向後端服務器發送請求時，或者從後端服務器接收響應頭時，出現超時 
invalid_header # 後端服務器返回空響應或者非法響應頭 
http_500 # 後端服務器返回的響應狀態碼為500 
http_502 # 後端服務器返回的響應狀態碼為502 
http_503 # 後端服務器返回的響應狀態碼為503
http_504 # 後端服務器返回的響應狀態碼為504 
http_404 # 後端服務器返回的響應狀態碼為404 
off # 停止將請求發送給下一臺後端服務器

運用場景 
1、proxy_next_upstream http_500 | http_502 | http_503 | http_504 |http_404;
當其中一臺返回錯誤碼404,500...等錯誤時，可以分配到下一臺服務器程序繼續處理，提高平臺訪問成功率，多可運用於前臺程序負載，設置proxy_next_upstream
proxy_next_upstream http_500 | http_502 | http_503 | http_504 |http_404;


2、proxy_next_upstream off


因為proxy_next_upstream 默認值: proxy_next_upstream error timeout;


場景:當訪問A時，A返回error timeout時，訪問會繼續分配到下一臺服務器處理，就等於一個請求分發到多臺服務器，就可能出現多次處理的情況，
 


如果涉及到充值，就有可能充值多次的情況，這種情況下就要把proxy_next_upstream關掉


proxy_next_upstream off


nginx 重發機制導致的重復扣款問題
   
 
 
 
 

            
  

           

              
              

            

            
相關推薦

			   
            
            
            
 

    


    
    
nginx 重發機制導致的重復扣款問題

     
 str   err   服務器   機制   停止   建立連接   head   後端服務   發送請求   問題：
     nginx 重發機制導制重復提交(客戶還款，被扣倆筆款，前端調用一次，後端執行2次)
proxy_next_upstream
語法: proxy_next_upstream err 



  
 

    


    
    
springboot+activemq中引入重發機制

     
 簡介   一個   value   nec   ring   cto   為我   body   over   一、簡介
在使用activemq消息中間件進行消息隊列傳輸時，總會由於各種原因導致消息失敗。
一個經典的場景是一個生成者向Queue中發消息，裏面包含了一組郵件地址和郵件內容。而消費者從Queue中 



  
 

    


    
    
ActiveMQ 重發機制與確認機制 實踐

     
 方法   Coding   ssa   this   消息發送   als   cer   出隊   引用   一、配置spring-activemq.xml

 1 <?xml version="1.0" encoding="UTF-8"?>
 2 <beans xmlns="http:/ 



  
 

    


    
    
activemq總結--重發機制

     
  
 
 在activemq中存在訊息確認機制，即ACK機制，ACK (Acknowledgement），即確認字元，在資料通訊中，接收站發給傳送站的一種傳輸類控制字元。表示發來的資料已確認接收無誤。JMS API中約定了Client端可以使用四種ACK_MODE,在javax.jms.Session介面中: 



  
 

    


    
    
使用performSelector設計最簡單的重發機制

     
  
 
 重發機制 
 在對網路進行http請求或者物聯網產業中對閘道器進行不斷的傳送資料幀時，重發機制是一個必須存在的功能，來保證使用者操作的可靠性，app會不斷的重複傳送，直到資料成功傳送，並且接受到回覆幀。 
 performSelector 
 performSelector: withObject: 



  
 

    


    
    
簡訊重發機制

     
 
目前簡訊重發分別做在Modem和 App ，對應不同的情況。
Modem：
     Modem的重發做在SMS-TL/ SMS-CM，針對傳送簡訊中的暫時性的錯誤。
     其中涉及到很多底層技術細節，並且這些對於App層來說都是透明的。
     但Modem端的處理可以保證會有1次重發，最長的等待時 



  
 

    


    
    
Volley請求的重發機制

     
  
 
 
  
  暮鼓集    行走集 
  
 原作於2017年01月02日 
 在傳送網路請求時，常常會遇到超時、迴應錯誤等情形，這時便需要考慮是否重發請求。Volley提供了一套機制，用於檢查問題及重發請求，這個機制的核心是RetryPolicy介面。 
 RetryP 



  
 

    


    
    
Spring ActiveMQ 整合（二）: 重發機制（訊息傳送失敗後的重新發送）

     
 
								
								            
						
                
       之前已經寫了一個spring   activemq整合的demo   ，今天繼續完善一下這個demo，讓功能更強大。

       假如現在我手裡有一個很重要的訊息的，想要發給一個人， 



  
 

    


    
    
Java UDP 重發機制

     
 
                
一、重發訊息有兩個原因：
①接收方未收到，此時重發是應該的。②接收方收到訊息但是發回的應答包丟失了，此時重發訊息則重複了，所以在接收方還得新增一個機制：若收到的訊息與以前發過的訊息重複，則再次傳送應答包。在這些機制下，能夠初步的保證UDP傳輸的完整性。為了UDP包不在IP層 



  
 

    


    
    
tcp重發機制，確認機制，視窗機制

     
 1.累積確認    一般地講，如果傳送方發了包1，包2，包3，包4；接受方成功收到包1，包2，包3。那麼接受方可以發回一個確認包，序號為4。一個確認包確認了累積到某一序號的所有包。而不是對沒個序號都發確認包。2.重發    如果傳送端實體在合理的往返時延(RTT)內未收到確認，那麼對應的資料（假設丟失了）將會 



  
 

    


    
    
使用SpringCloud Stream結合rabbitMQ實現訊息消費失敗重發機制

     
 > 前言：實際專案中經常遇到訊息消費失敗了，要進行訊息的重發。比如支付訊息消費失敗後，要分不同時間段進行N次的訊息重發提醒。

# 本文模擬場景

1. 當金額少於100時，訊息消費成功
1. 當金額大於100，小於200時，會進行3次重發，第一次1秒；第二次2秒；第三次3秒。
1. 當金額大於200時 



  
 

    


    
    
activemq-重發、去重

     
 .html   重啟   etc   iterator   延遲   隊列   void   fetch   維護   activemq的consumer端也有窗口機制，通過prefetchSize就可以設置窗口大小。加入窗口是為了批量獲取數據，同時可以設置optimizeAcknowledge來優化確認回復 



  
 

    


    
    
C語言頭文件中定義全局變量導致重復定義錯誤

     
 語言   總結   多個   sof   pan   全局變量   現在   程序編譯   升級   合作方升級SDK後，程序編譯出現變量重復定義的錯誤，通過錯誤提示無法找到什麽位置重復定義了，但確定是引入新SDK後才出現的錯誤，從SDK的頭文件中查找，最終發現在頭文件中定義了全局變量
我們的項目在多個頭文件 



  
 

    


    
    
關於QT信號和槽機制的重復綁定錯誤及改正

     
 之前   位置   對象   綁定   會銷   改變   設計   界面   再次   　　之前做過一個作業，是編寫五子棋、圍棋遊戲，因為需要界面，所以選擇了QT框架。Qt 的核心機制之一是信號與槽，主要用來進行兩個對象之間的通信。當一個對象狀態改變時，可以發出一個信號，另一個對象則執行與這個信號綁定的槽函 



  
 

    


    
    
並發入庫面臨重復數據的問題

     
 方案   ice   服務   數據庫   關註   處理   user   進行   數據   並發入庫面臨重復數據的問題
以User類為例，當添加一個用戶時，首先會去判斷用戶是否已經存在（即username是否已經在數據庫中了），如果沒有，則insert一條用戶數據，如果有，則提示用戶名已存在。
將這個操 



  
 

    


    
    
事件委托導致重復綁定多次事件

     
 綁定   方法   click   font   page   接口   In   ret   btn   最近在制作分頁的時候使用事件綁定，導致ajax訪問接口成倍的增加，找了好久發現是由於多次事件綁定引起的。

//分頁功能
    Sea("page").on("click",".page-btn",f 



  
 

    


    
    
ICE中地址對重發探測機制

     
  
 
 
  if (c->state == PJ_ICE_SESS_CHECK_STATE_WAITING)
 {


     /* See if we shall nominate this check */
     pj_bool_t nominate = (c->nominated  



  
 

    


    
    
nginx的重試機制 proxy_next_upstream

     
  
 
 現在對外服務的網站，很少只使用一個服務節點，而是部署多臺伺服器，上層通過一定機制保證容錯和負載均衡。
 nginx就是常用的一種HTTP和反向代理伺服器，支援容錯和負載均衡。
 nginx的重試機制就是容錯的一種。
 在nginx的配置檔案中，proxy_next_upstream項定義了什麼情況下 



  
 

    


    
    
jstorm kafkaspout未能實現fail機制重發功能

     
 
                問題的發現是zookeeper kafka的消費offset很久沒有更新，通過打日誌發現




lastoffset其實是從傳送的儲存了所有傳送的offset的pendingOffsets（原始碼裡只是個treeset，阿里實現了ack，fail的非同步，居然沒用Concu 



  
 

    


    
    
Yii+MYSQL鎖表防止並發情況下重復數據的方法

     
 yii   p s   一個表   操作   out   其它   mysq   return   sharp   https://www.jb51.net/article/88562.htm
本文實例講述了Yii+MYSQL鎖表防止並發情況下重復數據的方法。分享給大家供大家參考，具體如下：
lock t