Redis集群

Redis集群

redis集群三种模式

1、主从复制（ 奇数 3 一主两从 ）
2、哨兵模式 3 一主两从
3、cluster 集群 6 3 3 3 9
1、主从复制

主从复制：和mysql的主从复制类似，主可以写，写入主的数据通过RDB方式把数据同步到从服务器。从不能更新到主，也是哨兵模式的基础
缺点：没有办法实现故障自动化规复，只有主可以大概写
主从复制：主节点和从节点、数据的复制是单向的，由主复制到从
主从复制的流程：从想主发起哀求，主受到后创建RDB文件

部署主从复制
服务器：
redis1 192.168.100.21 主
redis2 192.168.100.22 从1
redis3 192.168.100.23 从2

1. # redis1、2、3
2. systemctl stop firewalld
3. setenforce0
4. yum -y install ntpdate
5. ntpdate ntp.aliyun.com
6. date
8. redis1
9. vim /etc/redis/6379.conf
10. 70 改成0.0.0.0或者注释，注释默认所有
11. 137 查看是否注释掉了
12. 700 appendonly no改成yes
14. redis2
15. vim /etc/redis/6379.conf
16. 70 改成0.0.0.0或者注释，注释默认所有
17. 287 replicaof 192.168.100.21 6379
18. 700 appendonly yes # 打开aof持久化功能
20. redis3
21. vim /etc/redis/6379.conf
22. 70 改成0.0.0.0或者注释，注释默认所有
23. 287 replicaof 192.168.100.21 6379
24. 700 appendonly yes # 打开aof持久化功能
26. # 同时
27. /etc/init.d/redis_6379 restart
28. netstat -antp | grep 6379
30. redis1
31. tail -f /var/log/redis_6379.log

复制代码

2、哨兵模式

哨兵：故障自动化规复，主从复制完成之后，从服务器会变成只读模式
切换方式：不是按照权重来进行切换，投票：主宕机，其他服务器投票选举，通过Raft算法，选一个例当前时间点更新最快的从变成主
故障切换时，主故障，变成从服务器，主变成从之后，也会进入只读模式
缺点：从节点一旦故障，读会受到影响

部署哨兵模式：
哨兵模式：基于主从复制基础上
服务器：
redis1 192.168.100.21 主
redis2 192.168.100.22 从1
redis3 192.168.100.23 从2

1. 同步操作
2. cd /opt
3. cd /opt/redis-5.0.7
4. # redis-5.0.7自带哨兵模式源码包--setinel.conf
5. vim sentinel.conf
6. 21 port 26379 不动，哨兵模式的默认端口
7. 17 protected-mode no   # 取消注释  # 关闭保护模式
8. 27 daemonize no 改成yes
9. 36 logfile "/var//log/sentinel.log"
10. 65 dir "/var/lib/redis/6379"
11. 84 sentinel monitor mymaster 192.168.100.21 6379 2
12. # 监听初始化监听，都是监听主服务器的状态，
13. #2 对应的就是从服务器的数量以及投票的参与者，参与者要和从服务器的数量一致
14. 113 sentinel down-after-milliseconds mymaster 30000
15. # 判断服务器宕机的时间周期 30秒 每30秒检测一次
16. 146 sentinel failover-timeout mymaster 180000
17. # 判断故障节点的超时的最大时间 180秒
18. wq!
21. 先启动主，再启动从!!!
22. redis-sentinel sentinel.conf &
24. redis1
25. redis-cli -p 26379 info Sentinel
27. 哨兵模式创建完成
29. redis1
30. /etc/init.d/redis_6379 stop
32. 查看日志文件
33. tail -f /var/log/sentinel.log

复制代码

3、集群

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

集群：redis3.0之后的分布式存储方案。集群由多个节点构成，redis数据生存在这些节点、集群中的节点分为主和从，主负责读写以及维护集群的信息，从节点进行主节点数据的复制（也可以查）。
redis集群的数据分片：在集群概念中，引用hash槽的概念，创建了集群有16384个哈希槽（0~16384）
3个节点：
主1：0~5460
主2：5461~10922
主3：10923~16383
注意：节点当中，如果主和从全部失败，整个集群都将不可用
集群部署：
集群：基于主从复制基础上，与哨兵不兼容
服务器：
redis1 192.168.100.21 主1
redis2 192.168.100.22 主2
redis3 192.168.100.23 主3
redis4 192.168.100.24 从1
redis5 192.168.100.25 从2
redis6 192.168.100.26 从3

1. # redis1、2、3、4、5、6
2. systemctl stop firewalld
3. setenforce 0
4. yum -y install ntpdate
5. ntpdate ntp.aliyun.com
6. date
8. vim /etc/redis/6379.conf
9. 70   注释
10. 89   protected-mode no
11. 136  
12. 833  cluster-enabled yes  取消注释
13. 841  cluster-config-file nodes-6379.conf 取消注释
14. 847  cluster-node-timeout 15000 取消注释
15. 700  appendonly yes
16. wq!
18. /etc/init.d/redis_6379 restart
21. # 启动集群和分配主从
22. redis-cli -h 192.168.100.21 --cluster create 192.168.100.21:6379 192.168.100.24:6379 192.168.100.22:6379 192.168.100.25:6379 192.168.100.23:6379 192.168.100.26:6379 --cluster-replicas 1
23. ------------------------------------------------------------------------------------------------------------
24. # -h 192.168.100.21
25. 配置集群的主连接节点---在那台机器上配就写那一台机器
26. # --cluster create 192.168.233.7:6379 192.168.233.14:6379 192.168.233.8:6379 192.168.233.15:6379 192.168.233.9:6379 192.168.233.16:6379
27. 前面是主,后面是从
28. # --cluster-replicas 1
29. 表示每个主只有一个节点
32. redis-cli -h 192.168.100.21 -p 6379
33. cluster slots   # 查看hash槽的分配
35. cluster nodes   # 查看节点

复制代码

集群总结：moved不是报错，只是系统提示客户端到指定位置的哈希槽进行读大概写，系统提示啥，你就去哪个节点操作即可，这个节点是该节点的主
集群的功能只是满足了高可用和写的负载均衡，不能保证数据的完备性
redis-cli -h 192.168.100.21 -p 6379
cluster slots # 查看hash槽的分配
cluster nodes # 查看节点

2. 集群总结：moved不是报错，只是系统提示客户端到指定位置的哈希槽进行读或者写，系统提示啥，你就去哪个节点操作即可，这个节点是该节点的主
4. 集群的功能只是满足了高可用和写的负载均衡，不能保证数据的完整性

复制代码

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。