作为对上一个问题的跟进，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吗？
答案 0 :(得分：6)
以下是我的答案：
想了解更多有关此魔法的信息。
Redis非常棒，但没有魔力。它只是一个非常务实的概念的智能和有效的实现。因为它是一个人性化的项目，通过查看源代码实际上很容易理解为什么。
这只是网络延迟还是Redis必须保持一些开销，直到刷新整个数据。
当然，Redis必须维护通信缓冲区，以便它可以处理较慢的网络链接。也就是说，这应该对感知的延迟产生很小的影响。在您的情况下，50毫秒可能主要是由于网络延迟，您可以通过运行ping命令或任何其他类似工具来检查。
连接数会影响Redis吞吐量吗？
当然，它可以像任何服务器软件一样。现在，您需要区分每个连接的吞吐量和服务器的全局吞吐量。
每个连接的吞吐量受连接数的严重影响。考虑服务器只能提供一定的带宽，并且这些带宽在连接之间共享。连接越多，每个连接的带宽就越少。
另一方面，服务器的全局吞吐量仅受连接数的轻微影响。 Redis可以接受成千上万的连接，没有任何问题。但仍然存在开销。根据经验，考虑到30000个连接，Redis仅支持100个连接可支持的吞吐量的一半。请参阅Redis benchmark page上提供的精美图表。
最后一个请求是否需要500muSec * 1000 = 500毫秒？
是的，但你的数字可能不对。
是的，所有活动都是序列化的（单线程设计），因此必须添加每个命令的处理时间。当同时接收到许多命令时，最后一个命令将在所有其他命令之后被提供。如果每个命令需要5个我们处理，并且同时收到1000个，则最后一个回复将在5毫秒内发送。
现在，实际上，真正并发查询的数量并不高。 Redis很少在同一事件循环迭代中同时收到1000个查询。
此外，您混淆响应时间（在客户端测量）和处理时间（将在Redis端测量）。 响应时间可以是500 us，但处理时间更接近5 us，不同之处在于在网络上和OS进程调度中花费的时间。请记住，只有处理时间必须累积，其他所有内容都通过连接并行化（例如网络延迟）。
要计算实例的平均处理时间，只需使用redis-benchmark来稀释实例。使用流水线时，看到处理速度高达400 Kop / s或更高的情况并不罕见，这使得平均处理时间为2.5 us。
响应大小可以在这里产生影响吗？
当然，它可以像任何服务器软件一样。超过一定的大小，延迟总是受数据量的影响，因为网络的带宽和速度都是有限的。对于以太网网络，此阈值与MTU的大小密切相关。
Redis上的TCP连接必须等到最后一个数据包交付，如果网络连接速度慢，它会减慢Redis吗？
绝对不是。 Redis系统地缓冲回复（无论其大小），并通过事件循环以非阻塞方式管理所有套接字。如果一个连接速度很慢（或者一个客户端很慢），Redis将尽可能多地填充相应的套接字缓冲区，在事件循环中注册套接字，然后移动到另一个连接。当套接字缓冲区中再次出现空间时，事件循环将继续在慢速连接上发送流量。什么都没有阻止。