6

最近、新しい Azure VM でサイド プロジェクトのホスティングを開始しました。アプリは Redis をメモリ内キャッシュとして使用します。ローカル環境ではすべて正常に動作していましたが、コードを Azure に移動したため、Booksleeve から奇妙な例外が発生しています。

アプリが最初に起動すると、すべて正常に動作します。ただし、非アクティブ状態が約 5 ～ 10 分間続くと、アプリへの次のリクエストでネットワーク例外が発生します (私は現在仕事中で、正確なエラー メッセージを把握していないため、家に帰ったら投稿します。これにより、内部の MessageQueue が閉じられ、その結果、後続のすべての Enqueue() で例外がスローされます (「キューが閉じられました」)。

それで、グーグルで調べた後、このSO投稿を見つけました：DIY接続マネージャーについて、BookSleeveを使用してRedis接続を維持しています。それが最善の方法である場合、私は確かに同様のものを実装できます。

だから、質問：

  1. RedisConnection が一定時間後に定期的に閉じるのは正常ですか?
  2. メソッドを見てきconn.SetKeepAlive()ましたが、さまざまな値を試してみましたが、違いはないようです。これ以上のことはありますか、それとも間違ったツリーを吠えていますか?
  3. 上記の投稿からの接続マネージャーのアイデアは、このシナリオを処理するための最良の方法ですか?
  4. 新しい Azure VM で Redis インスタンスをホストするとこの問題が発生する理由について、誰か追加の光を当てることができますか? また、Azure Redis VM に対してローカル環境を実行すると、この問題が発生することも確認できます。

前述のように、非アクティブ後に Redis 接続が停止するのが異常な場合は、家に帰ったときにログからスタック トレースと例外を投稿します。

ありがとう！

UPDATE Didier はコメントで、これは Azure が使用するロードバランサー に関連している可能性があると指摘しました。タイムアウトの詳細.aspx

その場合、このばかげた問題を説明できる接続マネージャーを実装する最良の方法は何でしょうか。作業単位ごとに接続を作成するべきではないと思いますよね?

4

2 に答える 2

6

他の回答/コメントから、これは、Azure インフラストラクチャがアイドル状態に見えるソケットをシャットダウンすることが原因のようです。何らかの操作を定期的に実行するタイマーをどこかに置くこともできますが、これは既に Booksleeve に組み込まれていることに注意してください: 接続すると、redis 接続タイムアウトが何であるかをチェックし、redis がソケットを閉じるのを防ぐためにハートビートを構成します。これをピギーバックして、Azure がソケットを閉じないようにすることもできます。たとえば、redis-cli セッションでは次のようになります。

config set timeout 30

30 秒の接続タイムアウトを持つように (再起動する必要なく、オンザフライで) redis を構成する必要があります。Booksleeve は、30 秒の直前にハートビートがあることを確認するための手順を自動的に実行する必要があります。これが成功した場合は、次の再起動後にもこの設定が適用されるように、構成ファイルも編集する必要があることに注意してください。

于 2012-06-14T06:36:41.460 に答える
1

Windows Azure のロード バランサーは、ロード バランサーの合計接続負荷に応じて X 時間後に接続を閉じます。そのため、接続でランダムなタイムアウトが発生します。

私は Redis 接続についてよく知られていないため、正しく実装する方法を提案することはできませんが、一般的に推奨される回避策は、セッションを維持するためのハートビート パルスを使用することです。ブログで提案されている回避策を探して、Redis に実装してみる機会はありますか?

于 2012-06-12T22:29:41.407 に答える