Redis原理 — 管道

Redis原理 — 管道

不使用管道的情况下,每个读写请求都会单独发送一个网络数据包,管道的本质是将多个写请求合并作为一个网络数据包发送给服务端,服务端合并多个响应通过一个网络数据包返回,这样多个命令的执行就只构成一个网络来回交互。

管道不是 Redis 服务端的技术而是由客户端提供的,用来减少网络交互、提高存取效率。

消息交互

执行两条命令,在没使用管道的情况下,会经历「读 -> 写 -> 读 -> 写」四个操作,总共花费2个网络数据包来回。

使用管道,客户端操作顺序变成了「读 -> 读 -> 写 -> 写」,只花费了1个网络数据包来回。

对于服务端而言没有任何区别,都是接收请求、处理请求、返回响应。客户端只需要对管道中的指令改变读写顺序就能大幅度节省 IO 时间。

管道压力测试

Reids 提供了一个压力测试工具 redis-benchmark,添加 -P 参数可以测试使用管道时 Redis 的负载能力。

redis-benchmark

  • -q 简洁输出,只显示每秒执行数
  • -t 只运行逗号分割的测试列表
  • -P 管道请求数,默认为1(无管道)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 压测 set 指令
root@5c41e786262f:/data# redis-benchmark -q -t set
SET: 36218.76 requests per second
-------------------------------------------------------
# 管道并发请求数量为 2 个时
root@5c41e786262f:/data# redis-benchmark -q -t set -P 2
SET: 45392.64 requests per second
-------------------------------------------------------
# 管道并发请求数量为 3 个时
root@5c41e786262f:/data# redis-benchmark -q -t set -P 3
SET: 49019.61 requests per second
-------------------------------------------------------
# 管道并发请求数量为 4 个时
root@5c41e786262f:/data# redis-benchmark -q -t set -P 4
SET: 51546.39 requests per second

如果继续提高管道的并发请求数量,会发现 QPS 不会继续上升了,这是因为 CPU 处理已经到达瓶颈。Redis 单线程的 CPU 占用已经达到 100无法继提升。

Comments