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