記一次dubbo介面呼叫造成的資料插入重複問題

2021-09-25 14:08:36 字數 2921 閱讀 2072

專案近期要上線,這段時間改bug改的躁動不安的,也沒時間好好寫點東西了。本篇文章想給大家分享的是昨天除錯改bug碰到的乙個大坑。dubbo的重試配置。

問題出現的原因是,我在服務端介面裡加了一段邏輯,導致程式執行時間增加了一些,消費端呼叫介面的時候超時了,導致觸發的重試機制,資料重複推送到

服務端,重複生成三條資料。

簡單搭建一下dubbo環境 dubbo-service dubbo-service-sdk dubbo-service-web

1、新建module dubbo-service-sdk 定義服務介面

/**

* @author v_liuwen

* @date 2019-07-24

*/public inte***ce asoservice

/**

* @author v_liuwen

* @date 2019-07-24

*/@data

public class asoinfodto implements serializable

2、新建module dubbo-service 實現sdk的介面

依賴

top.qrainly

dubbo-service-sdk

0.0.1-snapshot

com.alibaba.boot

dubbo-spring-boot-starter

0.2.0

org.apache.zookeeper

zookeeper

3.4.13

/**

* @author v_liuwen

* @date 2019-07-24

*/@service(version = "1.0", inte***ceclass = asoservice.class)

@component

@slf4j

public class asoserviceimpl implements asoservice ", jsonobject.tojsonstring(asoinfodto));

}}

3、新建module dubbo-service-web

依賴

top.qrainly

dubbo-service-sdk

0.0.1-snapshot

com.alibaba.boot

dubbo-spring-boot-starter

0.2.0

org.apache.zookeeper

zookeeper

3.4.13

定義業務介面

/**

* @author v_liuwen

* @date 2019-07-24

*/public inte***ce createasoservice

定義業務實現

/**

* @author v_liuwen

* @date 2019-07-24

*/@service

@slf4j

public class createasoserviceimpl implements createasoservice catch (interruptedexception e) ",e.getmessage());}}

}

測試類

@runwith(springrunner.class)

@springboottest

@autowired

private createasoservice createasoservice;

@test

public void contextloads()

}

啟動dubbo-service 執行測試方法

控制台輸出

2019-07-25 21:03:24.655  info 6720 --- [:20880-thread-5] t.q.dubboservice.impl.asoserviceimpl     : 插入售後單資訊-->

2019-07-25 21:03:27.603 info 6720 --- [:20880-thread-6] t.q.dubboservice.impl.asoserviceimpl : 插入售後單資訊-->

2019-07-25 21:03:30.616 info 6720 --- [:20880-thread-7] t.q.dubboservice.impl.asoserviceimpl : 插入售後單資訊-->

完美復現問題 剛開始就懷疑是不是重試配置導致的,但是看了一下@reference的retries預設也是0,也就是說不配置的話預設重試0次,也就是不重試。

那為啥還調了三次。於是嘗試配置了重試次數為-1

@reference(version = 「1.0」,retries = -1,check = false)

再次操作 控制台輸出

果然!真是重試配置搞的鬼!後來我們的處理方案並不是把重試次數設為-1,而是配置的超時時間為30000ms。畢竟在網路抖動以及異常情況下,重試確實是

乙個很好的彌補措施。配置超時時間也一樣可以解決問題。至於服務超時處理,這個,也確實要優化一下。

dubbo介面的注入可以通過xml的方式和宣告註解的方式注入

針對業務場景,配置合理的重試次數和超時時間,可以有效避免介面呼叫的問題

能配置超時時間盡量不要遮蔽重試機制

記一次失誤造成的影響

在使用salt給機器新增時間同步的計畫任務的時候,忘記salt的cron模組的寫法了,於是偷懶直接使用echo追加到 var spool cron root的方法新增了計畫任務。如下 salt cmd.run echo 10 usr sbin ntpdate ntp1.aliyun.com dev ...

記一次Supplier介面的應用

supplier是乙個構造型介面,建立物件的工廠,返回乙個物件。假設有類t,那麼有 t t0 new t suppliersupplier t new t t1 supplier.get 很多人不明白第二種建立方式的意義,我也僅應用到了一次。需求 需要根據從word或者excel中讀取a b物件資料...

記一次呼叫別人的介面方式和使用者模擬登入

1.引入jar包 2.在你的controller 裡面寫邏輯 如下 responsebody public void retu throws exception 3.必須登入以後才能傳送請求 如 想要請求人人網的資料 使用者必須登入才能得到傳送請求 解決方式 程式模擬瀏覽器登入 他需要的引數 初始化...