redis集群概述
Redis的集群方案大致有三种:
redis cluster集群方案
master/slave主从方案
使用哨兵模式来进行主从替换以及故障恢复Sentinel系统可以监视一个或者多个redis master服务,以及master服务的所有从服务;当某个master服务下线时,自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。
使用Docker搭建Redis 集群
文件位置自己随意
新建redis-sentinel主目录,进入目录内部,在新建一个sentinel目录用来存放哨兵脚本。在sentinel目录中新建 sentinel.conf 配置文件、Dockerfile、sentinel-entrypoint.sh脚本文件。
redis-sentinel # 项目根路径
├── docker-compose.yml # docker-compose文件
└── sentinel # 存放初始化sentinel容器的相关文件
├── Dockerfile # sentinel构建镜像文件
├── sentinel.conf # sentinel配置文件
└── sentinel-entrypoint.sh # sentinel.sh启动脚本
sentinel.conf 文件配置
# 哨兵sentinel实例运行的端口 默认26379
port 26379
sentinel monitor mymaster redis-master 6379 3
指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
================================================
sentinel down-after-milliseconds mymaster 5000
指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行同步,这个数字越小,完成failover所需的时间就越长
=========================================================================
sentinel parallel-syncs mymaster 1
故障转移的超时时间
=========
`sentinel failover-timeout mymaster 5000
`
sentinel-entrypoint.sh脚本文件配置
同步配置文件,启动哨兵
sed -i "s/$SENTINEL_QUORUM/$SENTINEL_QUORUM/g" /etc/redis/sentinel.conf
sed -i "s/$SENTINEL_DOWN_AFTER/$SENTINEL_DOWN_AFTER/g" /etc/redis/sentinel.conf
sed -i "s/$SENTINEL_FAILOVER/$SENTINEL_FAILOVER/g" /etc/redis/sentinel.conf
`exec docker-entrypoint.sh redis-server /etc/redis/sentinel.conf --sentinel`
Dockerfile文件配置
# 建立Dockerfile指定基础镜像,同时拷贝配置文件到镜像内部
FROM redis:latest
`EXPOSE 26379
ADD sentinel.conf /etc/redis/sentinel.conf
RUN chown redis:redis /etc/redis/sentinel.conf
COPY sentinel-entrypoint.sh /usr/local/bin/
RUN chmod +x /usr/local/bin/sentinel-entrypoint.sh
ENTRYPOINT ["sentinel-entrypoint.sh"]
`
docker-compose.yml文件配置
# 搭建几个从库,就需要在services中配置几个信息,开放相应端口
version: '2'
networks:
app-tier:
driver: bridge
services:
redis:
image: 'bitnami/redis:latest'
environment:
- REDIS_REPLICATION_MODE=master
- REDIS_PASSWORD=""
networks:
- app-tier
ports:
- '6380:6379'
redis-slave1:
image: 'bitnami/redis:latest'
environment:
- REDIS_REPLICATION_MODE=slave
- REDIS_MASTER_HOST=redis
- REDIS_MASTER_PASSWORD=""
- REDIS_PASSWORD=""
ports:
- '6381:6379'
depends_on:
- redis
networks:
- app-tier
redis-slave2:
image: 'bitnami/redis:latest'
environment:
- REDIS_REPLICATION_MODE=slave
- REDIS_MASTER_HOST=redis
- REDIS_MASTER_PASSWORD=""
- REDIS_PASSWORD=""
ports:
- '6382:6379'
depends_on:
- redis
networks:
- app-tier
redis-slave3:
image: 'bitnami/redis:latest'
environment:
- REDIS_REPLICATION_MODE=slave
- REDIS_MASTER_HOST=redis
- REDIS_MASTER_PASSWORD=""
- REDIS_PASSWORD=""
ports:
- '6383:6379'
depends_on:
- redis
networks:
- app-tier
redis-sentinel:
image: 'bitnami/redis-sentinel:latest'
environment:
- REDIS_MASTER_PASSWORD=""
depends_on:
- redis
- redis-slave1
- redis-slave2
- redis-slave3
ports:
- '26379-26382:26379'
networks:
- app-tier
启动服务
# 在后面加 -d 为在后台启动
# compose启动失败可以尝试手动启动Containers
docker-compose up --scale redis-sentinel=4
测试哨兵打开redis连接工具,连接redis,其中6380为master,6381、6382、6383为slave,此时只有master是有写的权限的,当使用slava进行写的时候会报 (error) READONLY You can't write against a read only replica.错误,即为搭建成功。
stop掉主库容器进程,模拟宕机
# stop掉主库容器进程,模拟宕机
docker stop 容器名称
此时主库已经连接不上了,当链接超时超过5秒,我们再次进入从库,使用info命令来查看从库的角色,发现之前6380本来是从库(slave)角色,现在已经变成主库了(master)了
这就是所谓的高负载高可用架构,在使用集群承担高负载的同时,也能进行高可用的容灾机制。