本文转载自微信公众号“小姐姐的味道”，作者小姐姐养的狗。转载本文请联系味觉小姐公众号。Redis快速可靠，是互联网公司的标配。它有四种部署模式：单机、主从、哨兵和集群。下面，仅从部署方式上，来说明一下它们的优缺点。单机模式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模式可以通过sentinelmonitor配置同时检测多组集群，在集群数量适中的情况下比较好用。但是哨兵模式有很多隐藏的坑。比如sentinel的启动只有在master存活的情况下才能正常运行；另外，如果你在你的redis配置文件中使用RENAME来屏蔽一些危险的命令，那么sentinel是无法启动的。客户端连接redis时，不能再直接连接redis实例。它需要从sentinel转过来获取一些变化信息。集群模式集群模式可以说是这里最优雅的方式了。你只需要部署多个点对点的redis节点，然后使用客户端命令对它们进行分组即可。ip=192.169.0.23./bin/redis-cli--clustercreate$ip:7001$ip:7002$ip:7003$ip:7004$ip:7005$ip:7006--cluster-replicas1也需要节点比较频繁，一般使用6个节点，三主三从。当超过10个节点时，它的协调就没有那么灵活了，很快就会达到单个集群的存储和性能上限。集群模式的一些缺点是隐藏的。它的服务器节点非常稳定，但是有些命令会严重影响性能。比如mget、pipeline等，它们需要将请求分发到多个节点去执行和聚合。节点越多，性能越低。在下面的文章中，我们将详细介绍一些常见的redis使用规范，其中一些规范是为了避免集群模式带来的一些问题。在其他方案中，可以看到redis的这些集群模式并不完美。处理小型服务可能不是问题。对于大型集群和服务，这些部署方式在运维和使用上都带来了很大的挑战。使用client-sidehash的方法是大型互联网中常用的方法。参考下面的文章，现实中的路由规则可能相当复杂，但请求总是可以精确地落在一个小群体上。对于大型集群的管理，我更喜欢master-slave模式，然后用Java或者其他语言开发一个可以集中控制的sentinel系统来管理上千个集群。由于Redis是一个文本协议，协议非常简单，而且Netty甚至直接内置了它的解析器，所以开发这样一个哨兵系统非常简单。一些中间代理软件也可以分担一些路由工作，但是由于是中间层，涉及到一层网络转发，对于Redis这种以速度取胜的服务来说实用性不是很高。还有更多的变种，比如下面这篇文章，它使用的是Redis协议，但是后端存储是MySQL，所以你的命令会被阉割。从上面的描述中我们可以看出，使用Redis是一回事，用好又是另一回事。你可能会花一天时间构建一个单节点的Redis；我可能花一个星期写一个Java版的Sentinel，BUG还是很多。在不懂技术的领导眼里，两者没有区别——都是满足业务的需求。不过也不用太担心。现实一般都是残酷的，电脑系统并没有想象中那么稳定。墨菲定律将永远教导他们做人。当然，领导每天都在教我做人。作者简介：品味小姐姐（xjjdog），一个不允许程序员走弯路的公众号。专注于基础架构和Linux。十年架构，每天百亿流量，与你探讨高并发世界，给你不一样的滋味。我的个人微信xjjdog0，欢迎加好友进一步交流。
