問題タブ [azure-redis-cache]

以下の構成でセッション サーバーとして redis を使用しようとしたときに問題が発生しました。

1. https://github.com/Azure/aspnet-redis-providersで同じアプリケーションをホストする複数の Windows サーバー
2. 重み付けされたルーティングを備えたエラスティック ロード バランサーは、要求をすべての IIS サーバーにリダイレクトします。
3. Redis は AWS エラスティック キャッシュでホストされ、両方のサーバーからアクセスできます

4. Redis は一度に 1 つのサーバーのセッション サーバーとして問題なく機能します

   セッションごとに 3 つのキーが作成されます

"{/_ktffpxxxxxxg2xixdnhe}_Write_Lock"

"{/_ktffpxxxxxxg2xixdnhe}_Data"

"{/_ktffpxxxxxxg2xixdnhe}_Internal"

問題: 1 つ以上のサーバーが同じインスタンスで redis からセッションにアクセスして同じユーザーにサービスを提供しようとすると、server1 が配置されている_Write_Lock場合、server2 はデータの読み取り + 更新タイムアウトまたは書き込みに失敗し、その後キーをクリアします

--> その結果、どのサーバーに対するユーザーの次のリクエストでも、セッションの検証に失敗します。

この問題が発生するのは私だけですか?? 助けてください ...

注: ELB でセッション スティッキを有効にすると、サインアウトは断続的ではありませんが、そのサーバーのすべてのユーザー セッションを失うことなく、アップグレードのためにサーバーを取り出すことが制限されます。

質問があります。3 つのシャード (マスターとスレーブを含む) を持つ Redis クラスターを使用しているとします。マスターとそのスレーブに同時に障害が発生すると、Redis クラスターは動作を継続できないことがわかりました。その後どうなりますか。

1. Redis クラスターは、他の 2 つのノードからも他のすべてのキーを削除しますか? (戻ってきたら)
2. このクラスターを手動で再起動する必要がありますか? また、他のキーの値を (他のノードで) 保持することはできますか?
3. Azure Redis Cache を使用するとどのように動作しますか?

前もって感謝します

A と B の 2 つの Azure ワーカー ロールがあります。

• A は、毎分ジョブを実行する Quartz スケジューラーです。
• 「Redisキャッシュ」から毎分いくつかのIDを読み取り、それらのIDのジョブを実行します。
• 'A' は、Worker ロール 'B' によってサブスクライブされている Service Bus キューにその出力を発行します。
• 'B' ワーカー ロールは、キューから値を読み取り、それらに対してさらに操作を実行します。
• どちらのワーカー ロールも、起動時にキャッシュを構築する必要があります。

次に、Azure コンポーネントの障害に関するいくつかの問題を示します。

• Redis キャッシュがダウンした場合、どう対処すればよいでしょうか。実行が再開されるまで実行を停止する必要があります。その後、キャッシュを再度構築する必要があります。'B' ワーカー ロールは、Redis が再び起動するまで、サービス バスからのメッセージのプルを停止する必要があります。

• ワーカー ロール 'B' でサービス バスの障害を処理するにはどうすればよいですか?

アプリケーションの一部は「ルール エンジン」として機能します。ルールは、プロセスの状態と時間の 2 つの要素で構成できます。ルールは単純にも複雑にもできます。すべてのルールにはステータスがあります - True または False

典型的なルールは次のようになります。

いつ - 9:00 から 11:00 までの時間で、プロセス 1 のステータスはオープンです。

時刻は 4:00 から 6:00 の間であり、プロセス 2 のステータスは閉じています。

したがって、このルールは、プロセス 1 の状態が変更されたとき、またはプロセス 2 の状態が変更されたときに、9:00、11:00、4:00、および 6:00 にチェックして評価する必要があります。評価後、ルールのステータスが (以前のものから) 変更された場合、イベントを発生させます。新しい結果が保存されるため、次にこのルールが評価されるときにその結果を比較できます。新しい結果が前の結果と同じ場合、何も起こりません。

これと同じことを実現するために、アプリケーションで 3 つの異なるコンポーネントを使用しました。

1) Web UI - ルールの作成、プロセス状態の変更など。プロセス状態またはルール構成が変更されるたびにイベントを発生させます。

2) スケジューラ - これは 1 分ごとにジョブを実行するワーカー ロール (ウィンドウ サービス) です. 開始時刻または終了時刻が現在時刻であるルールがあるかどうかをチェックします. 見つかった場合, イベントをキューに上げます.

3) ルール エンジン - このエンジンは、ルールの定義変更イベント、プロセス状態変更イベント、時間イベントの 3 種類のイベントをリッスンするワーカー ロール (ウィンドウ サービス) です。プロセスの状態変化や時間ルールイベントが発生した場合、これを条件とするルールを全て見つけ出し、それらのルールを発火させ、さらに「ルール状態変化」としてイベントを発生させます。

このソリューションは、Windows Azure クラウド プラットフォーム上に構築されています。設計上の決定事項をいくつか次に示します。

1) ルールの定義は SQL サーバーに保存されます。前述のように、ルールは本質的に階層的 (複雑) で、複数の条件で構成されている場合があります。

2) データベースから時間または Process1 によってルールを抽出するのは時間のかかる操作になる可能性があるため、SQL データベースからこのすべてのデータを 1 回フェッチし、Redis キャッシュに保存します。キーは、時​​間またはプロセス ID ですべてのルールを見つけることができるように作成されます。この操作は、ルール エンジンの起動時に行われます。すべてのプロセスの状態もデータベースとキャッシュに保存されます。

3) Azure サービス バスは、あるコンポーネントから別のコンポーネントにメッセージを渡すために使用されます。

4) Web UI からマスター データが変更されるたびに、イベントがキューに渡され、ルール エンジンがキャッシュを更新します。

システムは、オートスケーリングを念頭に置いて設計されています。ワークロードが増加すると、キューの深さが増加し、ルール エンジンにインスタンスを追加できます。

上記のデザインに改善点があれば提案してください。

高可用性とコンポーネント障害に関して私たちが直面している問題は次のとおりです。

複数の Azure サービスが使用されており、それらすべてが異なる時点で失敗する可能性があります (複数のインスタンスが使用されている場合でも)。

1) Web UI (Web ロール) 99.95 の可用性 - これは現時点では問題ではありません。

2) スケジューラ (ワーカー ロール) 99.95 の可用性

3) ルール エンジン (ワーカー ロール) 99.95 の可用性

4) Azure Service Bus 99.9 の可用性

5) Redis Cache 99.9 の可用性 (データに関する SLA なし)

すべてが正常に機能していると仮定すると、突然、次のいずれかの状況が発生します。

問題 1: ユーザーがルールの定義を UI から変更しています。システムはこのデータを SQL データベースに追加しますが、サービス バスが応答しません。この変更をルール エンジンに伝えることができないため、システムが同期しなくなります。- 解決策の 1 つは、DB 操作をロールバックし、しばらくしてから再試行するようにユーザーに指示することです。- もう 1 つのオプションは、2 フェーズ コミットを行うことです。サービス バスが応答しない場合は、データベースにフラグを保持します。キューが使用可能になるたびに、この変更をキューにプッシュするバックグラウンド プロセスを実行します。

問題 2: ユーザーがプロセスの状態を変更しています。システムはこれを SQL データベースに追加しますが、サービス バスが応答しません。このプロセス状態の変更は、ルール エンジンと通信できません。ルール エンジンは非同期になります。- 前のものと同じ。

問題 3: スケジューラ エンジンが停止する: タイム イベントが発生しないため、ルール エンジンはそれらのイベントを処理できません。- スケジューラーがジョブを実行するたびに時間を記録できます。スケジューラは常に、最初に見逃したすべてのイベントを発生させてから、新しいイベントの実行を開始する必要があります。

問題 4: ルール エンジンからのメッセージを処理しているときに、キャッシュがダウンします。ルール エンジンは、キューのメッセージを処理できません。メッセージを失うことはないので、これで問題ありません。ただし、キャッシュが戻ってきた場合、すべてのキャッシュ データも失われる可能性があります。ルール エンジンはキャッシュを再構築する必要があります (ルール エンジンの開始時に行われたように)。

御時間ありがとうございます。追加案があればよろしくお願いします。

いくつかのクイック ルックアップ データを格納するために Azure Redis Cache を使用しています。このキャッシュは 10 個のクライアント アプリケーションによって読み取られ、接続されています。すべてのアプリケーションは .NET 4.6 で記述されており、これには ASP.NET MVC Web アプリケーション、Web API、および 1 秒ごとに実行されるいくつかのワーカー ロールが含まれます。すべてのクライアントは、キャッシュへの接続に StackExchange.Redis を使用しています。ただし、断続的なタイムアウトが発生し、Azure Portal で最大接続数が 1000 に達していることを確認しました (価格レベルの場合)。クライアント アプリケーションは 10 個しかなく、いずれもマルチスレッド化されていないため、何がキャッシュへの 1000 接続を作成できるのでしょうか?

キャッシュ クライアントで従うことができるベスト プラクティスはありますか?

大きな JSON をRedisに保存したい。サイズ: 約 5 MB。

JSON を圧縮してから Redis に保存する方法はありますか。また、Redis から解凍されたデータを取得するのが遅いため、必要です。

Azure REDIS キャッシュとは何ですか? それの使い方？使う時と使わない時は？MS-SQL サーバーからデータにアクセスする単純な c# アプリケーションに使用できますか? Azure Redis キャッシュの使用を開始するのに最適なソースは何ですか?

例外メッセージ: GET allBots の実行中のタイムアウト、inst: 1、mgr: 非アクティブ、err: never、queue: 7、qu: 0、qs: 7、qc: 0、wr: 0、wq: 0、in: 65536、ar: 0、IOCP: (ビジー = 2、フリー = 998、最小 = 1、最大 = 1000)、ワーカー: (ビジー = 0、フリー = 2047、最小 = 1、最大 = 2047)

GET stock_by_symbol_leg.to のタイムアウト、inst: 1、mgr: 非アクティブ、err: never、queue: 13、qu: 0、qs: 13、qc: 0、wr: 0、wq: 0、in: 0、ar: 0 、IOCP: (ビジー=3、フリー=997、最小=1、最大=1000)、ワーカー: (ビジー=3、フリー=2044、最小=1、最大=2047)

GET stock_by_symbol_aapl のタイムアウト、inst: 1、mgr: 非アクティブ、err: never、queue: 13、qu: 0、qs: 13、qc: 0、wr: 0、wq: 0、in: 0、ar: 0、IOCP : (ビジー=3、フリー=997、最小=1、最大=1000)、ワーカー: (ビジー=3、フリー=2044、最小=1、最大=2047)

GET portefoliosBotById_ec030000-0001-1200-0000-000000000000 のタイムアウト、inst: 1、mgr: 非アクティブ、err: never、queue: 13、qu: 0、qs: 13、qc: 0、wr: 0、wq: 0、in : 0、ar: 0、IOCP: (ビジー=3、フリー=997、最小=1、最大=1000)、ワーカー: (ビジー=3、フリー=2044、最小=1、最大=2047)

私は StackExchange.Redis バージョン 1.1.603 と利用可能な最小の Azure インスタンスを使用しています。多くの GET/SET タイムアウト エラーが発生しています。私のボックスでRedisサーバーをローカルで使用している場合、この問題は発生しません。これにより、Azureで問題が発生する可能性があります。Redis に格納される情報は 2kb から 10kb 程度です。

Azure portal では、接続数が 20 未満、メモリ使用量が約 130 メガバイト、CPU 使用率が 35% 未満、Redis サーバーの負荷が常に 13% 未満であることがわかります。ポータルから問題の兆候が見られません。

その問題を解決するためのより多くの情報を入手できる場所はありますか?

編集

最初の投稿以来、いくつかの設定を改善しました。

1) Azure Redis の C0 から C1 インスタンスに渡しました。

2) 接続文字列を 15 秒のタイムアウトに変更しました。これがどのように見えるかです：

boursexxxxxxx.windows.net:6380,password=xxxxxxxx,ssl=True,abortConnect=False,connectRetry=5, connectTimeout=15000, synctimeout=15000"

3) 呼び出しごとにローテーションする 10 個の遅延読み込み ConnectionMultiplex のプールを作成しました。

4) 多くのキャッシュの値を減らしました。私が持っているシリアル化されたオブジェクトに応じて：

4.1) 1.25ko (5%)

4.2) 0.154ko (5%)

4.3) 26ko (20%)

4.4) 700ko (ここで作業する必要がありますが、100 エントリ未満に制限されています)

4.5) 5ko (30%)

4.6) 66ko (40%)

この種の推奨事項は、次のような複数の場所で見ました。

複数のファクトリ: 同じファクトリによって作成されたすべてのクライアント (受信者に加えて送信者) は、1 つの TCP 接続を共有します。最大メッセージ スループットは、この TCP 接続を通過できる操作の数によって制限されます。1 つのファクトリで得られるスループットは、TCP の往復時間とメッセージ サイズによって大きく異なります。より高いスループット レートを得るには、複数のメッセージング ファクトリを使用する必要があります。

Redis、RabbitMQ などについても同様の推奨事項を見つけることができます。私の質問は、1 つの TCP チャネルがどのように使い果たされるのでしょうか? 単一の TCP チャネルに帯域幅の制限はないと思います。

では、なぜ人々は高スループットのために複数のチャネルを持つことを提案するのでしょうか? それは次の理由によるものですか。

1. クライアント アプリケーションが多数の小さなメッセージを 1 つの tcp チャネルに送信する場合、各操作は tcp ソケットをロックしてからメッセージを送信します。ロック競合が発生する可能性があります。そして、複数の tcp チャネルを使用する場合、この競合はある程度解決される可能性があります。

2. 大きなメッセージが tcp チャネルで送信される場合、シリアライズ/デシリアライズしてチャネルにプッシュするのに時間がかかることがあります。他の小さなメッセージをブロックできます。

これらは実際の理由ですか (または、これらの仮定が間違っている場合、本当の理由は何ですか)?

.NET 実装で azure redis キャッシュを使用しています。キャッシュから取得する必要があるキーのリストがあります。今、これが私の実装です: `

説明のために少し簡略化しましたが、問題なく動作します。ただし、取得するキーのリストを渡すことで、バッチ ダウンロードのバッチ セットと同様のセットアップを行うことができるかどうか疑問に思っていました。通常、約 200 以上の ID です。それは可能ですか？