在这个page listing the redis clients 中，我统计了8 个异步库。我的理解是，像 node.js 或 tornado 这样的框架只有在异步回调函数不为 I/O 相互竞争时才有意义，否则你还不如去同步。
但是 Redis 是单线程的。所以他们实际上是在为 I/O 而战。 Redis 的单线程特性不是取消了异步回调的所有潜在好处吗？为什么在 Redis 中使用异步客户端有意义？
【问题讨论】：
标签： node.js asynchronous redis tornado reactor
Redis 的单线程特性与异步客户端的潜在好处无关。尽管具有独特的事件循环，Redis 能够同时管理大量客户端连接。我在单个 Redis 实例上看到了多达 30000 个连接的基准测试。
考虑一下，对于 Redis 或 memcached 等内存键/值存储，性能和延迟主要由网络往返而不是服务器端 CPU 消耗决定。诚然，当网络链路饱和时，网络往返的延迟会增加，但这并不意味着当网络远未饱和时它变得可以忽略不计。例如，在负载非常轻的 1 GbE 网络上，RTT 延迟接近 200 us 的情况并不少见。
结果是，除非网络链接接近饱和，客户端连接（或异步回调函数）很少相互竞争 I/O。套接字与缓冲区相关联，这些缓冲区在网络上分摊读取和写入操作的成本。大多数时候，等待状态不是由于 I/O 竞争，而是由于网络的延迟。
有多种方法可以减少网络延迟的影响：
流水线：将多个命令组合在一起，以便每组命令支付一次网络往返费用（实际上，这是同步流水线）。
非阻塞 I/O：虽然它不会减少往返次数（或它们的单独成本），但异步客户端可以同时管理它们。结果是网络延迟对应用程序吞吐量的影响较小（或没有）。
多个客户端连接：每个客户端连接都有自己的套接字，因此也有自己的缓冲区。更多的缓冲区通常意味着更好的吞吐量。更多的连接增加了同时和/或异步处理事物的机会，对整体性能产生积极影响。
这些解决方案都受到 Redis 生态系统的支持，并且可以组合以最大限度地提高性能。异步客户端通常允许这种组合。异步客户端的用例是什么？以下是几个例子：
实现异步流水线，以最大限度地减少单个连接上的等待状态。
在不依赖额外线程池的情况下将 Redis 连接与现有事件循环（例如 libevent、Node.js、Tornado、Twisted 等）集成。
支持多个 Redis 实例的数据分片。在这种情况下，客户端应用程序可能希望并行访问各种实例。使用异步客户端，可以方便地从唯一线程完成。
支持基于客户端应用程序与各种主/从实例的预连接的 HA 弹性模型。
事件循环、异步库和/或类似协程的机制是目前大多数高效 NoSQL 引擎的基石之一。
【讨论】：