redis集群 高可用

redis集群 高可用

redis集群的三种模式：
1、主从复制（redis集群的基础） 奇数 1主2从

2、哨兵模式 3 1主2从

3、cluster集群

主从复制：和MySQL的主从复制类似，主可以写，写入主的数据通过RDB方式把数据同步到从服务器。从不能更新到主。也是哨兵模式的基础。
缺点：无法实现故障自动化恢复，只有主能够写

**哨兵：**故障自动化恢复，主从复制完成之后，从服务器会变成只读模式。
故障切换时，主故障，变成从服务器，主变成从之后，也会进入只读模式。
缺点：从节点一旦故障，读会受到影响。

**cluster集群：**把每两台服务器作为主从模式，形成一个大的主从的集群。
解决了写操作的负载均衡。较为完善的高可用方案。
**缺点：**保证高可用，对数据的完整性要求不好。

一、主从复制（基础）：

主节点和从节点
数据的复制是单向的，由主复制到从
主从复制的流程：

主从复制部署：

192.168.11.144 redis 主
192.168.11.145 从1
192.168.11.146 从2

主配置 192.168.11.144

vim /etc/redis/6379.conf 
70  bind 0.0.0.0
700行	改为yes
[root@myslq4 ~]# /etc/init.d/redis_6379 restart
[root@myslq4 ~]# netstat -antp | grep 6379
tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN      37309/redis-server  
tcp        0      0 192.168.11.144:6379     192.168.11.146:33854    ESTABLISHED 37309/redis-server  
tcp        0      0 192.168.11.144:6379     192.168.11.145:39603    ESTABLISHED 37309/redis-server 

192.168.11.145 从1

  vim /etc/redis/6379.conf
  70 bind 0.0.0.0
  287  replicaof 192.168.11.144 6379
  700 appendonly yes
  /etc/init.d/redis_6379 restart

192.168.11.146 从2

vim /etc/redis/6379.conf
70行	     bind 0.0.0.0
288行	replicaof 192.168.11.144 6379
700行	改为yes
/etc/init.d/redis_6379 restart

二、哨兵模式

部署（以主从为基础）：

192.168.11.144 redis 主
192.168.11.145 从1
192.168.11.146 从2

vim sentinel.conf    主从都需要做
17  protected-mode no
21 port 26379
26 daemonize yes
36 logfile "/var/log/sentinel.log"    #哨兵保存日志
65 dir "/var/lib/redis/6379"
84 sentinel myid b219dca6d378e359d67225b33a1ce06079b703de     #当前主机的哨兵id
122 sentinel monitor mymaster 192.168.11.144 6379 2    #全指向主
#初始化监听都是监听主服务器，监听主服务器状态
#2 对应的是从服务器的数量以及投票的参与者要和从服务器一致
#2台服务器投票通过，主才能进行故障转移。
114行 sentinel deny-scripts-reconfig yes
#判断服务器宕机的时间周期 30秒 每30秒检测一次

147行 sentinel config-epoch mymaster 2
#判断故障节点的超时的最大时间180秒
[root@myslq3 redis-5.0.7]# redis-sentinel  sentinel.conf &    #重启哨兵模式
[root@myslq3 redis-5.0.7]# redis-cli  -p 26379 info Sentinel  #查看哨兵的主

三台
cd /opt
cd redis-5.0.7/
ls
vim sentinel.conf
17行	protected-mode no	#关闭保护模式
27行	daemonize yes
37行	logfile "/var/log/setinel.log"
66行	dir "/var/lib/redis/6379"
114行 sentinel deny-scripts-reconfig yes
#判断服务器宕机的时间周期 30秒 每30秒检测一次
122行 sentinel monitor mymaster 192.168.39.31 6379 2
#初始化监听，都是监听主，监听主服务器的状态。2 对应的就是从服务器的数量以及投票的参与者 参与者要和从服务器的数量一致.2台服务器投票通过，主才能进行故障转移
147行 sentinel config-epoch mymaster 2
#判断故障节点的超时的最大时间180秒

redis-sentinel sentinel.conf &
#重启哨兵模式
redis-cli -p 26379 info Sentinel
#查看哨兵的主

模拟断开投票
主
/etc/init.d/redis_6379 stop
从1从2
tail  -f /var/log/redis_6379.log
可以看到投票id过程以及谁被作为主

三、cluster集群

redis 3.0 之后的分布式存储方案

集群由多个节点组成，redis数据保存在这些节点中。
集群中的节点分为主和从。
主负责读写以及维护集群的信息
从节点进行主节点数据的复制（也可以查）

redis集群的数据分片
在集群概念中，引用的是hash槽的概念
创建了集群就有16384个哈希槽
0-16383
三个节点：
主1 0-5460
主2 5461-10922
主3 10923-16383
节点当中，如果主和从全部失败，整个集群将不可用

192.168.11.144 redis 主1
192.168.11.145 主2
192.168.11.146 主3
192.168.11.147 从1
192.168.11.148 从2
192.168.11.149 从3

vim /etc/redis/6379.conf        #所有主机均需要配置
 70 #bind 127.0.0.1 192.168.60.30	
 #将70行注释，表示默认所有
 89 protected-mode no
 #将yes改为no
 833 cluster-enabled yes
 #将833行取消注释89gg
 841 cluster-config-file nodes-6379.conf 
 #将841取消注释
 847 cluster-node-timeout 15000
 将847行取消注释
 700 appendonly yes
 #将700行的no改为yes
 /etc/init.d/redis_6379 restart
 #重启配置文件

redis-cli -h 192.168.11.144 --cluster create 192.168.11.144:6379 192.168.11.147:6379 192.168.11.148:6379 192.168.11.145:6379 192.168.11.146:6379 192.168.11.149:6379 --cluster-replicas 1

192.168.11.144集群的主连接节点  配置节点 （在11.144主机上输入命令）
表示每个主只有一个1节点,前面是主，后面是从
集群: moved不是报错，只是系统提示客户端到指定为止的哈希进行读或者写
系统提示啥，你就去哪个节点操作即可 这个节点是该节点的主。
集群的功能只是满足了高可用和写的负载均衡，不能保证数据的完整性。

完成测试

[root@myslq4 ~]# redis-cli -h 192.168.11.144 -p 6379
192.168.11.144:6379> CLUSTER SLOTS   #查看主从关系
192.168.11.144:6379> CLUSTER NODES   #获取Redis集群的当前配置信息
192.168.11.149:6379> set test2 33
(error) MOVED 8899 192.168.11.147:6379