在分布式框架中在服務的調用過程中，難免會存在請求超時（業(yè)務復雜、網絡延遲、服務器壓力），那么對于請求超時后的結果應該如何去處理呢？

例如:商戶系統(tǒng)創(chuàng)建訂單的時候調用【創(chuàng)建訂單服務】,此時由于某種原因導致執(zhí)行【創(chuàng)建訂單服務】的過程中請求超時了（階段1）這時候，如果是dubbo默認的配置，dubbo 將進行重試機制，調用其他的鏈路（如果存在訂單服務集群）去執(zhí)行【創(chuàng)建訂單服務】（階段2），這時候 原先還在超時的（階段1）的服務才執(zhí)行完畢，階段2的服務也執(zhí)行完畢，那么將會出現(xiàn)兩條一樣的訂單數據，這種情況應該如何去處理 ？

我這邊想到的解決方案 ：
1、去掉dubbo提供的重試機制，讓dubbo提供服務層如果出現(xiàn)超時就拋出異常，那么將不會出現(xiàn)數據不一致的問題，但是這里有個問題，是否所有的可能出現(xiàn)數據重復的服務都采用這個方式，那么dubbo重試機制的意義在哪里呢 ？
2、采用冪等性操作，在調用方創(chuàng)建一個唯一ID，當訂單服務端存儲的時候發(fā)現(xiàn)id已經存在，由orm層跑錯（如果在程序中判斷是否已經存在，可能存在超時服務還沒有insert的時候），然后將不會存儲相同的數據。但是這種方法還是感覺怪怪的。
請問對這個問題有沒有優(yōu)雅的解決方法 ？