性能优化 | Wireshark抓包告诉你为什么Redis Pipeline可以明显提升性能

就本人目前所接触过的系统而言, 大部分系统性能瓶颈还是在IO。

举个例子, 原本在内网表现压测表现正常的系统了，上了预发布环境后进行压力测试系统整体性能表现特别拉胯, 经过排查后发现 耗时主要集中MySQL与Redis查询/更新这一块, 排查数据库日志发现并没有特别离谱慢查询, 可以确定耗时基本上在IO这一块。

排查出问题之后, 立马开始对系统采取了以下优化措施:

• 需要使用到数据库数据的地方尽可能一次性查询出来
• 使用CASE WHEN机制一次性更新多条数据

优化之后性能有所提升, 但表现还是不佳, 最后定位到部分接口(排行榜类的)有以下行为:

• 由于缓存数据分散在多个zset中, 查询出多少条用户数据就会调用多少次zscore以及zrevrank来获取用户的积分或排名

以上行为造成了接口的主要耗时全部集中在了IO上, 虽然平均执行一条指令耗时大概在1ms(从发出请求到接收到返回数据), 但架不住积少成多。

由此, 我们引入了Redis的pipeline机制对系统中的缓存读取的部分进行了优化。

Redis Pipeline

我们知道典型的Redis是典型的C/S架构, 并且是请求/响应模型, 即:

• 在同一个TCP连接上, 客户端按顺序发出请求A, B, C, 服务端按照顺序返回A, B, C的响应, 大多数客户端的实现方式是发出请求A后会等待到响应返回才发出下一个请求。

与之形成对比的是HTTP2, 该协议支持在同一个TCP连接上发出多个请求, 并且响应是可以无序到达的

需要注意的是, Redis Pipeline 并不是像set,get之类的命令, 而是客户端将命令打包在一起，然后发送给Redis服