web-dev-qa-db-ja.com

スケーラブルなメッセージキューアーキテクチャの設計

私は最近、スケーラブルなエンタープライズコンピューターアーキテクチャのニュアンスを学び始めました。中心的なコンポーネントの1つはメッセージングキューです。あらゆるプログラミングパラダイムからできる限り学ぶために、独自のバージョンのメッセージングキューサービスを実装しようとしています。

これまでのところ、私の最初のデザインはスレッドソケットリスナーで実行されていますが、同じメッセージが2つの別々の処理ノードによって2回ダウンロードされるのを防ぐために、読み取りが開始されるとメッセージキューインデックスレジスタがロックされ、レジスタが読み込まれた後にロックが解除されます更新しました。そのため、スレッド化する必要がなくなり、メッセージングキューサービスが実行されているサーバーの処理速度に基づいて、スケーラブルシステムのサイズに上限が設けられます。

これを回避する方法は、複数のサーバーでメッセージキューサービスを実行することですが、同じメッセージが2回ダウンロードされる可能性が高くなります。このような問題が発生するのを防ぐ唯一の方法は、（サーバーまたは単一サーバーのスレッドでさえ情報を同期し、そのような再発行を検出した後）処理ノードにその停止を命令する失効コールバックを含めることです。現在のジョブ、および次のメッセージのメッセージキューを再クエリしますが、送信されるトラフィックの大部分は同期であり、コールバックが取り消されるため、ボトルネックが発生し、情報の処理が遅くなるため、多くの処理ノードがnull操作を実行し、時間を浪費します。

この問題を回避するために私が考えることができる最後の方法は、各メッセージキューサーバー（および各サーバーの各スレッド）が、キューのどこを探しているかに関して特定のオフセットを持つことですが、アプリケーションのタイプ、特に処理が特定の順序で実行される必要がある場合。

とはいえ、既存のエンタープライズグレードのメッセージキューサービスがこれらの問題をどのように回避できるかを示すメッセージキューアーキテクチャのデザインはありますか？

designscalabilitymessage-queue
24
topherg

要するに：

これは難しい問題です。車輪を再発明しないでください。

多くのテクノロジーがメッセージキューレイヤーを解決します。彼らは含まれています

私はこれをうまく行うための専門知識を主張していないので、それぞれの欠点を議論することは私が範囲外だと思います咳ウサギを使用しない咳。

これらのテクノロジを使用したくない場合でも、ドキュメントをお読みください。

これにより、1つのシステムで可能な設計パターンについて学習できます。 ZeroMQのドキュメント を読むと、優雅に実装された多くの従来のメッセージキューイングアーキテクチャについて学習できます。 ZeroMQを使用しない場合でも、これらのパターンを知っていると、そのパターンを実装できるかどうかを尋ねることにより、他のキューイングテクノロジーを評価するのに役立ちます。

RabbitMQ/AMQPの交換キューモデルについて学習します。ルーティングが発生する可能性があります-これはRedis PUBSUBでサポートされていますが、ZeroMQでサポートされたことを思い出しません-ファンアウトは、かなり長い間Memcachedポーリング（実装されていません！） 。

どれを選ぶか？

私はSLAがWebアプリにとって典型的なスタートアップで働いています-データの損失がほとんどなくサービスを迅速に復元できる限り、一部の停止は問題ありません。 TwitterやTumblrのようなスケーリングの問題について考える必要はなかったので、スループットの量について考える必要もありませんでした。そうは言っても、私のようなSLAを実装している場合は、次の考慮事項が頭に浮かびます。

  • クライアントライブラリは機能しますか？それらの接続を維持するのは簡単ですか？ （ZeroMQ、Redis：はい。RabbitMQ：いいえ）。
  • サーバーコンソールからの監視と管理は簡単ですか？ （Redis：はい、RabbitMQ：はい、ZeroMQ：覚えていませんが、それほど長くは使用していません）
  • クライアントは内部キューをサポートしているので、短時間の停止でデータ損失はほとんど発生しませんか？ （ZeroMQ、Redis：はい。RabbitMQ：いいえ。）

もちろん、たとえば、高頻度の取引所で働いている場合、これらはあなたの心配事が少なくなります。最終的にスループットを上げる代わりに、クライアント側のライブラリに開発時間を入れてもかまいません。しかし、私はこれをさらに書いて、これらのテクノロジーは、すぐに使える機能ではなく、パフォーマンスに基づいて市場に出る傾向があることを警告します。あなたがウェブスタートアップなら、前者よりも後者にはるか、そしてそれに応じて、使いやすさのために最適化されたRedisのようなものにもっと興味があります優れたパフォーマンスでの使用の難しさよりもパフォーマンスは、RabbitMQよりもおそらく良い選択です。 （RabbitMQは好きではありません）。

15
djechlin