我Redis，高可用，强的很~

机智的小神仙儿

已于 2024-09-11 21:12:45 修改

阅读量615

点赞数 11

文章标签： redis 数据库缓存

于 2024-09-11 21:12:01 首次发布

本文链接：https://blog.csdn.net/weixin_45956028/article/details/142150469

版权

7 篇文章 0 订阅

订阅专栏

我是 Redis，平时在服务器上快速处理数据，但有一天我突然意识到，我只有一个服务器。这让我感到不安——如果服务器突然掉线，所有请求都没法处理了，这可不行！于是，我和我的团队开始商讨如何提升系统的高可用性，确保无论发生什么问题，系统都能继续稳定地运行。

为了增强可靠性，我决定设置一个主节点和多个从节点。主节点负责处理写入、删除、修改等命令，并将这些操作同步到从节点。这样，即使主节点出现故障，从节点还能保持最新的数据副本。

主节点和从节点的配合很简单：每当主节点有写操作时，它会通知从节点，保持数据的一致性。随着时间推移，我和主节点的合作越来越顺畅，数据同步也越来越稳定。

不过，有一天，我遇到了一个麻烦——我掉线了！虽然只是短暂的一小会儿，但当我重新上线时，主节点老大哥却试图让我同步最新的 RDB 文件。这就有点麻烦了，因为 RDB 文件是全量数据同步，我只是掉线了一会儿，完全没必要重新同步所有数据，太耗时了。

这时，另一个从节点提出了一个妙计：“为什么不建立一个缓冲区，在我们掉线后，只把最新的命令给我们同步呢？”这话提醒了我，但主节点老大哥也有点迷茫：“我们该怎么确保缓存里的命令与你掉线前的数据完美对接呢？我怎么知道哪些命令你还没接收到？”

为了让缓冲区的命令和掉线的从节点对接上，另一个从节点提议使用一个游标。每次数据复制时，主节点和从节点都记录下当前的位置偏移量。这样，当从节点重新上线时，它就能通过游标知道自己缺失了哪些数据，而主节点也能准确地从缓冲区中提取这些数据并同步给它。

游标的引入让我们再也不担心短暂掉线带来的全量数据同步问题，系统的同步效率得到了大幅提高。

然而，好景不长，有一天主节点老大哥突然挂了！这可是大事，谁来负责数据的读写操作呢？这时，有人提议：“为什么不让其他从节点接管？让其中一个从节点成为新的主节点！”

为了实现这个想法，我们引入了哨兵机制。哨兵是由多个实例组成的一个监控系统，它负责时刻监视主节点的状态，并在主节点出现故障时，自动执行故障转移。哨兵会每隔 10 秒询问主节点的状态，主节点则会告诉它有哪些从节点，然后哨兵再去ping这些从节点，确保它们也都在正常工作。

不过，问题随之而来。偶尔，有的管理员认为某个节点掉线了，但其他管理员却觉得它还在线，这就产生了矛盾。为了避免这种情况，我们引入了两个新的概念：主观下线和客观下线。

一旦确认主节点掉线，就需要执行故障转移。哨兵会根据优先级选择新的主节点。优先选择断线时间最短、复制偏移量最少的从节点作为新的主节点。然后，其他的从节点会从这个新主节点同步数据，旧的主节点则降级为从节点。

通过这种方式，我们不仅确保了数据的一致性，还实现了整个系统的高可用。

经过这些努力，我终于实现了 Redis 的高可用。无论是短暂掉线、数据同步，还是主节点故障，都能在哨兵的监控下得到及时处理。整个 Redis 系统变得更加可靠，也不再担心因为某个节点掉线而导致整个系统崩溃。

通过主节点、从节点和哨兵机制的协作，我可以确保即便在大规模分布式环境下，依然保持系统的高效运行和稳定的服务能力。

关注

专栏目录