Redis入门到精通7-Redis主从辅助、哨兵机制、持久化机制
1.主从复制，读写分离
1、Master可以拥有多个Slave；
2、多个salve可以连接同一个Master，还可以链接到其他的slave
3、主从复制不会阻塞Master，在同步数据时，master可以继续处理client请求
4、提供系统的伸缩性。
1.1主从复制过程：
1、slave与master简历连接，发送sync同步命令；
2、master会开启一个后台进程，将数据快照保存到文件中，同时master主进程会开始收集新的写命令并缓存；
3、后台完成保存后，就将文件发送给slave；
4、slave将此文件保存到硬盘上
1.2主从复制配置：
1.2.1 准备从服务器
方法一：
直接新装一台虚拟机并修改IP，重新安装部署或者redis或者从其他机器上copy。
方法二：
使用虚拟机软件自带的克隆功能，克隆一台服务器。移除网卡配置信息，重新配置ip（或者在图形用户界面中修改）。
[root@localhost ~]#rm -rf /etc/udev/rules.d/70-persistent-net.rules [root@localhost ~]#reboot ..... ... . //重启登录 [root@localhost ~] vim /etc/sysconf/network-scripts/ifcfg-eth0
内容修改为：
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=dhcp
[root@localhost ~] service network restart [root@localhost ~] ip add //观察被自动赋予的IP 型如：10.0.31.135 [root@localhost ~] vim /etc/sysconf/network-scripts/ifcfg-eth0
修改为：
DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=static
IPADDR=10.0.31.135
PREFIX=24
GATEWAY=10.0.31.1
DNS1=10.0.31.1
重启网卡并测试网络连接：
[root@localhost ~] service network restart [root@localhost ~] ping www.baidu.com //内网机器就ping一台内网ip
克隆过来的服务器，有redis，,如果新机没有redis，可以用scp命令将redis的源码和redis服务copy到新机器上。
1.2.2 修改从服务器配置文件
主服务器不需要任何变化，只需要修改从服务器的/usr/local/redis/conf/redis.conf
[root@localhost ~]# cd /usr/local/redis/ [root@localhost redis]# ls bin conf [root@localhost redis] vim /usr/local/redis/conf/redis.conf
# slaveof
修改为：slaveof 10.0.31.144 6379
# masterauth
修改为: masterauth redis
1.2.3 依次启动主从节点
[root@localhost bin]# ./redis-server /usr/local/redis/conf/6379.conf
使用info查看role角色即可知道是主服务还是从服务。
1.2.4 验证主从复制
主节点继续写入数据，从节点观察数据；
从服务器写操作，不被允许： 127.0.0.1:6379> set a 1 (error) READONLY You can't write against a read only slave.
主节点模拟宕机，查看丛节点状态。
1.3存在问题
主节点宕机，无法继续写入数据。
2.哨兵模式
有了主从复制的实现之后，我们如果想从服务器进行监控，那么在redis2.6以后提供了一个”哨兵“机制，并在2.8版本以后功能稳定起来。
哨兵：顾名思义，就是监控Redis系统的运行状况。其主要功能有两点：
（1）监控主数据库和从数据库是否正常运行；
（2）主数据库出现故障时，可以自动将从数据库转换为主数据库，实现自动切换。
2.1 实现步骤
在其中一台从服务器配置sentinel.conf，如 135 (为什么要选一台从服务器：主服务器宕机，监听就无法实现，主从服务器都宕机，即便是有监听也没得切换了。当然，如果有多余的机器，可以在新机器上单独部署)。
（1）copy文件sentinel.conf到 /usr/local/redis/conf 中
[root@localhost ~]# cp /usr/local/src/redis3.2/sentinel.conf /usr/local/redis/conf/
（2）修改 sentinel.conf 文件
[root@localhost ~]# vim /usr/local/redis/conf/sentinel.conf
dir： 日志路径，根据自己的要求保存。
sentinel monitor mymaster 10.0.31.144 6379 1
解释 ： #名称 # ip #端口号 # 投票选举次数（即有多少篇就被选举为主，这里节点少，就配置为1）。
sentinel down-after-millisecond mymaster 5000
解释：哨兵程序多久去监控一次集群，#默认 1s 检查一次，这里配置超时5000毫秒为宕机。
sentinel failover-timeout mymaster 900000
解释：若哨兵在 该配置值内未完成failover操作(即发生故障时，m/s切换)，本次failover失败
sentinel parallel-syncs mymaster 1
解释：有多少个从节点
（3）启动sentinel哨兵
/usr/local/redis/bin/redis-server /usr/local/redis/conf/sentinel.conf --sentinel &
（4）查看哨兵相关消息命令
/usr/local/redis/bin/redis-cli -h 10.0.31.135 -p 26379 info sentinel
（5）关闭主服务器查看集群信息：
/usr/local/redis/bin/redis-cli -h 10.0.31.144 -p 26379 6379 shutdown
3.持久化机制
3.1Redis简单事务（期待后续版本更新）
redis的事务非常简单，使用方法：
首先是使用multi开启事务，这是设置的数据都会放在队里进行保存，最后使用exec执行，把数据依次存储到redis中，使用discard方法取消事务。
127.0.0.1:6379> multi OK 127.0.0.1:6379> set a 1 QUEUED 127.0.0.1:6379> set b 2 QUEUED 127.0.0.1:6379> set name jack QUEUED 127.0.0.1:6379> exec 1) OK 2) OK 3) OK 127.0.0.1:6379> keys * 1) "b" 2) "a" 3) "name"
存在问题：redis事务不能保证同时成功或失败进行提交或失败，所以redis事务目前还是比较简单，期待在后续版本中的优化。
127.0.0.1:6379> get a "1" 127.0.0.1:6379> get name "jack" 127.0.0.1:6379> multi OK 127.0.0.1:6379> incr a QUEUED 127.0.0.1:6379> incr name //将字符串类型incr QUEUED 127.0.0.1:6379> exec 1) (integer) 2 2) (error) ERR value is not an integer or out of range 字符串类型incr，报错，此时按照事务的特性，应该都回滚！ 127.0.0.1:6379> get a "2" //incr a 并没有回滚！ 127.0.0.1:6379>
3.2 持久化机制
Redis是支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到硬盘来保证持久化。redis持久化有两种方式
3.2.1 snapshotting 快照（rdb）
默认方式，将内存中以快照的方式写入到二进制文件中，默认为dump.rdb，可以通过配置设置自动做快照持久化的方式。我们可以配置redis在n秒内如果m个key修改，就自动做快照。
snapshotting 设置：redis.conf（本文中的6379.conf）
save 900 1 #900秒内，超过1个key被修改，则发起快照保存
save 300 10 #300秒内，超过10个key被修改，则发起快照保存
save 60 10000 #60秒内，超过10000个key被修改，则发起快照保存
3.2.2 append-only file（aof）
类似于mysql日志，由于快照方式是在一定时间间隔做一次，所以可能发生redis意外宕机的情况就会丢失最后一次快照后的所有被修改的数据，aof比快照方式有更好的持久化型，是由于redis在使用aof是，redis会将每一个收到的写命令都通过write函数追加到命令中，在redis重新启动时会重新执行文件中保存的写命令在内存中重建这个数据库的内容，这个文件在redis3.2/bin目录下，appendonly.aof。aof不是立即写到硬盘上，可以通过配置文件修改强制写到硬盘中。
aof设置：redis.conf（本文中的6379.conf）
appendonly yes //启动aof持久化 ,持久化有三种方式：
#appendfsync always //收到写命令就立即写入到磁盘，效率最慢，但是保证完整的持久化（最常用）
#appendfsync everysec //每秒写一次硬盘，在性能和持久化方面做了很好的这种
#appendfsync no //完全依赖os，性能最好，持久化没保证。
修改6379.conf appendonly yes 重启redis 发现conf/目录下多了一个appendonly.aof [root@localhost conf]# ll 总用量 52 -rw-r--r-- 1 root root 41421 10月 21 11:40 6379.conf -rw-r--r-- 1 root root 86 10月 21 11:42 appendonly.aof -rw-r--r-- 1 root root 41 10月 21 11:41 dump.rdb 执行set操作观察appendonly.aof的内容。
提示：开启aof后之前的rdb模式就时效了，且之前的数据会被清空。