ServiceStack.Redisを使用して実装された多数のRedisメッセージキューを多数のノードがリッスンするソリューションを実装しています。システム内で、各ノードは特定の「チャネル」とチャネル上の特定の操作を処理します。たとえば、メッセージは受信メールであり、チャネルは「abc」である可能性があります。
多くのチャネルがありますが、メッセージタイプの数は固定されています。
私は週末にServiceStackソースコード内を見て回り、RedisMessageQueueClientとRedisMqHostにいくつかのバリエーションを実装しました。構築時に「チャネル」を渡し、これを使用して、公開/監視されるキュー名を構築するという考え方です。
内部的には、既存のRedisMqHostとRedisMessageQueueClientは静的なQueueNamesを使用してキュー名を生成しますが、これは純粋にタイプ名に基づいてキューを生成するため、特定のチャネルだけを処理する方法はありません。更新したコードは、キュー名の最後にチャネル名を追加します。
たとえば、「abc」チャネルの場合、mq：InboundEmail：inはmq：InboundEmail：in：abcになります。
いくつかの場所を変更しただけでコードが正しく感じられませんが、QueueNamesクラスが全体で使用されています。
2つの質問：
複数のメッセージキューを持つという基本的な設計は正しいですか？これは複数のRedisデータベースとしてモデル化する必要がありますか（正しく聞こえません）、または多数のキューを持つという私の設計は適切ですか？チャンネルごとに約1,000のチャンネルと4つまたは5つのキューを見ていると思います。
私が見逃したメッセージキューを分割するための既存のメカニズムはありますか？それはかなり標準的な要件であるはずであり、Inキュー、Outキュー、PriorityキューとDlqキューがそれぞれにあるという点ですでにその下で発生しているように感じますメッセージタイプ。