1. 程式人生 > >Dubbo超時重試機制帶來的資料重複問題

Dubbo超時重試機制帶來的資料重複問題

             Dubbo的超時重試機制為服務容錯、服務穩定提供了比較好的框架支援,但是在一些比較特殊的網路環境下(網路傳輸慢,併發多)可能

由於服務響應慢,Dubbo自身的超時重試機制(服務端的處理時間超過了設定的超時時間時,就會有重複請求)可能會帶來一些麻煩。

        常見的應用場景故障:  1、傳送郵件(重複) ;2、賬戶註冊(重複).。

        解決方案:

1.對於核心的服務中心,去除dubbo超時重試機制,並重新評估設定超時時間。

                            (1)、去掉超時重試機制  

                                  <dubbo:provider delay="-1" timeout="6000"  retries="0"/> 

                            (2)、重新評估設定超時時間

                                  <dubbo:service interface="*.*" ref="*"  timeout="延長服務時間"/>

                      2.業務處理程式碼必須放在服務端,客戶端只做引數驗證和服務呼叫,不涉及業務流程處理。

相關推薦

Dubbo超時機制帶來資料重複問題

             Dubbo的超時重試機制為服務容錯、服務穩定提供了比較好的框架支援,但是在一些比較特殊的網路環境下(網路傳輸慢,併發多)可能 由於服務響應慢,Dubbo自身的超時重試機制(服

dubbo超時導致資料重複

      最近在寫郵件啟用測試的時,測試的時候出現註冊失敗,顯示使用者名稱已存在,但是在表單驗證和注開始都沒有問題。後來debug時發現在傳送郵件前,又執行了一次資料驗證。相當於是又走了一遍註冊流程,最後返回註冊失敗,併發送了郵件。在網上找了很多資料,說是dubbo超

jedis超時機制註意事項

del number 十進制 包含 str 沒有 時間 機制 await 最近使用redis集群進行incr操作,總是發現計數不準確,後來經過檢查發現redis在執行incr超時會執行重試機制,造成計數不準確,測試代碼: /** * incrf: *

Volley超時機制

基礎用法 Volley為開發者提供了可配置的超時重試機制,我們在使用時只需要為我們的Request設定自定義的RetryPolicy即可. 參考設定程式碼如下: int DEFAULT_TIMEOUT_MS = 10000; int DEFAULT_MAX_RETRIES = 3; Str

dubbo機制

對dubbo熟悉的人對下面的配置一定不會陌生: <dubbo:reference id="xxxx" interface="xx" check="true" async="false" retries="1" timeout="2000"/> 上面設定需要關注的幾個地方: 1.check=t

Redis學習筆記(七)jedis超時機制注意事項

redis系列文章目錄 jedis客戶端在建立連線時會設定一個超時,並且會有重試機制。 問題起源 在使用jedis客戶端的時候,我測試了一下incr命令,該命令在執行過程中是原子的,所

Volley超時機制詳解

Volley超時重試機制 基礎用法 Volley為開發者提供了可配置的超時重試機制,我們在使用時只需要為我們的Request設定自定義的RetryPolicy即可. 參考設定程式碼如下: int DEFAULT_TIMEOUT_MS = 10

Dubbo 源碼解析】07_Dubbo 機制

version ast 查看 error enabled pre div set time Dubbo 重試機制 通過前面 Dubbo 服務發現&引用 的分析,我們知道,Dubbo 的重試機制是通過 com.alibaba.dubbo.rpc.cluster.su

【原創】TCP超時機制探索

sender mic borde 做了 5.5 多次 字節 應用程序 實現 TCP超時重傳機制探索作者:tll (360電商技術)1)通信模型TCP(Transmission Control Protocol)是一種可靠傳輸協議。在傳輸過程中當發送方(sender)向接

SpringCloud Fegin超時源碼

bsp request uestc debug ima thread etc ogl null springCloud中最重要的就是微服務之間的調用,因為網絡延遲或者調用超時會直接導致程序異常,因此超時的配置及處理就至關重要。 在開發過程中被調用的微服務打斷點發現會又多

guava的機制guava-retrying使用

tco exceptio AI ide .class exc erb BE 一個 1,添加maven依賴 <dependency> <groupId>com.github.rholder</groupId> &l

PHP-RESQUE機制

pub 實現 方法 ole color except function cti ges 因為PHP-Resque 的重試需要自己寫,網上又沒啥輪子,而且resque也很久不更新了,所以自己研究下resque的源碼,然後也借鑒了Laravel的隊列重試機制,實現了PHP-Re

SpringCloud | FeignClient和Ribbon機制區別與聯系

feign per spec 笛卡爾 making log tag tom str 在spring cloud體系項目中,引入的重試機制保證了高可用的同時,也會帶來一些其它的問題,如冪等操作或一些沒必要的重試。 今天就來分別分析一下 FeignClient 和

TCP超時機制

TCP協議在能夠傳送資料之前就建立起了“連線”。要實現這個連線,啟動TCP連線的那一方首先將傳送一個SYN資料包。這只是一個不包含資料的資料包, 然後,開啟SYN標記。如果另一方同時在它收到SYN標記的埠通話,它將發回一個SYN+ACK:SYN和ACK標誌位都被開啟,並將A

Appium失敗截圖及機制封裝(二)

analyze ret boolean 做了 ktr assert public false fail 一、失敗截圖封裝 1、主要封裝了失敗之後的文件名、重寫了失敗之後消息、失敗了以後做個截圖,最後置為失敗,並且存放到相對路徑下、截圖操作,未把失敗用例至為Fail,主要代

nginx的機制 proxy_next_upstream

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

Spring Cloud Gateway機制

前言 重試,我相信大家並不陌生。在我們呼叫Http介面的時候,總會因為某種原因呼叫失敗,這個時候我們可以通過重試的方式,來重新請求介面。 生活中這樣的事例很多,比如打電話,對方正在通話中啊,訊號不好啊等等原因,你總會打不通,當你第一次沒打通之後,你會打第二次

多執行緒之失敗自動機制

發現一個比較好玩的東西: 如果你在使用多執行緒的使用中異常結束了,你應該如何操作呢? 例子: 正常情況下: 專案一啟動都可以跑完,如果有一段程式碼出現錯誤呢。 系統丟出了一個異常出來。 有沒有發生過這樣的情況,你寫的工作執行緒莫名其妙的掛了,如果不是被你剛好看到,拿只能抓瞎了,不知道啥原因了,因為異常

分組機制---可靠資料傳輸原理。

不知道從哪天開始,一禪也陷入了程式設計這條道路..... 小白:你知道嗎?資料在傳輸的時候是分割成一小塊一小塊傳輸的,我們把這一小塊的資料稱之為一個分組。我們在傳輸這塊分組的時候,主要面臨兩個問題。 1、這個分組在傳輸的過程中,由於在通道傳輸過程中,收到干擾,導致這個分組到達目的地之後出現了差

rabbitmq機制

1、應答模式 NONE 可以稱之為自動回撥,即使無響應或者發生異常均會通知佇列消費成功,會丟失資料。 AUTO 自動檢測異常或者超時事件,如果發生則返回noack,訊息自動回到隊尾,但是這種方式可能出現訊息體本身有問題,返回隊尾其他佇列也不能消費,造成佇列阻塞。 MANUAL