高可用方案
单机部署
单机模式的 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 类似，哨兵节点做成奇数个，是非常合适的。
哨兵模式可以通过 sentinal moniter 配置同时检测多套集群，在集群数量适中的时候，还是比较好用的。
但哨兵模式有很多隐藏的坑，比如哨兵的启动，必须在 master 存活的情况下才能正常运行；另外，如果你的 redis 配置文件中使用 rename 屏蔽了一些危险命令时，哨兵也不能够启动。
客户端在连接 redis 的时候，就不能再直接连接 redis 的实例，它需要从哨兵转上一圈，以便获取一些变更信息。
集群模式
集群模式可以说是这里面最优雅的方式了。你只需要部署多个对等的 redis 节点，然后使用客户端命令进行组群就可以了。
1 | ip=192.169.0.23 |
它对节点的要求也是比较多的，一般是采用 6 个节点，三主三从。当节点超过 10 个，它的协调性就不那么灵活了，所以单集群的存储和性能上限也很快能到达。
集群模式的一些缺点很隐蔽。它的服务端节点倒是非常稳定了，但有些命令会严重影响性能。比如 mget，pipeline 等。它们需要把请求分散到多个节点执行、再聚合。节点越多，性能越低。