redis高可用几种方案

Redis高可用 --高可用 读写分离

1 主从--高可用 读写分离

Redis主从复制：，当用户往Master端写入数据时，通过Redis Sync机制将数据文件发送至Slave，Slave 也会执行相同的操作确保数据一致+

优点：主写从读，降低读的压力。 缺点：master以为只有一个，所以写的压力难以降低； 从节点宕机，剩余一主一从，影响较小，可以继续使用

缺点：主节点宕机，无法继续使用，需要手工干预切换

Redis主从同步策略

主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis 策略是，无论如何，首先会尝试进行增量同步，如不成功，再要求从机进行全量同步

集群环境注意项

如果多个Slave重启或者master重启，会因为master_replid不一致导致全量同步，当多个同时出现的时候，可能会导致Master IO剧增而宕机。

2 哨兵（看词的意思也是放哨，即监控的意思）--高可用 读写分离

 

Redis主从虽然解决了单点导致的数据丢失问题，但是没有解决无缝的故障转移，也就是说在主库宕机后，从库无法自动切换为主库，需要手工去切换，在这一瞬间会对后端数据库造成极大的负载，可能直接导致后端数据库宕机

哨兵主要作用

监控：监控redis主库及从库运行状态；
通知：如果redis发生故障转移，可以通过邮件通知管理员；
自动故障转移：一旦发现主库宕机，则在从库中通过选举新的master进行故障转移。

工作原理

选举：超半数

哨兵(sentinel) 是一个分布式系统，你可以在一个架构中运行多个哨兵(sentinel) 进程，这些进程使用流言协议(gossipprotocols)来接收关于Master是否下线的信息，并使用投票协议(agreement protocols) 来决定是否执行自动故障迁移，以及选择哪个Slave作为新的Master。 每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息，以确认对方是否”活”着，如果发现对方在指定时间(可配置)内未回应，则暂时认为对方宕机了，这就是所谓的”主观认为宕机” （Subjective Down,简称sdown)。若“哨兵群”中的多数sentinel，都报告某一master没响应，系统才认为该master真正宕机，即“客观上认为宕机”（Objective Down,简称odown)，通过一定的vote算法，从剩下的slave节点中，选一台提升为 master，然后自动修改相关配置

优点
高可用，在主节点故障时能实现故障的转移

缺点：好像没办法做到水平拓展，如果内容很大的情况下

3 集群

集群模式和哨兵模式的区别

1. 哨兵模式监控权交给了哨兵系统，集群模式中是工作节点自己做监控
2. 哨兵模式发起选举是选举一个leader哨兵节点来处理故障转移，集群模式是在从节点中选举一个新的主节点，来处理故障的转移