Redis提供了许多提高和维护高效内存数据库使用的工具。在无需额外配置应用层的前提下，Redis独特的数据类型、指令和命令调优就可以满足应用的需求，但是错误的配置，更确切的说那些机外设备可能导致操作麻烦和性能问题。虽然导致了一些令人头疼的问题，但是解决方案是存在的，而且解决方案可能比我们预期的简单。
本系列文章介绍了使用Redis时遇到的一些令人头疼的问题，以及该解决这些问题。这些内容基于我们在运行上千个Redis数据库实例时的真实经历。
复制缓冲区限制
复制缓冲区主从服务器同步数据时保存数据的内存区域。在一个完整的主从同步中，初始化阶段同步时，主服务器在复制缓冲区中保存数据的变化。初始化阶段完成后，缓冲的内容发送到从服务器。这个过程可能会遇到缓冲区的容量限制，达到最大容量时复制会重新开始。为了避免这种情况，缓冲区需要依据复制过程中变化的类型和数量进行初始化配置。例如，一个小缓冲区可以存储少量的变化数据，但当变化比较多、比较大时，我们需要大缓冲区。一个更复杂的解决方案会更详细的设置缓冲区，避免冗长、大的复杂过程耗尽缓冲区（如果缓冲区太小）。最终，这个解决方案需要微调特定的数据库。
当256MB的硬限制到达时，或者软限制到达且持续60秒时，默认的复制链路会断裂（导致同步从头开始）。许多情况下，特别是写负载高和从服务器带宽不足的情况下，负载过程都无法结束。这可能导致无限循环，主Redis持续的将整个数据集复制到硬盘，这可以导致高速率的I/O操作，消耗高达三倍的额外内存。此外，无限循环将导致从服务器无法赶上主服务器，无法与主服务器完全同步。
一个简单地解决方案是提高输出从缓冲区，将软硬限制都设置为512MB，这个解决方案可以很快的提高结果。
因为有很多重新配置，所以务必理解：
1. 在增加复制缓冲区尺寸前，我们必须确保机器上有足够的内存。
2. Redis内存使用计算不考虑复制缓冲区容量。
以上是本文介绍的第一个问题。如我们上面谈到的，尽管有复制缓冲区限制，合适的配置是可以良好运行的。下面我们谈谈主从复制的另一问题。我们将深入讨论完成该过程所需的时间和可能导致麻烦的一些配置问题。
复制超时
如我们先前讨论的，Redis的复制过程包括两个同步阶段：初始化阶段和进行阶段。尽管进行阶段很稳定（只要保持主从服务器间的链路即可），初始化阶段不那么容易完成。成功的完成初始化同步不止依赖于复制缓冲区分配的内存，还基于该步骤花费的时间。
你可能想起来了，初始化同步步骤包括后台保存以及整个数据主导从的传播。基于数据库容量和网络连接质量，这可能是一个很长的过程。如果阶段耗时太久，Redis可能会达到复制超时设置，这可能会导致初始阶段重复进行。这种情况下，你会发现从Redis日志文档充斥着这些信息：
[28618] 21 Jul 00:33:36.031 * Connecting to MASTER 10.60.228.106:25994
[28618] 21 Jul 00:33:36.032 * MASTER <-> SLAVE sync started
[28618] 21 Jul 00:33:36.032 * Non blocking connect for SYNC fired the event.
[28618] 21 Jul 00:33:36.032 * Master replied to PING, replication can continue...
[28618] 21 Jul 00:33:36.032 * Partial resynchronization not possible (no cached master)
[28618] 21 Jul 00:33:36.032 * Full resync from master: 549907b03661629665eb90846ea921f23de6c961:2537453
Redis复制超时的默认值是60秒（见redis.conf文件的repl-timeout指令，或使用redis-cli运行“config get repl-timeout”）。这个时间可能很短，特别是当你有：
- 低速存储器：如果主服务器或从服务器是基于低速存储器的，如果是主服务器将导致后台进程花费很多时间；如果是服务器磁盘读写数据时间将延长。
- 大数据集：更大的数据集将需要更长的存储时间和传输时间。
- 网络性能：当主服务器和从服务器的网络链路有限制带宽和高延迟时，这会直接影响数据传输传输速率。
我们可以通过将复制超时设置为更合适的值来修正这个问题。首先是一个可接受复制数据库的的估计时间。第一步，检查Redis通过BGSAVE指令和检查相关行（如“Background saving started by pid nnn ”表示进程开始，“ Background saving terminated with success”表示进程结束）的日志文档执行后台进程所花的时间。然后，测量CN将主服务器上的结果RDB文件拷贝到从服务器硬盘所需的时间。最后，测量从硬盘加载数据实际消耗的时间（如重启Redis，在日志文件中寻找“DB loaded from disk”行）。这些方法可以大致估计复制超时值，保险起见，我们可能需要在上面加上10~20%。
依据测量值设定了超时后，我们可以通过让从服务器执行几次完整的同步和检查日志文件来测量复制的实际耗时。如果可能的话，在日常不同的时刻重复这个操作，确保在不同的负载下系统的表现良好。最后，切记随着数据库的增长，我们需要定时检查超时设置值。
以上描述的是Redis复制问题。复制是保持数据库可用、扩展数据库可读性的有力工具，不过注意复制的默认设置，确保依照实际使用情况配置数据库。下面我们谈谈客户端缓冲区。在有些情况下，客户端缓冲区会带来很多问题。
客户端缓冲区
你大概已经知道Redis是一个内存数据库，这意味着所有的数据都由RAM直接管理和提供的。因此Redis有着卓越的交付性能，Redis可以以亚毫秒级的延迟处理几万、几十万的请求。RAM是当下最快的存储技术——为了更好的理解延迟数字，请看以下数据：
Latency Comparison Numbers
--------------------------
L1 cache reference 0.5 ns
Branch mispredict 5 ns
L2 cache reference 7 ns 14x L1 cache
Mutex lock/unlock 25 ns
Main memory reference 100 ns 20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy 3,000 ns
Send 1K bytes over 1 Gbps network 10,000 ns 0.01 ms
Read 4K randomly from SSD* 150,000 ns 0.15 ms
Read 1 MB sequentially from memory 250,000 ns 0.25 ms
Round trip within same datacenter 500,000 ns 0.5 ms
Read 1 MB sequentially from SSD* 1,000,000 ns 1 ms 4X memory
Disk seek 10,000,000 ns 10 ms 20x datacenter roundtrip
Read 1 MB sequentially from disk 20,000,000 ns 20 ms 80x memory, 20X SSD
Send packet CA->Netherlands->CA 150,000,000 ns 150 ms
Notes
-----
1 ns = 10-9 seconds
1 ms = 10-3 seconds
* Assuming ~1GB/sec SSD
Credit
------
By Jeff Dean: http://research.google.com/people/jeff/
Originally by Peter Norvig: http://norvig.com/21-days.html#answers
Contributions
-------------
Some updates from: https://gist.github.com/2843375
Great 'humanized' comparison version:https://gist.github.com/2843375
Visual comparison chart: http://i.imgur.com/k0t1e.png
Nice animated presentation of the data: http://prezi.com/pdkvgys-r0y6/latency-numbers-for-programmers-web-development/
- See more at:http://redislabs.com/blog/top-redis-headaches-for-devops-client-buffers#sthash.9rHluMPF.dpuf
Redis，如同它的名字和设计，是一个移动服务器，客户端（通常）通过网络连接Redis。这种情况下，客户端请求返回客户端的时间将显著长于Redis CPU从RAM读取数据的时间。这意味着如果没有客户端缓冲区的话，Redis的主要差异与在该段时间对服务的响应有关。
客户端缓冲区组成了服务客户请求所需的内存空间，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
来源：oschina
链接：https://my.oschina.net/u/4352922/blog/4313145