Redis集群里从节点不仅仅是备份，还能做这些事你知道吗

很多人把Redis集群里的从节点简单地理解为一个“备胎”或者“备份服务器”，主节点干活，它就在旁边看着，等主节点出问题了才顶上去，这么想其实小看了从节点的能力，它不仅仅是为了防止数据丢失而存在的，它在系统平稳运行的时候，也能分担很多重要的工作,让整个集群变得更加强大和好用。

第一，从节点是读流量的强大后盾。

这是从节点最直接也是最重要的一个扩展能力，想象一下，你的应用非常火爆，有大量的用户同时在线，每一个用户的操作，比如浏览商品详情、刷新朋友圈、查看新闻列表，基本上都是“读”请求，如果所有这些请求都压到唯一的主节点上，主节点再厉害也可能被累垮,导致响应变慢。

这时候，从节点的价值就体现出来了，你可以配置应用程序，把所有的“读”请求，比如那些GET、HGET、LRANGE之类的操作，自动地发送到从节点上去执行，而像SET、HSET这样修改数据的“写”请求，依然交给主节点处理，这样就实现了“读写分离”，相当于给主节点请了一个（甚至多个）专门的助手来处理简单的查询工作，主节点可以更专注于处理重要的数据写入，从而提升了整个系统处理请求的能力和速度，对于一些读多写少的应用，比如内容网站、社交平台，通过增加从节点来扩展读能力,是一个非常经济有效的办法。

第二，从节点让数据备份变得不影响业务。

为了保证数据安全，我们定期需要对数据进行备份，就像给重要文件拍照留底一样，如果直接在主节点上执行备份操作，比如生成一个数据快照文件，这个过程可能会消耗比较多的CPU和内存资源，就像一台电脑在同时运行大型游戏和复制超大文件一样，难免会有些卡顿，如果这个备份操作正好发生在业务高峰期,就可能会影响到主节点处理正常用户请求的速度。

有了从节点，我们就可以把这个“体力活”交给它来做，你可以选择在一个或多个从节点上设置备份任务，让它们在不那么忙的时候（比如凌晨）去生成数据快照，这样做，备份过程对主节点完全没有干扰，主节点可以一如既往地提供高速服务，保证了线上业务的流畅性，相当于办公室里，老板（主节点）继续专注地谈大生意，而助理（从节点）在后面默默地整理文件档案,两不耽误。

第三，从节点为数据分析和重型操作提供了“安全沙箱”。

我们需要对数据库里的数据进行一些复杂的分析，或者执行一些比较耗时的命令，这些操作可能只是为了出个报表，或者做一些内部的数据挖掘，并不需要立刻得到结果,但它们可能会长时间占用数据库资源。

如果直接在主节点上跑这些分析任务，就好像在一条繁忙的高速公路上进行道路检修，肯定会造成严重的交通堵塞，影响正常的车辆（用户请求）通行，而从节点，特别是那些专门为此目的设置的从节点，就成为了一个完美的“安全沙箱”，你可以放心地把这些分析型的、重型的查询任务指向一个从节点，即使这个查询跑了很长时间，把从节点搞得速度很慢，也不会影响到主节点和其他为正常用户服务的从节点，这相当于在高速公路旁边专门修了一条辅路给工程车用,保证了主路的畅通无阻。

第四，从节点是实现高可用的基石。

这可能是大家最熟知的一点，但它的意义依然重大，主节点不可能永远不出问题，可能会因为硬件故障、网络问题等各种原因挂掉，Redis集群的高可用机制的核心，就是依赖于从节点，当一个主节点失效后，集群会自动从它的从节点中,选举出一个新的主节点来接管工作。

这个过程是自动化的，对于应用程序来说，可能只会感受到瞬间的卡顿，然后就能继续正常服务了，数据也不会丢失，没有从节点，主节点一挂，整个服务就彻底中断了，从节点在这里扮演了“接班人”的角色，确保了服务能够7x24小时不间断地运行,提供了故障恢复的能力。

第五，从节点助力无缝的版本升级和维护。

任何软件都需要更新升级来修复漏洞或获得新功能，Redis也不例外，直接关闭主节点进行升级会导致服务中断，利用从节点，我们可以实现一种“滚动升级”的策略。

具体做法是，我们可以先逐个升级从节点：将一个从节点脱离集群，升级它的Redis版本，测试无误后，再让它重新加入集群同步数据，等所有从节点都升级完毕后，最后再进行主节点的切换和升级，通过先将一个从节点提升为新的主节点，然后将旧的主节点降级为从节点再进行升级，这样可以实现整个集群在几乎不中断服务的情况下完成软件版本的更新，同样，对于硬件维护、机房迁移等操作，也可以利用类似的技巧,最大限度地减少对业务的影响。

Redis集群中的从节点是一个多面手，它绝不仅仅是数据的冷备份，而是一个积极参与系统运行、提升扩展性、保障稳定性、方便运维管理的活跃角色，充分利用从节点的这些能力，能够让你构建的Redis服务更加健壮、高效和灵活。 依据Redis官方文档关于复制与高可用的核心原理及常见实践方案整理）