redis群集——主从、哨兵模式
一.redis群集
1.单节点redis服务器带来的问题
单点故障，服务不可用
无法处理大量的并发数据请求
数据丢失一大灾难
解决方法
搭建redis集群
2.redis集群介绍
Redis 集群是一个提供在多个Redis间节点间共享数据的程序集。
Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据,从而达不到像Redis那样的性能,在高负载的情况下可能会导致不可预料的错误.
Redis 集群通过分区来提供一定程度的可用性,在实际环境中当某个节点宕机或者不可达的情况下继续处理命令.
3.Redis 集群的优势:
自动分割数据到不同的节点上。
整个集群的部分节点失败或者不可达的情况下能够继续处理命令。
4.Redis 集群的数据分片
Redis 集群没有使用一致性hash, 而是引入了 哈希槽的概念.
Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点，那么:
节点 A 包含 0 到 5500号哈希槽.
节点 B 包含5501 到 11000 号哈希槽.
节点 C 包含11001 到 16384号哈希槽.
这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我想移除节点A,需要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.
5.Redis 集群的主从复制模型
为了使在部分节点失败或者大部分节点无法通信的情况下集群仍然可用，所以集群使用了主从复制模型,每个节点都会有N-1个复制品.
在我们例子中具有A，B，C三个节点的集群,在没有复制模型的情况下,如果节点B失败了，那么整个集群就会以为缺少5501-11000这个范围的槽而不可用.
然而如果在集群创建的时候（或者过一段时间）我们为每个节点添加一个从节点A1，B1，C1,那么整个集群便有三个master节点和三个slave节点组成，这样在节点B失败后，集群便会选举B1为新的主节点继续服务，整个集群便不会因为槽找不到而不可用了.
不过当B和B1 都失败后，集群是不可用的.
6.配置过程
所需环境
主服务器M1 192.168.13.128
主服务器M2 192.168.13.135
主服务器M3 192.168.13.136
从服务器S1 192.168.13.129
从服务器S2 192.168.13.137
从服务器S3 192.168.13.138
在两台服务器上都安装Redis
tar zxvf redis-5.0.4.tar.gz
cd redis-5.0.4/
make
make PREFIX=/usr/local/redis install
ln -s /usr/local/redis/bin/* /usr/local/bin/
cd utils
./install_server.sh
在两台服务器上修改配置文件
[root@localhost utils]# vim /etc/redis/6379.conf
#bind 127.0.0.1 ##注释第70行的监听127地址,已监听所有地址
protected-mode no ##去掉第89行注释关闭安全保护
port 6379 ##去掉第93行注释,开启端口6379
daemonize yes ##去掉第137行注释,以独立进程启动
cluster-enabled yes ##去掉第833行注释,开启群集功能
cluster-config-file nodes-6379.conf ##去掉第841行注释,群集名称文件设置
cluster-node-timeout 15000 ##去掉第847行注释,群集超时时 间设置
appendonly yes ##去掉第700行注释,开启aof持久化
[root@localhost utils]# /etc/init.d/redis_6379 restart ##重启服务
Stopping ...
Redis stopped
Starting Redis server...
[root@localhost utils]# cd /var/lib/redis/6379/
[root@localhost 6379]# ls
appendonly.aof dump.rdb nodes-6379.conf ##生成aof,rdb和节点文件
在主服务器上安装rvm，Ruby控制群集软件
[root@master 6379]# gpg --keyserver hkp://keys.gnupg.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3
##导入key文件
[root@master 6379]# curl -sSL https://get.rvm.io | bash -s stable ##安装rvm
[root@localhost utils]# source /etc/profile.d/rvm.sh ##执行环境变量
[root@localhost utils]# rvm list known ##列出ruby可以安装的版本
[root@localhost utils]# rvm install 2.4.1 ##安装2.4.1 版本
[root@localhost utils]# rvm use 2.4.1 ##使用rubyruby2.4.1 版本
Using /usr/local/rvm/gems/ruby-2.4.1
[root@localhost utils]# ruby -v ##查看当前ruby2.4.1 版本
ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux]
[root@localhost utils]# gem install redis #再次安装Redis
在主服务器和从服务器上各添加两块网卡
并且重启网卡，关闭防火墙和安全功能
[root@slave utils]# service network restart ##重启网卡
[root@slave utils]# systemctl stop firewalld.service ##关闭防火墙
[root@slave utils]# setenforce 0
在master服务器上创建集群
##6个实例分为三组，每组一主一从
[root@master ruby-2.4.1]# redis-cli --cluster create 192.168.13.128:6379 192.168.13.129:6379 192.168.13.135:6379 192.168.13.136:6379 192.168.13.137:6379 192.168.13.138:6379 --cluster-replicas 1
##创建群集，每组一主一从
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 192.168.13.137:6379 to 192.168.13.128:6379
Adding replica 192.168.13.138:6379 to 192.168.13.129:6379
Adding replica 192.168.13.136:6379 to 192.168.13.135:6379
M: 6e0414dbd3045b2793b07be884d7335fd008a72d 192.168.13.128:6379
slots:[0-5460] (5461 slots) master ##128，129，135为主
M: cdea81d9007892c55c637e3416993d30fe297ba3 192.168.13.129:6379
slots:[5461-10922] (5462 slots) master
M: 6e0414dbd3045b2793b07be884d7335fd008a72d 192.168.13.135:6379
slots:[10923-16383] (5461 slots) master
S: 6e0414dbd3045b2793b07be884d7335fd008a72d 192.168.13.136:6379
replicates 6e0414dbd3045b2793b07be884d7335fd008a72d ##136，137，138为副本
S: cdea81d9007892c55c637e3416993d30fe297ba3 192.168.13.137:6379
replicates 6e0414dbd3045b2793b07be884d7335fd008a72d
S: cdea81d9007892c55c637e3416993d30fe297ba3 192.168.13.138:6379
replicates cdea81d9007892c55c637e3416993d30fe297ba3
...
Can I set the above configuration? (type 'yes' to accept): yes ##选择yes
验证群集读写原理
[root@master opt]# redis-cli -h 192.168.13.129 -p 6379 ##主服务器
192.168.13.129:6379> set name zhangsan ##创建键值对
OK
192.168.13.129:6379> keys *
1) "name"
192.168.13.129:6379> get name
"zhangsan"
192.168.13.129:6379> exit
[root@master opt]# redis-cli -h 192.168.13.137 -p 6379 ##从服务器
192.168.13.137:6379> keys * ##查看从上也有
1) "name"
192.168.13.137:6379> get name
"zhangsan"
[root@master opt]# redis-cli -h 192.168.13.128 -p 6379
192.168.13.128:6379> hset person age 20 ##用hash方式建立键值对
(integer) 1
192.168.13.128:6379> hset person name lisi
(integer) 1
192.168.13.128:6379> keys *
1) "person"
192.168.13.128:6379> hget person age ##获取键的值
"20"
192.168.13.128:6379> expire person 5 ##设置键的删除时间5s
(integer) 1
192.168.13.128:6379> keys *
1) "person"
192.168.13.128:6379> keys *
(empty list or set)
二.redis主从模式
是三种集群方式里最简单的。它主要是基于Redis的主从复制特性架构的。通常我们会设置一个主节点，N个从节点;默认情况下，主节点负责处理使用者的IO操作，而从节点则会对主节点的数据进行备份，并且也会对外提供读操作的处理。
1.主要的特点如下：
1.主从模式下，当某一节点损坏时，因为其会将数据备份到其它Redis实例上，这样做在很大程度上可以恢复丢失的数据。
2.主从模式下，可以保证负载均衡，这里不再叙说了
3.主从模式下，主节点和从节点是读写分离的。使用者不仅可以从主节点上读取数据，还可以很方便的从从节点上读取到数据，这在一定程度上缓解了主机的压力。
4.从节点也是能够支持写入数据的，只不过从从节点写入的数据不会同步到主节点以及其它的从节点下。
从以上，我们不难看出Redis在主从模式下，必须保证主节点不会宕机——一旦主节点宕机，其它节点不会竞争称为主节点，此时，Redis将丧失写的能力。这点在生产环境中，是致命的。
2.全量同步
Redis全量复制一般发生在slave初始化阶段，这时slave需要将master上的所有数据都复制一份。具体步骤如下：
1.从服务器连接主服务器，发送SYNC命令
2.主服务器接收到SYNC命令之后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令
3.主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令
4.从服务器接收到快照文件后丢弃所有旧数据，载入收到的快照
5.主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令
6.从服务器完成快照的载入，开始接收命令的请求，并执行来自主服务器缓冲区的写命令
3.增量同步
Redis增量复制是指slave初始化后开始正常工作时主服务器发送的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令
4.配置方式
所有redis服务器配置（主、从）
vi /etc/redis/6379.conf
bind 0.0.0.0 #修改监听地址为0.0.0.0（实验使用），现网环境建议 绑定从服务器IP地址
daemonize yes #开启守护进程
logfile /var/log/redis_6379.log #修改日志文件目录
dir /var/lib/redis/6379 #修改工作目录
appendonly yes #开启AOF持久化功能
slave从节点配置
replicaof 192.168.13.129 6379 #同步master节点IP和端口
验证
tail -f /var/log/redis_6379.log #主节点查看日志
##主节点上验证从节点
redis-cli
info replication
role:master
connected_slave:2 #从节点数量
slave0:ip=192.168.13.129,port=6379,state=online,offset=1246,lag=0
slave0:ip=192.168.13.137,port=6379,state=online,offset=1246,lag=1
##两台从节点详细信息
三.哨兵模式
是基于主从模式做的一定变化，它能够为Redis提供了高可用性。在实际生产中，服务器难免不会遇到一些突发状况：服务器宕机，停电，硬件损坏等。这些情况一旦发生，其后果往往是不可估量的。而哨兵模式在一定程度上能够帮我们规避掉这些意外导致的灾难性后果。其实，哨兵模式的核心还是主从复制。只不过相对于主从模式在主节点宕机导致不可写的情况下，多了一个竞选机制——从所有的从节点竞选出新的主节点。竞选机制的实现，是依赖于在系统中启动一个sentinel进程。
1.sentinel特点：
1.监控：它会监听主服务器和从服务器之间是否在正常工作。
2.通知：它能够通过API告诉系统管理员或者程序，集群中某个实例出了问题。
3.故障转移：它在主节点出了问题的情况下，会在所有的从节点中竞选出一个节点，并将其作为新的主节点。
4.提供主服务器地址：它还能够向使用者提供当前主节点的地址。这在故障转移后，使用者不用做任何修改就可以知道当前主节点地址。
sentinel，也可以集群，部署多个哨兵，sentinel可以通过发布与订阅来自动发现Redis集群上的其它sentinel。sentinel在发现其它sentinel进程后，会将其放入一个列表中，这个列表存储了所有已被发现的sentinel。
集群中的所有sentinel不会并发着去对同一个主节点进行故障转移。故障转移只会从第一个sentinel开始，当第一个故障转移失败后，才会尝试下一个。当选择一个从节点作为新的主节点后，故障转移即成功了(而不会等到所有的从节点配置了新的主节点后)。这过程中，如果重启了旧的主节点，那么就会出现无主节点的情况，这种情况下，只能重启集群。
当竞选出新的主节点后，被选为新的主节点的从节点的配置信息会被sentinel改写为旧的主节点的配置信息。完成改写后，再将新主节点的配置广播给所有的从节点。
2.配置
所有redis服务器配置（主、从）
vi /etc/redis/6379.conf
bind 0.0.0.0 #修改监听地址为0.0.0.0（实验使用），现网环境建议 绑定从服务器IP地址
daemonize yes #开启守护进程
logfile /var/log/redis_6379.log #修改日志文件目录
dir /var/lib/redis/6379 #修改工作目录
appendonly yes #开启AOF持久化功能
所有从节点配置
##所有节点都需要修改
vi redis-5.0.4/sentinel.conf
protected-mode no #关闭保护模式
daemonize yes #指定sentinel为后台启动
logfile "/var/log/sentinel.log" #指定日志存放路径
dir "/var/lib/redis/6379" #指定数据库存放路径
sentinel monitor mymaster 192.168.13.128 6379 2 #至少几个哨兵检测到主服 务器故障了，才会进行故障迁移
sentinel down-after-milliseconds mymaster 3000 #判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel failover-timeout mymaster 180000 #故障节的的最大超时时间为180000（180秒）
启动哨兵模式
redis-sentinel redis-5.0.4/sentinel.conf &
查看哨兵信息
redis-cli -h 192.168.13.128 -p 26379 info Sentinel
测试
查看redis-server进程号
ps -ef | grep redis
杀死master节点上redis-server的进程号
kill -9 进程号
验证结果
tail -f /var/log/sentinel.log
redis-cli -p 26379 INFO Sentinel