まず第一に、Alibaba のオープンソース メッセージ ミドルウェアである RocketMQ は、もともと MetaQ と呼ばれていました。ドキュメントには、プロデューサー、コンシューマー、ブローカーを含む RocketMQ のすべての側面が分散されているため、分散トランザクションをサポートしていると記載されています。ネットワーク上の理由で失われることは保証されていますが、プロジェクトではこの機能を使用しませんでした。また、RocketMQ には繰り返し消費の問題があるため、ドキュメントでは冪等性をビジネス側が独自に実装する必要があることが明確に示されています。 >

さらに、冪等性には実際にはほとんど影響がありません。同じシナリオで、システムがすべて統合されている場合でも、冪等性が達成されない場合は、どうすればよいでしょうか? 分散シナリオでは、さらに多くのリクエストが発生します。
そして冪等性はトークンを発行することで実現できます (実際に多くの記事が紹介されています)

まず第一に、このシナリオは分散トランザクションとは何の関係もありません。
次に、サービスの冪等性については、シナリオに応じてさまざまな方法で保証できます。サーバー側で、この requestID を検証するために、単純なメソッドを使用するなどの方法があります。 redis 分散ロックまたはその他の分散ロックの冪等性を検証できます

失敗時の再試行が含まれるため、プロバイダのインターフェースは冪等である必要があります。ただし、在庫控除などのインターフェースは冪等性を実現することが難しいため、失敗したインターフェースでは失敗した再試行を閉じることをお勧めします。
質問者のこのシナリオの主な理由は、呼び出し元がタイムアウトで失敗し、ロールバックしなかったことですamount。私の推測が正しければ、これは RPC 呼び出しであるはずなので、質問者は本当に分散トランザクションを必要としています詳細については、TCC を使用することも解決策です