基于Docker-compose搭建Redis高可用集群-哨兵模式（Redis-Sentinel）

首页 - Mac & Linux/2019-09-04
标签:   基于  redis  Docker  搭建  模式  compose  Sentinel  哨兵  集群  可用
基于Docker-compose搭建Redis高可用集群-哨兵模式（Redis-Sentinel）

    我们知道，Redis的集群方案大致有三种：1）redis cluster集群方案；2）master/slave主从方案；3）哨兵模式来进行主从替换以及故障恢复。

    sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。

    

    同样，我们使用docker进行搭建

    新建一个mkdir redis-sentinel文件夹

    进入项目文件夹 cd redis-sentinel，再建立一个sentinel专门来存放哨兵脚本，然后cd sentinel

    建立sentinel.conf配置文件：

     

sentinel monitor mymaster redis-master 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 5000

    该配置的意思是，监控主服务器的6379端口并且起两个实例，如果哨兵5s内没有收到主节点的心跳，哨兵就认为主节点宕机了，默认是30秒，如果5秒以上连接不上主库同步，则在5秒后进行选举，对其他的从服务器进行角色转换


    随后，建立sentinel-entrypoint.sh脚本文件：

     

#!/bin/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指定基础镜像，同时拷贝配置文件到镜像内部：

     

FROM redis

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"]

    最后退到项目根目录 cd ..

    建立docker-compose.yml配置文件：

     

version: '2'

networks:
  app-tier:
    driver: bridge

services:
  redis:
    image: 'bitnami/redis:latest'
    environment:
      - REDIS_REPLICATION_MODE=master
      - REDIS_PASSWORD=""
    networks:
      - app-tier
    ports:
      - '6379:6379'
  redis-slave:
    image: 'bitnami/redis:latest'
    environment:
      - REDIS_REPLICATION_MODE=slave
      - REDIS_MASTER_HOST=redis
      - REDIS_MASTER_PASSWORD=""
      - REDIS_PASSWORD=""
    ports:
      - '6380: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:
      - '6381:6379'
    depends_on:
      - redis
    networks:
      - app-tier
  redis-sentinel:
    image: 'bitnami/redis-sentinel:latest'
    environment:
      - REDIS_MASTER_PASSWORD=""
    depends_on:
      - redis
      - redis-slave
      - redis-slave2
    ports:
      - '26379-26381:26379'
    networks:
      - app-tier

    意思是，我们起三台redis服务，使用桥接的方式分别跑在6379,6380,6381端口号上 ，一主两从，并且会有哨兵实例来监控它们，最后项目结构是这样的

    

    在项目根目录下，启动服务：

     

docker-compose up --scale redis-sentinel=3

    如果希望在后台运行可以加-d参数

    此时我们可以测一下同步是否成功，分别开三个窗口登录到redis,redis-cli -p 6379,redis-cli -p 6380,redis-cli -p 6381

    在主库6379中set 123 123，然后分别在从库get 123

        没有问题，现在我们来测一下哨兵模式是否好用，如果主库由于某种原因宕机了，从库是否能自动切换角色

    我们可以手动停止主库的容器进程，来模拟宕机的情况

     

docker stop redissentinel_master_1

    

    此时主库已经连接不上了，此时如果链接超时超过5秒，我们再次进入从库，使用info命令来查看从库的角色

    

    发现之前6380本来是从库(slave)角色，现在已经变成主库了(master)了


    其实这就是所谓的高负载高可用架构，在使用集群承担高负载的同时，也能进行高可用的容灾机制。

    相关视频攻略：