Redisシリーズ-マスターコピー構成
redisは優れた性能を持っていますが、master/slaveという簡単なアーキテクチャを通じて、読み書き分離を行い、redisの性能をさらに掘り起こし、システムの可用性を高めることができます.
redisはどのように主従複製を行いますか?redisレプリケーションは主にmaster serverの永続化rdbファイルによって実現される.master serverはまずメモリスナップショットファイルをdumpし、rdbファイルをslave serverに渡し、slave serverはrdbファイルに基づいてメモリテーブルを再構築します.redisレプリケーションプロセスは次のとおりです.
1、slave serverがmaster serverへの接続を開始した後、salve serverは自主的にSYNCコマンドをmaster serverに送信する
2、master server SYNCコマンドを受け取った後、メモリスナップショットを行っているサブプロセスがあるかどうかを判断し、ある場合はその終了を待つ.そうでない場合、forkはサブプロセスであり、サブプロセスはメモリデータをファイルとして保存し、slave serverに送信する
3、master serverサブプロセスがデータスナップショットを行う場合、親プロセスはclient側からデータの書き込みを要求し続けることができ、この時、親プロセスは新しく書き込まれたデータを送信するキャッシュキューに置く
4、slave serverメモリスナップショットファイルを受信した後、メモリデータを空にし、受信したスナップショットファイルに基づいてメモリテーブルデータ構造を再構築する
5、master serverスナップショットファイルの送信が完了した後、キャッシュキューに保存されているサブプロセススナップショット中に変更されたデータをslave serverに送信し、slave serverと同じ処理を行い、データ整合性を保存する
6、master serverその後に受信したデータは、いずれもステップ1で確立した接続を通じてslave serverにデータを送信する
注意:slave serverネットワークまたはその他の理由でmaster serverとの接続が切断された場合、slave serverが再接続された場合、master serverのメモリスナップショットファイルを再取得する必要があります.slave serverのデータは自動的にすべて空になり、メモリテーブルを再構築すると、slave serverがリカバリサービスを開始するのが遅くなります.同時にmaster serverにも大きな圧力をもたらし、redisのレプリケーションに増分レプリケーションがないという概念が見られる.これはredis主従レプリケーションの主な弊害であり、実際の環境では、途中でライブラリを増やすことをできるだけ避ける.
上記の説明では、redisのプライマリ・セカンダリ・レプリケーションについて概説しましたが、master/slaveの構成方法について説明します.条件の制限のため、ここでは1台のマシンを使用して、2つのプロセスを起動して主従レプリケーションを行います.
マスターサーバプロファイルconf、主な構成は以下の通りです.
slave serverプロファイルslave
.conf,
主な構成は次のとおりです.
slave.confでは、主にslabeofでmasterのipとポートを指定します.マスターとslaveを起動します.
マスターサーバに接続し、データを書き込みます.
slave serverに接続し、データを読みます.
テストの結果から見ると、データは確かに自動的にコピーされました.コピー機能により、masterにデータのみを書き込み、slaveでデータを読み取り、masterの持続化(またはaof)機能をオフにすることで(salveでオン)、masterサーバの読み取り圧力を分担し、masterサーバの性能を向上させるとともに、masterが停止し、master serverをslave serverで迅速に置き換えることができ、システムの可用性を高めることができます.
実際の環境では、redisレプリケーションの特徴に基づいて、独自のレプリケーションアーキテクチャをカスタマイズできます.たとえば、master server->slave server->slave server->slave serverというドラッグアンドドロップ方式を採用すると、従来のドラッグアンドドロップ方式に比べて、データのコピー時のmaster serverの圧力が減少します.もちろん、redisレプリケーションの天然の欠陥のため、アクティブレプリケーションの方式「redisエージェント層、clientがmasterを書く時、複数のmasterを書く」を採用してredisが持参するレプリケーション戦略を最適化することもできますが、アクティブレプリケーションによって、どのようにデータの一貫性を維持するかは小さな挑戦ではありません.
redisプロファイルに関する情報は、以前のblog:Redisシリーズ-プロファイルのまとめを参照してください.
redisはどのように主従複製を行いますか?redisレプリケーションは主にmaster serverの永続化rdbファイルによって実現される.master serverはまずメモリスナップショットファイルをdumpし、rdbファイルをslave serverに渡し、slave serverはrdbファイルに基づいてメモリテーブルを再構築します.redisレプリケーションプロセスは次のとおりです.
1、slave serverがmaster serverへの接続を開始した後、salve serverは自主的にSYNCコマンドをmaster serverに送信する
2、master server SYNCコマンドを受け取った後、メモリスナップショットを行っているサブプロセスがあるかどうかを判断し、ある場合はその終了を待つ.そうでない場合、forkはサブプロセスであり、サブプロセスはメモリデータをファイルとして保存し、slave serverに送信する
3、master serverサブプロセスがデータスナップショットを行う場合、親プロセスはclient側からデータの書き込みを要求し続けることができ、この時、親プロセスは新しく書き込まれたデータを送信するキャッシュキューに置く
4、slave serverメモリスナップショットファイルを受信した後、メモリデータを空にし、受信したスナップショットファイルに基づいてメモリテーブルデータ構造を再構築する
5、master serverスナップショットファイルの送信が完了した後、キャッシュキューに保存されているサブプロセススナップショット中に変更されたデータをslave serverに送信し、slave serverと同じ処理を行い、データ整合性を保存する
6、master serverその後に受信したデータは、いずれもステップ1で確立した接続を通じてslave serverにデータを送信する
注意:slave serverネットワークまたはその他の理由でmaster serverとの接続が切断された場合、slave serverが再接続された場合、master serverのメモリスナップショットファイルを再取得する必要があります.slave serverのデータは自動的にすべて空になり、メモリテーブルを再構築すると、slave serverがリカバリサービスを開始するのが遅くなります.同時にmaster serverにも大きな圧力をもたらし、redisのレプリケーションに増分レプリケーションがないという概念が見られる.これはredis主従レプリケーションの主な弊害であり、実際の環境では、途中でライブラリを増やすことをできるだけ避ける.
上記の説明では、redisのプライマリ・セカンダリ・レプリケーションについて概説しましたが、master/slaveの構成方法について説明します.条件の制限のため、ここでは1台のマシンを使用して、2つのプロセスを起動して主従レプリケーションを行います.
マスターサーバプロファイルconf、主な構成は以下の通りです.
daemonize yes
pidfile /var/run/redis_6379.pid
port 6379
#save 900 1
#save 300 10
#save 60 10000
dbfilename dump.rdb
dir /var/lib/redis/6379
slave serverプロファイルslave
.conf,
主な構成は次のとおりです.
daemonize yes
pidfile /var/run/redis_6379.pid
port 6380
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir /var/lib/redis/6380
slaveof 127.0.0.1 6379slave.confでは、主にslabeofでmasterのipとポートを指定します.マスターとslaveを起動します.
/usr/local/bin/redis-server /etc/redis/master.conf
/usr/local/bin/redis-server /etc/redis/slave.conf
マスターサーバに接続し、データを書き込みます.
[root@xsf001 ~]# redis-cli -p 6379
redis 127.0.0.1:6379> set user.1.name zhangsan
OKslave serverに接続し、データを読みます.
[root@xsf001 ~]# redis-cli -p 6380
redis 127.0.0.1:6380> get user.1.name
"zhangsan"テストの結果から見ると、データは確かに自動的にコピーされました.コピー機能により、masterにデータのみを書き込み、slaveでデータを読み取り、masterの持続化(またはaof)機能をオフにすることで(salveでオン)、masterサーバの読み取り圧力を分担し、masterサーバの性能を向上させるとともに、masterが停止し、master serverをslave serverで迅速に置き換えることができ、システムの可用性を高めることができます.
実際の環境では、redisレプリケーションの特徴に基づいて、独自のレプリケーションアーキテクチャをカスタマイズできます.たとえば、master server->slave server->slave server->slave serverというドラッグアンドドロップ方式を採用すると、従来のドラッグアンドドロップ方式に比べて、データのコピー時のmaster serverの圧力が減少します.もちろん、redisレプリケーションの天然の欠陥のため、アクティブレプリケーションの方式「redisエージェント層、clientがmasterを書く時、複数のmasterを書く」を採用してredisが持参するレプリケーション戦略を最適化することもできますが、アクティブレプリケーションによって、どのようにデータの一貫性を維持するかは小さな挑戦ではありません.
redisプロファイルに関する情報は、以前のblog:Redisシリーズ-プロファイルのまとめを参照してください.