在互联网的大趋势下，用户体验、服务的可用性日趋重要。任何一个服务的不可用，都可能导致连锁式功能故障。
前言
高可用模型的已经逐渐形成一种套路：
- 主备/主从模式
- 集群模式
主备/主从模式
至少有两台服务节点master和backup/slave。同一时刻只有一台服务节点对外提供服务——master，backup/slave之一作为备/从机。当master宕机后，立即切换至backup/slave之一，backup/slave之一成为master，对外提供服务。
从主备/主从有无交互的角度可以划分：
- 主从交互：如mysql主从维持心跳，同步数据
- 主从不交互模式：nginx主备不交互，keepalive保证vip绑定
从故障转移方式角度划分：
- 利用第三方组件实现故障自动转移/主从切换：如使用keepalive实现主从切换
- 主从服务器软件自故障自动转移：如Redis Sentinel主从模式由Redis自实现
- 手动切换，转移故障：运维人员介入，经过操作实现切换
集群模式
至少有两台服务节点组成服务节点的群体，客户端常借助各种路由算法：
- 轮循
- 权重
- 随机
- 一致性hash
使得群体中的每个服务节点都对外提供一致性协同服务。即是集群的某一个或者某一些服务节点宕机，正常的节点仍能对外提供可用性服务，保证服务的高可用。集群模式天然的具有高可用特征。
Redis中的高可用
让Redis用户庆幸的是Redis中对这两种高可用模式都做了相应的实现。
Redis提供了Sentinel哨兵模式，即是主从模式的标准实现。Sentinel哨兵模式中，分为哨兵和存储两种类型节点。哨兵节点负责维护、监控、切换存储节点，存储节点主要负责提供数据管理能力——即单机Redis能力。
同时Redis还提供了集群模式，Redis的集群模式是Redis 3.0引入的新特征。整个集群中每个节点都作为存储节点，对外协同服务。
同时用户还可以简单的利用SHELL和Keepalive实现Redis的主从模式，不过在Redis完善的Sentinel模式下，这种方式就相形见绌了。