タグ付けされた質問 「pubsub」

3
マイクロサービス間でDTOを共有する方法は?
私のシナリオは次のとおりです。 さまざまな種類のセンサーからデータを受信し、後でさまざまなフロントエンドおよび分析サービスで使用できるように変換して保持するように設計されたシステムを設計しています。 私はすべてのサービスを可能な限り独立したものにしようとしていますが、問題があります。チームは、使用したいDTOを決定しました。外向きサービス(センサーデータ受信者)は、独自の方法でデータを受信し、JSONオブジェクト(DTO)に変換して、メッセージブローカーに送信します。メッセージのコンシューマーは、センサーデータメッセージの読み取り方法を正確に知ることができます。 問題は、いくつかの異なるサービスで同じDTOを使用していることです。更新プログラムは複数の場所に実装する必要があります。明らかに、ここでDTOのいくつかの余分なフィールドや不足しているフィールドを設計しました。サービスが更新されるまで問題はあまりありませんが、それでも私を悩ませ、気分が良くなります。間違いを犯す。簡単に頭痛になります。 システムを間違って設計しようとしていますか?そうでない場合、これを回避する方法は何ですか、または少なくとも私の心配を緩和するために?

3
Redisでメッセージキューを実装する方法は?
キューイングにRedisを使用する理由 私は、Redisがキューイングシステムを実装するための良い候補になることができるという印象を受けています。これまで、MySQLデータベースをポーリングまたはRabbitMQで使用してきました。RabbitMQには多くの問題があります。クライアントライブラリは非常に貧弱でバグが多いため、修正に開発者の時間をかけすぎないように、サーバー管理コンソールにいくつかの問題があります。少なくとも、ミリ秒で把握したり、パフォーマンスを真剣に推進したりすることはないので、システムがキューをインテリジェントにサポートするアーキテクチャを備えている限り、おそらく良好な状態にあります。 さて、それが背景です。基本的に、非常に古典的でシンプルなキューモデルがあります。仕事を生成する複数のプロデューサーと、仕事を消費する複数のコンシューマーがあり、プロデューサーとコンシューマーの両方がインテリジェントにスケーリングできる必要があります。すべてのサブスクライバーに作業を消費さPUBSUBせたくないので、ナイーブが機能しないことがわかります。1人のサブスクライバーに作業を受け取りたいだけです。最初のパスでは、インテリジェントデザインのように見えます。BRPOPLPUSH BRPOPLPUSHを使用できますか? 基本的な設計でBRPOPLPUSHは、1つの作業キューと進行状況キューがあります。コンシューマーが作業を受け取ると、アイテムをアトミックに進行キューにプッシュし、作業を完了するとそれが完了LREMします。これにより、クライアントが死んだ場合の作業のブラックホール化が防止され、監視が非常に楽になります。たとえば、大量のタスクがあるかどうかを通知するだけでなく、消費者がタスクを実行するのに長時間かかる問題があるかどうかを確認できます。 それは保証します 仕事はちょうど1人の消費者に届けられる 作業は進行キューで終了するため、消費者がブラックホールに陥ることはありません 欠点 私が見つけた最高のデザインはPUBSUB、Redisのキューイングに関するほとんどのブログ投稿が焦点を当てているものであるように思われるため、実際には使用していません。だから、私は明白な何かを見逃しているように感じます。PUBSUBタスクを2回消費せずに使用する唯一の方法は、作業が到着したという通知をプッシュするだけで、消費者はそれをブロックしないようにできRPOPLPUSHます。 一度に複数のワークアイテムを要求することはできません。これはパフォーマンスの問題のようです。私たちの状況にとっては大きなものではありませんが、この操作は高スループットまたはこの状況のた​​めに設計されたものではないことを明確に示しています 要するに、私は愚かな何かを見逃していますか? node.jsタグも追加します。これは、私が主に扱っている言語だからです。Nodeは、シングルスレッドでノンブロッキングな性質を考えると、実装のいくつかの単純化を提供するかもしれませんが、さらに、node-redisライブラリとソリューションを使用しています。

2
パブリッシュ/サブスクライブパターンは、gotoとどのように異なりますか?
私の理解では、後藤声明は一般的に眉をひそめているということです。しかし、パブリッシュ/サブスクライブパターンは、コードの一部がメッセージをパブリッシュすると、一方向の制御の転送を実行するという点で概念的に類似しているようです。プログラマは、プログラムのどの部分がこのメッセージにサブスクライブしているかわからない場合があります。 イベントを使用してモジュール間を便利に「ホップ」するJavaScriptプログラムの多くで、似たようなものを見てきました。パブリッシュ/サブスクライブまたはイベント駆動型のパターンについて何かが欠けていますか?

1
サービスバス上のメッセージの図解
複数のアプリケーションがサービスバスを介して通信する方法を明確に示す方法を探しています。私がこれまでに思いついた最高のものはシーケンス図ですが、私は本当にそれが好きではありません。シーケンス図は必然的にある種のシーケンスに関連しますが、それは私が本当に望んでいることではありません。さらに、すべてのサービスがサービスバスと通信し、シーケンス図が各サービスを別々の列に配置するため、サービスの数が増えると、矢印が重なってしまいます。 例えば、与えられた4つのサービスFOO、BAR、BAZ、とQUX: FOOタイプpublishおよびregenのメッセージを公開します。 BARタイプrequeueのメッセージをパブリッシュします。 BAZタイプがpublish、regen、およびrequeueのメッセージをサブスクライブし、タイプがtransmitのメッセージをパブリッシュします。 QUXタイプが送信のメッセージをサブスクライブします。 どのサービスでも、いつでもどのメッセージタイプでも公開できます(暗黙のシーケンスはありません)。 この情報を明確かつ明確に表すには、どのような図を使用する必要がありますか? これが私がこれまでに思いついた最高のものです:
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.