redis-cluster集群模式
Redis-cluster集群
| 1 | Redis3.0引入的分布式存储方案 |
| 2 | 集群由多个node节点组成,redis数据分布在节点之中,在集群之中分为主节点和从节点 |
| 3 | 集群模式当中,主从一一对应,数据写入和读取与主从模式一样，主负责写，从只能读 |
| 4 | 集群模式自带哨兵模式，可以自动实现故障切换，但是故障切换完成之前，整个集群都将不可使用，切换完毕之后，集群会立即恢复 |
集群的作用
| 集群有个特殊的地方,集群模式按照数据分片来的 | ||
| 1 | 数据分区 | 是集群的核心功能，每个主都可以对外提供读和写的功能，但是数据是一一对应写入主的对应从节点，在集群模式中，可以容忍数据的不完整 |
| 2 | 高可用 | 高可用是集群的主要目的 |
数据分片如何实现
| 1 | redis的集群引入了哈希槽的概念,redis集群当中共有16384个哈希槽位，从0开始计算 (0-16383) |
| 2 | 根据集群当中主节点数，分配哈希槽，每个主从节点只负责一部分的哈希槽位 |
| 3 | 每次读写都涉及到哈希槽位，key通过CRC16(校验机制)校验之后,对16384取余数，余数值决定数据放入哪个哈希槽位，通过这个值去找到对应槽位所在节点，然后直接跳转到这个节点进行存取操作 |
redis-cluster集群主从复制
| 1 | 主宕机之后，主节点原来负责的哈希槽位将会不可用，需要从节点代替主节点继续负责原有的哈希操作，保证集群正常工作 |
| 2 | 这也是故障切换的过程中，会提示集群不可用的原因，切换完成之后，集群恢复后继续工作 |
| 在集群模式当中，只能选择0号库，集群是不能切库的 |
集群流程
| 1 | 集群自带主从复制和哨兵模式 |
| 2 | 每个主节点之间互相间隔，可以容忍数据的不完整，核心目的就是为了实现高可用 |
| 3 | 哈希槽位决定每个节点的读写操作，在创建key时，系统已经分配好了指定槽位 |
| 4 | 面试题 MOVED不是报错，只是提醒客户端去分配好的槽位节点，获取数据 |
#6台redis同时操作,用多重执行
systemctl stop firewalld
setenforce 0#所有节点文件都需要操作,或者配置文件修改完毕后覆盖掉其他主机的redis配置文件
vim /etc/redis/6379.confbind 0.0.0.0
#70行,允许所有网段与我建立连接protected-mode no
#89行,保护模式要关闭掉port 6379
#93行,多实例不需要改端口,单示例需要改下端口daemonize yes
#137行,后台进程默认是打开的就不要动了appendonly yes
#700行,AOF持久化功能要打开,不打开会报错,哈希槽可能会分配失败cluster-enabled yes
#833行,取消注释cluster-config-file nodes-6379.conf
#841行,取消注释,这是集群的配置文件名称cluster-node-timeout 15000
#847行,取消注释,取消集群的超时时间设置,15秒内超时,将会执行主从切换[root@c1 redis]# /etc/init.d/redis_6379 restart
[root@c1 redis]# netstat -antp | grep redis主机1
[root@c1 redis]# redis-cli -h 192.168.233.66 --cluster create 192.168.233.66:6379 192.168.233luster-replicas 1
#replicas 1 规定一个主只能有一个从,主从的配合是随机的Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
#哈希槽分配Adding replica 192.168.233.70:6379 to 192.168.233.66:6379
Adding replica 192.168.233.71:6379 to 192.168.233.67:6379
Adding replica 192.168.233.69:6379 to 192.168.233.68:6379
#一个主对应一个从M: 1d66a340a048973f729745a643610c2ae33b3298 192.168.233.66:6379slots:[0-5460] (5461 slots) master
M: 4b7e1c65b1f090aa655963ebfdbf7be852f56522 192.168.233.67:6379slots:[5461-10922] (5462 slots) master
M: cd2e1c40d3df41db989de29f1bb9106465f4ab1b 192.168.233.68:6379slots:[10923-16383] (5461 slots) master
S: 75a179cffb4cd63e30980063341a6e82f0d0cb88 192.168.233.69:6379replicates cd2e1c40d3df41db989de29f1bb9106465f4ab1b
S: 011bbb8a7582c4319f9e0d2afb6b033c9c6f81ac 192.168.233.70:6379replicates 1d66a340a048973f729745a643610c2ae33b3298
S: e6c3f4199e97974db9f5103428e90bf7516a394b 192.168.233.71:6379replicates 4b7e1c65b1f090aa655963ebfdbf7be852f56522
#主的后面会有master,从是没有的Can I set the above configuration? (type 'yes' to accept): yes
#这样的分配是否接受,无特殊需求就yes[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
#表示集群创建成功#接下来只要验证集群的主从复制,读写分离,哨兵模式
CLUSTER nodes
#查看集群相关节点的详细信息127.0.0.1:6379> CLUSTER NODES
1d66a340a048973f729745a643610c2ae33b3298 192.168.233.66:6379@16379 myself,master - 0 0 1 connected 0-5460
#1d66a340a048973f729745a643610c2ae33b3298 表示编号,192.168.233.66:6379@16379 表示主机名,master 表示地位是主,0 0 1表示时间戳,connected 0-5460 表示当前主节点负责的哈希槽位127.0.0.1:6379> set test 1
(error) MOVED 6918 192.168.233.67:6379
#这个不是报错,表名客户端尝试读取键值对test,但实际槽位在6918,集群要求客户端移动到6918槽位所在的主机节点192.168.233.67,获取数据,系统只是提示创建键值时已被划分到6918哈希槽位,如果需要创建要去对应的哈希槽位操作127.0.0.1:6379> monitor
OK
#监控redis工作过程的实时日志,只有从在ping主,主不会ping从127.0.0.1:6379> monitor
OK
1700738454.422719 [0 192.168.233.66:6379] "PING"nginx实现代理
在nginx节点配置，实现负载均衡！
stream {upstream redis_cluster {server 192.168.233.7:6379;server 192.168.233.8:6379;server 192.168.233.9:6379;}server {listen 6379;proxy_pass redis_cluster;proxy_connect_timeout 1s;proxy_timeout 1s;proxy_responses 1;}
}nginx代理
| Proxy_responses 1; | 在集群之中只要有一个节点相应，然后代理服务器就会把响应传递给客户端，可以增加整个系统的稳定性，只要有一个节点响应，那么客户端就可以继续发起请求，不会因为某个节点失效，导致整个请求失效 |
| nginx是否可以提供多端口服务 | 可以提供多端口服务 |