私は、Akkaを使用して、Twitterストリームを(今のところ)取り込み、アクターを使用してさまざまな方法でメッセージを処理するリアルタイム処理システムを作成するプロジェクトに取り組んでいます。私は他の人がAkkaを使用して構築した同様のアーキテクチャについて読んでいて、この特定のブログ投稿が私の目に留まりました。
http://blog.goconspire.com/post/64901258135/akka-at-conspire-part-5-the-importance-of-pulling
ここでは、アクターに作業(メッセージなど)をプッシュする場合と、アクターに作業をプルさせる場合に発生するさまざまな問題について説明します。記事を言い換えると、メッセージをプッシュすることによって、どの作業単位がどの作業者によって受信されたかを知る組み込みの方法はなく、それを確実に追跡することもできません。さらに、ワーカーが突然多数のメッセージを受信し、各メッセージが非常に大きい場合、圧倒されてマシンのメモリが不足する可能性があります。または、処理がCPUを集中的に使用する場合は、CPUのスラッシングが原因でノードが応答しなくなる可能性があります。さらに、jvmがクラッシュすると、アクターがメールボックスに持っていたすべてのメッセージが失われます。
メッセージをプルすると、これらの問題が大幅に解消されます。特定のアクターはコーディネーターから作業をプルする必要があるため、コーディネーターは各ワーカーの作業単位を常に把握しています。作業者が死亡した場合、コーディネーターはどの作業単位を再処理するかを知っています。また、メッセージはワーカーのメールボックスに配置されないため(1つのメッセージをプルし、別のメッセージをプルする前に処理するため)、アクターがクラッシュした場合にそれらのメールボックスが失われることは問題ではありません。さらに、各ワーカーは現在のタスクを完了した後にのみより多くの作業を要求するため、ワーカーが同時に処理できる以上の作業を受け取ったり開始したりする心配はありません。明らかに、コーディネーター自体がクラッシュしたときに何が起こるかなど、このソリューションには問題もありますが、今のところ、これは問題ではないと仮定しましょう。
http://letitcrash.com/post/29044669086/balancing-workload-across-nodes-with-akka-2
これにより、このプルパターンを実行する代わりに、プッシュを実行するが耐久性のあるメールボックスを使用するという代替案について考えました。私が考えていた例は、RabbitMQを使用するメールボックスを実装し(Redis、MongoDB、Kafkaなどの他のデータストアもここで機能します)、アクターの各ルーター(すべて同じ目的で使用されます)を共有することでした同じメッセージキュー(または使用するデータストアに応じて同じDB /コレクションなど)。言い換えると、各ルーターは、メールボックスとして機能する独自のキューをRabbitMQに持ちます。このように、ルートの1つがダウンした場合でも、まだアップしているルートは、通常のメモリ内メールボックスを使用しなくなったため、キューがオーバーフローすることをあまり心配せずに、RabbitMQから取得し続けることができます。また、メールボックスはメモリ内に実装されていないため、ルートがクラッシュした場合、失われる可能性のあるメッセージのほとんどは、クラッシュ前に処理していた単一のメッセージです。ルーター全体がダウンした場合、ルーターが回復してメッセージの処理を再開できるようになるまで、RabbitMQ(または使用されているデータストア)が増加した負荷を処理することが期待できます。
耐久性のあるメールボックスに関しては、バージョン2.0に戻ると、AkkaはMongoDBやZooKeeperなどで動作するいくつかのメールボックスを実装していたため、これらをより積極的にサポートすることに力を注いでいたようです。しかし、何らかの理由でアイデアを放棄したようです。最新バージョン(この投稿の執筆時点では2.3.2)以降のある時点で、それらについては言及されていません。enqueue()、dequeue()などのメソッドを提供するMessageQueueインターフェースを実装することで、独自のメールボックスを実装することもできます。そのため、RabbitMQ、MongoDB、Redisなどで機能するメールボックスを作成することはできません。問題になる。
とにかく、これについてあなたの男とギャルの考えを聞きたかっただけです。これは、引っ張る代わりに実行可能な方法のように見えますか?
この質問はまた、akka-userにかなり長く有益なスレッドを生み出しました。要約すると、(永続的な)アクターによって処理される作業項目を明示的に管理し、そこから可変数のワーカーアクターが新しいジョブをプルすることをお勧めします。これにより、リソース管理が向上し、処理対象と再試行の処理方法を明示的に制御できるようになります。 。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加