質問1：どのようにメッセージが失われることはありません
どのようにメッセージングミドルウェア100％のメッセージ配信の成功を保護するには？構成でカフカACKパラメータによって達成することができます。
- パラメータ0：まだbeoker戻り、原因のデータの損失を書かれていない場合プロデューサーは、ACKを待ちません。
- パラメータ1：首尾よく成功した同期のフォロワーを待たずに、書かれた後の戻りACKリーダー。
- -1パラメータ：コロニーfolleowerすべての待機中のディスクが正常に戻った後。
ACKメカニズムは、メッセージは以下の理由により、失われていない100％を保証するものではありません。
我々は、すべてのプロデューサにメッセージを送信する場合、すべてのMQは、ディスクに保存した後、コールバックACKまたはNACKを開始します。毎回メッセージがディスクに永続化されているので、このケースでは、MQスループットが非常に高いではありません。ディスクに書き込まれるこのアクションは非常に遅いです。シナリオは許容されない。この高い同時実行では、スループットが低すぎます。
MQの永続性は、実際のディスクを達成するので、非同期呼び出しによって処理され、彼のような特定のメカニズム、次のとおりです。数千のメッセージがあるまでは、待機時に1回のブラシディスク。むしろ、各メッセージ、ブラシディスクに比べ。
だから、かご確認ください非同期のメカニズムは、MQを磨いていないメモリ内のメッセージを確認するためにも機構が、これはまだ100％の保証はメッセージが失われないことができないにつながる、システムの高スループットを確保するために、実際にリスニングのメカニズムでありますディスクからディスクへのダウンには、と私は扱うことができませんでした。
ソリューション：先にスケジュールされたタスクの永続性+のニュース
プロセスの説明：
- メッセージを配信するために再注文サービスの生産に先立って、第一のメッセージはに永続化されるのRedis又はDB、お薦めのRedis、高性能。送信用のステータスメッセージ。
- メカニズムがメッセージを聞くかどうか確認が正常に送信されましたか？ACK成功のメッセージとして、削除のRedisをこのメッセージに。
- NACKメッセージもし失敗した場合、これは、サービス・メッセージの再送に応じて選択することができます。あなたはまた、彼らのビジネスによって決定されたメッセージを、削除することができます。
- ここでは、一定の時間間隔をプルする、またはサービスが成功メッセージACK注文を受けていないことを示すために、この状態でメッセージのステータスを送信するタイミングタスクを追加しました。
- 定期的なタスクは、メッセージの代償の配信を行います。MQコールバックがACK受信に成功した場合、この時間は、その後のRedisこのメッセージには、削除します。
質問2：どのようにメッセージを送る何の重複がないことを確認するには？
プロデューサ冪等を達成するために、カフカは、プロデューサID（すなわちPID）とシーケンス番号を導入しました。
- PID。初期化時におけるそれぞれの新しいプロデューサーがユニークなPIDが割り当てられます、PIDは、ユーザーには表示されません。
- シーケンスNumbler。（各PID、各プロデューサ<トピック、パーティション>数対応する、送信データについて単調に0シーケンスからの増加に
カフカは、その上に各プロデューサ冪等メッセージ内にそれを確認する必要があり、複数の生産者、同時にメッセージで結果が、カフカ、異なる生産者を識別するためのPIDの導入の全てであってもよいです。
カフカのために、電力および他の問題のメッセージを送信するプロデューサによって解決されます。すなわち、各メッセージを繰り返すかどうかを区別する必要があります。
各シーケンスNumbler、配列Numblerによって区別各メッセージのメッセージを追加することによってカフカ。パーティションへの各メッセージが対応は、異なるメッセージのパーティションは、繰り返すことが不可能発生しました。各パーティションに対応するすべてのシーケンスNumbler
より数ブローカよりシーケンス番号の一つがそれを受け入れるキャッシュ場合は、各メッセージを受信するために、この配列番号のキャッシュに格納されているブローカ端は、そうでない場合は破棄されます。これは、メッセージが提示繰り返しを実現することができます。しかし、全く同じ<トピック、パーティション>のためのセマンティクスたらそれだけで1つのプロデューサを確保します。プロデューサーは異なるpartionの冪等で話題を保証するものではありません。
