Websocket 接続を介してデータを受信し、各メッセージを Azure Redis キャッシュにプッシュする Node.js アプリケーションがあります。メッセージの永続的な配列をダウンストリームで使用するために変数に保存し、一定の間隔でその配列をキャッシュから同期します。少し複雑ですが、後で、キャッシュに書き込むアプリケーションの半分と、キャッシュから読み取るアプリケーションの半分を分離したいと思います..
02:00 GMT 頃、Azure portal の統計に基づいて、その同期で "キャッシュ ミス" が発生し始めたようです。これは、05:00 頃に再び "キャッシュ ヒット" を取得し始めるまでの数時間続きました。
キャッシュ ミスは、05:00 頃にピークに達する CPU 使用率の急激な増加に対応しています。そして私がピークと言うとき、私はそれが 81% に達することを意味します。
したがって、05:00頃にCPUがピークに達し、その後通常に戻り、「キャッシュミス」はなくなりますが、キャッシュメモリの使用量を見ると、約37.4mbの使用から約3.85mbの使用に減少します（これは「空」状態)、およびこのアプリケーションで使用されているリストは空でした。
アプリケーションがキャッシュに対して実行している唯一の関数は LPUSH と LRANGE であり、データを削除する機能を備えたものは何もありません。また、誰かが疑問に思っている場合に備えて、CPU がメモリ使用量を増やしたときにそうではなかったので、その不正を示唆するものは何もありません。データの追加がトリミングされました。
ベーシックプランのみなので、無敵などとは思っていませんが、スタンダードプランのレプリケーション機能がなくても、完全に自分自身を一掃することはできないと思っていました-私はRedis は定期的に自身をディスクに書き込み、エラーから回復したときにそこから復元するという印象。
これらはすべて、私の質問方法です。
ここで何が起こったのか、誰か知っていますか？
これが他の人が誤って自分自身をトリガーできるものである場合、同じキャッシュを使用している他のアプリケーションで、壊滅的な失敗を引き起こした可能性のある問題に注意する必要がありますか?
スタンダード プランはこの種の問題に悩まされることはないと言う声を大歓迎します。なぜなら、私はすでにそれを分岐させており、それが正しい選択であると感じられるのは素晴らしいことだからです。
事前に多くの感謝..