36

シナリオ: プロデューサーからコンシューマーへの伝搬遅延を小さくしたい低ボリュームのトピック (~150 メッセージ/秒) があります。

プロデューサーからのタイム スタンプを追加し、それをコンシューマーで読み取って伝播遅延を記録しました。デフォルトの構成では、メッセージ (20 バイト) は 1960 ミリ秒から 1230 ミリ秒の伝播遅延を示しました。同じマシンで 1 つのプロデューサーと 1 つの単純なコンシューマーを試したので、ネットワークの遅延は発生しませんでした。

トピックのフラッシュ間隔を 20 ミリ秒に調整しようとすると、1100 ミリ秒から 980 ミリ秒に低下します。次に、消費者"fetcher.backoff.ms"を10msに調整してみました.1070ms - 860msに落ちました。

問題: 20 バイトのメッセージの場合、伝播遅延をできるだけ低くしたいと考えており、~950 ミリ秒はより高い数字です。

質問: 構成で見逃しているものはありますか? 私はコメントを歓迎します。あなたが得た遅延は最小限です。

仮定: Kafka システムには、コンシューマがプロデューサからメッセージを取得する前にディスク I/O が含まれており、これはハードディスクの RPM などに関連しています。

更新:耐久性と待ち時間のためにログ フラッシュ ポリシーを調整しようとしました。
構成は次のとおりです。

# The number of messages to accept before forcing a flush of data to disk
log.flush.interval=10
# The maximum amount of time a message can sit in a log before we force a flush
log.default.flush.interval.ms=100
# The interval (in ms) at which logs are checked to see if they need to be 
# flushed to disk.
log.default.flush.scheduler.interval.ms=100

同じ 20 バイトのメッセージの場合、遅延は 740 ミリ秒から 880 ミリ秒でした。

次のステートメントは、構成自体で明確にされています。
いくつかの重要なトレードオフがあります。

  1. 耐久性: フラッシュされていないデータは、クラッシュが発生した場合に失われるリスクが高くなります。
  2. Latency : データは、フラッシュされるまで消費者に提供されません (これによりレイテンシが追加されます)。
  3. スループット: 一般に、フラッシュは最もコストのかかる操作です。

したがって、150ms ～ 250ms のマークに到達する方法はないと思います。(ハードウェアのアップグレードなし) .

4

5 に答える 5

47

私は質問をかわそうとしているわけではありませんが、このユースケースにはkafkaは適していないと思います。Kafka は素晴らしいと思いますが (職場での使用を強く支持してきました)、その強みは低レイテンシーではありません。その強みは、高いプロデューサ スループットと、高速および低速コンシューマの両方のサポートです。耐久性と耐障害性を提供​​しますが、rabbitMQ のようなより汎用的なシステムも提供します。RabbitMQ は、node.js を含むさまざまなクライアントもサポートしています。Kafka と比較して rabbitMQ が不足するのは、非常に大量のメッセージ (150K msg/s など) を処理する場合です。その時点で、Rabbit の耐久性へのアプローチは崩壊し始め、Kafka は本当に際立っています。Rabbit の耐久性とフォールト トレランス機能は、20K msg/s を超えています (私の経験では)。

また、このような高いスループットを実現するために、Kafka はメッセージをバッチ処理します。バッチは小さく、そのサイズは構成可能ですが、多くのオーバーヘッドを発生させずに小さくしすぎることはできません。残念ながら、メッセージのバッチ処理は低レイテンシーを非常に困難にします。Kafka でさまざまな設定を調整できますが、待機時間を常に 1 ～ 2 秒未満にする必要がある場合は、Kafka を使用しません。

また、新しいアプリケーションを起動する場合、Kafka 0.7.2 は適切な選択ではありません。現在はすべて 0.8 に焦点を当てているため、問題が発生した場合は自分で対処する必要があり、新しい機能は期待できません。今後の安定版リリースについては、こちらのリンクをたどってください。安定版 Kafka リリース

繰り返しになりますが、Kafka は、一般的ではあるものの非常に特殊なユース ケースに最適だと思います。私の職場では、Rabbit と Kafka の両方を使用しています。それは無償のように思えるかもしれませんが、実際には無料です。

于 2013-12-14T16:26:56.637 に答える
23

この質問が出されてから 1 年以上が経過していることは承知していますが、開発目的で Kafka クラスターを構築したばかりで、プロデューサーからコンシューマーまでのレイテンシーが 1 ミリ秒未満であることがわかりました。私のクラスターは、SAN ストレージを備えたクラウド VM サービス (Skytap) で実行されている 3 つの VM ノードで構成されているため、理想的なハードウェアとはほど遠いものです。私は Kafka 0.9.0.0 を使用しています。これは、質問者が古いものを使用していたと確信できるほど新しいものです。私は古いバージョンの経験がないので、アップグレードするだけでこのパフォーマンスの向上が得られるかもしれません.

私が作成した Java プロデューサーとコンシューマーを実行して、レイテンシーを測定しています。どちらも、同じ Skytap 環境内の 4 番目の VM で同じマシン上で実行されます (ネットワーク レイテンシを最小限に抑えるため)。プロデューサは現在の時刻を記録し ( System.nanoTime())、その値を Avro メッセージのペイロードとして使用して、送信します (acks=1)。コンシューマーは、1 ミリ秒のタイムアウトで継続的にポーリングするように構成されています。メッセージのバッチを受信すると、現在の時刻を記録し (System.nanoTime()再度)、送信時刻から受信時刻を差し引いて待ち時間を計算します。100 件のメッセージがある場合、100 件すべての待ち時間の平均を計算し、stdout に出力します。レイテンシ計算でクロック同期の問題が発生しないように、プロデューサーとコンシューマーを同じマシンで実行することが重要であることに注意してください。

私は、プロデューサーによって生成されたメッセージの量でかなり遊んできました。数が多すぎて遅延が増加し始めるポイントは確かにありますが、150/秒を大幅に上回っています。時折のメッセージの配信には 20 ミリ秒ほどかかりますが、大多数は 0.5 ミリ秒から 1.5 ミリ秒の間です。

これらはすべて、Kafka 0.9 のデフォルト構成で実現されました。微調整する必要はありませんでした。最初のテストでは batch-size=1 を使用しましたが、後で低ボリュームでは効果がなく、レイテンシが増加し始める前にピーク ボリュームに大幅な制限を課すことがわかりました。

ローカル マシンでプロデューサーとコンシューマーを実行すると、まったく同じ設定で 100 ミリ秒の範囲のメッセージ レイテンシが報告されることに注意することが重要です。単に Kafka ブローカーに ping を実行した場合とまったく同じレイテンシが報告されます。

プロデューサーとコンシューマーからのサンプル コードとその他の詳細を使用して、このメッセージを後で編集しますが、忘れる前に何かを投稿したかったのです。

編集、4年後：

私はこれに賛成票を投じたばかりだったので、戻ってきて再読しました。残念ながら (実際には幸いなことに)、私はもうその会社で働いておらず、共有すると約束したコードにアクセスできなくなりました。Kafka も 0.9 以降、いくつかのバージョンが成熟しています。

その後の時間で学んだもう 1 つのことは、トラフィックがあまりないときに Kafka のレイテンシが増加することです。これは、クライアントがバッチ処理とスレッド処理を使用してメッセージを集約する方法によるものです。メッセージの連続ストリームがある場合は非常に高速ですが、「沈黙」の瞬間があると、次のメッセージはストリームを再び動かすためのコストを支払う必要があります。

私が Kafka のチューニングに深く関わってから数年が経ちました。最新バージョン (2.5 -- プロデューサー構成ドキュメントはこちら) を見ると、それらがゼロになっていることがわかりますlinger.ms(メッセージを送信する前にプロデューサーが待機する時間は、複数のメッセージをバッチ処理することを期待しています)。デフォルトでは、再び移動するための前述のコストは問題にならないことを意味します。私が思い出したように、0.9 ではデフォルトでゼロにならず、このような低い値に設定することにはトレードオフがありました。プロデューサ コードは、そのトレードオフを排除するか、少なくとも最小限に抑えるように変更されていると思います。

于 2016-01-25T14:46:20.987 に答える
8

ここからの結果が示すように、Kafka の最新バージョンのレイテンシは非常に最小限に抑えられているようです。

2 ミリ秒 (中央値) 3 ミリ秒 (99 パーセンタイル) 14 ミリ秒 (99.9 パーセンタイル)

于 2016-01-28T20:11:11.677 に答える