问为什么为Redis使用异步客户端是有意义的呢？

EN

Redis的单线程特性与异步客户端的潜在好处无关。尽管具有独特的事件循环，Redis能够同时管理大量的客户端连接。我在一个Redis实例上看到了多达30000个连接的基准测试。

只要考虑到内存中的密钥/值存储(如Redis或memcached )，性能和延迟都由网络往返而不是服务器端CPU消耗所主导。诚然，当网络链路饱和时，网络往返的延迟会增加，但这并不意味着当网络远远没有饱和时，它就变得微不足道。例如，在一个负载非常轻的1 GbE网络上，几乎可以看到200 us的RTT延迟。

其结果是，除了网络链路接近饱和时，客户端连接(或异步回调函数)很少相互竞争I/O。套接字与缓冲器相关联，后者摊销网络上读写操作的成本。大多数情况下，等待状态不是由于I/O竞争，而是由于网络的延迟。

有多种方法可以减少网络延迟的影响：

• 管道：将多个命令组合在一起，以便每个命令组支付一次网络往返费用(实际上，这是同步流水线)。
• 非阻塞I/O：虽然它不会减少往返次数(或它们各自的成本)，但异步客户端可以同时管理它们。其结果是网络延迟对应用程序吞吐量的影响较小(或不影响)。
• 多客户端连接：每个客户端连接都有自己的套接字，因此也有自己的缓冲区。更多的缓冲区通常意味着更好的吞吐量。更多的连接增加了并发和/或异步处理事物的机会，对整体性能产生了积极影响。

这些解决方案都是由Redis生态系统支持的，并且可以结合起来以最大限度地提高性能。异步客户端通常允许这种组合。异步客户端的用例是什么？以下是几个例子：

• 实现异步流水线，以最小化单个连接上的等待状态。
• 将Redis连接集成到现有的事件循环(如libevent、Node.js、旋风、Twisted等)而不依赖于额外的线程池。
• 支持多个Redis实例的数据切分。在这种情况下，客户端应用程序可能希望对各个实例的访问并行化。使用异步客户端，可以方便地从一个唯一的线程进行操作。
• 支持基于客户端应用程序到各种主/从实例的预连接的HA弹性模型。

事件循环、异步库和/或协同机制是大多数高效NoSQL引擎的基石之一。