公司项目涉及到redis，最近不太忙于是准备仔细学习下，起初是直接在Windows下搭建，现在试试Docker下搭建redis然后试下哨兵配置，废话不多说，直接搭建步骤：
1.Docker安装redis
指令1）docker search redis
查找redis镜像，结果显示不同版本
2）docker pull redis
docker 直接拉取redis镜像 ，默认最新版本
2.搭建redis主从复制（读写分离）配置
2.1.创建redis容器实例
指令：
docker run --name redis-6379 -p 6379:6379 -d redis
docker run --name redis-6380 -p 6380:6379 -d redis
docker run --name redis-6381 -p 6381:6379 -d redis
如果以前创建过相同redis容器实例
docker ps -a 查看显示所有的容器，包括未运行的。
docker restart name
进入容器内部 : docker exec -it redis-6379 /bin/bash
启动 redis 客户端 连接本地的 redis 服务 :redis-cli
连接远程的 redis 服务 :redis-cli -h host -p port -a password
2.2 按照1主2从的结构搭建，即1个Master，2个Slaver节点
2.2.1 查看容器内网的ip地址等信息
docker inspect containerid
redis-6379：172.17.0.2:6379
redis-6380：172.17.0.3:6379
redis-6381：172.17.0.4:6379
2.2.2 使用命令修改配置
指令：SLAVEOF host port
SLAVEOF 172.17.0.2 6379
通过指令如果不改动redis.conf配置文件，容器宕机再次启动时则的需要重新手动配置
2.2.3 修改redis.conf配置文件
redis默认无配置文件，于是需要手动添加
直接修改slaveof、logfile、dir配置
dir:工作目录（存放日志文件、持久化文件）
logfile:日志文件名称
3.搭建redis哨兵（主从切换）配置
3.1 首先了解下为什么需要哨兵配置
redis主从模式解决了数据备份和单例可能存在的性能问题，但是其也引入了新的问题。由于主从模式配置了三个redis实例，并且每个实例都使用不同的ip（如果在不同的机器上）和端口号，根据前面所述，主从模式下可以将读写操作分配给不同的实例进行从而达到提高系统吞吐量的目的，但也正是因为这种方式造成了使用上的不便，因为每个客户端连接redis实例的时候都是指定了ip和端口号的，如果所连接的redis实例因为故障下线了，而主从模式也没有提供一定的手段通知客户端另外可连接的客户端地址，因而需要手动更改客户端配置重新连接。另外，主从模式下，如果主节点由于故障下线了，那么从节点因为没有主节点而同步中断，因而需要人工进行故障转移工作。
为了解决这两个问题，在2.8版本之后redis正式提供了sentinel（哨兵）架构。关于sentinel，这里需要说明几个概念：
| 名词 | 逻辑结构 | 物理结构 |
| 主节点 | redis主服务/数据库 | 一个独立的redis进程 |
| 从节点 | redis从服务/数据库 | 一个独立的redis进程 |
| sentinel节点 | 监控redis数据节点 | 一个独立的sentinel进程 |
| sentinel节点集合 | 若干sentinel节点的抽象集合 | 若干sentinel节点进程 |
| 应用方 | 泛指一个或多个客户端 | 一个或多个客户端线程或进程 |
每个sentinel节点其实就是一个redis实例，与主从节点不同的是sentinel节点作用是用于监控redis数据节点的，而sentinel节点集合则表示监控一组主从redis实例多个sentinel监控节点的集合，比如有主节点master和从节点slave-1、slave-2，为了监控这三个主从节点，这里配置N个sentinel节点sentinel-1，sentinel-2，...，sentinel-N。如下图是sentinel监控主从节点的示例图：
从图中可以看出，对于一组主从节点，sentinel只是在其外部额外添加的一组用于监控作用的redis实例。在主从节点和sentinel节点集合配置好之后，sentinel节点之间会相互发送消息，以检测其余sentinel节点是否正常工作，并且sentinel节点也会向主从节点发送消息，以检测监控的主从节点是否正常工作。。前面讲到，sentinel架构的主要作用是解决主从模式下主节点的故障转移工作的。这里如果主节点因为故障下线，那么某个sentinel节点发送检测消息给主节点时，如果在指定时间内收不到回复，那么该sentinel就会主观的判断该主节点已经下线，那么其会发送消息给其余的sentinel节点，询问其是否“认为”该主节点已下线，其余的sentinel收到消息后也会发送检测消息给主节点，如果其认为该主节点已经下线，那么其会回复向其询问的sentinel节点，告知其也认为主节点已经下线，当该sentinel节点最先收到超过指定数目（配置文件中配置的数目和当前sentinel节点集合数的一半，这里两个数目的较大值）的sentinel节点回复说当前主节点已下线，那么其就会对主节点进行故障转移工作，故障转移的基本思路是在从节点中选取某个从节点向其发送slaveof no one（假设选取的从节点为127.0.0.1:6380），使其称为独立的节点（也就是新的主节点），然后sentinel向其余的从节点发送slaveof 127.0.0.1 6380命令使它们重新成为新的主节点的从节点。重新分配之后sentinel节点集合还会继续监控已经下线的主节点（假设为127.0.0.1:6379），如果其重新上线，那么sentinel会向其发送slaveof命令，使其成为新的主机点的从节点，如此故障转移工作完成。
3.2 Sentinel哨兵特点
监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为复制新的主服务器； 当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。
3.3 哨兵配置
redis默认无sentinel.conf，所以需要自己创建
进入根目录创建sentinel.conf文件
cd / && touch sentinel.conf修改文件内容为：
sentinel monitor mymaster 172.17.0.2 6379 1使用指令vim编辑sentinel.conf时如果有如下错误
如果出现：bash: vim: command not found
解决：1、apt-get update 2、apt-get install vim
原因为编辑该文件时异常退出，而vim在编辑文件时会创建一个交换文件swap file以保证文件的安全性，所以在每次打开这个文件都会出现警告，该文件是隐藏的，可通过ls -la命令查看，使用rm命令进行删除
最后，启动Redis哨兵：
使用 redis-sentinel /sentinel.conf 启动Redis哨兵监控
使用 ps –ef |grep redis 命令，可以看到redis-server和redis-sentinel正在运行配置文件只需要配置master的信息就好啦，不用配置slave的信息，因为slave能够被自动检测到(master节点中有关于slave的消息)。
至此配置3个Sentinel节点，Sentinel哨兵配置完毕。
4.验证
关闭主机，将刚才停止的主机启动起来，发现启动后其自动成为从机
参考：
https://www.cnblogs.com/hutao722/p/9644620.html