单机模式
大部分人使用redis，最初的目的都是为了缓解数据库的压力。在应用于数据之间添加一个缓存，进而提高效率。
持久化
redis的数据都是存储在缓存中的，一旦redis挂了，重启缓存数据都会丢失。
在重启后的一段时间里，缓存是不存在的，请求依旧会直接落在数据库上。如果redis在启动后能将数据恢复回来是不是这个问题就解决了。这就引出了一个新的需求数据持久化。将数据通过持久化方案落到磁盘上，保证数据不丢失。
持久化说明可以参考redis 持久化 RDB AOF
主从多副本
redis重启后，持久化数据恢复到内存中毕竟还是需要一段时间的。为了更可能的减少等待时间，可以部署多个redis副本，部署成主从的形式，多副本数据同步。主负责写写数据，从负责读数据，实现读写分离。从挂了，不会影响应用。主挂了，可以手动提升一个从作为主。
哨兵模式
上文提到的主从多副本还是有一个问题没有解决，如果主挂了，需要手动提升从作为主。手动过程需要人工干预，于是新的方案是引入哨兵模式：使用哨兵作为观察者检测主的状态。如果主出现了异常，则通过选举算法自动提升一个从作为主，保证整个系统的可用。
为了防止误判，哨兵的选举算法要求哨兵的个数是奇数，当然一个是不够的（一个的可用性太低了），最少是三个。
集群模式
通过上文的描述，似乎可以保证整个系统的稳定性，但如果考虑到容量，整个系统似乎还是单台服务器的容量，必须要考虑横向扩展。
在这个方案里，第三方和官方有不同的方案。
第三方方案
第三方方案codis的方案就是起着一个中间代理的作用，能够把所有的Redis实例当成一个来使用，在客户端操作着SDK的时候和操作Redis的时候是一样的，没有差别。但是某些命令codis是不支持的。
官方集群方案
redis官方集群从3.0开始支持。
简单的说就是redis数据进行分片，分散到各个节点中。这个分片被称为hash slot，最多可分为16438（为什么是这个数？参考https://www.cnblogs.com/rjzheng/p/11430592.html）务中心化处理，包含主从与哨兵功能。客户端链接急群众的任意一个节点均可正常使用。
特点：
- 所有的redis节点彼此互联（PING-PONG机制），内部使用二进制协议优化传输速度和带宽；
- 节点的fail是通过集群中超过半数的节点检查失效时才生效；
- 客户端与redis节点直连，不需要中间proxy层，客户端不需要连接集群所有的节点，连接集群中任何一个可用节点即可；
- redis-cluster把所有的物理节点映射到[0-16383]slot上,cluster 负责维护
rediscluster 特点
