对于redis slave的持久化模型,除了从slave到master进行rsync rdb之外,还有没有更好的方法?

对于redis slave的持久化模型,除了从slave到master进行rsync rdb之外,还有没有更好的方法?

我的 redis 机器的 rdb 大小约为 1 GB。我的应用程序大量使用 redis,不能让主服务器处理 bgsave,否则,它会拖慢主服务器机器上的所有系统。因此,我必须阻止主服务器执行 bgsave,只让从服务器执行持久性工作。

问题出现在需要重启 master 的时候。它必须从 slave 复制 rdb 以将初始数据加载到内存中。这个过程大约需要 30-60 秒。如果我的 redis 变大,这个过程的时间就会增加。

我曾尝试使用 NFS 让主服务器和从服务器使用相同的 rdb 来读/写,但是复制过程强制主服务器在从服务器第一次连接到主服务器时执行 bgsave,而它无法执行这项工作,因为源 rdb(主服务器)和目标 rdb(从服务器)位于同一位置。

问题是“有没有更好的方法来完成这个初始将 rdb 加载到内存中的作业?”。

答案1

简而言之,没有本质上“更快”的方法来加速从 AOF 或 RDB 加载数据到 Redis。也许更快的磁盘会带来一点提升,但正如您所观察到的,这是一个线性时间操作。

长话短说,您已经达到了当前架构的极限,重新考虑一下会对您大有裨益。这种情况下有几个选项,网络上有详细介绍(您必须根据自己的经验来确定哪种解决方案最适合您。)

以下是一些选项,首先介绍最复杂的选项:

  • 2-3 个从属服务器和自动故障转移,由 ZooKeeper 协调
  • 使用 Redis Sentinel
  • 代理服务器

在我看来,此时对数据进行分区对您没有太大帮助,因为您的数据集仍然相对较小。总体而言,您需要在保持持久性的同时解决主服务器的可用性和协调问题。

BGSAVE最后,上面更复杂的答案涉及水平扩展。您在单台主机和小型数据集下承受着压力:您应该考虑垂直扩展以解决您的眼前问题(即为主服务器配备更强大的机器)。这样,您就完全避开了BGSAVE从服务器/重启主服务器/从从服务器加载的问题,至少目前如此。从短期来看,它也可能更具成本效益。

相关内容