笔者目前所在公司存在多套 Redis 集群:
上云后,均为广东的某个云厂商的 2 个可用区,不再使用 IDC 数据中心,部署架构一致。
有人提出了一个很耐人寻味的问题:
这个架构有问题,如果两地之间网络故障,必定会出现脑裂!
真的会出现脑裂吗?
不至于吧!网络分区后,理论上广州机房是可用的,中山因为没有主(访问从库将槽位重定向回主库),所以中山机房不可用。所以只有一个机房可写,不会脑裂。
猜想终究是猜想,实践出真知!现在 docker 太方便了,搭一个集群模拟一下就 OK 了~
准备环境:
建立以下文件夹,并准备 docker-compose.yml:
mkdir -p ./data/redis/8001/data && \
mkdir -p ./data/redis/8002/data && \
mkdir -p ./data/redis/8003/data && \
mkdir -p ./data/redis/8004/data && \
mkdir -p ./data/redis/8005/data && \
mkdir -p ./data/redis/8006/data && \
mkdir -p ./data/redis/9001/data && \
mkdir -p ./data/redis/9002/data && \
mkdir -p ./data/redis/9003/data && \
mkdir -p ./data/redis/9004/data && \
mkdir -p ./data/redis/9005/data && \
mkdir -p ./data/redis/9006/data
广州机房 6 个端口:
version: '3'
services:
redis_gz_1:
image: publicisworldwide/redis-cluster
network_mode: host
volumes:
- ./data/redis/8001/data:/data
environment:
- REDIS_PORT=8001
redis_gz_2:
image: publicisworldwide/redis-cluster
network_mode: host
volumes:
- ./data/redis/8002/data:/data
environment:
- REDIS_PORT=8002
redis_gz_3:
image: publicisworldwide/redis-cluster
network_mode: host
volumes:
- ./data/redis/8003/data:/data
environment:
- REDIS_PORT=8003
redis_gz_4:
image: publicisworldwide/redis-cluster
network_mode: host
volumes:
- ./data/redis/8004/data:/data
environment:
- REDIS_PORT=8004
redis_gz_5:
image: publicisworldwide/redis-cluster
network_mode: host
volumes:
- ./data/redis/8005/data:/data
environment:
- REDIS_PORT=8005
redis_gz_6:
image: publicisworldwide/redis-cluster
network_mode: host
volumes:
- ./data/redis/8006/data:/data
environment:
- REDIS_PORT=8006
中山机房 6 个端口:
version: '3'
services:
redis_zs_1:
image: publicisworldwide/redis-cluster
network_mode: host
volumes:
- ./data/redis/9001/data:/data
environment:
- REDIS_PORT=9001
redis_zs_2:
image: publicisworldwide/redis-cluster
network_mode: host
volumes:
- ./data/redis/9002/data:/data
environment:
- REDIS_PORT=9002
redis_zs_3:
image: publicisworldwide/redis-cluster
network_mode: host
volumes:
- ./data/redis/9003/data:/data
environment:
- REDIS_PORT=9003
redis_zs_4:
image: publicisworldwide/redis-cluster
network_mode: host
volumes:
- ./data/redis/9004/data:/data
environment:
- REDIS_PORT=9004
redis_zs_5:
image: publicisworldwide/redis-cluster
network_mode: host
volumes:
- ./data/redis/9005/data:/data
environment:
- REDIS_PORT=9005
redis_zs_6:
image: publicisworldwide/redis-cluster
network_mode: host
volumes:
- ./data/redis/9006/data:/data
environment:
- REDIS_PORT=9006
docker-compose up 启动后,使用以下命令搭建集群:
docker run --rm -it inem0o/redis-trib create --replicas 1 \
10.43.2.6:8001 \
10.43.2.6:8002 \
10.43.2.6:8003 \
10.43.2.6:8004 \
10.43.3.7:9004 \
10.43.2.6:8005 \
10.43.3.7:9005 \
10.43.2.6:8006 \
10.43.3.7:9006 \
10.43.3.7:9001 \
10.43.3.7:9002 \
10.43.3.7:9003
你会发现集群搭起来了!有以下提示信息:
...master:
10.43.2.6:8001
10.43.3.7:9004
10.43.2.6:8002
10.43.3.7:9005
10.43.2.6:8003
10.43.3.7:9006
...
Adding replica 10.43.3.7:9001 to 10.43.2.6:8001
Adding replica 10.43.2.6:8004 to 10.43.3.7:9004
Adding replica 10.43.3.7:9002 to 10.43.2.6:8002
Adding replica 10.43.2.6:8005 to 10.43.3.7:9005
Adding replica 10.43.3.7:9003 to 10.43.2.6:8003
Adding replica 10.43.2.6:8006 to 10.43.3.7:9006
...
此时,集群是 广州、中山 各 3 个 master,不符合我们的场景,需要手工切换一下主从:
# 分别在从库 3 个端口做主从切换 10.43.2.6:9004-9006
redis-cli -h 10.43.2.6 -p 8004 CLUSTER FAILOVER
OK
redis-cli -h 10.43.2.6 -p 8005 CLUSTER FAILOVER
OK
redis-cli -h 10.43.2.6 -p 8006 CLUSTER FAILOVER
OK
3 个端口提主成功,10.43.2.6 此时运行 6 个 master,而 10.43.3.7 运行 6 个 slave 示例。
如何断网?很简单,iptables 无敌!
我们在广州(10.43.2.6)丢掉中山(10.43.3.7)的包就好了:
iptables -I INPUT -s 10.43.3.7 -pudp --dport 18001:18006 -j DROP && \
iptables -I INPUT -s 10.43.3.7 -ptcp --dport 18001:18006 -j DROP && \
iptables -I INPUT -s 10.43.3.7 -ptcp --dport 8001:8006 -j DROP && \
iptables -I INPUT -s 10.43.3.7 -pudp --dport 8001:8006 -j DROP
执行后,中山一直打印重连主库失败的日志,主库也探测到从库断开了,通过 CLUSTER NODES 命令可以获取各个节点状态。
结论一:A [6Master/0Slave] + B [0Master/6Slave],A 机房可读可写,B 机房不可读不可写(CLUSTERDOWN)
报错信息如下:
10.43.3.7:9006> set a12 2
(error) CLUSTERDOWN The cluster is down
另外,我还测试了主库分布在双机房的情况:
结论二:A [4Master/2Slave] + B [2Master/4Slave],A 机房可读可写,B 机房不可读不可写(CLUSTERDOWN)
结论三:A [3Master/3Slave] + B [3Master/3Slave],AB 机房均不可读不可写(CLUSTERDOWN)
为什么不可读?
因为请求从库它会自动转发(MOVED)到主库,而主库不可用(达不到半数以上节点),所以彻底凉了!
解决办法是不使用偶数节点,极端情况下(master 均等分布两地)会导致整个集群不可用。
实验完,不要忘了删掉规则,恢复网络:
iptables -D INPUT -s 10.43.3.7 -pudp --dport 18001:18006 -j DROP && \
iptables -D INPUT -s 10.43.3.7 -ptcp --dport 18001:18006 -j DROP && \
iptables -D INPUT -s 10.43.3.7 -ptcp --dport 8001:8006 -j DROP && \
iptables -D INPUT -s 10.43.3.7 -pudp --dport 8001:8006 -j DROP
(完)
文章来源于本人博客,发布于 2022-03-12,原文链接:https://imlht.com/archives/254/