17

1日に数ギガバイトのメッセージを処理する必要がある本番環境のアプリケーションがあります。私はKafkaのアーキテクチャとパフォーマンスがとても好きです。それは私のニーズに完全に適合します。

いつかメッセージングレイヤーをKafkaに置き換えたいと思います。0.7.1バージョンは、パフォーマンスの安定性と一貫性の観点から、本番環境での使用に十分ですか？

4

4 に答える 4

13

作成された（そして後にオープンソース化された）LinkedInやTumblrなど、すでにいくつかのビッグデータ企業で確実に使用されています。Tumblrだけで、1日あたり数ギガバイトのメッセージを処理します。LinkedInもそこまで進んでいると思います。あなたはここで現在それを使用していることが知られている会社のリストを見ることができます：

https://cwiki.apache.org/confluence/display/KAFKA/Powered+By

また、必ずメーリングリストに登録してください。多くの人が積極的に試して本番環境で使用しています。

私はそれがあなたがそれに投げることができるどんなボリュームでも扱うことができると確信しています。

于 2012-10-06T23:09:07.500 に答える
10

Kafkaが生産の準備が整う前に欠けていると思う重要な機能が1つあります。

「プロデューサーがKafkaブローカーに連絡できない場合にメッセージをディスクにフラッシュする」この問題はかなり前にここに提出されています： https ：//issues.apache.org/jira/browse/KAFKA-156

この機能により、プロデューサーが常にイベントを送信できる必要がある一部のユースケースでは、完全なKafkaイベントパイプラインがさらに堅牢になります。たとえば、ページビューやいいねボタンのクリックを追跡していて、すべてのKafkaブローカーに到達できない場合でも、イベントを見逃したくない場合です。

于 2013-03-10T21:11:32.513 に答える
3

私はデイブに同意する必要があります。カフカは優れたツールですが、手動で実行できるいくつかの基本的な機能が欠けていますが、カフカが何を提供するかを考える必要があります。不足しているものは次のとおりです。

  • （デイブが言ったように）プロデューサーがメッセージを送信できなかったときにディスクにメッセージをフラッシュする
  • 消費者は、（消費されただけでなく）処理されたメッセージと再起動の場合に処理されなかったメッセージを追跡することができます。
  • 監視-プロデューサーのキューの現在のサイズやブローカーの書き込み/読み取りペースなど、システム内のエンティティの現在のステータスを受信する方法（これらは実行できますが、ツールの一部ではありません）。
于 2013-08-12T07:23:03.273 に答える
2

私はかなり前からkafkaを使ってきました。ネイティブのJavaおよびPythonクライアントを使用することをお勧めします。

適切なnode.jsクライアントを見つけるのに苦労しなければなりませんでした。多くのバグがあったため、さまざまなクライアントを使用して、文字通りコード全体を何度も書き直しました。最終的にnode.jsのfranz- kafkaで解決しました。

それとは別に、消費者のオフセットを維持することは少し難しいです。AMQPベースのApacheQpidまたはRabbitMQに存在する交換のようないくつかの優れた機能が欠けています

配布されているので、オフラインメッセージをサポートし、パフォーマンスは本当に印象的です。私もそれを好みました:)

于 2012-12-27T19:30:34.823 に答える