Redis - QPS、响应时间、连接数、响应大小和网络连接速度之间的相关性

Question

作为我上一个问题的后续，How does Redis achieve the high throughput and performance?

我有以下问题

我亲眼目睹了 Redis 的运行，并对它的能力印象深刻和敬畏。想更多地了解这种魔法。我已经看到，当 Redis 框和查询框更接近时，即使在高 QPS (1kps) 下，响应时间也是 5ms。当它们在地理上更远时(相同的数据中心与不同的数据中心)，响应时间可达 50 毫秒。这只是网络延迟还是 Redis 必须保持一些开销，直到整个数据被刷新。

连接数会影响Redis吞吐量吗？想象一下，Redis 能够在 500 微秒内对每个请求做出响应。想象一下，在一个给定的实例中有 1000 个不同的请求，来自 1000 个不同的客户端连接。最后一个请求是否需要 500muSec * 1000 = 500ms？

响应大小可以在这里产生影响吗？想象一下每个响应的大小为 100 KB 的数量级，Redis 上的 TCP 连接必须等到最后一个数据包交付，如果网络连接很慢，它会减慢 Redis 的速度吗？

Answer 1

以下是我的回答:

想更多地了解这种魔法。

Redis 很棒，但没有魔法。它只是对非常务实的概念的巧妙而有效的实现。而且因为它是一个人性化的项目，通过查看源代码，实际上很容易理解为什么。

这只是网络延迟还是 Redis 必须保持一些开销，直到整个数据被刷新。

当然，Redis 必须维护通信缓冲区，以便处理较慢的网络链接。也就是说，这对感知延迟的影响应该很小。在您的情况下，50 毫秒可能主要是由于网络延迟，您可以通过运行 ping 命令或任何其他类似工具来检查。

连接数会影响Redis吞吐量吗？

当然，它可以，就像任何服务器软件一样。现在，您需要区分每个连接的吞吐量和服务器的全局吞吐量。

每个连接的吞吐量受到连接数量的严重影响。考虑到服务器只能提供一定的带宽，而这个带宽是跨连接共享的。连接越多，每个连接的带宽越少。

另一方面，服务器的全局吞吐量仅受连接数的轻微影响。 Redis 可以毫无问题地接受数以万计的连接。但是仍然有开销。根据经验，请考虑在 30000 个连接时，Redis 仅支持其在 100 个连接时所能支持的吞吐量的一半。查看 Redis benchmark page 上提供的精美图表.

最后一个请求是否需要 500muSec * 1000 = 500ms？

是的，但你的数字可能是错误的。

是的，所有事件都是序列化的(单线程设计)，因此必须添加每个命令的处理时间。当同时收到多个命令时，最后一个将在所有其他命令之后执行。如果每个命令需要 5 us 来处理，同时收到 1000 个，那么最后一个回复将在 5 ms 内发送。

现在，在实践中，真正并发查询的数量并没有那么高。 Redis 在同一个事件循环迭代中很少会同时收到 1000 个查询。

此外，您混淆了响应时间(在客户端测量)和处理时间(在 Redis 端测量)。响应时间可以是500us，但处理时间更接近5us，区别在于网络和OS进程调度所花费的时间。请记住，只需累积处理时间，其他所有内容都通过连接并行化(例如网络延迟)。

要计算实例的平均处理时间，只需使用 redis-benchmark 使实例饱和。使用流水线时，经常会看到实例处理速度高达 400 Kop/s 或更高，平均处理时间为 2.5 us。

响应大小可以在这里产生影响吗？

当然，它可以，就像任何服务器软件一样。超过一定规模后，延迟总是受数据量的影响，因为带宽和网络速度都是有限的。对于以太网网络，此阈值与 MTU 的大小密切相关。

Redis 上的 TCP 连接必须等到最后一个数据包被传递，如果网络连接很慢，它会减慢 Redis 的速度吗？

绝对不。由于事件循环，Redis 系统地缓冲回复(无论它们的大小)，并以非阻塞方式管理所有套接字。如果一个连接很慢(或一个客户端很慢)，Redis 会尽可能多地填充相应的套接字缓冲区，在事件循环中注册套接字，然后移动到另一个连接。当套接字缓冲区中再次有空间时，事件循环将继续在慢速连接上发送流量。没有什么会阻塞。