Redis由于将数据保存在内存中，访问速度远远大于基于磁盘的数据库（如MySQL）。但是由于内存容量有限、断电数据容易丢失，因此Redis常作为缓存使用，并且其高可用也是一个非常重要的问题。Redis的高可用方案可以从以下三个方面进行考虑：
- 尽可能保证Redis 自身不出问题
- Redis 一旦出现了问题可以尽早被发现
- Redis 出了问题之后可以尽快恢复
1. Redis自身高可用
Redis本身提供了哨兵模式、集群模式两种高可用方案，核心思想是通过哨兵节点（哨兵模式）或主节点（集群模式）监控所有主节点的状态，一旦发现某一个主节点不可用，将其对应的从节点切换成主节点。由于从节点之前已经同步了主节点的数据，因此对应用方影响不大（但是实际还是会有影响的）。
- 哨兵模式经常是部署三台哨兵节点，然后根据数据的内存使用情况，分配相同数量的主从节点，应用服务需要连接到哨兵节点上。
- 集群模式一般是3主3从结构，并且每个节点尽量部署在不同的物理机上，降低一台机器down掉对集群的影响。
除了在部署上通过哨兵模式或集群模式保证Redis高可用外，在使用上还特别需要注意：
- Redis尽量专集群专用，这样有几点好处:
- 防止Redis实例上连接的客户端太多，某一个应用获取不到连接从而无法访问Redis
- 因为Redis是单线程的，避免处理某一个耗时的请求时，拖慢或阻塞其他应用
- 注意慢查询和大key（key对应的value占内存特别大），因为Redis是单线程的，在处理一个特别慢的请求时，实例之间同步状态受到影响，极端情况下会被认为当前实例已经下线，从而频繁地切换主从
- 禁止一些危险命令的使用
- flushall、flushdb
- eval 命令中执行一个特别慢的脚本
- Redis实例个数不要特别多，或者某一个实例分配特别大的内存
2. Redis监控
满足以上条件也无法保证Redis万无一失，还需要对Redis进行监控，以便可以尽早地发现问题。需要注意的是除了对Redis本身的健康状态进行监控外，还需要监控Redis实例所在物理机的状态，包括机器是否可以访问、内存使用量、磁盘占用量等。
Redis的监控运维平台可以参考搜狐开源的CacheCloud
3. Redis持久化方案
前两步已经基本能够保证Redis的高可用了，但Redis还是出问题了，就得考虑如何快速恢复了。Redis可以通过开启持久化，保证Redis重启时候，数据可以快速恢复。Redis持久化方案包括RDB（fork子进程，将内存快照写到磁盘上）和aof（双写Redis的所有操作）。
但是需要注意的是，无论是RDB的 fork子进程，还是aof的双写都会对Redis的性能造成影响，并且这两种方式都无法完全保证数据一点都不丢失。因此生产上常常禁用持久化的，而是通过前两步骤保证。
以上三种方案都无法很好地保证Redis的数据完全不丢失，因此又回到了Redis的使用场景上，读多写少，只做缓存使用，并且能够接受数据的丢失，一旦数据丢失，可以从数据库中重新加载进来。
