延迟情况是难以忍受的。现代计算机能以惊人的速度生成数据，并且高速互联网(经常是在重要的服务器之间有多个并行连接)提供了极大的带宽，但是这可恶的延迟意味着电脑花了大量时间等待数据。基于延续的编程变得越来越流行的几个原因之一。让我们考虑一些规则的程序代码：
string a = db.StringGet("a");
string b = db.StringGet("b");
按照这些关联的步骤，这看起来像：
[req1] # 客户端 : 客户端库构造出一个请求1
[c=>s] # 网络 : 请求1被发送到服务器
[server] # 服务器 : 服务器处理请求1
[s=>c] # 网络 : 响应1被发送回客户端
[resp1] # 客户端 : 客户端库解析响应数据1
[req2]
[c=>s]
[server]
[s=>c]
[resp2]
现在让我们突出客户端处理的部分：
[req1]
[====waiting=====]
[resp1]
[req2]
[====waiting=====]
[resp2]
记住这是不可测量的，如果是用时间来衡量，那么会一直等待下去(一直耗费时间在等待处理)。
管道
由于这个原因，很多Redis客户端允许你利用管道，处理发送多个消息而无需等待每一个的回复，并且当消息进来的时候，回复的处理将会延后。在.NET中，一个操作可以被初始化且尚未完成；在完成后或者发生错误后由TPL通过 Task/Task<T> 的API封装。本质上，Task<T> 表示的是一个"将来可能的T类型的值"(非泛型 Task 实际上是 Task<void>)。你可以二选其一：
- .Wait() (阻塞执行，直到任务完成)
- .ContinueWith(...)或者await (创建一个在目标任务完成时异步执行的延续任务)
例如：下面是Redis客户端利用管道的示例代码：
var aPending = db.StringGetAsync("a");
var bPending = db.StringGetAsync("b");
var a = db.Wait(aPending);
var b = db.Wait(bPending);
注意：在这里我使用了 db.Wait 因为他会自动的应用同步超时配置，如你你喜欢的话，你也可以使用 aPending.Wait() 或者Task.WaitAll(aPending, bPending)；使用管道允许我们在网络中立即得到两个请求，从而消除大部分的延时。此外，它也可以帮助我们减少包碎片：20个请求单独的发送(等待每个响应)至少需要20个包，但是在管道中发送20个请求只需要少数几个包(甚至只需要一个包)。
即发即弃
一个特别的管道案例是当我们不关心操作的响应，允许代码继续执行且排队操作是在后台处理的时候。这通常意味着我们能把并发工作放在来自一个单独调用的连接中。我们可以使用 flags 参数来实现：
// 可调期限 db.KeyExpire(key, TimeSpan.FromMinutes(5), flags: CommandFlags.FireAndForget); var value = (string)db.StringGet(key);
FireAndForget 标记会使客户端库去正常的排队工作，但是会立即返回一个默认值(KeyExpire 会返回一个 bool 类型，这将返回 false，因为默认值是 false - 然而返回的是毫无意义的值，我们应该忽略)。*Async 方法也会返回一个已完成的 Task<T>作为默认值(或者一个已完成的 Task 作为 void 返回 )。
多路复用(Multiplexing)
使用管道处理技术是非常好的，但是我们经常单独使用阻塞代码仅去取一个单独的值(或者可能只执行一些操作，这取决于各自的需要)。这意味着我们仍然有这样一个问题：我们花费大量的时间去等待数据从客户端传输到服务器端。现在我们考虑一个繁忙的应用，这可能是一个web服务。这类应用通常都具有高并发性，当你有20个并行应用请求所有需要的数据，你可能想旋转(spinning up)这20个连接，或者你可以同步访问一个单独连接(这意味着最后的调用者需要等待前面19个全部执行完成才开始)。或者作为一个妥协方式，也许是个出租5个连接的连接池--不管你怎么做，都会有大量的等待操作。StackExchange.Redis 不需要那样做；反而，它为你做了大量的工作，通过多路复用单个连接，使你可以有效的利用空余的时间。当不同的调用方同时访问时，它会自动使用管道分离访问请求，所以无论使用阻塞方式或者异步方式访问，这些工作都是被管道处理的。因此我们可以有10或者20个先前的"get a and b"的场景(来自不同应用的请求)，并且它们会尽快的取得连接。从本质上讲，它填补了 waiting 时间与其他调用方的工作。
因此，StackExchange.Redis不会提供(并将永远不会提供)"阻塞弹出(blocking pops)"(BLPOP, BRPOP 以及 BRPOPLPUSH) - 因为这将允许一个单独的调用方拖延整个多路复用器，进而阻塞所有的调用方。 StackExchange.Redis 需要保持的工作是为了验证某个事务的前提条件，这就是为什么StackExchange.Redis封装了这样的条件在内部管理 Condition 实例。更多事务信息。如果你想要"阻塞弹出(blocking pops)"，那么我强烈建议你考虑使用发布/订阅功功能：
sub.Subscribe(channel, delegate {
string work = db.ListRightPop(key);
if (work != null) Process(work);
});
//...
db.ListLeftPush(key, newWork, flags: CommandFlags.FireAndForget);
sub.Publish(channel, "");
注意：无需阻塞操作即可达到相同的目的有：
- 数据不是通过发布/订阅发送的；发布/订阅API仅被用来通知工人来检查更多的工作
- 如果没有工人，那么新项仍然在缓冲列表中，工作不会执行
- 仅有一个工人能弹出一个值；当消费者多于生产者，一些消费者将得到通知然后发现没有什么可做的
- 当你重新启动工人，你应该假设有积压工作可以处理
- 除此之外，对于阻塞弹出的语义是相同的
并发
应该注意的是管道/多路复用器/future-value 等方式与基于 延续的异步代码也是做得非常好的；例如：
string value = await db.StringGet(key);
if (value == null) {
value = await ComputeValueFromDatabase(...);
db.StringSet(key, value, flags: CommandFlags.FireAndForget);
}
return value;