Apache Kafka=は、順序付けられていないタスクキューとして使用するのに適していますか？
Kafkaは、プロデューサーによって割り当てられたパーティションに従って、着信メッセージをパーティションに分割します。パーティションからのメッセージは、異なる消費者グループの消費者によって消費されます。
このアーキテクチャでは、制作時にパーティションを指定する必要があるため、Kafka=をワーク/タスクキューとして使用することに慎重になります。これにより、パーティションが送信されるため、消費者グループ内の1人の消費者のみ。事前にパーティションを指定するのではなく、そのタスクを実行できる消費者が指定できるようにします。Kafka次の利用可能な消費者がタスクをプルできるアーキテクチャで、作品の制作時にパーティションを選択して事前に作品を分割する必要はありませんか？
このトピックにパーティションを1つだけ使用すると、すべてのタスクが同じキューに配置されますが、コンシューマーの数はコンシューマーグループごとに1つに制限されるため、各コンシューマーは異なるグループに属する必要があります。その後、すべてのタスクが各コンシューマグループに分散されますが、これは私が探している種類の作業キューではありません。
Apache Kafka=はタスクキューとしての使用に適していますか？
タスクキューにKafka=を使用するのは悪い考えです。代わりにRabbitMQを使用してください。
タスクキューにKafkaを使用できますが、いくつかの問題が発生します。Kafkaは、設計上、単一のパーティションを消費することを許可していません） 、たとえば、単一のパーティションが多くのタスクでいっぱいになり、パーティションを所有するコンシューマがビジーの場合、そのパーティション内のタスクは「飢 "」に陥ります。これは、トピック内のタスクの消費順序が変わらないことも意味しますタスクが特定の順序で消費される必要がある場合に深刻な問題を引き起こす可能性のあるタスクが生成された順序と同一（1つのコンシューマと1つのパーティションのみが必要であることを完全に達成するには、Kafka -これは、1つのノードのみによるシリアル消費を意味します。複数のコンシューマーと複数のパーティションがある場合、タスク消費の順序はトピックレベルで保証されません）。
実際-Kafka=トピックはコンピューターサイエンスの方法ではキューではありません。キューは先入れ先出しを意味します-これはあなたが得るものではありませんKafkaレベル。
もう1つの問題は、パーティションの数を動的に変更することが難しいことです。新しいワーカーの追加または削除は動的でなければなりません。新しいワーカーがカクファでタスクを取得できるようにする場合は、パーティション番号を可能な限り最大のワーカーに設定する必要があります。これは十分にエレガントではありません。
要するに、代わりにRabbitMQまたは他のキューを使用してください。
そのすべてを言った-Samza（by linkedin）は、kafka=ストリーミングベースのタスクキューの一種として： Samza
編集：スケールに関する考慮事項：Kakfaはビッグデータ/ビッグスケールツールであることを忘れていました。あなたの仕事率が巨大な場合、Kafka=は以前に書いたことにも関わらずあなたにとって良い選択肢かもしれません。巨大なスケールに対処することは非常に困難であり、Kafka小規模なスケール（たとえば、1秒あたり最大数ドーズ/数百ジョブ）について話している場合、再びKafkaはRabbitMQと比較して不適切な選択です。
これは規模に依存すると言うでしょう。時間単位で予想されるタスクの数。
最終目標として説明するのは、基本的にKafkaがデフォルトでどのように機能するかです。メッセージを生成するときのデフォルト（最も広く使用されている）オプションは、ラウンドロビン方式でパーティションを選択するランダムパーティショナーを使用することです、パーティションを均等に使用し続ける（したがって、パーティションの指定を避けることが可能です）。
パーティションの主な目的は、メッセージの処理を並列化することであるため、このような方法で使用する必要があります。
パーティションが使用される他の一般的に使用される「もの」は、特定のメッセージが生成される順序と同じ順序で消費されることを保証します（そのようなメッセージがすべて同じになるようにパーティション化キーを指定します）パーティション。たとえば、userIdをキーとして使用すると、すべてのユーザーがそのような方法で処理されることが保証されます。
このトピックでは、作業またはタスクキュー内のタスクの実行順序を中心に多くの議論があります。実行の順序は作業キューの機能であってはならないという考えを提示します。
作業キューは、個別のタスクの完了に向けて制御可能な数のワーカースレッドを適用することにより、リソースの使用を制御する手段です。キュー内のタスクに処理順序を適用することは、キュー内のタスクにも完了順序を適用することを意味します。つまり、キュー内のタスクは常に前のタスクの終了後にのみ処理される次のタスクで順番に処理されます。これは事実上、シングルスレッドのタスクキューがあることを意味します。
一部のタスクで実行の順序が重要な場合、それらのタスクは、完了時にシーケンス内の次のタスクをワークキューに追加する必要があります。それまたはあなたは、処理されたときに実際に1つのワーカーでジョブのリストを順番に処理するシーケンシャルジョブタイプをサポートしています。
作業キューが実際に作業を順序付けすることは決してありません。次の利用可能なプロセッサは、タスクの完了前または完了後に何が発生したかに関係なく、常に次のタスクを取る必要があります。
また、作業キューの基礎としてkafkaを見ていましたが、調査するほど、希望するプラットフォームのように見えなくなります。
私は、主に異種のリソースを同期する手段として使用されており、異種のジョブ要求を実行する手段としてではないことを確認しています。
ワークキューで重要だと思うもう1つの分野は、タスクの優先順位付けのサポートです。たとえば、キューに20個のタスクがあり、新しいタスクがより高い優先度で到着した場合、そのタスクを行の先頭にジャンプして、次に利用可能なワーカーがピックアップするようにします。 Kafkaはこれを許可しません。
Kafka=をメッセージキューとして使用しようとすると、主に2つの障害があります。
Ofer's answer で説明されているように、単一のコンシューマーから単一のパーティションのみを消費でき、処理の順序はパーティション内でのみ保証されます。したがって、タスクをパーティション間で公平に分散できない場合、これは問題になる可能性があります
デフォルトでは、指定されたポイント（オフセット）までのすべてのメッセージの処理のみを確認できます。従来のメッセージキューとは異なり、選択的な確認応答を行うことはできず、障害が発生した場合は選択的な再試行を行うことはできません。これは kmq を使用して対処できます。これにより、追加トピックの助けを借りて個々のacks機能が追加されます（免責事項：私はkmqの著者です）。
RabbitMQはもちろん代替手段ですが、異なる（より低い）パフォーマンスとレプリケーションの保証も提供します。要するに、RabbitMQのドキュメントには、ブローカー パーティショントレラントではない と記載されています。メッセージキューとデータレプリケーションの比較 mqperf も参照してください。