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

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

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

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

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

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

要するに：

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

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

• ZeroMQ
• RabbitMQ
• アパッチカフカ
• Redis、BLPOPまたはPUBSUBを使用して（これを行う方法をここで尋ねました）。
• RabbitMQ以外の他のAMQP実装

私はそれぞれの欠点を議論することは範囲外であると思いますが、少なくともこのよく咳をする専門知識を主張していないので、Rabbit coughを使用しないでください。

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

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

RabbitMQ / AMQPの交換キューモデルについて学びます。ルーティングはあなたのために出てくるかもしれません-これはRedis PUBSUBによってサポートされていますが、ZeroMQによってサポートされたことを覚えていません。

どうやって選ぶの？

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

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

もちろん、たとえば、高頻度のトレーディングショップで働いている場合、これらはそれほど重要ではありません。最終的にスループットを向上させる代わりに、クライアント側のライブラリに開発時間を費やすことをいとわないでしょう。しかし、これらの技術は、すぐに使える機能ではなく、パフォーマンスに基づいて市場に出回る傾向があることを警告するために、これをさらに書いています。Webスタートアップの場合、前者よりも後者のほうがはるかに興味があります。したがって、優れたパフォーマンスでの使用の難しさよりも優れたパフォーマンスでの使いやすさにより最適化されたRedisのようなものは、おそらくRabbitMQよりも良い選択。（私はRabbitMQが本当に好きではありません）。