Zhi-Redis哨兵模式 + 集群

Redis的哨兵模式

为什么使用哨兵

主从是针对读请求的横向扩展，但是Master挂了，剩余的slave不能写入，任何保证可用性，实现继续读写，就必须要其中一个slave变成master，自动不会切换，需要哨兵去切换。

什么是哨兵

Sentinel(哨兵)是用于监控Redis集群中Master状态的工具，是Redis高可用解决方案，哨兵可以监视一个或者多个Redis master服务，以及这些master服务的所有slave；当某个master宕机后，会把这个master下的某个slave升级为master来替代已宕机的master继续工作。

  哨兵可以做到监控的作用，对于哨兵来讲，一个是肯定不够的，往往采用多个，Sentinel集群对Redis做到的一个监控，这样就能够为Redis集群做一个高可用。

配置哨兵监控master

1. 拷贝sentinel配置文件

   [root@localhost redis-5.0.9]# cp sentinel.conf /usr/local/redis/
   

2. 配置sentinel.conf

   [root@localhost redis-5.0.9]# cd /usr/local/redis/
   [root@localhost redis]# vi sentinel.conf 
   

   普通配置

   # bind 127.0.0.1 192.168.1.1
   #
   protected-mode no       不使用保护模式	
   # port <sentinel-port>
   port 26379
   daemonize yes   在后台运行
   pidfile /var/run/redis-sentinel.pid
   logfile "/usr/local/redis/sentinel/redis-sentinel.log"    日志
   dir /usr/local/redis/sentinel          工作空间
   

   核心配置

   sentinel monitor mymaster 172.16.139.161 6379 2     #mymaster：哨兵集群名称    2：需要两台哨兵同意则证明master是宕机了，把从节点变成一个master
   sentinel auth-pass mymaster zk  #设置密码 
   sentinel down-after-milliseconds mymaster 30000    #为主节点配置一个毫秒的时间，被哨兵认为是宕机的时间段，时间间隔
   sentinel parallel-syncs mymaster 1  #当某一个slave被投票选举成新的master的以后，新的master与slave需要做数据的同步，同步的并行个数，1代表1个接着1个
   sentinel failover-timeout mymaster 180000    #主备切换的超时时间，哨兵需要做故障转移，哨兵本身也是一个进程，如果说它没有去执行或者超过这个时间，由于哨兵是一个集群，会由其他的哨兵来处理剩余的工作。
   

   mkdir /usr/local/redis/sentinel -p   #创建配置文件中指定的目录
   

3. 哨兵部署以集群的形态呈现的，三个节点上面每一个都有一个哨兵，配置内容是一样的
   可以通过远程传输工具scp

   [root@localhost redis]# scp sentinel.conf root@172.16.139.162:/usr/local/redis/
   root@172.16.139.162's password: 
   sentinel.conf                                     100% 9753     5.4MB/s   00:00    
   [root@localhost redis]# scp sentinel.conf root@172.16.139.163:/usr/local/redis/
   

4. 启动哨兵 分别启动三台哨兵，查看进程

   [root@localhost redis]# redis-sentinel sentinel.conf      
   [root@localhost redis]# ps -ef | grep redis
   root       3227      1  0 11:04 ?        00:00:29 /usr/local/bin/redis-server 0.0.0.0:6379
   root       5666      1  0 15:18 ?        00:00:00 redis-sentinel *:26379 [sentinel]  
   

5. 测试
   1 master挂了，看slave是否成为master
   在客户端挂起，再次查看主从信息，发现要重新输入密码，是因为新的master和slave之间有一个数据同步的过程。
   2 master恢复，观察slave状态

6. 结论
   master挂了以后，由于哨兵监控，剩余的slave会进行选举，选举后其中一个成为master，当原来的master恢复后，他会成为slave。

哨兵可能出现的问题

1. 解决原master恢复后不同步的问题
   原来的master恢复成slave之后，他的同步状态不OK，master_link_status:down：down

   127.0.0.1:6379> info replication
   # Replication
   role:slave
   master_host:172.16.139.163
   master_port:6379
   master_link_status:down
   

   这是因为我们只设置了162和163的masterauth，这是由于同步master的数据，但是161一开始是master是不受影响的，当master转变为slave或，由于他没有设置masterauth，所以他不能从新的master同步数据，随之导致info replication的时候，同步状态为down，所以只需要修改redis.conf中的masterauth为 zk即可
2. master无法同步数据给slave的方案检查如下：
   1. 网络通信问题，要保证互相ping通，内网互通
   2. 关闭防火墙，对应的端口开放
   3. 统一所有的密码， 通过逐台检查机器以防某个节点被遗漏

Redis集群

为什么使用集群

  主从复制以及哨兵，他们可以提高读的并发，但是单个master容量有限，数据达到一定程度会有瓶颈，这个时候可以通过水平扩展为多master-slave成为集群。

  Redis-cluster：他可以支撑多个master-slave，支持海量数据，实现高可用与高并发。
  哨兵模式其实也是一种集群，他能够提高读请求的并发，但是容错方面可能会有一些问题，比如master同步数据给slave的时候，这其实一异步复制，这个时候master挂了，那么slave上的数据就没有master新，数据同步需要时间的，1-2秒的数据会丢失。master恢复并转换成slave后，新数据则丢失。

特点：

1. 每个节点知道彼此之间的关系，也会知道自己的角色，当然他们也会知道自己存在于一个集群环境中，他们彼此之间可以交互和通信，比如ping pong，这些关系可以保存到某一个配置文件中，每个节点都有.
2. 客户端要和集群建立连接的话，只需要和其中一个建立关系就行。
3. 某个节点挂了，也是通过超过半数的节点来进行检测，进行投票，如果是真的客观下线了，这个时候就会发起一个主从的切换，这个和之前的哨兵模式是一个道理。
4. Redis在进行切分的时候，每一组数据存储涉及到插槽的概念，又可以称为槽节点，用于存储数据。
5. List item

集群容错：
  构建Redis集群，需要至少3个节点作为master，以此组成一个高可用的集群，此外每个master都需要配备一个slave，所以整个集群需要6个节点，这也是最经典的Redis集群，也可以称之为三主三从，容错性更加。

构建Redis集群

1. 配置集群conf

   cluster-enabled yes  #开启集群模式
   cluster-config-file nodes-6379.conf   #每一个节点需要有一个配置文件，需要6份，每个节点处于集群的的角色都需要告知其他所有节点，彼此知道，这个文件用于存储集群模式下的集群状态等信息，这个文件由Redis自己维护，我们不用管，如果你要重新创建集群，那么把这个文件删了就行。
   cluster-node-timeout 5000   #超时时间，超时则认为master宕机，随后主备切换
   appendonly yes   #开启AOF
   

2. 创建集群前，dump和aof文件是不能有的，或者需要将数据清空，否则在构建集群的时候会报错

   [root@localhost redis]# cd working/
   [root@localhost working]# ll
   总用量 4
   -rw-r--r--. 1 root root  0 10月 25 21:37 appendonly.aof
   -rw-r--r--. 1 root root 92 10月 25 22:25 dump.rdb
   [root@localhost working]# rm appendonly.aof dump.rdb 
   rm：是否删除普通空文件 "appendonly.aof"？y
   rm：是否删除普通文件 "dump.rdb"？y
   

3. 重启Redis，查看Redis运行情况

   [root@localhost working]# /etc/init.d/redis_init_script start
   Starting Redis server...
   1914:C 25 Oct 2020 22:31:38.761 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
   1914:C 25 Oct 2020 22:31:38.761 # Redis version=5.0.9, bits=64, commit=00000000, modified=0, pid=1914, just started
   1914:C 25 Oct 2020 22:31:38.761 # Configuration loaded
   [root@localhost working]# ll
   总用量 4
   -rw-r--r--. 1 root root   0 10月 25 22:31 appendonly.aof
   -rw-r--r--. 1 root root 114 10月 25 22:31 nodes-6379.conf
   [root@localhost working]# ps -ef |grep redis
   root       1915      1  0 22:31 ?        00:00:00 /usr/local/bin/redis-server 0.0.0.0:6379 [cluster]
   root       1921   1772  0 22:31 pts/0    00:00:00 grep --color=auto redis
   

4. 配置6台，并启动实例

5. 创建集群

   1. 如果使用的Redis3.x版本，需要使用redis-trib.rb来构建集群，最新版使用C语言来构建了，这个要注意
   2. 一下为新版的Redis构建方式
   3. 创建集群，主节点和从节点比例为1
   4. redis-cli -a zk --cluster create 172.16.139.164:6379 172.16.139.165:6379 172.16.139.166:6379 172.16.139.167:6379 172.16.139.168:6379 172.16.139.169:6379 --cluster-replicas 1

6. 检查集群信息 -a 密码

   [root@localhost working]# redis-cli -a zk --cluster check 172.16.139.164:6379