タグ付けされた質問 「message-queue」

たとえば、RabbitMQのようなAMQPの使用を検討すべきユースケースを誰かが説明できますか？長所と短所は何ですか？

45 design  message-queue 

私はこの記事を読んだばかりで、混乱しています。 1つのwebappと1つの別個のアプリケーションが「ワーカー」として動作し、両方が同じデータベースを共有しているとしましょう。 ああ、私は「共有」と言いました。しかし、この記事は何について警告していますか？： 第4に、アプリケーション（またはサービス）間でデータベースを共有することは悪いことです。そこに無定形の共有状態を置くのはあまりにも魅力的であり、それを知る前に、巨大に結合したモンスターができます。 =>反対。別個のアプリケーションが依然として同じユニットの一部である場合があります。したがって、この場合、「カップリングの問題」という概念は意味がありません。 続けましょう：webappはクライアントHTTPリクエストを処理し、いつでもいくつかの集約（DDD用語）を更新して、対応するドメインイベントを生成します。 ワーカーの目標は、必要なジョブを処理することにより、これらのドメインイベントを処理することです。 ポイントは： イベントデータをワーカーに渡す方法 読んだ記事が推進する最初の解決策は、優れたメッセージ指向ミドルウェアであるRabbitMQを使用することです。 ワークフローは簡単です： Web dynoがイベントを生成するときはいつでも、RabbitMQを介してイベントを発行し、ワーカーにフィードします。 欠点は、潜在的な送信エラーやハードウェアの問題に対処せずに、集約更新のコミットとイベントの発行の間の即時の一貫性を保証するものがないことです。それは別の主な問題です。 例：集約の更新が成功せずにイベントが発行された可能性があり、その結果、ドメインモデルの誤った表現を表すイベントが発生しました。 グローバルXA（2フェーズコミット）が存在すると主張できますが、すべてのデータベースまたはミドルウェアに適合するソリューションではありません。 それでは、この即時の一貫性を確保するための優れたソリューションは何でしょうか？： IMO、集計更新と同じローカルトランザクションでデータベースにイベントを保存します。 シンプルな非同期スケジューラが作成され、データベースから現在の未公開イベントをクエリし、それらをRabbitMQに送信します。RabbitMQはワーカーにデータを入力します。 しかし、なぜwebapp側で余分なスケジューラーが必要なのか、そしてところで：この場合RabbitMQが必要なのはなぜですか？ このソリューションでは、特にデータベースが共有されているため、RabbitMQは不要である可能性があります。 実際、どのような場合でも、即時一貫性にはデータベースからのポーリングが含まれることがわかりました。 したがって、なぜワーカーはこのポーリングに直接責任を負わないのでしょうか？ したがって、なぜWeb上の多くの記事が、データベース指向のキューイングを批判しているのに、メッセージ指向のミドルウェアを宣伝しているのか疑問に思います。 記事の抜粋： シンプルで、仕事に適したツールを使用します。このシナリオは、メッセージングシステムを求めています。上記のすべての問題を解決します。これ以上のポーリング、効率的なメッセージ配信、完了したメッセージをキューからクリアする必要、共有状態はありません。 そして、即時の一貫性は無視されますか？ 要約すると、データベースが共有されているかどうかにかかわらず、ケースが何であれ、データベースポーリングが必要なようです。 いくつかの重要な概念を見逃しましたか？ ありがとう

33 architecture  domain-driven-design  message-queue  middleware 

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

29 node.js  message-queue  redis  pubsub  producer-consumer 

分散キューの問題を解決するさまざまな方法について、もっと詳しく学ぼうとしています。それで、私はすでにどんな製品、サービス、実装と研究論文があるかについて知りたいです。 実装は多くの課題に直面し、トレードオフを余儀なくされます。 順序が強いですか、緩いですか？ べき等を入れていますか？ 単一のマシンに収まるものよりも多くのキューを使用できますか？ 単一のマシンに収まるデータよりも多くのデータをキューに入れることができますか？ データを失う可能性がある前に、何台のマシンがクラッシュする可能性がありますか？ ネットスプリットを許容できますか？ ネット分割が修正されると、自動的にデータを調整できますか？ クライアントがクラッシュした場合に配信を保証できますか？ 同じメッセージが複数回配信されないことを保証できますか？ ノードは任意の時点でクラッシュし、戻ってきて、ジャンクを送信できませんか？ ダウンタイムなしで実行中のクラスターにノードを追加、またはノードからノードを削除できますか？ ダウンタイムなしで実行中のクラスターのノードをアップグレードできますか？ 異種サーバーで問題なく実行できますか？ サーバーのグループにキューを「固定」できますか？（例：「これらのキューはヨーロッパのデータセンターでのみ許可されています」） 可能であれば、少なくとも2つのデータセンターにデータレプリカを配置することを確認できますか？ 私は、どの実装でもそのすべてに「はい」と言うことができるという幻想は持っていません。さまざまな実装について聞いてみたいだけです。それらがどのように機能するか、どのようなトレードオフを行ったか、そしておそらく彼らが特定のトレードオフのセットを決定した理由。 また、上記のリストで見逃したかもしれない課題がある場合。

23 distributed-computing  message-queue 

最近、スケーラブルなエンタープライズコンピューターアーキテクチャのニュアンスを学び始めました。中心的なコンポーネントの1つはメッセージングキューです。プログラミングパラダイムからできる限り多くを学ぶために、独自のバージョンのメッセージングキューサービスを実装しようとしています。 これまでのところ、私の最初の設計はスレッドソケットリスナーで実行されますが、2つの別々の処理ノードによって同じメッセージが2回ダウンロードされるのを防ぐために、読み取りが開始されるとメッセージキューインデックスレジスタがロックされ、レジスタがロック解除されるとロックが解除されます更新しました。そのため、これはスレッド化の必要性をなくし、メッセージングキューサービスが実行されているサーバーの処理速度に基づいてスケーラブルなシステムのサイズに上限があることを意味します。 これを回避する方法は、複数のサーバーでメッセージキューサービスを実行することですが、これにより、同じメッセージが2回ダウンロードされる可能性が高くなります。このような問題の発生を防ぐ唯一の方法は、（サーバー、または単一サーバー上のスレッドでさえ、情報を同期し、そのような再発行を検出した後）処理ノードに停止するように命令する失効コールバックを含めることです現在のジョブ、および次のメッセージのためにメッセージキューを再クエリしますが、送信されるトラフィックのほとんどが同期および失効コールバックであり、ボトルネックを引き起こし、情報の処理を遅らせる天井があります多くの処理ノードがnull操作を実行し、時間を浪費します。 この問題を回避するために考えることができる最後の方法は、各メッセージキューサーバー（および各サーバーの各スレッド）がキュー内のどこを探しているかに関して特定のオフセットを持たせることですが、それは特に処理を特定の順序で実行する必要がある場合は、アプリケーションのタイプ。 ということで、既存のエンタープライズグレードのメッセージキューサービスがこれらの問題をどのように回避するかを示すことができるメッセージキューアーキテクチャの設計はありますか？

22 design  scalability  message-queue 

数人の開発者の間で議論がかなり白熱したアプリケーションがあります。 基本的に、Webレイヤーとバックエンドレイヤーに分割されます。Webレイヤーは単純なWebフォームによって情報を収集し、このデータをJSONドキュメント（文字列は.jsonファイル）としてバックエンドが使用する監視フォルダーに格納します。バックエンドは数秒ごとにこのフォルダーをポーリングし、ファイルを取得して、その機能を実行します。 ファイル自体は非常にシンプル（つまり、すべての文字列データ、ネストなし）で、最大で1〜2kで、システムはほとんどの時間をアイドル状態にします（ただし、最大100メッセージまでバーストします）。バックエンド処理ステップは、メッセージごとに約10分かかります。 議論は、ある開発者がファイルシステムをメッセージングレイヤーとして使用することは悪いソリューションであると示唆した場合、リレーショナルデータベース（MySQL）、noSQLデータベース（Redis）、またはプレーンREST APIコールなどを代わりに使用する必要がある場合に出てきます。 Redisは、キュー内のメッセージ処理のために組織内の他の場所で使用されることに注意してください。 私が聞いた議論は次のように分類されます フラットファイルを支持して： フラットファイルは、他のソリューションよりも信頼性が高くなります。ファイルは、「監視」フォルダーから、取得後に「処理」フォルダーに、最後に「完了」フォルダーに移動するためです。とにかく他のものを壊すような非常に低レベルのバグがない限り、メッセージが消えるリスクはありません。 フラットファイルを理解するには、それほど高度な技術は必要ありません- catそれだけです。書き込むクエリはありません。誤ってメッセージをキューからポップして、メッセージが永遠に消えてしまうリスクはありません。 ファイル管理コードは、すべての言語の標準ライブラリの一部であるため、プログラミングの観点からデータベースAPIよりも簡単です。これにより、コードベースの全体的な複雑さと、導入する必要のあるサードパーティコードの量が削減されます。 YAGNI原則州フラットファイルが今うまく動作することを、それを残して、より複雑なソリューションに変更するための実証され必要はありません。 データベースを支持して： ファイルがいっぱいのディレクトリよりもデータベースを拡張する方が簡単です フラットファイルには、誰かが「完了」ファイルを「監視」ディレクトリにコピーして戻すリスクがあります。このアプリケーションの性質（仮想マシン管理）により、これにより壊滅的なデータ損失が発生する可能性があります。 T / Sにより高度な技術を必要とするアプリは、教育を受けていないスタッフが物事を突くだけで何かを台無しにする可能性が低いことを意味します。 特にRedisなどのDB接続コードは、少なくとも標準ライブラリファイル管理機能と同じくらい堅牢です。 DB接続コードは、ファイル操作よりもレベルが高いため、開発者の観点からは（機能的にではないにしても）明らかに単純です。 私が見ることができることから、両方の開発者は多くの有効なポイントを持っています。 これら2人のプロファイル開発者、またはプロデータベース開発者のうち、どちらがソフトウェアエンジニアリングのベストプラクティスに沿っているのでしょうか？

20 database  programming-practices  file-handling  message-queue 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 先週、Akkaのドキュメントを深く掘り下げ、最終的にアクターシステムとは何か、そしてそれらが解決する問題を理解しました。 私の従来のJMS / AMQPメッセージブローカーの理解（および経験）は、以下を提供するために存在するということです。 プロデューサーとコンシューマー間の非同期処理。そして 持続性、再試行、フォールバックを含むメッセージ配信の保証 しかし、Akkaはこれを提供し、必要なインフラストラクチャと運用オーバーヘッドをすべて排除しませんか？ Akkaでは、すべてのアクター通信は非同期で非ブロッキングです。そして Akkaでは、SupervisorStrategies再試行、フォールバック、およびエスカレーションを達成するために存在します。これも要件である場合、実質的にあらゆるタイプのストアに持続するようにアクターを構成できます。 私のアプリがAkkaを使用している場合、JMS / AMQPブローカー（ActiveMQ、RabbitMQ、Kafkaなど）を写真に取り入れる必要がありますか？つまり、新しいAkkaベースのアプリが新しい JMS / AMQPブローカークラスターの導入を保証するユースケースはありますか？なぜですか？ 唯一の議論は、おそらく私のAkkaアプリを別のシステムと統合する必要があるということです。ただし、その場合、Akka-Camelモジュールを使用すると、AkkaはCamelの統合機能の網羅的でほぼ無限のリスト（TCP、FTP、ZeroMQ、リストは延々と続く...）を活用できます。 考え？

19 asynchronous-programming  message-queue  messaging  akka 

メッセージのキューイングに関するアドバイスを求めています。「ジョブ」をメッセージキューに投稿する必要があります。 最初の提案は、SQL Serverインスタンスを使用して、そこからのメッセージを処理することだけでした。インターネットで読んだことはすべて、Message Queueにデータベースを使用することはスケーラブルなソリューションではないことを示唆しています。このため、RabbitMQまたは他のサードパーティMQを使用するというアイデアが提案されました。 もう1つ考慮すべきことは、「ジョブ処理」の要件が30秒以上にならないことです。したがって、ジョブを実行するプロセスは30秒ごとにデータベースをポーリングします。私には、これはそれほど悪くはないようで、おそらくデータベースに大きな負荷をかけなくても大丈夫でしょう。 クライアントに必要な追加サポートを追加しないように、これに使用できるデータベースが既にクライアントに配置されていますが、サードパーティMQを追加した場合、ネットワーク構成などの追加サポートがあります。多くのユーザーがいることを考えると、かなりの数です。 私が検討していたもう1つのオプションは、ユーザーがどちらかを選択できるようにすることでした。小さいユーザーの場合、SQL Serverソリューションは問題ありませんが、大きいユーザーの場合、サードパーティのMQソリューションを構成できます。 私はソリューションで販売されていません。誰かが私が考慮すべきことやアドバイスを持っているかどうか疑問に思っています。

17 database  message-queue 

カフカのサイトによると： 「Kakfaは、リアルタイムデータパイプラインとストリーミングアプリの構築に使用されます。」 インターネットを広く検索して、「ストリームデータ」とは何かについて、一般に受け入れられている次の定義を見つけました。 ストリームデータは、ネットワークを介してソースから宛先に連続して流れるデータです。そして ストリームデータは本質的にアトミックではありません。つまり、データのフローストリームのどの部分も意味があり、処理可能であることを意味します。そして ストリームデータはいつでも開始/停止できます。そして 消費者は自由にデータのストリームをアタッチおよびデタッチし、必要な部分だけを処理できます さて、上で言ったことが間違っている、不完全である、または完全に間違っている場合、私を修正することから始めてください！多かれ少なかれ軌道に乗っていると仮定すると... 「ストリーミングデータ」が何であるかを理解したので、KafkaとKinesisがストリーミングデータを使用するアプリケーションの処理/仲介ミドルウェアとして自身に請求するときの意味を理解しました。しかし、それは私の興味をそそりました。KafkaやKinesisのような「ストリームミドルウェア」を、従来のメッセージブローカーのような非ストリーミングデータに使用できるかどうか。そしてその逆：RabbitMQ、ActiveMQ、Apolloなどの従来のMQをデータのストリーミングに使用できますか、または使用すべきですか？ アプリケーションが処理が必要なJSONメッセージのバックエンドの一定の集中砲火を送信する例を見てみましょう。処理はかなり複雑です（検証、データの変換、フィルタリング、集計など）。 ケース＃1：メッセージは映画の各フレームです。これは、フレームデータといくつかのサポートメタデータを含むビデオフレームごとに1つのJSONメッセージです ケース＃2：メッセージは時系列データであり、おそらく時間の関数としての誰かのハートビートです。したがって、t = 1でのハートビートを表すメッセージ＃1が送信され、t = 2でのメッセージ＃2にはハートビートが含まれます。 ケース＃3：データは完全にばらばらであり、時間によって、または「データストリーム」の一部として無関係です。おそらく、数百人のユーザーがボタンをクリックしてアクションを実行するアプリケーションをナビゲートすると発生する監査/セキュリティイベント Kafka / Kinesisの課金方法と「ストリーミングデータ」とは何であるかを理解すると、これらはケース＃1（連続したビデオデータ）と＃2（連続した時系列データ）の明らかな候補のようです。ただし、RabbitMQのような従来のメッセージブローカーがこれらの入力の両方を効率的に処理できなかった理由はわかりません。 また、ケース＃3では、発生したイベントのみが提供されるため、そのイベントに対する反応を処理する必要があります。私にとってこれは、RabbitMQのような従来のブローカーが必要であることを意味します。しかし、KafkaまたはKinesisでイベントデータの処理を処理できない理由もありません。 だから基本的に、私は言うルーブリックを確立しようとしています：私はY特性を持つXデータを持っています。Kafka / Kinesisのようなストリームプロセッサを使用して処理する必要があります。または、逆に、私が判断するのに役立つもの：Z特性を持つWデータがあります。従来のメッセージブローカーを使用して処理する必要があります。 だから私は尋ねる：データ（またはそれ以外）がストリームプロセッサとメッセージブローカーの間の決定を導くのに役立つのは、どちらもストリーミングデータを処理でき、両方が（非ストリーミング）メッセージデータを処理できるからですか？

13 message-queue  stream-processing  apache-kafka 

イベント駆動型マイクロサービスアーキテクチャの変更を処理するためのオプションを調査している調査プロジェクトを行っています。 したがって、4つの異なるサービスを利用できるアプリケーションがあるとします。これらの各サービスには、ローカルデータを格納するための独自のデータベースがあります。 このセットアップでは、4つのサービスがイベントバスを使用して相互に通信します。したがって、サービスで何かが発生すると、イベントが発行されます。そのイベントに関心のある他のすべてのサービスは、独自の方法で処理します。 その場合、アーキテクチャー内のさまざまなサービスは、これらのイベントの内容（属性など）について「契約」を持つ必要があります。したがって、サービスはこれらのイベントに「疎結合の依存関係」を持っています 私の質問は次のとおり です。これらのイベントの変更をどのように処理できますか？ それでは、サービスAがアプリケーションに新しいユーザーを登録するとします。したがって、 "" UserRegistered "イベントを送信します。サービスBがそのイベントを取得して処理します。ただし、サービスチームCの一部の開発者は、登録済みユーザーの性別も必要であると判断しました。そのため、イベントが変更され、属性gender 「UserRegistered」イベントに追加されます。 サービスBが再デプロイせずに、その追加属性を使用して同じイベントを引き続きピックアップできることをどのように確認できますか？ そして、この問題に取り組み、これらのイベントをバージョン管理する他の方法はありますか？

9 communication  versioning  microservices  message-queue  code-contracts 

Client application-> Front-end API cloud server->のような3層システム用のREST APIを設計していますuser's home API server (Home)。 Homeはホームデバイスであり、Front-endWebsocketまたは長い投票（これは、RESTに違反している最初の場所です。後でさらに悪化します）を介した接続を維持することになっています。Front-endほとんどの場合、Client要求をHome接続にトンネルし、一部の呼び出し自体を処理します。にHome通知を送信することがありますClient。 Front-endHome基本的に同じAPI を持っています。LAN経由で直接Client接続している可能性がありますHome。この場合、それ自体にHomeいくつかのClientアクションを登録する必要がありFront-endます。 このシステムでのRESTの長所は次のとおりです。 RESTは人間が読める形式です。 RESTには、動詞（CRUDなど）、名詞、および応答コードのプロトコルオブジェクトへの明確に定義されたマッピングがあります。 HTTP上で動作し、可能なすべてのプロキシを渡します。 RESTコントラは次のとおりです。 リクエストとレスポンスのコミュニケーションスタイルだけでなく、パブリッシュサブスクライブも必要です。 3層通信エラーを処理するには、HTTPエラーコードでは不十分な場合があります。必要な接続が壊れていて、あるはずだったことを知るためだけに、非同期呼び出しにFront-end戻る場合があります。202 AcceptedHome503 Homeにメッセージを送信する必要がありますClient。ClientポーリングするFront-endか、接続を維持する必要があります。 我々は考えているWAMP / アウトバーンを、それがすでにメッセージキューのように見ていることを私を襲ったとき、機能をパブリッシュ/サブスクライブを取得するのWebSocketの上に。 一種のメッセージングキューをトランスポートとして評価する価値はありますか？ メッセージキューの逆のように見えます： CRUD動詞とエラーコードをメッセージレベルで自分で定義する必要があります。 「メンテナンスコストが高い」と書いてありますが、どういう意味ですか？ これらの考慮事項はどのくらい深刻ですか？

9 architecture  web-services  rest  message-queue  websockets 

アプリでは、ある種のマイクロサービスアプローチを使用しています（ただし、実際にはそれに準拠していません）。 サービスがダウンしているか例外がスローされている場合、アプローチはそれをキュー（ActiveMQ）に入れ、サービスが再びアップしたときに再試行します。 これは「標準」ソリューションですか？それとも、何らかの理由で回避する必要がありますか？ または、この問題に対するより良い、または代替の解決策はありますか？

8 microservices  message-queue 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、討論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 6年前休業。 ベンダーにほとんどとらわれない（MQ実装の例は問題ありません）が、アーキテクチャ、管理、命名法、原子性、耐久性、パターン、およびMessage Queueシステムでの論理的配備についての詳細に行く本の推奨事項はありますか？ 確かに、MQシリーズ、MSMQ、SysV IPC（OK、それはそれを拡張しているかもしれません）、RabbitMQ、＆c＆cの間に十分な共有概念がありますか？

8 books  message-queue