Redis Multi/Exec 的 IO 成本答案

【问题标题】：IO Costs of Redis Multi/ExecRedis Multi/Exec 的 IO 成本
【发布时间】：2013-08-10 05:45:40
【问题描述】：

我想向 Redis 发送一个 multi/exec 命令，如下所示：

redis 127.0.0.1:6379> MULTI
OK
redis 127.0.0.1:6379> LPUSH "JIMMY" "ABC"
QUEUED
redis 127.0.0.1:6379> LRANGE "JIMMY" 0 -1
QUEUED
redis 127.0.0.1:6379> EXEC

不过，我想了解一下网络 I/O 成本。似乎会有 4 次往返，虽然我认为 Redis 会保持连接打开？

在一个块中发送所有这些命令不是更快吗？甚至有可能做到这一点吗？

【问题讨论】：

标签： redis

【解决方案1】：

是的，这是可能的，这称为pipelining。除非您需要上一个命令的结果来执行此操作（即存在数据依赖性），否则您不必在发送下一个命令之前等待服务器回答。之后您将按顺序收到服务器回复。您的示例中的命令可以在单个 TCP 数据包中以最小的开销发送。

【讨论】：

【解决方案2】：

您也可以将 EVAL 与 LUA 脚本一起使用，命令在服务器上执行：

eval "redis.call('lpush',KEYS[1],'abc'); return redis.call('lrange',KEYS[1],'0','-1');" 1 JIMMY

【讨论】：

两个等效命令的性能差异是什么 - 比如更新列表，然后获取列表中的所有项目？
LPUSH 的性能因子为 O(1)； LRANGE 是 O(S+N)，redis.io/commands#list，你是这个意思吗？
并非如此。我的意思是将 LUA 脚本与包含相同命令的标准 redis multi/exec 进行比较
哦，我的错。 redis 指出，脚本通常比流水线（滚动到底部）redis.io/topics/pipelining 更高效并且提供更低的延迟，脚本的最大优势是当您需要前一个命令的结果作为另一个命令的输入时；使用脚本，它都是服务器端的，而流水线必须将结果返回给客户端。脚本可以为您提供更大的灵活性和更低的成本，我愿意这样做。