一、問題描述：
dubbo消費者端向 dubbo 服務提供者端發起RPC遠程調用，服務提供者端任務正常執行，但是卻執行了3次。後來發現，雖然 provider 端程序正常執行，但是執行超時了，此時，consumer 端在超時前沒有收到響應，就按照 dubbo 默認的重試機制一共調用了3次。
這種超時導致的重試，如果是讀操作，影響倒是不大，但如果是寫操作，會導致多次insert，應該避免這種問題。
由於我的項目中， provider 端是執行shell腳本，向服務器寫文件，同時將執行日誌與shell執行結果文件存到mysql，導致了多條寫數據。
二、consumer 端報錯信息：
六月 15, 2020 11:04:25 上午 org.apache.catalina.core.StandardWrapperValve invoke
嚴重: Servlet.service() for servlet [dispatcherServlet] in context with path [/tmp-web] threw exception [Request processing failed; nested exception is com.alibaba.dubbo.rpc.RpcException: Failed to invoke the method. Tried 3 times of the providers [172.x.x.x:7070] (1/1) from the registry 172.x.x.x:2181 on the consumer x.x.x.19 using the dubbo version 2.6.2. Last error is: Invoke remote method timeout.
provider: dubbo://172.x.x.x:7070/service.JmeterExecuteService?anyhost=true&application=tmp-web&dubbo=2.6.2&side=consumer&timeout=3000&version=1.0.0, cause: Waiting server-side response timeout.client elapsed: 0 ms, server elapsed: 3002 ms, timeout: 3000 ms,
provider端日誌的錯誤現象：雖然執行結果爲true，但是由於超時，同一次調用重試了3次。
三、解決步驟：
1.取消重試。
關閉服務的重連，需要設置retries = -1 。
參考連接：【dubbo重試次數】
2.延長超時時間
以上操作發現，雖然dubbo的重試取消了，consumer 端只請求了一次，但是客戶端日誌卻還是在報錯，超時的異常依然存在，需要將超時時間設置長一點。
consumer 消費者端日誌：
provider 服務端日誌：
問題解決了。注意：超時時間與重試的配置 是在provider端的，consumer端沒有配置超時與重試參數。
四、dubbo 官網建議的配置優先級
以超時爲例，這是從高到低的優先級（重試，負載平衡，活動對象也應用相同的規則）：
方法級別，接口級別，默認/全局級別。
在同一級別上，消費者的優先級高於提供者
提供者方的配置通過註冊表以URL的形式傳遞給消費者方。
建議提供者爲每個服務設置一個超時，因爲提供者確切地知道一種方法需要執行多長時間。如果使用者同時引用多個服務，則無需關心每個服務的超時設置。