モデレーターの呼びかけに応えて、入門的な教育記事をいくつか投稿します。Redis のマスター/スレーブ レプリケーション プロセスと、オンライン ビジネスでバグの原因となった私が発見した目立たない機能について簡単に説明します。

モデレーターの呼びかけに応えて、入門的な教育記事をいくつか投稿したいと思います。Redis のマスター/スレーブ レプリケーション プロセスと、オンライン ビジネスでバグの原因となった私が発見した目立たない機能について簡単に説明します
前に書きます:

PHP とは直接関係はありませんが、現在では redis が非常に主流になっており、効率が低いことに不満を持ちながらもリアルタイムで 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 に接続します。サーバースレーブでは、この値が同期されていることがわかります。


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

スレーブ:


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


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

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

を実行します。データの冗長性を回避し、怠惰にするため (変更が最小限になるように)、プラン B を採用しました。
最後に、真相を解明するために、redis のソース コードを調べたところ、確かに aof モジュールに段落があることがわかりました。これは、おそらく del やフラッシュdb などのコマンドを実行するときに、リリースするものがないことがわかったので、このコマンドを aof ファイルに追加するように報告しませんでした。また、info やmonitor などデータに影響を与えない監視関連のコマンドは aof ファイルに書き込まれません。
------解決策---------
Mysqlのメモリテーブルの使い方、よくわかりました ギャップメモリとハードディスク間のデータ読み取りの間は、基本的には memcache
-----解決策----- - ---
良い点
-----解決策---------
ハイチャンは良いです、理解してください。 。 。
------解決策------------------
気に入っていただければ、PHP プログラミングを学びたいと思っています
-----解決策---------

- -----解決策---------------------

----- -解決策 --------------------
サポート :)
-----解決策----- - ----------------


シャドウスナイパー兄弟、ありがとう！
------解決策-----
共有していただきありがとうございます
- -----解決策------------------
通りすがりのphp初心者
-----解決策 - -------------------
悪くない、それについて学ぶチャンスがある
-----解決策- --- ----------------
わかりました、共有してくれてありがとう！
------解決策---------
上部の小さなクリック
------解決策----------------------
わかりました、共有してくれてありがとう！