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)了

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