单机模式
单机模式的redis非常简单，你只需要启动一个单一的节点就可以了，安装过程不超过5分钟。
通过redis-benchmark测试简单的命令，QPS可达到10w以上，不得不说非常的让人惊艳了。
单机模式的问题也非常明显。缺乏高可用的机制！
假如redis进程死了，进程就只能够穿透到底层的数据库中，对业务来说非常的危险。如果你把redis当作数据存储来用，情况会更加严重，甚至会丢失数据。
主从模式
所以最基本的redis部署，都会增加一个或者多个slave（现在叫replication）。
当主redis发生问题的时候，能够选取一个slave顶上去。
非常可惜的是，这种模式和传统的MySQL主从一样，切换起来比较蛋疼，需要借助外部的工具，比如keepalived等辅助进行切换，部署和维护难度直接飙升。
keepalived是一个基于VRRP协议来实现的高可用方案，通过 IP 漂移实现高可用。从描述上就可以看出它需要网络管理员的参与，和我们轻量级的redis背道而驰。
哨兵模式
哨兵模式就是使用额外的进程来替换keepalived的功能，对redis进程的存活性进行判断。在哨兵模式下，一旦主节点宕机，从节点作为主节点的备份可以随时顶上来。
但哨兵模式一个最大的问题，就是哨兵的数量太多，至少需要3个节点。
对redis进行仲裁的时候，需要n/2+1个节点投票才能确认，这也是分布式系统的一般做法 (quorum)。和Zookeeper类似，哨兵节点做成奇数个，是非常合适的。
哨兵模式可以通过sentinel monitor配置同时检测多套集群，在集群数量适中的时候，还是比较好用的。
但哨兵模式有很多隐藏的坑，比如哨兵的启动，必须在master存活的情况下才能正常运行；另外，如果你的redis配置文件中使用RENAME屏蔽了一些危险命令时，哨兵也不能够启动。
客户端在连接redis的时候，就不能再直接连接redis的实例，它需要从哨兵转上一圈，以便获取一些变更信息。
集群模式
集群模式可以说是这里面最优雅的方式了。你只需要部署多个对等的redis节点，然后使用客户端命令进行组群就可以了。
ip=192.169.0.23 ./bin/redis-cli --cluster create $ip:7001 $ip:7002 $ip:7003 $ip:7004 $ip:7005 $ip:7006 --cluster-replicas 1
它对节点的要求也是比较多的，一般是采用6个节点，三主三从。一旦节点数量超过10个，协同性就会变得不太灵活，因此，单个集群的存储和性能上限也迅速达到。
集群模式的一些缺点很隐蔽。它的服务端节点倒是非常稳定了，但有些命令会严重影响性能。比如mget,pipeline等。它们需要把请求分散到多个节点执行、再聚合。节点越多，性能越低。
