記事ディレクトリ
1 スタンドアロンの Redis には 4 つの大きな問題があります
1.1 データ損失の問題
| 解決 | Redis データの永続性を実現する |
|---|
永続性: Redis キャッシュはメモリに格納されますが、メモリにはデータが格納されず (メモリの読み取りと書き込みが高速)、ディスクにはデータが格納されます (より多くの IO 相互作用、読み取りと書き込みが遅い) ため、Redis をメモリに格納し、データを永続的に格納する必要があります。ディスク中央へ。
1.2 障害回復の問題
| 解決 | Redis Sentinel を使用してヘルス検出と自動回復を実現する |
|---|
1.3 並行性の問題
| 解決 | マスター/スレーブ クラスタを構築して読み書き分離を実現する |
|---|
1.4 ストレージ容量の問題
| 解決 | シャード クラスターを構築します。動的な拡張を実現するスロット機構を使用 |
|---|
2 データ損失の問題: Redis の永続性は RDB と AOF を解決します
2.1 RDB の永続性
RDB(Redis データベース バックアップ ファイル) (Redis データ バックアップ ファイル): とも呼ばれますRedis数据快照。把内存中的数据记录到磁盘中.
Redis インスタンスが失敗して再起動したら、RDB文件ディスクからスナップショット ファイル ( ) を読み取り、データを復元します。デフォルトでは、現在実行中のディレクトリに保存されます。
2.1.1 実行タイミング
| 実行時間 | 説明 | テスト |
|---|---|---|
| 保存コマンドを実行する | save コマンドにより、メイン プロセスが RDB を実行し、他のコマンドはプロセス中にブロックされます。只有在数据迁移时可能用到此命令 |
 |
| bgsave コマンドを実行します | このコマンドは、异步执行RDB実行後に开启独立进程RDB を完了することができ、メイン プロセスは影響を受けることなくユーザー リクエストの処理を続行できます。 |
 |
| ダウンタイム | Redis がダウンしているときに保存コマンドを実行して、RDB の永続性を実現します。 |  |
| トリガー RDB 条件 | Redis 内にはトリガー RDB メカニズムがあり、redis.conf ファイルで変更できます。 |   |
2.1.2 トリガー RDB 条件とその他の構成
Redis には RDB をトリガーするメカニズムがあり、これは redis.conf ファイルにあり、形式は次のとおりです。
# 900秒内，如果至少有1个key被修改，则执行bgsave ， 如果是save "" 则表示禁用RDB
save 900 1
save 300 10
save 60 10000
RDB の他の構成も redis.conf ファイルで設定できます。形式は次のとおりです。
# 是否压缩 ,建议不开启，压缩也会消耗cpu，磁盘的话不值钱
rdbcompression yes
# RDB文件名称
dbfilename dump.rdb
# 文件保存的路径目录
dir ./
2.1.3 RDBの原理
RDB の原則: まず、bgsave が開始されると、fork のメイン プロセスが子プロセスを取得し、子プロセスはメイン プロセスの保存データを共有します。次に、フォークが完了すると、メモリ データが読み取られ、RDB ファイルに書き込まれます。
fork采用copy-on-write技术：
- メイン プロセスが読み取り操作を実行すると、共有メモリにアクセスします。
- メイン プロセスが書き込み操作を実行すると、データのコピーがコピーされ、書き込み操作が実行されます。
2.1.4 RDB モードでの bgsave の基本的な処理
まず、fork のメイン プロセスがメモリ空間を共有するプロセスを取得します。次に、子プロセスがメモリ データを読み取り、新しい RDB ファイルに書き込みます。最後に、古い RDB ファイルを新しい RDB ファイルに置き換えます。
2.1.5 RDBのデメリット
- RDB の実行間隔が長い (必要があるため)
保存一时刻redis缓存的所有快照、两次RDB之间写入数据丢失风险- 子プロセスのフォーク、圧縮、RDB ファイルの書き出しに時間がかかる
2.2 AOF 永続性
2.2.1 AOFの原理
AOF (追加専用ファイル): Redis によって処理されるすべての書き込みコマンドは、AOF ファイル (コマンド ログ ファイル) に記録する必要があります。
2.2.2 AOF 構成
2.2.2.1 AOF はデフォルトで無効になっています。redis.conf 設定ファイルを変更して AOF を有効にします。
# 是否开启AOF功能，默认是no
appendonly yes
# AOF文件的名称
appendfilename "appendonly.aof"
2.2.3 AOF コマンド記録頻度の 3 つの戦略
# 表示每执行一次写命令，立即记录到AOF文件
appendfsync always
# 写命令执行完先放入AOF缓冲区，然后表示每隔1秒将缓冲区数据写到AOF文件，是默认方案
appendfsync everysec
# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
appendfsync no
2.2.4 AOF ファイルの書き換え
2.2.4.1 書き直す理由:
AOF 方式はコマンドを記録するため、RDB 方式で生成されるファイルは非常に大きくなります。**
2.2.4.2 書き直しのアイデア:
たとえば、同じキーに対する複数の操作の場合、最後の操作のみが意味を持つため、そのような操作で生成されるガベージ コマンドを削減する必要があります。
2.2.4.3 実装:
コマンドを実行して
bgrewriteaofAOF ファイルに書き換え機能を実行させ、最小限のコマンドで同じ効果を実現します。
2.2.4.4 しきい値がトリガーされると、Redis は AOF ファイルも自動的に書き換えます。しきい値は redis.conf で設定することもできます:
# AOF文件比上次文件 增长超过多少百分比则触发重写
auto-aof-rewrite-percentage 100
# AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size 64mb
2.3 RDBとAOFの比較
3 同時実行の問題: Redis マスター/スレーブ
3.1 Redis マスター/スレーブ アーキテクチャを構築する理由
単一ノード Redis の同時実行能力には上限があり、同時実行能力を向上させる必要がある場合は、マスター/スレーブ クラスタを構築して読み書き分離を実現する必要があります。
3.1 マスタースレーブ アーキテクチャの構築
3.2 マスタースレーブデータ同期原理
3.2.1 完全同期
マスタースレーブデータ同期の原理: まず、マスタースレーブが最初に接続を確立するときに、完全同期を実行します (ネットワークを介して RDB ファイルをスレーブに転送します)。
3.2.2 質問: マスターは軟膏が初めて接続されたことをどのように認識しますか? そしてマスターは、この軟膏が自身のスレーブノードであることをどのように判断するのでしょうか?
回答: スレーブはデータ同期を実行します. まず, スレーブはマスターにデータを送信します
自己原有的replid和offset. マスターがスレーブによって送信された応答がそれ自体と同じであることを発見した場合不一致, これはこれ全新slaveを行う必要があることを意味します全量同步. その後,スレーブは情報をmaster独自に保存します。replid和offset发送给slave将来的には、スレーブのレプリカはマスターと同じになり一致、スレーブが独自のスレーブ ノードであることも決定されます。つまり、ノードが初めて同期されるかどうかをマスターが判断します。基準は です
比较replid是否相同。
| 名詞 | 説明 |
|---|---|
| レプリケーション ID (replid) (データセット タグ) | 同じ ID は同じデータ セットを示します。各マスターには固有の応答があり、スレーブはマスター ノードの応答を継承します。 |
| オフセット (オフセット) | repl_baklog のデータの増加とともに増加します。スレーブが同期を完了すると、現在の同期オフセットが記録されます。たとえばslave的offset小于master的offset、スレーブデータを記述する場合は落后于master必須です更新。 |
3.2.3 増分同期
4 障害回復の問題: Redis Sentinel
5 ストレージ容量の問題: Redis シャーディング クラスタ
マスター マスター ノードのレプリケーションに RDB を使用する理由は? AOF を使用しない理由は?
回答: 誤解、最初に RDB、次に AOF、つまり RDB と AOF の組み合わせ