客户端缓冲区组成了服务客户请求所需的内存空间，Redis的每个连接都配有自己的缓冲区空间。处理请求后，Redis把响应数据复制到客户端缓冲 区，然后继续处理下一个请求，与此同时，请求客户端通过网络连接读取数据。Redis客户端缓冲区配置在redis.conf文件，通过client- output-buffer-limit normal指令配置（你可以在运行时通过config get client-output-buffer-limit指令获取设置）。默认的redis.conf文件定义如下： client-output-buffer-limit normal 0 0 0 这些数值分别代表缓冲区软限制，硬限制和以秒为单位的超时（类似于复制缓冲区）。当Redis终止连接时，这些值提供保护——不需要客户读取回复——当缓冲区尺寸达到a）软限制并且保持状态直到超时b）硬限制。将这些数值都设为0意味着关闭保护。 不过，和复制缓冲区不同的是客户端缓冲区来自Redis数据内存空间。可以通过maxmemory指令设置Redis的总内存值，达到极限 后，Redis将应用其配置的驱逐策略（由maxmemory-policy 指令定义）。因此，低性能的客户或大量的同时连接可能会因为数据集尺寸和客 户端缓冲区达到内存限制导致Redis实例过早的驱逐键或禁止更新。 由于生命周期的相对性，一个客户端不需要降低性能就可能导致这种现象。因为RAM读取和网络读取存在着很大的速度差异，过多的客户端缓冲区很可能耗 尽Redis内存，即使是在高性能的客户端和网络连接中。例如，考虑下（万恶的）KEYS指令，这个指令触发后，Redis将会把整个键的名空间拷贝给客 户端缓冲区。如果我们的数据库有很多键，这很可能导致驱逐。 警告：使用KEYS时务必要谨慎，不要在生产环境下使用KEYS。使用KEYS除了可能导致上文提到的驱逐外，还可能会在很长时间内封锁Redis。 KEYS不是唯一一个可能导致这种情况的指令。类似的指令还有SMEMBERS，HGETALL，LRANGE和ZRANGE（以及与这些指令相关的指令），当值（或范围）足够大，或者当有很多公开连接（每个连接都需要单独的缓冲区）时，这些指令可能导致类似的现象。 我们强烈推荐谨慎负责的使用这些指令。我们推荐大家使用SCAN家族指令替代这些指令，v2.8版本加入了SCAN指令。SCAN指令不仅允许Redis在后续的SCAN调用间继续处理请求，还降低了耗尽客户端缓冲区的概率。 客户端缓冲区是Redis内存需求和管理常常会忽略的方面。客户端缓冲区的默认设置有风险，很可能导致内存耗尽。我们要有依据的设置缓冲区阈值—考 虑“maxmemory”设置，当下和预测内存使用，应用流量模式。谨慎的使用先前提到的指令可以避免那些令人头疼的问题。欢迎关注我们后续的文章。 原文链接： Top Redis Headaches for Devops – Client Buffers Top Redis Headaches for Devops – Replication Timeouts Top Redis Headaches for Devops – Client Buffers（翻译/仁君 责编/仲浩） |
