前言

废掉一个人最隐蔽的方式，就是让他忙到没时间成长

一个老外的有关Redis的博客文章中提到一个有趣的事情：它们在测试期间获得的延迟图。为了持久化Redis的数据到磁盘（例如：RDB持久化），Redis需要调用fork()系统命令。

通常使用物理服务器和大多数虚拟机管理程序进行fork是很快的，即使很大的进程也是如此。 然而，Xen的fork()速度很慢，因此对于某些EC2实例类型（以及其他虚拟服务器提供程序），每次父进程调用fork()以便进行RDB持久化时，可能会出现严重的延迟峰值。 如下图所示，清晰的展示了延迟峰值：

您可以想象一下，如果您在fork()的时候做一个延迟测试，那么在父进程fork()的时候，所有请求将延迟一秒（以上图为例）。 这将产生大量具有高延迟的样本，并且将影响99%的结果。

要更改实例类型，配置，设置或其他任何内容以改善此行为是一个好主意，并且有些用例即使单个请求具有过高延迟也是不可接受的。然而很明显的是，每30分钟发生1秒的延迟峰值不是很明显，因为这与在请求中均匀分布延迟峰值有很大不同。

如果是均匀分布的峰值，如果访问某个页面需要对Redis服务器执行大量请求，则访问页面很可能会碰到延迟：这会严重影响服务质量。

然而，如上图所示，每运行30分钟后1秒的延迟是完全不同的事情。具有良好延迟表现的百分比随着请求数量的增加而变得更好，因为请求越多，这个延迟就越不可能在样本中过度表示出来，反而会被隐藏。如果您每分钟只有1个请求，并且其中一个请求恰好碰到fork()导致的高延迟，那就会让延迟测试结果非常难看。

另外：大多数页面浏览不受影响。 因为唯一那几个用户碰到1秒延迟的，是刚好他们的请求和fork()在同一时间，其他用户的请求只会有极低的概率碰到这样糟糕的事情。 另外请注意，与fork()撞上的页面访问（即使由100个请求组成）也不会延迟超过一秒，因为fork()完成后请求就会完成，并不需要等到RDB持久化完成。

只有fork()会导致延迟毛刺，fork出来的子进程在生成RDB文件过程中，并不会对系统有很大的影响。除非子进程生成RDB文件的过程中（这个过程使用了操作系统的copy-on-write机制）有大量的写入，而且服务器可用内存不多，这时候可能会发生swapping导致出现延迟。

在当今最流行的运行时环境EC2实例中，fork延迟是Redis用户最糟糕的体验之一，所以redis作者正着手测试Redis和EC2：相信很快就会在Redis官方文档中有对EC2进行特定优化的说明 ，到时候会有比在master-slaves中禁用持久性操作更安全的方案。

如果您现在需要EC2 + Redis主机并且已禁用持久性，则最简单的部署方式是禁用Redis实例的自动重启，并使用Sentinel进行故障转移，以便崩溃的主服务器不会自动返回可用状态。 在检查故障转移成功并且有新的可用的master后，系统管理员可以手动重新启动实例。

需要说明的是，并非所有EC2实例都是相同的，恰恰相反，各种EC2实例fork表现差异还很大。如下图所示，是老外做的一些测试：

总结

• Redis持久化时调用fork可能引起严重的延迟（RDB持久化以及AOF rewrite都会调用fork命令）；
• 只是fork时引起延迟，fork完成后，子进程生成RDB/AOF文件的过程并不会引起延迟；
• 即使Redis是单线程处理命令，但是服务器配置最好还是需要双核，如果有多个Redis实例，那么核心数相应的翻倍；
• 除了fork会引起延迟外，Redis中那些时间复杂度为O(n)的也会引起性能毛刺，例如keys命令等。