redis3.0 クラスターの機能
マスター スレーブ レプリケーション (読み取り/書き込み分離)
マスター スレーブ レプリケーションのメリットは 2 点です。
マスター/スレーブの設定
6379、6380、6381 ディレクトリを作成し、インストール ディレクトリ内の redis.conf をこれら 3 つのディレクトリにそれぞれコピーします。
これら 3 つのディレクトリにそれぞれ入力し、構成ファイルをそれぞれ変更し、ポートを 6379 (マスター)、6380 (スレーブ)、および 6381 (スレーブ) に設定します。同時に、pidfile ファイルを別のパスに設定します。
redis でマスターとスレーブを設定するには 2 つの方法があります:
Secondメソッド 再起動後、マスターとスレーブのレプリケーション関係は失われます。
マスター/スレーブ情報の表示: INFO レプリケーション
マスター:
role: ロール
connected_slaves : スレーブの数
slave0: スレーブ情報
スレーブ:
マスター-スレーブ-スレーブのアーキテクチャ
読み取り専用スレーブ
デフォルトでは、redis データベースは読み取り専用であり、スレーブとして動作する場合は書き込み操作を実行できません。
構成ファイルで非読み取り専用を有効にできます:slave-read-only no
##レプリケーション プロセスの原則
- 1. スレーブ データベースとマスター データベースの間に MS 関係が確立されると、SYNC コマンドがマスター データベースに送信されます;
- 2.マスター データベースは SYNC コマンドを受信すると、バックグラウンドで保存を開始し、スナップショット (RDB 永続化プロセス) を実行し、その間に受信した書き込みコマンドをキャッシュします。
- #3. スナップショットが作成されると、が完了すると、メイン Redis はスナップショット ファイルとすべてのキャッシュされた書き込みコマンドを Redis に送信します;
- 4. Redis から受信した後、スナップショット ファイルがロードされ、受信したキャッシュされたコマンドがキャッシュされます
- 5. その後、マスター Redis が書き込みコマンドを受信するたびに、データの一貫性を確保するためにコマンドをスレーブ Redis に送信します;
ディスク レプリケーションなし
合格 前回のレプリケーション プロセスから、メイン ライブラリは SYNC コマンドを受信すると RDB プロセスを実行することがわかりました。設定ファイルで RDB 永続性が無効になっている場合でも、メインライブラリが配置されているサーバーのディスク IO パフォーマンスが悪い場合、このレプリケーションプロセスにボトルネックが発生します。幸いなことに、Redis はバージョン 2.8.18 でディスクレスレプリケーション機能を実装しました (ただし、これはこの機能はまだ実験段階です)。
原則: Redis は、スレーブ データベースでのレプリケーションの初期化中にスナップショットをディスクに保存しませんが、ネットワーク経由でスレーブ データベースに直接送信し、IO の低下を回避します。パフォーマンスの質問。
ディスクレス レプリケーションを有効にする:
repl-diskless-sync yes
レプリケーション アーキテクチャでダウンタイムが発生した場合はどうすればよいですか?
マスター/スレーブ レプリケーション アーキテクチャにダウンタイムがある場合は、状況を確認する必要があります:
1. スレーブ Redis のダウンタイム
a) 这个相对而言比较简单，在Redis中从库重新启动后会自动加入到主从架构中，自动完成同步数据；
b) 问题？ 如果从库在断开期间，主库的变化不大，从库再次启动后，
主库依然会将所有的数据做RDB操作吗？还是增量更新？（从库有做持久化的前提下）
ログイン後にコピー
No はい、Redis バージョン 2.8 以降に実装されており、マスターとスレーブが切断後に回復したときに増分レプリケーションを実現できるためです。
#2. Redis のメイン ダウンタイム
これは比較的複雑で、完了するには次の 2 つの手順が必要です
i. 第一步，在从数据库中执行SLAVEOF NO ONE命令，断开主从关系并且提升为主库继续服务；
ii. 第二步，将主库重新启动后，执行SLAVEOF命令，将其设置为其他库的从库，这时数据就能更新回来；
ログイン後にコピー
This手動による回復プロセスは実際には非常に面倒でエラーが発生しやすいのですが、それを解決する良い方法はありますか?現在、Redis ではセンチネル機能が改善されています。
Sentinel
Sentinel とは
名前が示すように、Sentinel の役割は Redis システムの動作を監視することです。独立したプロセス。
1. マスター データベースとスレーブ データベースが正常に動作しているかどうかを監視します; -
原理
单个哨兵的架构：
多个哨兵的架构：
多个哨兵，不仅同时监控主从数据库，而且哨兵之间互为监控。
配置哨兵
启动哨兵进程首先需要创建哨兵配置文件：
vim sentinel.conf
ログイン後にコピー
ログイン後にコピー
输入内容：
sentinel monitor taotaoMaster 127.0.0.1 6379 1
ログイン後にコピー
说明：
taotaoMaster：监控主数据的名称，自定义即可，可以使用大小写字母和“.-_”符号
127.0.0.1：监控的主数据库的IP
6379：监控的主数据库的端口
1：最低通过票数
ログイン後にコピー
启动哨兵进程：
redis-sentinel ./sentinel.conf
ログイン後にコピー
由上图可以看到：
配置多个哨兵
vim sentinel.conf
ログイン後にコピー
ログイン後にコピー
输入内容：
sentinel monitor taotaoMaster 127.0.0.1 6381 2
sentinel monitor taotaoMaster2 127.0.0.1 6381 1
ログイン後にコピー
集群
即使有了主从复制，每个数据库都要保存整个集群中的所有数据，容易形成木桶效应。
使用Jedis实现了分片集群，是由客户端控制哪些key数据保存到哪个数据库中，如果在水平扩容时就必须手动进行数据迁移，而且需要将整个集群停止服务，这样做非常不好的。
Redis3.0版本的一大特性就是集群（Cluster），接下来我们一起学习集群。
架构
(2)Redis节点之间互相连接并采用二进制协议以优化传输速度和带宽利用。同时也使用PING-PONG机制来确保连接稳定
(2)节点的fail是通过集群中超过半数的节点检测失效时才生效.
(3)客户端与redis节点直连,不需要中间proxy层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可
(4)redis-cluster把所有的物理节点映射到[0-16383]slot（插槽）上,cluster 负责维护node<->slot<->value
修改配置文件
1、 设置不同的端口，6379、6380、6381
2、 开启集群，cluster-enabled yes
3、 指定集群的配置文件，cluster-config-file “nodes-xxxx.conf”
创建集群
首先，进入redis的安装包路径下：
cd /usr/local/src/redis/redis-3.0.1/src/
执行命令：
./redis-trib.rb create --replicas 0 192.168.56.102:6379 192.168.56.102:6380 192.168.56.102:6381
ログイン後にコピー
–replicas 0：指定了从数据的数量为0
注意：这里不能使用127.0.0.1，否则在Jedis客户端使用时无法连接到！
redis-trib用法：
测试
什么情况？？(error) MOVED 7638 127.0.0.1:6380
因为abc的hash槽信息是在6380上，现在使用redis-cli连接的6379，无法完成set操作，需要客户端跟踪重定向。
插槽的分配
通过cluster nodes命令可以查看当前集群的信息：
该信息反映出了集群中的每个节点的id、身份、连接数、插槽数等。
当我们执行set abc 123命令时，redis是如何将数据保存到集群中的呢？执行步骤：
1、 接收命令set abc 123
2、 通过key（abc）计算出插槽值，然后根据插槽值找到对应的节点。（abc的插槽值为：7638）
3、 重定向到该节点执行命令
ログイン後にコピー
整个Redis提供了16384个插槽，也就是说集群中的每个节点分得的插槽数总和为16384。
./redis-trib.rb 脚本实现了是将16384个插槽平均分配给了N个节点。
注意：如果插槽数有部分是没有指定到节点的，那么这部分插槽所对应的key将不能使用。
插槽和key的关系
计算key的插槽值：
key的有效部分使用CRC16算法计算出哈希值，再将哈希值对16384取余，得到插槽值。
什么是有效部分？
新增集群节点
再开启一个实例的端口为6382
执行脚本：
./redis-trib.rb add-node 192.168.56.102:6382 192.168.56.102:6379
ログイン後にコピー
已经添加成功！查看集群信息：
发现没有插槽数。
接下来需要给6382这个服务分配插槽，将6379的一部分（1000个）插槽分配给6382：
查看节点情况：
删除集群节点
想要删除集群节点中的某一个节点，需要严格执行2步：
1、 将这个节点上的所有插槽转移到其他节点上；
a) 假设我们想要删除6380这个节点
b) 执行脚本：./redis-trib.rb reshard 192.168.56.102:6380
c) 选择需要转移的插槽的数量，因为3380有5128个，所以转移5128个
d) 输入转移的节点的id，我们转移到6382节点：82ed0d63cfa6d19956dca833930977a87d6ddf7
e) 输入插槽来源id，也就是6380的id
f) 输入done，开始转移
g) 查看集群信息，可以看到6380节点已经没有插槽了。
ログイン後にコピー
2、 使用redis-trib.rb删除节点
a) ./redis-trib.rb del-node 192.168.56.102:6380 4a9b8886ba5261e82597f5590fcdb49ea47c4c6c
b) del-node host:port node_id
c)
d) 查看集群信息，可以看到已经没有6380这个节点了。
ログイン後にコピー
故障机制
1、 集群中的每个节点都会定期的向其它节点发送PING命令，并且通过有没有收到回复判断目标节点是否下线；
2、 集群中每一秒就会随机选择5个节点，然后选择其中最久没有响应的节点放PING命令；
3、 如果一定时间内目标节点都没有响应，那么该节点就认为目标节点疑似下线；
4、 当集群中的节点超过半数认为该目标节点疑似下线，那么该节点就会被标记为下线；
5、 当集群中的任何一个节点下线，就会导致插槽区有空档，不完整，那么该集群将不可用；
6、 如何解决上述问题？
a) 在Redis集群中可以使用主从模式实现某一个节点的高可用
b) 当该节点（master）宕机后，集群会将该节点的从数据库（slave）转变为（master）继续完成集群服务；
ログイン後にコピー
集群中的主从复制架构
架构：
出现故障：
4.9.3. 创建主从集群
需要启动6个redis实例，分别是：
6379（主） 6479（从）
6380（主） 6480（从）
6381（主） 6481（从）
启动redis实例：
cd 6379/ && redis-server ./redis.conf && cd ..
cd 6380/ && redis-server ./redis.conf && cd ..
cd 6381/ && redis-server ./redis.conf && cd ..
cd 6479/ && redis-server ./redis.conf && cd ..
cd 6480/ && redis-server ./redis.conf && cd ..
cd 6481/ && redis-server ./redis.conf && cd
ログイン後にコピー
创建集群，指定了从库数量为1，创建顺序为主库（3个）、从库（3个）：
./redis-trib.rb create --replicas 1 192.168.56.102:6379 192.168.56.102:6380 192.168.56.102:6381 192.168.56.102:6479 192.168.56.102:6480 192.168.56.102:6481
ログイン後にコピー
以上がRedisクラスターの特徴は何ですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
