新しい同僚が Kafka を使い始めて震え上がる...

画像はBaotu.comより

RocketMQ、Kafka、Pulsar はすべて、現在業界で広く使用されているオープン ソースのメッセージ キュー (MQ) コンポーネントです。

著者は職場で MQ 選択に関連するコンテンツに遭遇し、「トランザクション メッセージ」の概念は MQ コンポーネントごとに異なる意味合いを持つことを知りました。

したがって、この記事では、これら 3 つのメッセージ キュー (MQ) のトランザクション メッセージ間の類似点と相違点を簡単に分析してみます。目的は、メッセージ キュー トランザクション メッセージの全体像を形成し、同様のビジネス ニーズを持つ学生に参考資料やリファレンスを提供することです。

メッセージキューの進化

メッセージ キュー (MQ) は、送信中にメッセージを保存するコンテナーまたはサービスを指します。これは、サーバーレスおよびマイクロサービス アーキテクチャに適した非同期のサービス間通信方式です。分散システムが高性能、高可用性、スケーラビリティなどの高度な効果を実現するための重要なコンポーネントです。

一般的な主流のメッセージ キューには、ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ、Pulsar などがあります。

社内にはTubeMQ、Ckafka、TDMQ、CMQ、CDMQ、Hippoなどがあります。

①カフカ

Apache Kafka は、Apache Software Foundation によって開発され、Scala で記述されたオープンソースのメッセージング システム プロジェクトです。

Kafka はもともと LinkedIn によって開発され、2011 年初頭にオープンソース化されました。2012 年 10 月に Apache Incubator を卒業しました。このプロジェクトの目標は、リアルタイム データを処理するための、統合された高スループット、低レイテンシのプラットフォームを提供することです。

Kafka は、分散型、パーティション化型、マルチレプリカのログ配信サービスです。独自の設計によりメッセージング システムの機能を提供します。

全体的なアーキテクチャ図は次のとおりです。

②ロケットMQ

Apache RocketMQ は、低レイテンシ、強力な一貫性、高いパフォーマンスと信頼性、テラスケールの容量、柔軟なスケーラビリティを備えた分散メッセージングおよびストリーミング プラットフォームです。これは Kafka の設計アイデアに基づいていますが、Kafka のコピーではありません。

全体的なアーキテクチャ図は次のとおりです。

③パルサー

Apache Pulsar は、Apache Software Foundation のトップレベル プロジェクトであり、次世代のクラウドネイティブ分散メッセージング プラットフォームです。

メッセージング、ストレージ、軽量機能コンピューティングを統合し、コンピューティングとストレージを分離したアーキテクチャ設計を採用し、マルチテナント、永続ストレージ、複数のコンピュータ ルームでの地域間データ レプリケーションをサポートし、強力な一貫性、高スループット、低レイテンシ、高スケーラビリティなどのストリーミング データ ストレージ特性を備えています。クラウドネイティブ時代のリアルタイム メッセージ ストリーム伝送、ストレージ、コンピューティングに最適なソリューションと見なされています。

全体的なアーキテクチャ図は次のとおりです。

背景

①取引とは何か？

トランザクション: すべての操作が正常に実行されるか失敗するかのいずれかになるプログラム実行単位です。

トランザクションには、ACID と呼ばれる 4 つの基本特性があります。

• 原子性: トランザクションは分割できない全体です。トランザクション内のすべての操作は、成功するか失敗するかのいずれかになります。
• 一貫性: トランザクションが実行される前と実行された後、データは状態間で一貫している必要があります (A が B に送金する場合、A がお金を差し引いても B が受け取らないということは起こりません)。
• 分離: 複数の同時トランザクションは互いに分離されており、相互に干渉することはできません。
• 耐久性: トランザクションが完了すると、データへの変更は永続的に保存され、ロールバックすることはできません。

分散トランザクション: 異なる分散システムの異なるノードに配置されたトランザクション参加者、トランザクション サポート サーバー、リソース サーバー、およびトランザクション マネージャーを指します。分散トランザクションは、分散システム内の異なるノード間のデータの一貫性を確保するためによく使用されます。

分散トランザクションには、一般的に次のソリューションがあります。

XA (2PC/3PC) : 最も代表的なものは、Oracle Tuxedo システムで提案された XA 分散トランザクション プロトコルです。 XA は、トランザクション マネージャーとローカル リソース マネージャーの 2 つの部分に大まかに分かれています。

ローカル リソース マネージャーは、多くの場合、データベースによって実装されます。たとえば、Oracle や DB2 などの商用データベースはすべて XA インターフェイスを実装しており、トランザクション マネージャーはグローバル スケジューラーとして各ローカル リソースの送信とロールバックを担当します。

XA プロトコルには通常、2 フェーズ コミット (2PC) と 3 フェーズ コミット (3PC) の 2 つの実装が含まれます。名前が示すように、2 フェーズ コミットには 2 つのコミット フェーズが含まれます。最初のフェーズは準備フェーズ (投票フェーズ) です。 2 番目のフェーズはコミット フェーズ (実行フェーズ) です。

実装プロセスは次のとおりです。

2 フェーズ コミットはアトミック操作を提供できるように見えますが、いくつか欠陥があります。 3 フェーズ コミット (3PC) は、2 フェーズ コミット (2PC) のアップグレードおよび最適化です。興味のある方はさらに詳しく知ることができます。ここでは詳細には触れません。

TCC (Try-Confirm-Cancel) : Try、Commit、Cancel の 3 つの命令の略語で、補償トランザクションとも呼ばれます。

論理モデルは XA 2 フェーズ コミットに似ており、トランザクション処理プロセスも似ていますが、2PC は DB レベルで適用されるのに対し、TCC はアプリケーション レベルの 2PC として理解できるため、実装するにはビジネス ロジックを記述する必要があります。

TCC の中心的な考え方は、「各操作に対して、対応する確認 (Try) と補償 (Cancel) を登録する必要がある」というものです。

メッセージ トランザクション: いわゆるメッセージ トランザクションは、メッセージ キューに基づく 2 フェーズ コミットであり、本質的にはメッセージ キューの特殊な使用法です。

ローカル トランザクションとメッセージ送信を分散トランザクションに組み合わせて、ローカル操作が成功し、外部メッセージが正常に送信されるか、または両方が失敗することを保証します。

メッセージ キューに基づく 2 フェーズ コミットは、高同時実行シナリオで、分散トランザクションをメッセージ トランザクション (システム A のローカル操作 + メッセージの送信) + システム B のローカル操作に分割するためによく使用されます。

システム B の動作はメッセージによって駆動されます。メッセージ トランザクションが成功する限り、操作 A は成功し、メッセージが送信される必要があります。

このとき、B はローカル操作を実行するためのメッセージを受信します。ローカル操作が失敗した場合、B の操作が成功するまでメッセージは再送信されます。これにより、A と B 間の分散トランザクションが偽装されて実装されます。

仕組みは次のとおりです。

上記のソリューションは A と B の操作を完了できますが、A と B は強く一貫性があるわけではなく、結果的に一貫性があります。これも BASE 理論の要件を満たしています。

拡張すると、BASE は、Basically Available、Soft state、Eventually Consistent の 3 つのフレーズの略語になります。

BASE 理論は、CAP における AP の拡張であり (CAP では、分散システムは CAP の 3 つの項目のうち最大 2 つしか同時に満たすことができないことが証明されています)、強力な一貫性を犠牲にして可用性を実現します。

障害が発生した場合、コア機能が利用可能であることを保証しながら、部分的な利用不可が許容されます。データは一定期間不整合になる可能性がありますが、最終的には一貫した状態になります。 BASE理論を満たすトランザクションを「柔軟なトランザクション」と呼びます。

②Exactly-once セマンティクスとは何ですか?

分散システムでは、どのノードでも異常が発生したり、クラッシュしたりする可能性があります。メッセージ キューでも同様です。プロデューサーがメッセージを生成しているときに、ブローカーがクラッシュして使用できなくなったり、ネットワークが突然切断されたりするなどの異常な状況が発生する可能性があります。

例外が発生したときにプロデューサーがメッセージを処理する方法に応じて、システムは次の 3 つのメッセージ セマンティクスを持つことができます。

少なくとも 1 回のセマンティクス: プロデューサーは、ブローカーから ACK (メッセージ確認) 通知を受信することによって、メッセージがトピックに正常に書き込まれたことを確認します。

ただし、プロデューサーが ACK 通知の受信時にタイムアウトになったり、ブローカーからエラー メッセージを受信したりすると、メッセージの再送信が試行されます。

ブローカーがトピックにメッセージを正常に書き込んだが、プロデューサーに ACK をまだ送信していないときにクラッシュすると、プロデューサーによって再送信されたメッセージがトピックに再度書き込まれ、最終的にメッセージがコンシューマーに繰り返し配信されることになります。つまり、メッセージは失われませんが、繰り返し送信される可能性があります。

最大 1 回のセマンティクス: プロデューサーが ACK タイムアウトを受信したとき、またはブローカー エラー メッセージを受信したときにメッセージを再送信しない場合、メッセージが失われ、トピックに書き込まれず、コンシューマーによって消費されない可能性があります。

シナリオによっては、重複した消費を避けるために、メッセージの損失を許容することができます。つまり、メッセージは失われる可能性がありますが、複製されることはありません。

正確に 1 回のセマンティクス: 正確に 1 回のセマンティクスにより、プロデューサーが同じメッセージをサーバーに複数回送信した場合でも、サーバーはそれを 1 回だけ記録します。

正確に 1 回のセマンティクスは最も信頼性が高いですが、理解するのが最も困難でもあります。正確に 1 回のセマンティクスでは、メッセージ キュー サーバー、メッセージ プロデューサー、およびコンシューマー アプリケーションの連携が必要です。

たとえば、コンシューマ アプリケーションがメッセージを正常に消費して ACK し、その後消費ポイントを以前のメッセージ ID にロールバックすると、そのメッセージ ID 以降のすべてのメッセージがコンシューマ アプリケーションによって再度消費されます。つまり、メッセージは失われたり、繰り返し送信されたりすることはありません。

RocketMQ、Kafka、Pulsar トランザクション メッセージ

①RocketMQトランザクションメッセージ

RocketMQ はバージョン 4.3.0 ですでに分散トランザクション メッセージをサポートしています。ここで、RocketMQ は 2PC の考え方を採用してトランザクション メッセージの送信を実装し、第 2 フェーズでタイムアウトまたは失敗したメッセージを処理するための補正ロジックを追加します。

プロセスを次の図に示します。

具体的なワークフローは、通常のトランザクション メッセージの送信と提出、および異常な状況下でのトランザクション メッセージの補償プロセスに分かれています。

• メッセージ キューでトランザクション トピックを開きます。
• トランザクションで実行される最初のサービスは、「セミメッセージ」 (セミメッセージと通常のメッセージの唯一の違いは、トランザクションがコミットされる前はメッセージがコンシューマーに表示されないことです) をメッセージ キューに送信します。
• セミメッセージが正常に送信された後、セミメッセージを送信したサービスはローカル トランザクションの実行を開始し、ローカル トランザクションの実行結果に基づいてトランザクション メッセージをコミットするかロールバックするかを決定します。
• ローカル トランザクションが成功すると、この「セミメッセージ」は、分散トランザクションの後続のステップで独自のローカル トランザクションを実行するための通常のメッセージに変換されます。

ここでのトランザクション メッセージの場合、コンシューマーが消費に失敗したためにプロデューサーがロールバックすることはありません。トランザクション メッセージを使用するアプリケーションは、高可用性と最終的な一貫性を追求します。メッセージの消費が失敗した場合、RocketMQ は消費が成功するまでメッセージを再プッシュする責任を負います。

補償プロセス: RocketMQ は、異常な状況を解決するためにトランザクションのバックチェックを提供します。 RocketMQ がコミットまたはロールバック要求を受信しない場合、ブローカーはプロデューサーのローカル トランザクションのステータスを定期的にチェックし、プロデューサーのローカル トランザクションのステータスに基づいて「半分のメッセージ」がコミットされるかロールバックされるかを処理します。

注目すべきは、独自のビジネス ロジックに従って逆クエリ ロジック インターフェイスを実装する必要があり、その後 Broker が戻り値に基づいてコミットするかロールバックするかを決定することです。

さらに、このリバース クエリ インターフェイスはステートレスである必要があり、どのプロデューサー ノードへの要求でも正しいデータが返されます。

補正プロセスは、メッセージのコミットまたはロールバックがタイムアウトしたり失敗したりする状況を解決するために使用されます。 RocketMQ トランザクション メッセージのメイン フローで、あるフェーズのメッセージがユーザーに表示されない仕組み。

その中で、通常のメッセージと比較したトランザクションメッセージの最大の特徴は、1 段階で送信されたメッセージがユーザーには見えないという点です。

では、ユーザーには見えないメッセージを作成するにはどうすればよいでしょうか? RocketMQ トランザクション メッセージの動作は次のとおりです。メッセージが「半分のメッセージ」の場合、元のメッセージのトピックとメッセージ消費キューをバックアップし、トピックを RMQ_SYS_TRANS_HALF_TOPIC に変更します。

コンシューマー グループがトピックをサブスクライブしていないため、コンシューマーは「半分のメッセージ」メッセージを消費できません。次に、RocketMQ は、トピック RMQ_SYS_TRANS_HALF_TOPIC からメッセージをプルして消費するためのスケジュールされたタスクを開始します。

プロデューサー グループに基づいてサービス プロバイダーを取得し、トランザクション ステータスのクエリ要求を送信し、トランザクション ステータスに基づいてメッセージをコミットするかロールバックするかを決定します。

この時点で、ここで話題になっているのは、前述の分散トランザクションにおけるメッセージトランザクションであることは誰もが理解していると思います。目的は、分散トランザクションにおけるシステムの最終的な一貫性を実現することです。

②Kafkaトランザクションメッセージ

RocketMQ のトランザクション メッセージングとは異なり、Kafka のトランザクションは基本的にそのべき等メカニズムと組み合わせて使用​​され、Exactly-once (上記参照) セマンティクスを実現します。

この機能を開発する理由は、次のようにまとめられます。

ストリーム処理の需要: ストリーム処理の増加に伴い、より強力な処理保証を備えたストリーム処理アプリケーションの需要も高まっています。

たとえば、金融業界では、金融機関はストリーム処理エンジンを使用して、ユーザーのローンやクレジットを処理します。このタイプのユースケースでは、各メッセージが例外なく 1 回だけ処理される必要があります。

つまり、ストリーム処理アプリケーションがメッセージ A を消費し、その結果をメッセージ B (B = f(A)) として生成する場合、正確に 1 回の処理保証は、B が正常に生成された場合にのみ A を消費済みとしてマークできることを意味し、その逆も同様です。

トランザクション API を使用すると、ストリーム処理アプリケーションは 1 つのアトミック操作でメッセージを消費、処理、生成できます。これは、トランザクション内のメッセージのバッチを、多数のトピック パーティションから受信、生成、確認できることを意味します。トランザクションに関係するすべての操作は、全体として成功するか失敗します。

現在、Kafka が提供するデフォルトの配信信頼性保証は、少なくとも 1 回です。メッセージが正常に「送信」されたが、ブローカーの応答がプロデューサーに正常に送り返されない場合 (たとえば、ネットワークに瞬間的なジッターがある場合)、プロデューサーはメッセージが実際に正常に送信されたかどうかを判断できません。

したがって、再試行することしか選択できないため、Kafka はデフォルトで少なくとも 1 回の保証を提供しますが、これによりメッセージが繰り返し送信されることになります。

ほとんどのユーザーは、メッセージが失われたり繰り返し処理されたりしないように、メッセージが 1 回だけ配信されることを望んでいます。

つまり、プロデューサーが同じメッセージを繰り返し送信した場合でも、ブローカーは自動的に重複を排除できます。

下流の消費者の観点から見ると、メッセージは依然として 1 つだけです。それで、問題は、Kafka が正確に 1 回を達成するにはどうすればよいかということです。

簡単に言えば、これは 2 つのメカニズムを通じて行われます。

• 冪等性
• 取引

べき等性プロデューサー: 「べき等性」という言葉はもともと数学の概念に由来しており、特定の操作または関数を複数回実行しても、そのたびに得られる結果は変わらないことを意味します。

べき等性には多くの利点がありますが、その最大の利点は、べき等性操作はシステム状態を破壊しないため、安全に再試行できることです。

非べき等操作の場合は、特定の操作を複数回実行することによる状態への影響について依然として考慮する必要がありますが、べき等操作の場合は、これについてまったく考慮する必要はありません。

Kafka では、プロデューサーはデフォルトではべき等ではありませんが、べき等なプロデューサーを作成できます。これは実際にはバージョン 0.11.0.0 で導入された新しい機能です。

enable.idempotence を true に設定すると、プロデューサーは自動的にべき等プロデューサーにアップグレードされ、他のすべてのコード ロジックを変更する必要はありません。

Kafka は自動的にメッセージの重複を排除するのに役立ちます。冪等性を実現するために、Kafka は基盤となる設計アーキテクチャに ProducerID と SequenceNumber を導入しています。

ProducerID: 新しい各プロデューサーが初期化されると、このセッションを識別するための一意の ProducerID が割り当てられます。

SequenceNumber: 各 ProducerID について、プロデューサーがデータを送信する各 Topic および Partition は、0 から単調に増加する SequenceNumber 値に対応します。

ブローカーはメモリ内に (pid, seq) マッピングを維持し、メッセージを受信した後に seq をチェックします。プロデューサーがクリア メッセージの ACK を失った場合、またはタイムアウト後に ACK を受信しなかった場合は、再試行する必要があります。

• new_seq=old_seq+1: 通常のメッセージ。
• new_seq<=old_seq: メッセージが重複しています。
• new_seq>old_seq+1: メッセージは失われます。

さらに、べき等性プロデューサーの範囲を理解する必要があります。まず、単一のパーティション上でのみべき等性を保証できます。つまり、べき等プロデューサーは、トピックのパーティション上に重複したメッセージが表示されないことを確認できますが、複数のパーティション上でべき等性を実現することはできません。

第二に、単一セッションでのみべき等性を実現でき、セッション間では実現できません。ここでのセッションは、プロデューサー プロセスの実行として理解できます。 Producer プロセスを再起動すると、このべき等性の保証は失われます。

複数のパーティションと複数のセッションでメッセージの重複をゼロにしたい場合はどうすればよいでしょうか?答えは、トランザクション、またはトランザクションプロデューサーに依存することです。これは、べき等プロデューサーとトランザクション プロデューサーの最大の違いでもあります。

トランザクション プロデューサー: メッセージが複数のパーティションにアトミックに書き込まれることを保証できます。すべてのメッセージが正常に書き込まれるか、またはすべてのメッセージが失敗します。

さらに、トランザクション プロデューサーはプロセスの再起動の影響を受けません。プロデューサーが再起動された後も、Kafka は送信されたメッセージの Exactly-once 処理を保証します。

通常の Producer コードと比較して、トランザクション Producer の注目すべき特徴は、いくつかのトランザクション API を呼び出すことです。

initTransaction、beginTransaction、commitTransaction、abortTransaction など、それぞれトランザクションの初期化、トランザクションの開始、トランザクションのコミット、トランザクションの終了に対応します。

Kafka トランザクション メッセージは、プロデューサー、トランザクション コーディネーター、ブローカー、グループ コーディネーター、コンシューマーなどの共同参加を通じて実装されます。

プロデューサー: プロデューサーに固定の TransactionalId を割り当てます。これにより、複数のプロデューサー セッション (プロデューサーの再起動/切断と再接続) にわたってプロデューサーの ID を継続的に識別できます。

各プロデューサーはエポックを増分します。トランザクション内の同じ TransactionalId のエポックを識別するために使用されます。トランザクションが初期化されるたびに増加し、サーバーがプロデューサー要求が古い要求であるかどうかを認識できるようにします。

エポックを使用してプロデューサーの各「再生」をマークすると、同じプロデューサーが複数のセッションを持つことを防ぐことができます。

プロデューサーは、べき等メッセージの動作に従い、送信された BatchRecord にトランザクション ID とエポックを追加します。

トランザクション コーディネーター: コンシューマー グループの負荷分散のコーディネーターに似たトランザクション コーディネーターを導入します。トランザクションを実装する各プロダクション エンドには、トランザクション コーディネーターが割り当てられます。メッセージのトランザクション送信は、2 フェーズ送信方式で実現されます。

トランザクション コーディネーターは、特別なトピック (トランザクション トピック) を使用します。トランザクション トピック自体も永続的です。ログ情報はトランザクションのステータス情報を記録し、トランザクション コーディネータによって書き込まれます。

トランザクション コーディネーターは、R​​PC 呼び出しを通じてブローカーとコンシューマーを調整し、トランザクションの 2 フェーズ コミットを実装します。

各ブローカーはトランザクション コーディネーターを起動し、hash(TransactionalId) を使用してプロデューサーに対応するトランザクション コーディネーターを決定し、クラスター全体の負荷を分散します。

ブローカー: 制御メッセージの導入: これらはクライアントによって生成され、トピックに書き込まれる特別なメッセージですが、コンシューマーには表示されません。これらは、ブローカーが、以前にプルされたメッセージがアトミックにコミットされたかどうかをコンシューマーに通知できるようにするために使用されます。

ブローカーは、トランザクションコーディネータのコミット/アボート制御メッセージを処理し、制御メッセージを通常のメッセージと同様にトピックに書き込み（図のcでマークされたメッセージは、トランザクションコミットのログオフセットを確認するために通常のメッセージと織り交ぜられています）、メッセージコミットオフセットhwを前方にプッシュします。

グループ コーディネーター: トランザクション中に消費オフセットがコミットされると、グループ コーディネーターはトランザクション消費オフセットをオフセット ログに書き込みます。トランザクションがコミットされると、トランザクション オフセット確認メッセージがオフセット ログに書き込まれます。

コンシューマー: コンシューマーはコミットされていないメッセージとトランザクション制御メッセージをフィルタリングし、これらのメッセージをユーザーに表示しないようにします。

これを実現するには 2 つの方法があります。

コンシューマー キャッシュ モード: isolation.level=read_uncommitted を設定します。この時点で、トピックのすべてのメッセージがコンシューマーに表示されます。

コンシューマーは、トランザクション制御メッセージを受信するまでこれらのメッセージをバッファリングします。トランザクションがコミットされると、これらのメッセージが公開されます。トランザクションが中止された場合、これらのメッセージは破棄されます。

ブローカーのフィルタリング方法: isolation.level=read_committed を設定します。現時点では、トピック内のコミットされていないメッセージはコンシューマーには表示されません。メッセージは、トランザクションが終了した後にのみコンシューマーに表示されます。

Broker が Consumer に送信する BatchRecord メッセージには、どのトランザクションが「中止」トランザクションであるかを示すリストが含まれます。コンシューマーは、中止トランザクションのメッセージを単純に破棄できます。

トランザクション メカニズムは、消費者が表示できるメッセージの範囲に影響するため、単純にハイ ウォーターマークに依存するわけではありません。

トランザクション コンシューマーの可視性を決定するために、LSO (Log Stable Offset) と呼ばれる変位値に依存します。

③Pulsar取引メッセージ

Apache Pulsar は 2.8.0 でトランザクション関連の機能を正式にサポートします。 Pulsar が提供するトランザクションは、RocketMQ の 2PC トランザクション実装とは異なります。ローカル トランザクション バックトラッキング メカニズムは存在しませんが、これは Kafka のトランザクション実装メカニズムに似ています。

Apache Pulsar のトランザクションは主に、Pulsar 関数などのストリーム コンピューティング シナリオで Exactly-once セマンティクスの実装を保証するために使用されます。

これは、エンドツーエンドのトランザクション実装のセマンティクスを保証するという Apache Pulsar のイベント ストリーミングの位置付けとも一致しています。

Pulsar では、トランザクション セマンティクスは次のように定義されています。イベント ストリーム アプリケーションは、メッセージの消費、処理、生成のプロセス全体をアトミック操作として定義できます。つまり、プロデューサーまたはコンシューマーは、複数のトピックとパーティションにまたがってメッセージを処理し、これらのメッセージが 1 つの単位として処理されるようにすることができます。

Pulsar トランザクションには次のセマンティクスがあります。

• トランザクション内のすべての操作は 1 つの単位としてコミットされます。すべてのメッセージが送信されるか、まったく送信されないかのいずれかです。
• 各メッセージは 1 回だけ書き込まれ、処理されるため、障害が発生した場合でもデータの損失や重複は発生しません。
• トランザクションが中止された場合、このトランザクション内のすべての書き込みとコミットはロールバックされます。

トランザクション内のバッチ メッセージは、複数のパーティションにわたって受信、生成、確認することができます。

• コンシューマーはコミットされた（確認された）メッセージのみを読み取ることができます。つまり、ブローカーは、オープントランザクションに属するトランザクション メッセージや中止されたトランザクションに属するメッセージを配信しません。
• 複数のパーティションにわたるメッセージの書き込みはアトミックです。
• 複数のサブスクリプションにわたるメッセージ確認はアトミックです。サブスクライブされたコンシューマーがトランザクション ID を使用してメッセージを確認する場合、メッセージは 1 回だけ正常に確認されます。

Pulsar トランザクション メッセージは、次の主要なポイントで構成されます。

トランザクション ID (TxnID) : Pulsar 内の一意のトランザクションを識別します。トランザクション ID の長さは 128 ビットです。上位 16 ビットはトランザクション コーディネーター ID 用に予約されており、残りのビットは各トランザクション コーディネーター内で単調に増加する番号として使用されます。

トランザクションコーディネーター (TC) : Pulsar Broker で実行されるモジュールです。トランザクションのライフサイクル全体を維持して、トランザクションがエラー状態になるのを防ぎます。トランザクション タイムアウトを処理し、トランザクション タイムアウト後にトランザクションが中止されるようにします。

トランザクション ログ: すべてのトランザクション メタデータはトランザクション ログに保存されます。トランザクション ログは Pulsar トピックによって記録されます。トランザクション コーディネーターがクラッシュした場合、トランザクション ログからトランザクション メタデータを回復できます。

トランザクション ログには、トランザクション内の実際のメッセージではなく、トランザクションの状態が格納されます (実際のメッセージは実際のトピック パーティションに格納されます)。

トランザクション キャッシュ: トランザクション内でトピック パーティションに生成されたメッセージは、そのトピック パーティションのトランザクション バッファー (TB) に格納されます。

トランザクション バッファ内のメッセージは、トランザクションがコミットされるまでコンシューマーには表示されません。トランザクションが中止されると、トランザクション バッファ内のメッセージは破棄されます。

トランザクション バッファは、進行中および中止されたすべてのトランザクションをメモリに格納します。すべてのメッセージは、実際にパーティション化された Pulsar トピックに送信されます。

トランザクションがコミットされると、トランザクション バッファー内のメッセージがコンシューマーに対して具体化 (表示) されます。トランザクションが中止されると、トランザクション バッファ内のメッセージは破棄されます。

保留中の確認状態: 保留中の確認状態では、トランザクションが完了するまで、トランザクション内のメッセージの確認が維持されます。メッセージが保留中の確認応答状態にある場合、メッセージが保留中の確認応答状態から削除されるまで、他のトランザクションはメッセージを確認応答できません。

保留中の確認のステータスは、保留中の確認ログ (カーソル台帳) に保存されます。新しく起動されたブローカーは、保留中の確認ログから状態を回復して、状態の確認が失われないようにすることができます。

処理フローは一般的に次のステップに分かれます。

• 取引を開きます。
• トランザクションを使用してメッセージを公開します。
• トランザクション確認メッセージを使用します。
• 取引を終了します。

Pulsar のトランザクション処理プロセスは、Kafka のトランザクション処理の考え方とほぼ一致しています。誰もが TC と、すべての TC 操作を永続化してトランザクション ステータスの変更のすべての要求を記録するための対応するトピックを持っています。

同様に、トランザクションの開始時には、TC に対応するオーナー ブローカーの場所を照会するための専用のトピックがあります。

違いは次のとおりです。

• Kafka では、未確認メッセージはブローカー側で管理されますが、Pulsar ではクライアント側で管理されます。トランザクション タイムアウトは、トランザクションが正常に実行されたかどうかを判断するために使用されます。したがって、トランザクション タイムアウトの存在により、クライアント側とブローカー側のトランザクション処理の一貫性が保証されます。
• Kafka 自体には単一のメッセージに対する Ack がないため、Kafka のトランザクション処理は順番にしか実行できません。トランザクション要求がブロックされると、後続のすべてのトランザクション要求がブロックされます。ただし、Pulsar はメッセージに対して単一の Ack を実行できるため、ここでの各トランザクションの Ack アクションは独立しており、トランザクションがブロックされることはありません。

結論は

RocketMQ と Kafka/Pulsar のトランザクション メッセージの実際のシナリオは異なります。

RocketMQ のトランザクションは、ローカル トランザクションの実行とメッセージの送信という 2 つの操作が成功するか失敗するかを保証するという問題を解決します。

さらに、RocketMQ では、トランザクション実行の成功率とデータの一貫性を最大化するために、トランザクション バックチェック メカニズムが追加されました。

Kafka のトランザクションは、トランザクションで送信された複数のメッセージが成功するか失敗するかを保証するという問題を解決します。

ここでの複数のメッセージは、必ずしも同じトピックとパーティション内にある必要はなく、複数のトピックとパーティションに送信されるメッセージにすることもできます。

もちろん、Kafka トランザクションの実行中にローカル トランザクションを開始して、RocketMQ トランザクション メッセージと同様の効果を実現することもできます。

ただし、Kafka にはトランザクション メッセージのバックチェック メカニズムがありません。直接例外をスローします。ユーザーは、例外に基づいて独自の再試行メソッドを実装し、トランザクションの正常な操作を確保できます。

これらに共通するのは、すべてが 2 フェーズ コミットを通じてトランザクションを実装し、トランザクション メッセージが別々のトピックに保存されることです。

違いは、RocketMQ は「セミメッセージ」を通じて実装されるのに対し、Kafka は対応するトピックにメッセージを直接送信し、クライアントを通じてフィルタリングすることです。

さらに、それらが使用されるシナリオは非常に異なります。 RockteMQ は主にローカル トランザクションとメッセージに基づいてデータの一貫性を解決しますが、Kafka のトランザクションはリアルタイム ストリーム コンピューティング シナリオに適用される Exactly-once メカニズムを実装するために使用されます。

Pulsar のトランザクション メッセージは Kafka のアプリケーション シナリオおよびセマンティクスに似ていますが、基盤となる実装メカニズムの違いにより、詳細が一部異なります。

今では非常に明確になっていると思います。トランザクション メッセージを選択して適用する方法については、まずビジネス ニーズを理解する必要があります。

分散トランザクションの最終的な一貫性を実現したいですか、それとも Exactly-once セマンティクスを実現したいですか?要件を理解すれば、どのコンポーネントを選択すればよいかが非常に明確になります。

著者: 劉若宇

紹介: WeChat 決済バックエンド開発エンジニア。北京大学で修士号を取得。彼は、テンセントWXG海外決済チームの複数の重要な事業の研究開発に深く関わっており、バックグラウンド開発の豊富な経験を持っています。テンセントの技術共有の専門家であり、ソーシャルリクルートメントの人材スカウト。

編集者：タオ・ジアロン

出典：公開アカウントYunjia Community（ID：QcloudCommunity）から転載