为什么它是有意义的使用异步客户Redis的？ [英] Why does it make sense to use asynchronous clients for Redis?

问题描述

在上市Redis的客户这页，我算8异步库。我的理解是，像如Node.js的龙卷风只能让当异步回调函数不互相争抢我感觉框架/ O，否则你还不如去同步。

In this page listing the redis clients, I counted 8 asynchronous libraries. My understanding is that frameworks like as node.js or tornado only make sense when the asynchronous callback functions are not fighting with each other for I/O, otherwise you might as well go synchronous.

但Redis是单线程的。因此，他们实际上是争取I / O。不Redis的的单线程性质取消异步回调的所有潜在的好处？为什么它是有意义的使用异步客户Redis的？

But Redis is single-threaded. So they are actually fighting for I/O. Doesn't the single-threaded nature of Redis cancel all the potential benefits of asynchronous callbacks? Why does it make sense to use asynchronous clients with Redis?

推荐答案

的Redis的单线程性质是无关的有关异步客户端的潜在好处。尽管其独特的事件循环，Redis是能够同时管理好多个客户端连接。我见过的基准与单一的Redis实例高达30000连接。

The single-threaded nature of Redis is irrelevant regarding the potential benefits of an asynchronous client. Despite its unique event loop, Redis is able to concurrently manage a good number of client connections. I have seen benchmarks with up to 30000 connections on a single Redis instance.

刚认为，在内存中的键/值存储像Redis的或memcached的，性能和延迟是由网络主导的往返，而不是服务器端的CPU占用率。理所当然，网络的等待时间的往返增加时该网络链路饱和，但它并不意味着当网络是远离饱和它变得可以忽略不计。举例来说，一个非常轻负载的1 GbE网络上，这种情况并不少见看到RTT延迟接近200我们。

Just consider that with in-memory key/value stores like Redis or memcached, the performance and latencies are dominated by the network roundtrips rather than server-side CPU consumption. Granted, the latency of network roundtrips increases when the network links are saturated, but it does not mean it becomes negligible when the network is far from saturation. For instance, on a very lightly loaded 1 GbE network, it is not uncommon to see the RTT latency close to 200 us.

其结果是，当网络链路是接近饱和，客户端连接（或异步回调函数）很少彼此的I / O的竞争除外。套接字关联到缓冲读写操作的网络上的成本缓冲器。大部分时间，等待状态不是由于I / O的竞争，但在网络的等待时间。

The consequence is, except when the network links are close to saturation, client connections (or asynchronous callback functions) are rarely competing with each other for I/Os. Sockets are associated to buffers which amortize the cost of read and write operations on the network. Most of the time, the wait states are not due to I/O competition, but to the latency of the network.

有不同的方法来减少网络延迟的影响：

There are various ways to decrease the impact of network latency:

• 管道：分组多个命令在一起，使网络往返是按命令组一次祈祷，（实际上，这是同步流水线）。

• pipelining: grouping multiple commands together so that network roundtrips are payed once per group of commands (actually, this is synchronous pipelining).

非阻塞I / O的：在不减少往返次数（或他们的个人费用），异步客户端可以同时管理它们。结果是网络延迟具有应用吞吐量上较少（或没有）的影响。

non blocking I/Os: while it does not reduce the number of roundtrips (or their individual cost), an asynchronous client can manage them concurrently. The consequence is the network latency has less (or no) impact on the application throughput.

多个客户端连接：每个客户端连接都有自己的插座，因此，其自己的缓冲区。更多的缓冲区往往意味着更好的吞吐量。更多的连接增加了机会，同时和/或异步处理的事情，对整体业绩产生积极影响。

multiple client connections: each client connection has its own socket, and therefore its own buffer. More buffers often means better throughput. More connections increases the opportunity to process things concurrently and/or asynchronously, with positive impacts on the overall performance.

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

These solutions are all supported by the Redis ecosystem, and can be combined to maximize the performance. Asynchronous clients typically allows this kind of combinations. What are the use cases of an asynchronous client? Here are a few examples:

• 实现异步流水线，单个连接上尽量减少等待状态。

• implementing asynchronous pipelining, to minimize the wait states on a single connection.

集成与现有的事件循环Redis的连接（S）（如libevent的，Node.js的，龙卷风，扭曲，等等），而不依赖于额外的线程池。

integrating Redis connection(s) with an existing event loop (such as libevent, Node.js, Tornado, Twisted, etc ...) without relying on an extra thread pool.

支持数据分片与多个Redis的实例。在这种情况下，客户端应用程序可能会想的访问并行的各种实例。与异步客户机，它可方便地从一个唯一的线程完成

supporting data sharding with multiple Redis instances. In that case, the client application will probably want to parallelize the accesses to the various instances. With an asynchronous client, it can be conveniently done from a unique thread.

支持基于客户端应用程序的各种主的pre-连接上的HA弹性模型/奴隶实例。

supporting the HA resiliency models based on the pre-connection of the client application to the various master/slaves instances.

事件循环，异步库，和/或协程状机制是大部分有效的NoSQL引擎那里的基石之一

Event loops, asynchronous libraries, and/or coroutine-like mechanisms are one of the corner stones of a majority of the efficient NoSQL engines out there.

这篇关于为什么它是有意义的使用异步客户Redis的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！