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

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

复制缓冲区限制

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

Redis默认设置：

> config get client-output-buffer-limit1) "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操作难题。如上所述，就复制缓冲区限制而言，正确的配置可能会有很长的路要走。请务必留意本汇编中的下一篇文章，其中包括复制超时以及如何相应地处理它们。