如何解决Redis中的key过期问题

每个循环上采样的数字由变量

ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP

该测试有一个控件和三个测试实例，可以对更多key进行采样。500和200是任意的。值300是基于统计样本大小的计算器的输出，其中总key数是总体大小。在上面的图表中，即使只看测试实例的初始数量，也可以清楚地看出它们的性能更好。这个与运行扫描的百分比的差异表明，过期key的开销约为25％。

虽然对更多key进行采样有助于我们找到更多过期key，但负延迟效应超出了我们的承受能力。

上图显示了99.9％的延迟（以毫秒为单位）。这表明延迟与采样的key的增加相关。橙色代表值500，绿色代表300，蓝色代表200，控制为黄色。这些线条与上表中的颜色相匹配。

在看到延迟受到样本大小影响后，我想知道是否可以根据有多少key过期来自动调整样本大小。当有更多的key过期时，延迟会受到影响，但是当没有更多的工作要做时，我们会扫描更少的key并更快地执行。

这个想法基本上是可行的，我们可以看到内存使用更低，延迟没有受到影响，一个度量跟踪样本量显示它随着时间的推移在增加和减少。但是，我们没有采用这种解决方案。这种解决方案引入了一些在我们的控件实例中没有出现的延迟峰值。代码也有点复杂，难以解释，也不直观。我们还必须针对每个不理想的群集进行调整，因为我们希望避免增加操作复杂性。

//if (dbs_per_call > server.dbnum || timelimit_exit)
dbs_per_call = server.dbnum;

99.9%的以微秒为单位。 未修改的Redis在上面，修改的Redis在下面。

我们开始研究为什么注释掉这一行会产生如此巨大的差异。由于这是一个if语句，我们首先怀疑的是分支预测。我们利用

gcc’s__builtin_expect

接下来，我们查看生成的程序集，以了解究竟发生了什么。

我们将if语句编译成三个重要指令mov、cmp和jg。Mov将加载一些内存到寄存器中，cmp将比较两个寄存器并根据结果设置另一个寄存器，jg将根据另一个寄存器的值执行条件跳转。跳转到的代码将是if块或else块中的代码。我取出if语句并将编译后的程序集放入Redis中。然后我通过注释不同的行来测试每条指令的效果。我测试了mov指令，看看是否存在加载内存或cpu缓存方面的性能问题，但没有发现区别。我测试了cmp指令也没有发现区别。当我使用包含的jg指令运行测试时，延迟会回升到未修改的级别。在找到这个之后，我测试了它是否只是一个跳转，或者是一个特定的jg指令。我添加了非条件跳转指令jmp，跳转然后跳回到代码运行，期间没有出现性能损失。

我们花了一些时间查看不同的性能指标，并尝试了cpu手册中列出的一些自定义指标。关于为什么一条指令会导致这样的性能问题，我们没有任何结论。当执行跳转时，我们有一些与指令缓存缓冲区和cpu行为相关的想法，但是时间不够了，可能的话，我们会在将来再回到这一点。

既然我们已经很好地理解了问题的原因，那么我们需要选择一个解决这个问题的方法。我们的决定是进行简单的修改，以便能够在启动选项中配置稳定的样本量。这样，我们就能够在延迟和内存使用之间找到一个很好的平衡点。即使删除if语句引起了如此大幅度的改进，如果我们不能解释清楚其原因，我们也很难做出改变。

此图是部署到的第一个集群的内存使用情况。顶线(粉红色)隐藏在橙色后面，是集群内存使用的中值。橙色的顶行是一个控件实例。图表的中间部分是新变化的趋势。第三部分显示了一个正在重新启动的控件实例，与淡黄色进行比较。重新启动后，控件的内存使用量迅速增加。