1. メッセージの損失を防ぐ方法
プロデューサーレベルでは、ackパラメータ確認メカニズムがあります。
-1 に設定すると、リーダーはすべてのレプリカが同期された後にのみ ACK を送信します。これにより、リーダーとレプリカの 1 つだけが生き残ることができます。
メッセージが失われないようにする
消費者：
自動送信を手動送信に変更する
2. 繰り返し摂取を防ぐ方法
メッセージ損失を防ぐソリューションでは、メッセージの送信後にネットワーク ジッターが原因でプロデューサーが ACK を受信しなかった場合、ブローカーは実際にはそれを受信しています。このとき、プロデューサーは再試行するため、ブローカーは複数の同一のメッセージを受信し、コンシューマーによる繰り返しの消費が発生します。
対処方法:
プロデューサーは閉じて再試行します。メッセージ損失が発生します (非推奨)
コンシューマーは非冪等消費の問題を解決します。
-冪等性と呼ばれる: 複数のアクセスの結果は同じです。 REST リクエストの場合 (get (冪等)、post (非冪等
など)、put (冪等)、delete (冪等))
ソリューション:
1. データベースに結合主キーを作成し、同じ主キーによって複数のレコードが作成されないようにします。
ユーザーの注文を処理する必要がある注文システムを備えた電子商取引プラットフォームがあるとします。このビジネス シナリオでは、共同主キーを使用して繰り返しの使用を避けることができます。
注文システムの注文データがデータベース テーブルに保存されているとします。テーブル構造には、注文 ID、ユーザー ID、製品 ID、注文ステータスなどのフィールドが含まれています。
注文システムは、在庫システムや物流システムなどのメッセージ キューを介して処理するために、注文データを他のシステムに送信します。注文システムが在庫システムに注文メッセージを送信する際、ネットワークのジッターなどの理由でメッセージの送信に失敗する場合があり、この場合、注文システムは再試行します。
ただし、特定の理由 (ネットワーク遅延、再試行メカニズムの設計など) により、再試行プロセスにより同じ注文メッセージが在庫システムに繰り返し送信される場合があります。二重消費を防ぐ方法がないと、在庫システムが同じ注文を複数回処理する可能性があり、在庫エラーやその他の問題が発生する可能性があります。
この問題を解決するには、注文データ テーブルに注文 ID、ユーザー ID、製品 ID で構成される共同主キーを作成します。このようにして、注文システムが新しい注文を受け取ると、まず同じ結合主キーを持つレコードがデータベース内にすでに存在するかどうかを確認します。
重複レコードがある場合、注文システムは注文メッセージがすでに処理されていると判断し、重複メッセージの処理をスキップすることを選択できます。重複するレコードがない場合は、注文データがデータベースに挿入され、メッセージが処理のために在庫システムに送信されます。
共同主キーを使用することで、注文システムでの重複消費の問題を確実に防止できます。注文システムが再試行する場合でも、在庫システムは初めて受け取った注文メッセージのみを処理し、繰り返しの消費によって引き起こされる問題を回避します。
2. 分散ロックを使用し、ビジネス ID をロックとして使用します。正常に作成できるレコードが 1 つだけであることを確認する
ユーザーがさまざまなアクティビティに登録できるオンライン イベント登録システムがあるとします。このビジネス シナリオでは、分散ロックを使用して、同じユーザーが 1 つのイベントにのみ正常に登録できるようにすることができます。
イベント登録システムの登録レコードがデータベース テーブルに保存されているとします。テーブル構造には、登録 ID、ユーザー ID、アクティビティ ID、登録ステータスなどのフィールドが含まれています。
ユーザーがイベントに登録しようとすると、システムは次のことを行う必要があります。
- ユーザーがイベントに登録しているかどうかを確認します。
- ユーザーがすでにイベントに登録している場合は、ユーザーが再度登録できないように、対応するプロンプトが返されます。
- ユーザーがイベントに登録していない場合は、登録情報がデータベースに挿入され、登録プロセスが完了します。
このシナリオでは、分散ロックを使用して、同じユーザーが 1 つのイベントにのみ正常に登録できるようにすることができます。ユーザー ID をロックのキーとして使用します。ユーザーがイベントに登録しようとすると、まずユーザーのロックを取得しようとします。
ロックが取得された場合は、ユーザーがイベントに登録していないことを意味し、登録操作を続行して分散ロックにユーザー ID をロックの値として保存できます。
ロックを取得できない場合は、ユーザーがすでにイベントに登録していることを意味し、ユーザーが再度登録できないように、対応するプロンプトをユーザーに返すことができます。
3. メッセージの連続消費を実現する方法
- プロデューサー: メッセージが順番に消費され、メッセージが失われないことを確認します。同期送信を使用し、ack を 0 以外の値に設定します。
- コンシューマ: トピックは 1 つのパーティションのみを設定でき、コンシューマ グループには 1 つのコンシューマのみが存在できます。
パフォーマンスが犠牲になるため、kafka を連続して使用する使用シナリオはあまり多くありませんが、たとえば、rocketmqこの分野では特殊な機能が設計されています。
4. メッセージ バックログの問題を解決する方法
4.1 メッセージバックログ問題の出現
メッセージ コンシューマーの消費速度は、プロデューサーのメッセージ生成速度よりもはるかに遅いため、Kafka には大量のデータが消費されません。未使用のデータが蓄積されると、コンシューマ アドレッシングのパフォーマンスがますます低下し、最終的には Kafka が提供する外部サービス全体のパフォーマンスの低下につながり、その結果、他のサービスへのアクセスが遅くなり、サービス雪崩が発生します。
4.2 メッセージバックログの解決策
このコンシューマーでは、マルチスレッドを使用してマシンのパフォーマンスを最大限に活用してメッセージを消費します。
ビジネス アーキテクチャ設計を通じて、ビジネス レベルの消費のパフォーマンスを向上させます。
複数のコンシューマ グループと複数のコンシューマを作成し、それらを他のマシンに展開して一緒に消費し、コンシューマの消費速度を高めます。
コンシューマを作成する それ以外の場合は、 Consumer は、複数のパーティションを含む別のトピックを Kafka に作成し、複数のコンシューマを含む複数のパーティションを作成します。コンシューマは、ポーリングされたメッセージを消費せずに、新しく作成されたトピックに直接転送します。この時点で、新しい トピックの複数のパーティションの複数のコンシューマが一緒にコンシューマを開始します。 —— 一般的には使用されません
5.遅延キューの効果を理解する
5.1 アプリケーションシナリオ
注文の作成後、30 分以上支払いがない場合、注文をキャンセルする必要がありますが、このシナリオは遅延キューによって実現できます。
5.2 具体的な計画
kafka で対応するトピックを作成する
コンシューマはトピックのメッセージを消費します (ポーリング)
コンシューマは消費時にメッセージの作成を決定しますメッセージ 時間と現在時間が 30 分を超えているかどうか (注文が支払われていない場合)
はいの場合: データベース内の注文ステータスをキャンセルに変更します。
「いいえ」の場合: 現在のメッセージのオフセットを記録し、後続のメッセージの使用を停止します。 1分待った後、再度Kafkaからオフセットとそれ以降のメッセージを引っ張ってきて、引き続き判定を行い、これを繰り返します。