キューは、セッション状態の適切なメカニズムではありません。メッセージパッシング用です。また、1 つのインスタンスがキュー メッセージを読み取ると、特定のロール インスタンスがそのメッセージを処理している間、そのメッセージは表示されなくなります。また、メッセージを使い終わったら、そのメッセージをどうしますか? 更新してから、再び表示しますか? 問題は、読み取る「セッション」を選択できないことです。これはほぼ FIFO キューです (適切に処理されないメッセージが再表示される可能性があります)。キー/値ストアとは異なります。
アクセス可能なセッション リポジトリを作成するには、Azure のロール内 (または専用ロール) キャッシュを利用できます。これは、ロール インスタンス全体に分散されたキャッシュです。テーブルストレージも使用できます-単純なキー/値タイプの読み取り/書き込みだけです。また、Table Storage は node.js Azure SDK に含まれています。
つまり、ここでキャッシュルートに行きましょう。あなたのセッションは存続期間が短く、(推測では) あまり多くのメモリを消費しないため、インロール キャッシュから始めることができます (キャッシュはワーカー ロールの RAM をノード コードと共有し、メモリー）。キャッシュは memcache にも対応しており、ノード アプリケーションから簡単にアクセスできます。
この回答を見ると、キャッシュにアクセスする場所が示されます。この方法でキャッシュをセットアップする必要がありますが、 という内部エンドポイントを追加して memcache サーバー ゲートウェイもセットアップする必要がありますmemcache_default。次に、memcache クライアント クラスを内部エンドポイントに向けます。終わり。
完全な手順 (および専用のキャッシュ ロールを設定するときに使用する memcache ゲートウェイとクライアント shim に関する詳細) は、こちらです。専用キャッシュを使用する場合は、ノード アプリのワーカー ロールでクライアント shim を使用することが推奨されるため、手順が少し異なることがわかります。