for example: the merchant system calls [create order Service] when creating an order, and for some reason, the request during the execution of [create order Service] has timed out (stage 1). If it is the default configuration of dubbo, dubbo will retry the mechanism and call other links (if there is an order service cluster) to perform [create order Service] (Phase 2). At this time, the execution of the service which was still in timeout (phase 1) is completed, and the service of phase 2 is also completed, then two pieces of the same order data will appear. How should this situation be handled?
< hr > the solution I have in mind:
1. Remove the retry mechanism provided by dubbo and let the dubbo service layer throw an exception if it times out, then there will be no data inconsistency. But there is a question: whether all services that may have data duplication adopt this method, so what is the significance of the dubbo retry mechanism?.
2. Use idempotent operation to create a unique ID, in the caller. When the order is stored on the server side, it is found that the id already exists and the orm layer runs the error (if you judge whether it already exists in the program, there may be a time when the timeout service does not have insert), and then the same data will not be stored. But it still feels weird.
is there an elegant solution to this problem?