カフカの古典的なインタビューの質問.

オンライン問題のリバランス

クラスター構造の変更によるコンシューマーグループのリバランスのため、Kafka セット内のノード数が数百など多数の場合、リバランスに数分から数時間かかる場合があります。 Kafka の場合 TPS の影響が大きい

原因:

グループメンバー数の変更
購読トピック数の変更
トピックの変更にサブスクライブするパーティションの数

グループメンバーの崩壊とグループメンバーの自主的な脱退は、2 つの異なるシナリオです。メンバーはコーディネーターにクラッシュを積極的に通知しないため、コーディネーターはクラッシュを検出するために完全な session.timeout サイクル (ハートビートサイクル) を必要とする場合があり、これは必然的にコンシューマーラグを引き起こします。グループを離れることは積極的にリバランスを開始することであり、クラッシュすることは受動的にリバランスを開始することであると言えます。

解決：

加大超时时间 session.timout.ms=6s
加大心跳频率 heartbeat.interval.ms=2s
增长推送间隔 max.poll.interval.ms=t+1 minutes

ZooKeeper の役割

現在、Kafka は ZooKeeper を使用してクラスターメタデータ、メンバー管理、コントローラーの選択、およびその他の管理タスクを格納しています。その後、KIP-500 提案が完了すると、Kafka は ZooKeeper にまったく依存しなくなります。

メタデータを保存するということは、トピックパーティションのすべてのデータが ZooKeeper に保存され、他の "人" がそれとの整合性を維持する必要があることを意味します。
メンバー管理とは、ブローカーノードの登録、登録解除、および属性の変更を指します。
コントローラーの選択とは、トピックの削除、パラメーター構成などを含むがこれらに限定されないクラスターコントローラーの選択を指します。

一言で言えば: KIP-500 は、コミュニティが開発した Raft ベースのコンセンサスアルゴリズムを使用して、コントローラーの自己選択を実現します。

メタデータの保存も同様で、Raft アルゴリズムに基づく etcd が近年ますます認知されるようになってきました

重要なデータを保存するためにこれを使用するシステムがますます増えています。たとえば、 seckill システムでは、MQ を消費するサービスの数を制御するために、各ノードの情報を保存するためによく使用されます。一部の業務システムの構成データも、etcdを介して業務システムの各ノードにリアルタイムで同期されます. たとえば、seckill 管理バックグラウンドは etcd を使用して、seckill アクティビティの構成データを seckill API の各ノードに同期します。リアルタイムでサービス。

レプリカコピーの役割

外部の読み取りおよび書き込みサービスを提供し、クライアントの要求に応答できるのは、Kafka のリーダーコピーのみです。フォロワーコピーは、PULL 方式のみを使用してリーダーコピーのデータを受動的に同期し、リーダーコピーが配置されているブローカーがダウンした後はいつでもリーダーコピーを申請する準備ができています。

Kafka 2.4 以降、コミュニティは、フォロワーレプリカが構成パラメーターを介して制限付きの読み取りサービスを提供できるようにすることができます。
以前は、一貫性を確保するための主な手段はハイウォーターマークメカニズムでしたが、リーダーが継続的に変化するシナリオでは、ハイウォーターマークの値ではデータの一貫性を保証できませんでした。最高水準点の値。

読み書きの分離をサポートしないのはなぜですか?

Kafka 2.4 以降、Kafka は制限付きの読み取りと書き込みの分離を提供します。
シナリオは適用されません。読み取りと書き込みの分離は、読み取り負荷が高く、書き込み操作の頻度が比較的低いシナリオに適しています。
同期機構。Kafka は PULL メソッドを使用してフォロワー同期を実現し、レプリケーションの遅延は比較的大きくなります。

二重消費を防ぐ方法

コードレベルでは、消費ごとにオフセットを送信する必要があります。
Redis と組み合わせてMysql の一意のキー制約を使用して、 id が消費されているかどうかを確認することで、set メソッドを直接使用して Redis を保存できます。
量が多く誤判断が許される場合はブルームフィルターも利用可能

データが失われないようにする方法

プロデューサーのプロダクションメッセージは、構成確認ack=allによって解決できます。
ブローカー同期中のリーダーのダウンタイムは、ISR コピー + 再試行を構成することで解決できます
コンシューマーが失われた場合、オフセットを自動的に提出する機能をオフにして、システムが処理を完了したときにオフセットを提出することができます

順次消費を保証する方法

単一トピック、単一パーティション、単一コンシューマー、単一スレッド消費、低スループット、非推奨
単一のキーが順番どおりであることのみを確認する必要がある場合は、キーごとに個別のメモリキューを申請し、各スレッドがそれぞれメモリキューを消費して、単一のキー (ユーザー ID、アクティビティ ID など) の順序が正しくなるようにします。保証することができます。

####【オンライン】消費の滞りを解消する方法

コンシューマを修理して消費できるようにし、N 個のユニットの容量を拡張します。
トピックを一時トピックに均等に配布する配布プログラムを作成する
N セットのコンシューマーを同時に開始して、さまざまな一時トピックを消費する

メッセージバックログを回避する方法

消費の並列処理を増やす
バルク消費
コンポーネント IO の相互作用の数を減らす
優先消費

if (maxOffset - curOffset > 100000) {
    
    
  // TODO 消息堆积情况的优先处理逻辑
  // 未处理的消息可以选择丢弃或者打日志
  return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
}
// TODO 正常消费过程
return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;

作者：我是hope啊
链接：https://juejin.cn/post/7062892826241007646
来源：稀土掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

メッセージキューを設計する方法

迅速な水平拡張、ブローカー + パーティション、および異なるマシンでのパーティションをサポートする必要がある. マシンを追加すると、トピックに従ってデータが移行される. 分散は、一貫性、可用性、およびパーティションの耐障害性を考慮する必要がある.

一貫性:プロデューサーのメッセージ確認、コンシューマーの冪等性、ブローカーのデータ同期
可用性:データが失われたり繰り返されたりしないようにする方法、データを永続化する方法、および永続化する際の読み取りと書き込みの方法
パーティションのフォールトトレランス:使用する選択メカニズムと複数のコピーを同期する方法
大量のデータ:メッセージのバックログと大量のトピックのパフォーマンス低下を解決する方法

パフォーマンスの面では、タイムホイール、ゼロコピー、IO 多重化、順次読み書き、および圧縮バッチ処理から学ぶことができます。