Redis学习笔记(三) Redis主从架构和主从从架构 (1)
准备
修改pidfile 为下面做准备
关闭RDB持久化修改持久化文件的保存位置
启动Redis
redis-server /etc/redis.conf使用客户端连接Redis
redis-cli连接成功,接下来就可以愉快的玩耍啦~~~
主从复制(读写分离)
Redis的主从复制功能非常强大，一个master可以拥有多个slave,而一个slave又可以拥有多个slave,如此下去,形成了强大的多级服务器集群架构. 可以避免Redis单点故障,构建读写分离架构,满足读多写少的应用场景.
Redis复制功能的几个重要方面
1. 一个Master可以有多个Slave；
2. Redis使用异步复制。从2.8开始，Slave会周期性（每秒一次）发起一个Ack确认复制流（replication stream）被处理进度；
3. 不仅主服务器可以有从服务器，从服务器也可以有自己的从服务器，多个从服务器之间可以构成一个图状结构；
4. 复制在Master端是非阻塞模式的，这意味着即便是多个Slave执行首次同步时，Master依然可以提供查询服务；
5. 复制在Slave端也是非阻塞模式的：如果你在redis.conf做了设置，Slave在执行首次同步的时候仍可以使用旧数据集提供查询；你也可以配置为当Master与Slave失去联系时，让Slave返回客户端一个错误提示；
6. 当Slave要删掉旧的数据集，并重新加载新版数据时，Slave会阻塞连接请求（一般发生在与Master断开重连后的恢复阶段）；
7. 复制功能可以单纯地用于数据冗余（dataredundancy），也可以通过让多个从服务器处理只读命令请求来提升扩展性（scalability）：比如说，繁重的 SORT 命令可以交给附属节点去运行。
8. 可以通过修改Master端的redis.config来避免在Master端执行持久化操作（Save），由Slave端来执行持久化。
主从架构
准备3个配置文件端口分别为
6379 (Master)
6380 (Slave)
6381 (Slave)
修改原来的redis.conf文件 ,拷贝出2个redis.conf文件
mv /etc/redis.conf /etc/redis.6379.conf
cp /etc/redis.6379.conf /etc/redis.6380.conf
cp /etc/redis.6379.conf /etc/redis.6381.conf
通过vi修改6380 和 6381 配置文件
vi /etc/redis.6380.conf通过命令替换 6379 为 6380
:%s/6379/6380/g
表示修改成功, wq退出并保存
用一样的方式修改6381 的配置文件
注意: 配置文件在前面已经修改pidfile 参数,如果没有修改一定要修改该参数为不同的值
通过配置文件启动3个Redis实例
通过ps 命令查看Redis进程
主从的配置有2种方法:
在redis.conf中设置 slaveof
使用redis-cli客户端连接到Redis服务中,执行slaveof命令
这种方式在重启之后就会失去主从复制关系
修改6381的配置文件 ,然后重启6381 .
通过redis-cli进入6379这个服务
查看主从信息：INFO replication
从库显示的信息
测试主从关系
在主库写入数据 ,然后在从库读取数据
主从从结构
主从从架构就是
Master下面有个 Slave , 而Slave下面还有一个Slave
我们吧 6381 重启一下
此时的主从信息
只剩下一主一从了
然后使用redis-cli客户端连接到Redis服务,执行slaveof命令
查看此时的主从信息
6379:
6379只有一个从库 6380
6380:
6380有一个主库 6379 还有一个从库 6381
6381:
6381只有一个主库 6380
这样主从从架构就搭建好了
测试 , 先清空key
在主库中设置数据
在从库中获取数据
6380 和 6381都已经获取到数据了
好了,主从从架构搭建完成!
从库只读
默认情况下redis数据库充当slave角色时是只读的不能进行写操作。
如果进行写操作就会报错
我们可以修改Redis的配置文件的配置参数slave-read-only, 修改为no
数据同步的过程
① 当从库和主库建立MS关系后，会向主数据库发送SYNC命令(同步命令);
② 主库接收到SYNC命令后会开始在后台保存快照（RDB持久化过程），并将期间接收到的写命令缓存起来;所以就算关掉了RDB持久化方式,在他们同步的时候也会产生RDB文件
以上主库只做了2件事情
将接收的命令进行RDB持久化
在RDB持久化中,将接收的命令缓存起来
① 当快照完成后，主Redis会将快照文件和所有缓存的写命令发送给从Redis;
② 从Redis接收到后，会载入快照文件并且执行收到的缓存的命令;
③ 之后，主Redis每当接收到写命令时就会将命令发送从Redis，从而保证数据的一致;
在这个过程中主从同步是通过RDB来同步数据, 即使禁用了RDB也没有用,那么就会产生IO问题,在这个复制过程可能就会出现瓶颈. Redis在2.8.18版本开始实现了无磁盘复制功能
Redis在与从库进行复制初始化时将不会吧快照储存到磁盘,而是直接通过网络发送给从库,避免了IO性能问题.
修改repl-diskless-sync 为 yes
宕机处理
在主从架构中出现了宕机的情况
① Slave 宕机
在Redis中,从库重新启动会自动加入到主从架构中,自动完成同步数据
Redis 2.8之后,在从库有做持久化的前提下,如果从库在断开的期间,主库的变化不大,从库再次启动后,主库不会将或有的数据进行RDB操作,而是进行增量复制
② Master 宕机
一 : 在Slave中执行SLAVEOF NO ONE 命令,断开主从关系并且提升为主库继续服务;
二 : 将主库重新启动后,执行 SLAVEOF命令,将其设置为其他Redis的从库,这个时候数据就同步回来了;
这样通过人工的方式来处理Redis的宕机情况步骤虽然少,但是还是容易出现异常的,下面我们通过Redis的哨兵(sentinel)功能来实现高可用的架构