モデレーターの呼びかけに応じて、入門的な教育記事を投稿します-PHPチュートリアル-php.cn

前に書きました:

PHP とは直接の関係はありませんが、効率の低さに不満を言いながらもリアルタイムで mysql をチェックしている友人が多く見られるようになりました。そこで、redis を導入しましょう。結局のところ、それはディスクよりも読み書き速度が n 段高く、mysql、mongo、cassandra よりも学習コストがはるかに低いです。ぜひ試してみる価値があります。

初心者の場合は、Redis の同期方法を詳しく見て概要を理解することができます。
あなたが古い Redis ユーザーである場合は、その詳細は非常に目立たないことですが、将来的には実際に影響を与える可能性があることを思い出させてください。

この記事は Redis に関するチュートリアル記事でも、詳細な Redis ソースコード分析の中核原則の紹介でもありません。私は皆さんに、特別な観点から redis の利点と注意すべき点を見てもらいたいと思っています。今後、必要に応じて、redis の使用方法やパラメータ設定などの詳細を中心に紹介していきます。 Linux C に精通し、ソースコードの解析が得意な専門家に比べれば、私はまだ初心者です。間違いがあれば、直接指摘していただければ幸いです。

Redis でのデータ永続化には 2 つのオプションがあります:

1 aof ファイルの書き込み
2 スナップショット RDB ファイルの書き込み

両方が同時に開かれた場合、redis は起動後、最初に aof ファイルからデータを回復しようとします。。さらに、マスター/スレーブの場合、redis はスレーブからマスターに aof ファイルをプルして、マスター/スレーブの同期を実現します。

スナップショット rdb については説明しませんが、ここでは主に aof について説明します。 redis でコマンドを実行すると、redis は aof ファイルに追加します。

まず、このマシン上で 2 つの Redis サーバーを開き、1 つはマスターとしてポート 12345 をリッスンします。もう 1 つはポート 12346 でリッスンし、スレーブとして機能します。

次に、redis-cli は redis-server マスターに接続し、テスト用の値を書き込みます。

同様に、redis-cli は redis-server スレーブに接続します。この値が同期されていることがわかります。

次に、master と redis の aof ファイルを見てみましょう。それらが完全に一致していることがわかります。
マスター:

スレーブ:

ここで、この mytestkey をマスターから削除します。これは aof ファイルにも書き込まれ、スレーブに同期されます。
マスターで del mytestkey を実行します。

スレーブの aof ファイルを確認し、同期されている最後の 3 行に注目してください。

これは、Redis のマスター/スレーブ同期の基本原理です。
redis で実行されたコマンドは aof ファイルに書き込まれ、マスターで実行されたコマンドは aof ファイルをスレーブに同期します (正確には、スレーブはマスターに同期コマンドを送信して aof ファイルをプルします)。

ただし例外もあります:

新しいキーを作成して削除しただけなので、ライブラリには何もないはずです。この時点で削除すると、存在しないキーを削除したことと同じになり、redis は (整数) 0 を返します。 lushdb はデータベースをクリアする操作です。データベースにデータがあるかどうかに関係なく、ok が返されます。
では、ライブラリにデータがない場合、これら 2 つのコマンドは aof ファイルに書き込まれて同期されるのでしょうか?

答えは「いいえ」です。del mytestkey には 2 回目は書き込まれず、flushdb にも書き込まれません。また、aof ファイルはスレーブに同期されません。

なぜこのことを申し上げたいかというと、このような性質上、一昨日ネットビジネスで重大なバグが発生したからです。私たちのオンラインビジネスは、複数の php Web サーバー + 複数の Redis で構成されています。 Redisにも主従関係があり、主従関係は一方向のリンクリスト構造を採用しています。つまり、マスター -> スレーブ -> スレーブ -> スレーブ... マスターは、スレーブが必要とするすべてのパブリックデータを保存します。 PHP Web サーバーは Redis スレーブを読み取るため、各スレーブは独自の一意のキャッシュを書き込む必要があります。これは完璧に思えます。Redis の負荷分散が実現され、メモリデータの冗長性が回避されます。キャッシュの冗長性を避けるため。また、キャッシュキーの競合を避けるために (実際、これはキープレフィックスを追加するだけで簡単に解決できます)、これはマスターとスレーブの同期、つまりデータの一貫性の中心概念に違反します。各 PHP Web サーバーは、対応するサーバーにデータを送信し、データを書き込みます。奴隷。結局のところ、キャッシュはキャッシュです。これらのキャッシュは、設定時にキーの有効期限を設定しませんでした。代わりに、イベント駆動型のアプローチを使用して、すべてのマシンのキャッシュを一度にクリアします。

Redis 内のすべてのパブリックデータを更新するための一連のスクリプトが毎晩あります。パブリックデータとキャッシュは異なるパーティションに保存されます。パブリックデータがライブラリ 0 に保存されている場合、キャッシュはライブラリ 1 に保存されます。マスターに対して
select 0
lushdb
select 1
lushdb

を実行すると、マスターのキャッシュパーティション 1 ライブラリにデータがないため、問題が発生します。したがって、このflushdbは実際にはローカルのaofファイルに書き込みませんし、各スレーブと同期しません。その結果、キャッシュがまったくクリアされず、翌日データが更新されないというバグが発生しました。ここでモニターを設定しなかったのですが、翌日、複数の部門から質問を受けました。問題があり、その理由を見つけるのに午後かかりました。イートンに非難される。。。。

解決策も非常に簡単です:
A マスターに均一にデータを書き込むように変更します
B スクリプトが夜間にマスター上のキャッシュパーティションをクリーンアップするとき、最初にキーを設定してから、flushdb を実行します

データの冗長性を回避し、怠惰になる（これが最小の変更です）ので、私はプランBを採用しました。
最後に、本題に入るために、redis のソースコードを確認したところ、確かに aof モジュールを作成する際に段落があったことがわかりました。これは、おそらく del や flashdb などのコマンドを実行するときに、解放するものがないことが判明したため、aof ファイルには送信されません。このコマンドをに追加します。また、info やmonitor などデータに影響を与えない監視関連のコマンドは aof ファイルに書き込まれません。