redis 实现高并发主要依靠主从架构，一主多从。主从后要高可用，就要加哨兵，可以实现任何一个实例宕机，可进行主备切换。高并发高可用后想容纳大数据，要redis集群
主从架构：主从架构
redis集群：集群
一、哨兵机制介绍
1.1、哨兵功能 / 哨兵机制
可以在一个架构中运行多个哨兵进程，这些进程使用协议来接收master是否下线信息，并使用投票协议 来决定是否执行自动故障转移，以及选择哪个slave作为新的master；
每个哨兵会向其它哨兵、master、slave定时发送消息，以确定对方是否活着，如果对方在指定时间未回应，则暂时任务对方已经挂掉了；
若大多数哨兵都认为master没响应系统才会认为该master死亡（通过一定算法从剩下slave节点中选一台升为master）。
哨兵机制用于管理多个Redis服务器，该分布式系统（哨兵机制）执行下面三个任务（功能）：
（1）集群监控：负责监控 redis master 和 slave 进程是否正常工作。
（2）消息通知：如果某个 redis 实例有故障，那么哨兵负责发送消息作为报警通知给管理员。
（3）故障转移：如果 master node 挂掉了，会自动转移到 slave node 上（需要大部分的哨兵都同意才行，涉及到了分布式选举）。
配置中心：如果故障转移发生了，通知 client 客户端新的 master 地址。
1.2、哨兵注意点
（1）故障转移时，判断一个master node是宕机了，需要大部分的哨兵都同意才行，涉及到了分布式选举的问题
（2）哨兵至少需要3个实例，来保证自己的健壮性
哨兵集群必须部署 2 个以上节点，如果哨兵集群仅仅部署了 2 个哨兵实例，quorum = 1
配置 quorum=1，如果 master 宕机， s1 和 s2 中只要有 1 个哨兵认为 master 宕机了，就可以进行切换，同时 s1 和 s2 会选举出一个哨兵来执行故障转移。但是同时这个时候，需要 majority（运行的哨兵数）。如果此时仅仅是 M1 进程宕机了，哨兵 s1 正常运行，那么故障转移是 OK 的。但是如果是整个 M1 和 S1 运行的机器宕机了，那么哨兵只有 1 个，此时就没有 majority 来允许执行故障转移，虽然另外一台机器上还有一个 R1，但是故障转移不会执行
经典的 3 节点哨兵集群是这样的：
配置 quorum=2，如果 M1 所在机器宕机了，那么三个哨兵还剩下 2 个，S2 和 S3 可以一致认为 master 宕机了，然后选举出一个来执行故障转移，同时 3 个哨兵的 majority 是 2，所以还剩下的 2 个哨兵运行着，就可以允许执行故障转移
（3）哨兵 + redis主从的部署架构，是不会保证数据零丢失的，只能保证redis集群的高可用性
1.3、哨兵主从切换的数据丢失问题（两种情况）
（1）异步复制导致的数据丢失：
因为 master->slave 的复制是异步的，所以可能有部分数据还没复制到 slave，master 就宕机了，此时这部分数据就丢失了
（2）脑裂导致的数据丢失：
脑裂：某个 master 所在机器突然脱离了正常的网络，跟其他 slave 机器不能连接，但是实际上 master 还运行着。此时哨兵可能就会认为 master 宕机了，然后开启选举，将其他 slave 切换成了 master。这个时候，集群里就会有两个 master ，也就是所谓的脑裂
此时虽然某个 slave 被切换成了 master，但是可能 客户端还没来得及切换到新master，还继续向旧 master 写数据。因此旧 master 再次恢复的时候，会被作为一个 slave 挂到新的 master 上去，自己的数据会清空，重新从新的 master 复制数据。而新的 master 并没有后来 client 写入的数据，因此，这部分数据也就丢失了
1.4、数据丢失问题的解决方案
进行如下配置
min-slaves-to-write 1 //要求至少有 1 个 slave
min-slaves-max-lag 10 //数据复制和同步的延迟不能超过 10 秒
- 1
- 2
(1)减少异步复制数据的丢失
有了 min-slaves-max-lag 这个配置，就可以确保说，一旦 slave 复制数据和 ack 延时太长，就认为可能 master 宕机后损失的数据太多了，那么就拒绝写请求，这样可以把 master 宕机时由于部分数据未同步到 slave 导致的数据丢失降低的可控范围内
(2)减少脑裂的数据丢失
如果一个 master 出现了脑裂，跟其他 slave 丢了连接，那么上面两个配置可以确保说，如果不能继续给指定数量的 slave 发送数据，而且 slave 超过 10 秒没有给自己 ack 消息，那么就直接拒绝客户端的写请求。因此在脑裂场景下，最多就丢失 10 秒的数据
1.5、宕机类型sdown 和 odown 转换机制
sdown 是主观宕机：就一个哨兵如果自己觉得一个 master 宕机了，就是主观宕机 odown 是客观宕机：如果 quorum 数量的哨兵都觉得一个 master 宕机了，就是客观宕机
1.6、哨兵集群的自动发现机制
哨兵互相之间的发现，是通过 redis 的 pub/sub 系统实现的，
（1）每个哨兵都会往 sentinel:hello 这个 channel 里发送一个消息，这时候所有其他哨兵都可以消费到这个消息，并感知到其他的哨兵的存在。
（2）每隔两秒钟，每个哨兵都会往自己监控的某个 master+slaves 对应的channel 里发送一个消息，内容是自己的 host、ip 和 runid 还有对这个 master 的监控配置。
（3）每个哨兵也会去感知到同样在监听这个 master+slaves 的其他哨兵的存在
（4）每个哨兵还会跟其他哨兵交换对 master 的监控配置，互相进行监控配置的同步
1.7、quorum 和 majority理解
每次一个哨兵要做主备切换，首先需要 quorum 数量的哨兵认为 odown（客观宕机），然后选举出一个哨兵来做切换，这个哨兵还需要得到 majority 哨兵的授权，才能正式执行切换。
如果 quorum < majority，比如 5 个哨兵，majority 就是 3，quorum 设置为 2，那么就 3 个哨兵授权就可以执行切换。
但是如果 quorum >= majority，那么必须 quorum 数量的哨兵都授权，比如 5 个哨兵，quorum 是 5，那么必须 5 个哨兵都同意授权，才能执行切换
1.8、哨兵模式修改配置
实现步骤:
1.拷贝到etc目录
cp sentinel.conf /usr/local/redis/etc
2.修改sentinel.conf配置文件
sentinel monitor mymast 192.168.110.133 6379 1 #主节点 名称 IP 端口号 选举次数
sentinel auth-pass mymaster 123456
3. 修改心跳检测 5000毫秒
sentinel down-after-milliseconds mymaster 5000
4.sentinel parallel-syncs mymaster 2 --- 做多多少合格节点
5. 启动哨兵模式
./redis-server /usr/local/redis/etc/sentinel.conf --sentinel &
6. 停止哨兵模式
