环境
| 名称 | 版本号 |
|---|---|
| CentOS | 7.x |
| Redis | 5.0.7 |
Redis安装
192.168.1.136 master
192.168.1.137 slave
192.168.1.138 slave
主从模式
主从也是也就是读写分离。master节点主要进行写操作，多个slaves进行读操作。分解一台节点的压力。
主从模式配置十分简单。这里我选择136作为master节点，其他两台作为slave
如果master不配置密码和绑定IP的话是不需要动的，，主要是配置在slave两台节点上。
cd /usr/local/redis
vi redis.conf
1
2
3
4
5
6
#master的ip和端口
replicaof 192.168.1.136 6379
#如果master有密码 则写密码
masterauth xxxxx
#没有限定ip，所有机器都能访问，所有将保护模式设置为no
protected-mode no
两个slave是相同的配置。
配置结束，直接使用脚本启动Redis。就可以进行测试了。
测试
进入master节点的redis客户端，查看状态
此时两个从节点已经连接上，我们紧接着在master节点上做一些操作
在master节点上可以正常读写操作。
我们再去任意一个slaves节点上进入redis客户端
slave上的节点数据跟master保持一致，并且正常根据key来获取没有问题，但是如何进行写操作会报错，提示只有读权限。
哨兵模式
基于主从模式下进行哨兵模式配置。是一种高可用模式。解决了主从模式下。主节点如果宕机，导致从节点只有可读等问题
先将之前解压过的redis安装文件夹中sentinel.conf拷贝到跟redis.conf同一目录,统一风格
cp ./sentinel.conf /usr/local/redis/
先新建一个文件夹用于存放sentinelx工作用的文件，在配置文件中进行配置
mkdir /usr/local/redis/sentinel/
进去配置所在的位置，修改它
cd /usr/locl/redis/
vi sentinel.conf
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
#关闭保护模式，如果绑定了指定ip就不要改变了
protected-mode no
#守护模式
daemonize yes
#配置log日志
logfile "/usr/local/redis/sentinel/redis-sentinel.log"
#工作空间
mkdir "/usr/local/redis/sentinel"
#配置哨兵 quorum可以理解为投票哨兵个数，当有指定个数哨兵投票，故障节点标记为宕机。
sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1、6379 2
#设置连接redis密码 没有的话可以不设
sentinel auth-pass <master-name> <password>
#master被sentinel认定失效的间隔
sentinel down-after-miliseconds mymaster 3000
#剩余的slaves重新和新的master做同步的并行个数
sentinel parallel-syncs mymaster 1
#主备切换的超时时间，哨兵要去做故障转移。由于哨兵是一个进程，如果哨兵出异常，超过这个时间 会由其他的哨兵来处理。
sentinel failover-timeout mymaster 180000
配置完毕后保存，然后将这份配置文件拷贝到另外两台机器对应的路径下，三台机器的配置是一致的
scp ./sentinel.conf root@192.168.1.137:/usr/local/redis/
scp ./sentinel.conf root@192.168.1.138m sr/local/redis/
哨兵是单独的进程，所以要分别在三台机器上使用命令运行
redis-sentinel ./sentinel.conf
测试
把三台机器的redis和sentinel全部启动。
先进入主节点的客户端，使用info replication
之前我们在新建的/usr/local/redis/sentinel/文件夹下面有相关的日志记录，可以对应着看
tail -fn 100 redis-sentinel.log
这就是主节点的相关信息，有两个slaves，说明目前主从模式是OK的
关闭主节点,然后查看相关log
/etc/init.d/redis_init_script stop
- 先标记136节点主观下线(sdown,136上的哨兵认为它已经不能工作了)
- 投票选举出哨兵的leader用于做后面故障转移
- 将master节点客观下线(odown,当有另外台哨兵认为master已经不能工作了就进行客观下线，具体需要确认的哨兵数量根据配置
quorum来的) - 同步配置文件，最后将
138作为新的master
进入138节点的redis客户端,此时138节点已经是master节点了
如果重新启动了136的redis，它只能作为一个新的slave被加进去。并不存在会恢复之前master身份。
我们可以再做个测试，先进入136节点的redis客户端
然后这是在新master节点138节点的redis客户端
所以得出结论。即便master发生了变化，也不会影响之前的读写分离，sentinel内部都帮我们处理好了
