【kafka】partitionパーティションポリシー

クラスタ内で拡張するのに便利で、各パーティションはその存在する機械に適応するために調整することができ、1つのtopicはまた複数のパーティションから構成することができ、そのためクラスタ全体は任意のサイズのデータに適応することができる.
同時性を高めることができます.Partition単位で読み書きできるからです.
Producerが送信したデータをProducerRecordオブジェクトにカプセル化する必要があります.

ProducerRecord(String topic, Integer partition, K key, V value)

ProducerRecord(String topic, Integer partition, Long timestamp, K key, V value)

ProducerRecord(String topic, K key, V value)

ProducerRecord(String topic, V value)

パーティションポリシー:

(1)partitionが示されている場合は、示された値を直接partiton値とする.

(2)partition値が指定されていないがkeyがある場合、keyのhash値とtopicのpartition数とを取り残してpartition値を得る.

(3)partition値もkey値もない場合、1回目の呼び出し時にランダムに1つの整数(後にこの整数で呼び出すたびに自増)を生成し、この値をtopicで利用可能なpartitionの総数と余り取ってpartition値、すなわち一般的なround-robinアルゴリズムを得る.

ACKメカニズム（生産者データが失われないことを保証する）

生産者はbrokerにメッセージを送信します.brokerは生産者にこのメッセージが成功したかどうかを伝える必要があります.成功しなければ、生産者は再送のメカニズムを取ることもできる.
メッセージはPartitionに送信されるため、Partitionには複数のコピーが同時に存在します.レプリカは、メッセージをリアルタイムで同期する必要があります.
borkerはメッセージが成功したかどうかを判断し、メッセージが信頼できる落盤である.

半数以上のメッセージが同期を完了すると、ackが送信されます.遅延は低いが、新しいリーダーを選出する際、n台のノードの故障を許容するには、2 n+1個のコピー

が必要である.

すべてのコピーがメッセージ同期を完了してからackが送信されます.遅延は高いが、新しいリーダーを選出する際、n台ノードの故障を許容するには、n+1コピー

が必要である.
Kafkaが選択した第2のスキームは、遅延が高いが、ネットワーク遅延がKafkaに与える影響は小さく、Kafkaの各パーティションに大量のデータがあり、第1のスキームは大量のデータの冗長性をもたらす.

最適化方案：ISR

リーダーはデータを受け取り、すべてのfollowerがデータの同期を開始しますが、followerがあります.何らかの障害でリーダーと同期できない場合は、リーダーが同期が完了するまで待っていなければackを送信できません.この問題はどのように解決しますか.
リーダーは動的集合in-sync replica set(リーダーと同期を保つfollower集合)を維持した.パラメータreplica.lag.time.max.msは時間しきい値を設定し、followerが所定の時間に同期を完了しない場合、followerをこのセットから削除します.
一部のメッセージデータでは、信頼性は必要ありません.すなわち、生成者がackメカニズムを必要としない場合、データの信頼性を必要としない場合、kafkaはISRにおけるfollowerの全ての受信が成功するまで待つ必要がない、ackに戻る.したがってKafkaはユーザに3種類の信頼性レベルを提供し、ユーザは信頼性と遅延の要求に基づいてバランスをとる.
acksパラメータ構成:
0:(送信のみ)producerはbrokerのデータが落ちるのを待たずにackに戻り、brokerが故障した場合にデータが失われる可能性がある
1:(brokerデータドロップのみ保証)producerはbrokerのackを待っており、partitionのリーダードロップが成功するとfollower同期を待たずに直接ackに戻る
follower同期が成功する前にleaderが故障すると、データが失われます.
-1(all):(brokerとすべてのfollowerデータのドロップを保証する)producerはbrokerのackを待っていて、partitionのleaderとfollowerがすべてドロップに成功した後にackに戻ります.
しかしfollower同期が完了した後、brokerがackを送信する前にleaderに障害が発生すると、データが重複します.

メッセージべき乗等化

kafka0.11リリース前にメッセージのべき乗等性を解決するには、消費者ごとに手動でメッセージの重み付けを行う必要があります(redis、またはmysqlプライマリ・キーの特性を使用して、消費されたメッセージを格納できます).これもRocketMQのメッセージのべき乗等性の解決策です.
kafka0.11バージョン以降、borkerはべき乗等性をサポートしています.元の消費者側が手動で必要としていたデータborkerのオリジナルサポートに再生しました.
べき乗等性を有効にするには、Producerのパラメータのenableだけを使用します.idompotenceをtrueに設定すればいいです.
原理:べき乗等性をオンにしたProducerは初期化時にPIDが割り当てられ,同じPartitionへのメッセージにSequence Numberが付随する.一方、Broker側はキャッシュを行い、同じプライマリ・キーを持つメッセージがコミットされると、Brokerは1つだけ永続化されます.しかし、PIDの再起動は変化し、異なるパーティションにも異なるプライマリ・キーがあるため、brokerはメッセージのべき乗等性を解決し、パーティション間セッションのExactly Onceを保証することはできません.つまり生産者を再起動することはできません.そうでなければ重複メッセージが発生します