問題タブ [azure-queues]

現在、nServiceBus でホストされているアプリケーションで何かを起動して実行するのに苦労しています。サードパーティがメッセージを投稿している azure ServiceBus キューがあり、アプリケーション (現時点ではローカルでホストされています) にこれらのメッセージを受信させたいと考えています。

エンドポイントを構成する方法についての回答をグーグルで検索しましたが、有効な構成で運がありませんでした。Azureストレージキューに接続する方法の例を見つけることができますが、サービスバスキューには接続しないので、これを行ったことがありますか? (他の理由で Azure Servicebus キューが必要です)

私が持っている設定は以下の通りです

. Message=エンドポイント開始時の例外、エラーがログに記録されました。理由: 入力キュー [mytimeoutmanager@sb://[ * ].servicebus.windows.net/] は、この Source=NServiceBus.Host と同じマシン上にある必要があります

.

Azure キューにあるメッセージの量を計算する方法をアドバイスしてください

私の問題の解決策は実際よりも簡単なはずのように思えます。リモート クライアント マシンが Azure Service Bus キューからメッセージを送受信できることをテストして確認しようとしています。

Microsoft がhttps://www.windowsazure.com/en-us/develop/net/how-to-guides/service-bus-amqp/で提供しているサンプル アプリケーションを使用しています。

すべてのポートが開いている限り、サンプル アプリケーションは問題なく動作します。ただし、ポート 80/443 のみが使用可能な場合に機能するソリューションが必要です。80/443 でのインバウンド/アウトバウンド トラフィックのみを許可するように Windows ファイアウォールを構成すると、機能しません。「アクセス許可で禁止されている方法でソケットにアクセスしようとしました」というエラーが表示されます。

サンプル アプリケーションの問題のある行は次のとおりです。

私は非常に多くのサイトを見てきましたが、見つけた提案の 1 つは、次のように接続モードを Http に設定することでした。

それもうまくいきません。

リモート クライアントまたは Azure がホストするロールでカスタム サービスをセットアップしようとはしていません。Azure の Service Bus キューとトピックを介してメッセージを送受信できるようにする必要があります。

誰かが私の欠陥を指摘できますか?

64K の制限がある Azure キューを介して、圧縮された Base64 データを送信する必要があります。
私のコードはデータを圧縮してから、Base64 文字列としてエンコードします。
圧縮およびエンコードされた文字列が 64000 バイトを超えていないことを確認します (以下の encodedLen を参照)。ただし、~57,000 バイトのメッセージを追加しようとすると、コードがクラッシュしました。

Visual Studio 2012 と .Net 4.5 を使用しています。
ここで何が欠けていますか？

多くの開発者と同様に、既存のアプリを SQL Azure フェデレーションに統合する方法を探していますが、Identity 列 (テーブルの主キー) を置き換えることは大きな問題です。

多くの理由から、主キーに GUID を使用したくありません (GUID についての議論を開かないでください。それは私の質問ではありません: GUID が必要ないだけです)。

そのため、標準 SQL データベースの「ID」機能を置き換えるキー プロバイダーを構築する必要があります。私は Entity Framework を使用しているので、 (クラスのメソッドをIdオーバーライドすることによって) 挿入の直前に値を設定する場所を簡単に見つけることができます。「ファーム対応」である現在の Id を取得するための「あまり複雑ではない」実装を見つける必要があるだけです。SaveChangesObjectContext

この SO 投稿を読みました:「シャード データベース (Azure Federated Database) の ID 生成」および「 MSDN Magazineの Windows Azure で複数のノードを同期する」ですが、この解決策は私にとって少し複雑に思えます。

SQL テーブルごとに 1 つの Azure キューを (自動的に) 作成することを考えています。これには、事前に読み込まれた連続する整数のリストが含まれています。Id 値が必要な場合は、キューからメッセージを取得するだけで (非表示になり、途中で削除されます)、現在使用可能な Id が得られます。

"Windows Azure Queues" と "Windows Azure Service Bus Queues" のどちらを選択するかについては、Service Bus Queues の"高い" 待ち時間のため、"Windows Azure Queues" を好みます。Azure Queues の「注文保証」がないことは問題ではないと思います。

Azure キューを使用して Id 値を提供するというアイデアについてどう思いますか? その考えを放棄する議論はありますか? SQL Azure フェデレーション データベースで整数 ID を提供するためのより良いアイデア、または良い習慣はありますか? ありがとう。

編集 ：

Astaykov は SnowMaker を提案しました。Azure Storage lib の v2 との完全な互換性を確保するために、SnowMakerのフォークを最終的に行いました。

編集2

ここで説明されているように、 Azure SQL フェデレーションは 2015 年 9 月に Web 層とビジネス層で廃止されることに注意してください。しかし、この質問は、カスタム シャーディング ソリューションにも当てはまります。

Azure キュー (ストア アカウント) 内のメッセージ数 (またはおおよその数) を特定する方法があることは知っています。ただし、Azure Service Busキューで保留中のメッセージの数を照会する方法はありますか?

高負荷/大規模な Web サービスのステート マシンとして Azure Queues を使用したいと考えています。

クライアントは Web サービス エンドポイントにリクエストを送信し、その時点でリクエスト ID を返します。

次に、Worker ロールがメッセージを処理できるようにメッセージをキューに送信しますが、送信プロセス中にデータベース アクティビティは発生しません。代わりに、メッセージが存在するキューを使用して、現在の状態を表現したいと考えています。

私の問題は、worker ロールがキューからメッセージを取得して処理すると、そのキューで非表示になることです。そのメッセージの処理状況を確認したい場合、あいまいなメッセージ状態があります。メッセージが失われたか受信されなかったか、キューに入っているが処理中であるために表示されていないかのいずれかです。

理想的には、目に見えないメッセージをピークにできるようになりたいです。リクエスト ID に一致するものが見つかった場合、それが非表示の場合は処理中であり、表示されている場合は処理を待機していることがわかります。明らかに、その操作はデータベースの書き込みにつながるため、いつ処理が完了するかを知っています。

これは可能ですか、それとも Azure キュー内の非表示のメッセージを覗き見ることができないという事実が、これを不可能にするのでしょうか?

Azure にデプロイする Web サイトを開発しています。現在、Azure Queue を使用してユーザーにメールを送信しています。現在のスレッドをスリープ状態にすることで、60 秒ごとに受信メッセージのキューをチェックしています。

私の問題は、スレッドを待機して60秒間待機したくないということです。代わりに、キューが実際にメッセージを受信したときにメッセージ送信機能をトリガーしたいのです。Service Bus トピック/サブスクリプションのメカニズムはわかりましたが、同じサブスクリプション メカニズムを Azure キューで (トピック/サブスクリプションを使用せずに) 実装できるかどうかを知りたいです。これは可能ですか？メッセージがキューに受信された場合にのみ実行できるように、Azure キューは何かをリッスンできますか。私は確かにスレッドをスリープ状態にしたくありません。

ありがとうございました。