Devops 最头疼的 Redis 问题 – 复制缓冲区

Redis 提供了各种工具，旨在改进和维护高效的内存数据库使用。 虽然其独特的数据类型和命令可以微调数据库以服务应用程序请求，而无需在应用程序级别进行任何额外处理，但配置错误，或者更确切地说，使用开箱即用的配置，可能（并且确实）会导致运营挑战和性能问题。 尽管这些挫折是造成许多头疼的原因，但解决方案确实存在，甚至可能比预期的更简单。

本系列文章将重点介绍使用 Redis 时出现的一些最令人恼火的问题，以及如何解决这些问题的技巧。 它们基于我们运行数千个 Redis 数据库实例的实际经验。

复制缓冲区限制

复制缓冲区是内存缓冲区，当从 Redis 服务器与主服务器同步时，它会保存数据。 在完整的 Master-Slave 同步中，在同步的初始阶段对数据执行的更改由主服务器保存在复制缓冲区中。 完成初始阶段后，缓冲区的内容将发送到从服务器。 此过程中可以使用的缓冲区大小有限制，导致当达到最大值时复制从头开始，如我们在关于无休止的 Redis 复制循环的帖子中所述。 为了防止这种情况发生，需要根据复制过程中预计进行的更改的数量和类型对缓冲区进行初始配置。 例如，少量的更改和/或更改中的较小数据可以使用较小的缓冲区，而如果有大量的更改和/或更改很大，则需要一个大的缓冲区。 更全面的解决方案需要将缓冲区设置为非常高的水平，以抵消冗长或繁重的复制过程最终会耗尽缓冲区的可能性（如果后者太小）。 最终，此解决方案需要微调手头的特定数据库。

Redis 默认设置

> config get client-output-buffer-limit
1) "client-output-buffer-limit"
2) "normal 1073741824 536870912 30 slave 268435456 67108864 60 pubsub 33554432 8388608 60"

正如此处所解释的，一旦达到 256MB 的硬限制，或者达到 67MB 的软限制并持续 60 秒，此默认配置复制链接将被打破（导致同步从头开始）。 在许多情况下，尤其是在具有高“写入”负载和从服务器带宽不足的情况下，复制过程将永远无法完成。 这可能导致无限循环情况，其中主 Redis 不断地将整个数据集分叉和快照到磁盘，这可能导致使用高达三倍的额外内存以及高 I/O 操作率。 此外，这种无限循环情况导致从服务器永远无法赶上并与主 Redis 服务器完全同步。

一个提供即时改进的简单解决方案是通过将硬限制和软限制都设置为 512MB 来增加输出从缓冲区的大小

> config set client-output-buffer-limit "slave 536870912 536870912 0"

与许多重新配置一样，重要的是要理解

1. 在增加复制缓冲区的大小之前，您必须确保您的机器上有足够的内存。
2. Redis 内存使用量计算不考虑复制缓冲区大小。

这使我们结束了关于 Redis 常见运营头疼问题的第一个文章。 如上所述，就复制缓冲区限制而言，正确的配置大有帮助。 请务必留意本汇编中的下一篇文章，该文章涵盖复制超时以及如何相应地处理它们。