Redis高可用到底咋弄,常见的那些方案和工具都有哪些呢?
- 问答
- 2026-01-02 00:01:30
- 5
Redis的高可用,说白了就是让Redis服务在各种可能出问题的情况下,还能继续干活儿,或者能很快地恢复过来,不让业务因为Redis挂了而瘫痪,核心目标就两点:一是数据尽量不丢,二是服务尽量不停,围绕这两个目标,业界搞出了几种主流的方案,咱们一个一个说。
主从复制 这是最基础、也是最简单的高可用基础,就像它的名字,弄一个主Redis节点,专门负责写数据;然后可以挂一个或多个从Redis节点,它们专门从主节点那里同步数据,主要负责读请求,这样一来,读的压力可以分散到多个从节点上,提升了整体读性能,万一主节点宕机了,我们手动把一个从节点提升为主节点,然后让应用改一下连接地址,就能恢复服务。 这个方案有个明显的缺点:故障切换不是自动的,你得派人盯着,或者写脚本监控,发现主节点挂了再手动操作,这个手动操作的过程,服务是不可用的,对于要求高的业务来说,这个中断时间太长了,主从复制更像是一种数据备份和读写分离的方案,为真正的高可用打下了基础,但它本身的高可用能力比较弱。(来源:Redis官方文档关于复制的说明)

哨兵模式 为了解决主从复制需要手动切换的问题,Redis提供了一个叫“哨兵”的工具,你可以把哨兵理解成一群自动的“监控员”,这些哨兵进程会不间断地检查主节点和从节点是否还“活着”,一旦哨兵们通过投票发现主节点真的挂了,它们就会自动从剩下的从节点中,选举出一个新的主节点,然后通知其他的从节点和客户端(需要客户端支持哨兵)“换老大”了。 这样一来,故障切换就变成了自动化的,大大缩短了服务中断的时间,哨兵模式是早期实现Redis高可用的标准方案,它通常需要部署奇数个哨兵实例(比如3个或5个),这样可以避免在网络出现分区时,哨兵们自己“分裂”成两派无法做出决策的情况。 不过哨兵模式也有它的局限,它只解决了故障转移,但写操作仍然只在主节点进行,所以写性能和存储容量还是会受到单台机器限制,在故障转移的瞬间,可能会有一小部分数据丢失(主节点还没来得及把最新数据同步给从节点就挂了),整个切换过程虽然自动化了,但依然需要几秒到十几秒的时间,期间应用可能会遇到短暂的错误。(来源:Redis官方文档关于Sentinel的详细介绍)
Redis Cluster 集群模式 这是Redis官方推出的“终极”分布式方案,旨在同时解决高可用和扩展性(尤其是写扩展和超大内存需求)两大难题,它不再依赖哨兵,而是把数据自动分片到多个主节点上,每个主节点都负责存储一部分数据(数据分片),并且每个主节点还拥有一个或多个从节点。 客户端可以直接连接集群中的任意节点,如果请求的数据不在这个节点上,节点会告诉客户端应该去哪个正确的节点访问,这就是“重定向”,高级的客户端还能缓存这种映射关系,下次直接连到对的节点。 在高可用方面,Redis Cluster内置了类似哨兵的功能,如果某个主节点挂了,它的从节点会自动被提升为新的主节点,继续服务它负责的那部分数据,由于数据是分片存储的,所以整个集群的写能力和存储空间可以随着主节点的增加而线性增长。 Redis Cluster是目前生产环境中最推荐的方式,尤其适用于数据量很大、并发要求很高的场景,但它也有些代价,比如架构更复杂,一些跨key的操作(比如多个key的集合运算)会受限,因为这几个key可能被分到了不同的节点上,客户端也需要支持集群协议。(来源:Redis官方文档关于Redis Cluster的架构设计)

基于代理的分片集群 在Redis Cluster成熟之前,很多公司为了解决单机瓶颈,自己搞了一套方案,其核心是引入一个“代理层”,比如Twemproxy或者Codis,应用不再直接连接Redis实例,而是连接这个代理,代理根据预设的规则(比如对key做哈希计算),把请求转发到后面对应的Redis实例上去。 在后端,可以部署多个主从复制组,每个组负责一个数据分片,代理层负责路由和故障转移,这种方案的优点是,对客户端来说非常简单,就像连接一个普通的Redis一样,不需要关心后端细节,Codis等工具还提供了图形化的管理界面,方便扩容和数据迁移。 但缺点也很明显,就是多了一层代理,网络延迟会增加一点,而且代理本身也可能成为性能瓶颈和单点故障(通常需要对代理做高可用),随着官方的Redis Cluster越来越稳定和完善,这种第三方代理方案的新增使用已经变少了,但一些老系统可能还在用。(来源:对早期业界实践如Twemproxy、Codis等工具的架构分析总结)
- 要求不高,简单备份读写分离:用主从复制。
- 要求自动故障切换,数据量不大:用哨兵模式。
- 数据量巨大,要求高可用和高并发读写:用Redis Cluster集群模式,这是主流选择。
- 遗留系统或特定场景:可能会遇到基于代理的分片集群。
选择哪种方案,最终要看你的业务对数据一致性、可用性、性能以及运维复杂度的具体要求来定。
本文由黎家于2026-01-02发表在笙亿网络策划,如有疑问,请联系我们。
本文链接:https://haoid.cn/wenda/72748.html
