redis速度快、可靠，是互联网公司的标准配备。 有独立、主从、哨兵、群集四种部署模式。
以下仅从部署模式说明这些优点和缺点。
脱机模式
独立模式的redis非常简单，只需引导一个节点即可在5分钟内安装。
根据redis-benchmark测试的简单指令，QPS达到10w以上，令人惊讶。
独立模式的问题也很明显。 没有高可用性机制！
redis流程死亡时，流程只能透过基础数据库，对业务非常危险。 使用redis作为数据存储可能会导致情况恶化和数据丢失。
主从模式
因此，最基本的redis部署将添加一个或多个slave (现在称为复制)。
如果主redis出现问题，可以选择从站上升。
遗憾的是，这种模式和传统的MySQL主从一样，切换的话蛋包会痛，需要用外部工具，例如keepalived等辅助切换，导入和维护的难度会直接增加。
keepalived是基于VRRP协议的高可用性方案，通过IP漂移实现高可用性。 由说明可知，需要网络管理者的参加，与轻量的redis相反。
哨兵模式
哨兵模式将keepalived的功能替换为多馀的进程，并确定redis进程的生存性。 在感知通道模式下，当主节点关闭时，可以随时将从节点作为主节点进行备份。
但是，哨兵模式的最大问题之一是哨兵的数量过多，至少需要3个节点。
仲裁redis时需要n/2 1个节点投票，这也是分布式系统中的常见做法。 与Zookeeper相似，哨点应为奇数个。
哨兵模式可以用sentinel monitor结构同时检测多个簇，在簇数适度的情况下很方便。
但是，哨位图案中有很多隐蔽的洞。 例如，哨兵的启动必须在master存活期间正常工作，如果在redis配置文件中使用RENAME掩蔽危险命令，哨兵也无法启动。
客户端连接到redis时，不能直接连接到redis实例。 为了取得变更信息，需要从哨所绕一周。丛集模式
簇模式可以说是其中最优雅的方式。 只需引入多个对等redis节点，并使用客户端命令进行分组。
redis的这些集群模型并不完美。 应对小型服务可能没有问题，但是对于大型集群和服务，这些部署方法在运输和使用上都有非常大的问题。
使用客户端散列的方法是大型互联网上常用的方法。 请参阅下一篇文章。 现实的路由规则可能会变得相当复杂，但是请求总是可以准确地落在一个小团体上。
为了管理大型集群，我倾向于成为主从模式，然后开发出能够使用Java等语言进行集中管理的哨兵系统，管理数千个集群。
Redis是一种文本协议，协议非常简单，Netty直接将其解析器内置，因此开发这样的哨兵系统非常简单。
有些中间层代理软件可以分担路由选择工作，但由于是中间层，涉及网络传输，对于以Redis这样的速度获胜的服务不实用。
下一篇文章使用Redis协议，但后端存储是MySQL，所以命令将被阉割。
中文
电话咨询
微信咨询
公众号
