接触redis已经有了两个年头，虽然对业务上的使用已经很熟悉，但是对于redis高性能高可用方面的了解还不够深入，所以逐步开始学习reids搭建主从和集群。
今天开始介绍的是最简单的主从搭建，废话不多说，开始了～
首先讲一下主从的架构，和mysql的主从一样，redis的主从也是从节点同步主节点的数据。我们介绍的这个主从是一主多从的架构，即是一个主节点，多个从节点，一般我们至少需要两个从节点来实现，因为一般的数据库对读的压力比较大，所以从节点会需要的多。主节点负责写入，然后从节点负责读出，读写分离。多个从节点也会分担读的压力。
我们接下来会在一台机器上启动多个三个redis实例，一主两从。
redis-server --port 6379 启动master
redis-server --port 6380 --slaveof 127.0.0.1 6379 启动从一
redis-server --port 6381 --slaveof 127.0.0.1 6379 启动从二
这样我们的主从服务器就搭建好了，我们可以测试试试。
我们可以在master中写入数据，和读取数据，但是在从slave只能读，不能写。而且我们能够看到主节点写入的数据在从几点都可以读取到，这就是主从想要达到的效果。
但是如果master宕机了怎么办呢？这就造成了数据没法写入，造成了数据的丢失，这就需要有一个slave站出来，承担写入的责任，也就是它要升为master，相对其他的slave也必须以它为主，来同步数据。这个我们可以通过人工来实现，但是在真是的业务场景中，我们不能可能实时去监控master，一旦master挂掉，人工的处理防方式速度慢，很大可能造成数据的丢失。这就用到了“哨兵”。
Redis Sentinel是一个分布式架构，包含若干个Sentinel节点和Redis数据节点，每个Sentinel节点会对数据节点和其余Sentinel节点进行监控，当发现节点不可达时，会对节点做下线标识。如果被标识的是主节点，他还会选择和其他Sentinel节点进行“协商”，当大多数的Sentinel节点都认为主节点不可达时，他们会选举出一个Sentinel节点来完成自动故障转移工作，同时将这个变化通知给Redis应用方。整个过程完全自动，不需要人工介入，所以可以很好解决Redis的高可用问题。
下面这张图很好的描述了这种监控的关系，这张图是从网上找的，太懒了，不像想画了：
其实每个sentinel是有互相监控的，并不是只监控其他的数据节点。
redis-sentinel.conf文件一般存在redis安装目标录下，由于我们需要在同一台机器部署多个，所以我们需要使用不同的端口。redis-sentinel的端口默认是26379，很好记，redis的默认端口6379+20000。以此类推我们启动三个redis-sentinel的端口分别是26379、26380、26381。这个我们需要在redis-sentinel.conf中修改。以下是配置文件：// Sentinel节点的端口
port 26379
dir /var/redis/data/
logfile "26379.log"
// 当前Sentinel节点监控 127.0.0.1:6379 这个主节点
// 2代表判断主节点失败至少需要2个Sentinel节点节点同意
// mymaster是主节点的别名
sentinel monitor mymaster 127.0.0.1 6379 2
//每个Sentinel节点都要定期PING命令来判断Redis数据节点和其余Sentinel节点是否可达，如果超过30000毫秒且没有回复，则判定不可达
sentinel down-after-milliseconds mymaster 30000
//当Sentinel节点集合对主节点故障判定达成一致时，Sentinel领导者节点会做故障转移操作，选出新的主节点，原来的从节点会向新的主节点发起复制操作，限制每次向新的主节点发起复制操作的从节点个数为1
sentinel parallel-syncs mymaster 1
//故障转移超时时间为180000毫秒
sentinel failover-timeout mymaster 180000
我们这样命名sentinel-26379.conf、sentinel-26380.conf、sentinel-26381.conf
接下来启动：
redis-sentinel sentinel-26379.conf、redis-sentinel sentinel-26380.conf、redis-sentinel sentinel-26381.conf
这样哨兵就可以正常工作啦～当我们把master的进程kill掉的时候会发现，会有slave变成了master，多么神奇～