分散システムでは、強い一貫性を達成することは容易ではありません。でも2PCは、3PCフェーズ・コミット、強い一貫性を保証することはできません。
私たちは、理由は矛盾非常に小さい確率で、システム全体のパフォーマンス、拡張性や影響を受けたの低下につながることができず、アーキテクチャが非常に複雑になります。そのため、2PC / 3PCで結果整合性は、使用の多くを得るために、業界でより良い解決策である、大規模なアプリケーションの不在に提出。
再試行メカニズム
以下に示すように、サービス消費者を同時に呼び出し、サービスAサービスBの呼び出しが成功した場合、サービスA、サービスBの呼識別は、最終的な一貫性を確保するために、最も簡単な方法は、再試行です。
再試行、長い待ち時間やスタック、枯渇資源を避け、タイムアウトサービスの消費者を設定するために注意を払います。
ときに消費者の再試行、以下の点に注意する必要があります。
タイムアウト時間、
リトライ回数、
間隔リトライ;
リトライ減衰時間間隔、
特定の実装の詳細は、「エレガントな春tryerベースの再試行戦略」を参照してください。
第二に、ローカルログ記録
ローカルログインすることで、その後、ツールの定期検査を開始し、分散制御システム、またはその他のバックエンドシステムを集めます。実際の状況によると、手動で選択することができます。
ログ形式：たTranID-AB-詳細
トランザクションIDとしてTRANSID、あなたは乱数列を生成することができます。
詳細は、コンテンツデータを詳細に、
呼び出しが成功すると、Aの成功を記録し、
通話がB、または失敗を失敗した場合などは、記録されていない、すなわち何のログB成功はありません、リコールB;
定期的に検出し、処理ログ。
識別ログ収集の設計は、下図のように。
第三に、信頼性の高いメッセージングモデル
失敗の確率が比較的低い実際のビジネスシナリオで考慮に入れては、以下のスキームを検討してください。
サービスコンシューマーサービスBは、コール、最初の再試行に失敗しました。再試行の特定の数が失敗した場合、メッセージが直接送信されるメッセージキューは、非同期処理に変換されます。
そのようなカフカ、非同期処理のためにRocketMQ他のオープンソース分散メッセージシステムとして、比較的強いMQに分配されてもよいです。
サービスBは、アセンブリの取り扱い専用の集積エラーもメッセージMQから収集補償を継続することができます。
他の凹凸サービス成分を含む別個の構成要素、またはプロセスエラー、独立補償処理MQメッセージ。
このアプローチはまた、サービスの消費者は、これは小さな確率のイベントです、ハングアップニュースに発行されていない、失われたメッセージの危険性があります。
別の実施形態 - 信頼性のあるメッセージモード、図に示すように。RocketMQ、カフカなど、サービス消費者メッセージキューブローカにメッセージを送信します。消費者のニュースによってサービスAおよびサービスB。
メッセージはMQによって失われないようにMQ MQは、MQ信頼性確保、使用することができ、分散、および永続することができます。
信頼性の高いメッセージスキーマの利点：
スループット強化、
いくつかのシナリオでは、応答時間が短縮されます。
問題：
存在不一致的时间窗口（业务数据进入了MQ，但是没有进入DB，导致一些场景读不到业务数据）；
增加了架构的复杂度；
消费者（Service A/B）需要保证幂等性；
针对上述不一致的时间窗口问题，可以进一步优化。
将业务分为：核心业务和从属业务
核心业务服务 - 直接调用；
从属业务服务 - 从MQ 消费消息；
直接调用订单服务（核心服务），将业务订单数据落地DB；同时，发送向MQ 发送消息。
考虑到在向MQ 发送消息之前，Service Consumer（创建订单）可以会挂掉，也就是说调用订单服务和发送Message 必须在一个事务中，因为处理分布式事务比较麻烦，且影响性能。
因此，创建了另外一张表：事件表，和订单表在同一个数据库中，可以添加事务保护，把分布式事务变成单数据库事务。
整个流程如下：
（1）创建订单 - 持久化业务订单数据，并在事件表中插入一条事件记录。注意，这里在一个事务中完成，可以保证一致性。如果失败了，无须关心业务服务的回退，如果成功则继续。
（2）发送消息 - 发送订单消息到消息队列。
如果发送消息失败，则进行重试，如果重试成功之前，挂掉了，则由补偿服务去重新发送消息（小概率事件）。
补偿服务会不断地轮询事件表，找出异常的事件进行补偿消息发送，如果成功则忽略。
如果发送消息成功，或者补偿服务发送消息成功，则可以考虑删除事件表中的事件信息记录（逻辑删除）。
（3）消费消息 - 其他从属业务服务，则可以消费MQ中的订单消息，进行自身业务逻辑的处理。
上述设计方案中，有3点需要说明一下：
（1）直接调用订单服务（核心业务），是为了让业务订单数据尽快落地，避免不一致的时间窗口问题，保证写后读一致性。
（2）事業の受注がMQに直接メッセージを送って作成し、それは、実時間を長くするだけで、異常事態、補償サービスの使用のみです。少ないリアルタイムを要求した場合、それは論理的なメッセージを直接削除送っ考慮することができます。
（3）追加のイベントテーブルの導入は、単一の分散トランザクション・データベース・トランザクションになるために、ある程度、また、データベースへの圧力を増加させました。
上記の私を修正するために歓迎を共有するために私自身の考えのいくつかは、ある、関心の波を見つける方法は、パートナーシップのアイデアは、コメントやプライベートの手紙できるIああ〜
