当前位置：首页 > 问答 > 正文

Redis各种模式到底差在哪儿，聊聊那些你可能没注意的细节和区别

说到Redis的模式，很多人可能只知道单机、主从、哨兵和集群这几种，但真要细问它们之间到底有什么不同，为什么有时候用这个而不用那个，可能就有点模糊了，今天我们就抛开那些复杂的配置参数,聊聊这些模式核心的差别和一些容易被忽略的细节。

单机模式：最简单的开始，也是最脆弱的形态

单机模式就是只运行一个Redis实例，所有数据都存在这一台机器上，这是最基础、最简单的模式,学习和开发测试时基本都用它。

核心差别：它没有高可用性可言，所谓高可用，就是说服务挂了能不能自动恢复，单机模式下，这台机器一旦出问题（比如硬盘坏了、断电了），整个Redis服务就彻底不可用了,数据也可能丢失。
关键细节：很多人以为用了Redis数据就万无一失了，其实不然，即使在单机版，Redis也提供了持久化机制（RDB快照和AOF日志）来尽量避免数据丢失，但这是个取舍：持久化太频繁会影响性能，不频繁则丢数据风险高，单机模式的核心问题在于,它无法应对机器本身的故障。

主从模式：数据有了“备份”，但故障需要“手动”

为了解决单机模式的脆弱性，主从模式被引入，它通常由一个主节点和多个从节点组成，主节点负责写操作，然后将数据变化同步给从节点；从节点主要承担读操作,分担主节点的压力。

Redis各种模式到底差在哪儿，聊聊那些你可能没注意的细节和区别

核心差别：它实现了数据的冗余备份，如果只是从节点挂了，不影响使用；如果主节点挂了，从节点上有完整的数据副本,数据不会丢。
容易被忽略的细节：
1. 故障切换不是自动的：这是主从模式和哨兵模式最大的区别，当主节点宕机时，整个系统会处于无法写入的状态，需要运维人员手动将一个从节点“提拔”成新的主节点，并让其他节点和应用程序指向这个新主节点，这个过程需要时间,期间服务会中断。
2. 读写分离的复杂性：虽然从节点可以分担读压力，但应用程序需要配置成将读写请求分别发送到主节点和从节点，由于数据同步是异步的，从节点的数据可能会比主节点旧一点点（毫秒级），如果应用对数据一致性要求极高,可能无法接受读取到旧数据。

哨兵模式：给主从加上“自动故障转移”

哨兵模式在主从模式的基础上，增加了一组独立的“哨兵”进程，哨兵不存储数据，它的任务就像一群保安,7x24小时监控主从节点是否健康。

Redis各种模式到底差在哪儿，聊聊那些你可能没注意的细节和区别

核心差别：实现了高可用，当哨兵发现主节点失联时，它会自动发起投票，从剩余的从节点中选举出一个新的主节点，并通知客户端和其他的从节点切换到这个新主节点,整个过程无需人工干预。
容易被忽略的细节：
1. 脑裂问题：在网络出现分区（比如主节点和部分哨兵、从节点之间网络突然中断）时，可能会产生两个“主节点”都认为自己是老大，导致数据写入混乱，虽然Redis哨兵有机制来尽量避免这种情况,但在极端网络条件下仍有可能发生。
2. 扩容瓶颈：哨兵模式解决了高可用问题，但并没有解决单主节点写能力和存储容量受限的问题，所有的写请求仍然只集中在一个主节点上，如果数据量巨大，单机内存装不下，或者写并发超高，哨兵模式就无能为力了,这是它和集群模式的根本区别。

集群模式：为了“海量数据”和“高并发写”而生

集群模式是Redis的终极解决方案，它通过分片（Sharding）的方式来分散数据和负载。

核心差别：它将数据自动分片到多个主节点上，每个主节点只存储整个数据集的一部分，每个主节点还可以配置多个从节点，实现高可用，这样既突破了单机内存和性能的限制,又保证了高可用。
容易被忽略的细节：
1. key的分布：数据是怎么分布到不同节点上的呢？Redis集群通过计算key的哈希槽（slot）来决定，一个集群有16384个槽，每个节点负责一部分槽，这就要求客户端必须支持集群协议，能够正确地根据key找到对应的节点，有些操作，比如同时操作多个key（如MSET），要求这些key必须在同一个节点上（即位于同一个哈希槽），否则会报错，这就需要使用“哈希标签”来确保一批key被分配到同一个槽。
2. gossip协议：集群节点之间通过一种叫gossip的协议来通信，彼此交换信息、检测故障，这比哨兵的集中式监控更去中心化，扩展性更好,但状态传播可能会有轻微延迟。
3. 网络要求更高：由于节点间需要频繁通信,集群对网络的质量和稳定性要求比前几种模式都高。

选择哪种模式,完全取决于你的业务场景。