Kafkaが順次消費を保証する方法
送信側：
送信側は非同期で送信できないため、非同期送信の場合、メッセージの順序を保証する方法はありません。
ストレージ側：
（1）メッセージは分割できません。つまり、トピックは1つのキューのみを持つことができます。Kafkaではパーティションと呼ばれ、RocketMQではキューと呼ばれます。複数のキューがある場合、同じトピックのメッセージは複数のパーティションに分散され、順序は保証されません。
（2）キューが1つしかない場合でも、2番目の問題が発生します。マシンがハングアップした後、別のマシンに切り替えることはできますか？それが高可用性の問題です。
たとえば、現在のマシンがハングした場合でも、消費されていないメッセージがそこに残っています。この時点で別のマシンに切り替えると、可用性が保証されます。しかし、メッセージの順序がめちゃくちゃになりました。
非同期の複製ではなく同期の複製を確保するには、マシンを切断する前に、ハングしたマシンですべてのメッセージを消費し、メッセージの残りがないようにする必要があります。明らかに、これは難しいことです。
受信側：
受信側では、並列に消費することはできません。つまり、複数のスレッドまたは複数のクライアントが同じキューを消費することはできません。
重複や損失がないことを確認する方法
Kafkaメッセージは、プロダクション情報が失われず、繰り返し消費の問題が発生しないことを保証します
。1）同期モードを使用する場合、メッセージが安全に生成されることを保証する3つの状態があります。 、データは失われます。
2）メッセージが失われる可能性のある別のケースもあります。非同期モードを使用し、バッファーがいっぱいの場合、それが0に構成されていると（確認が受信されないときにバッファープールがいっぱいになると）、バッファープール内のメッセージが空になります。 ）、データはすぐに破棄されます。
データ生成中のデータ損失を回避する方法：
上記の2つの状況を回避できる限り、メッセージが失われないようにすることができます。
1）同期モードでは、確認メカニズムは-1に設定されます。つまり、メッセージはリーダーとすべてのコピーに書き込まれます。
2）また、非同期モードでは、メッセージが送信されたが確認応答が受信されなかった場合、バッファー・プールがいっぱいになり、ブロッキング・タイムアウト時間を制限しないように構成ファイルに設定されます。データが失われないようにブロックします。データの消費中、データの損失を回避する方法：Stormを使用する場合は、Stormのackfailメカニズムを有効にする必要があります。Stormを使用しない場合は、データが処理されたことを確認してからオフセット値を更新する必要があります。低レベルAPIでは、オフセット値を手動で制御する必要があります。