Redis BLPOP使用

Redis BLPOP使用

概述

1.场景分析

2.现状

3.问题

4.优化

第1节 场景分析

1.前端页面调用后端接口，完成类似支付宝扫码领红包的功能

2.前端页面需要后端接口同步返回领取红包的结果

3.后端接口经过微服务等多个子系统，最终获取红包发放结果

4.后端多个子系统之前通过Kafka异步通信

问题：同步的接口调用，接口实现却是异步的，如何将异步的实现转为同步的接口调用？？？

第2节 目前现状

系统目前实现方式如下图所示。

主线程在未获取到处理结果时，需要等待执行结果。目前采用的方式是通过主线程休眠150ms，重试最多10次，即主线程最多阻塞150ms的方式等待处理结果。

第3节 可能存在的问题

当后端系统在第151ms返回处理结果后，后端系统1需要在等待150-1=149ms才会得到处理结果。造成主线程多等待149ms，这149ms就是无效的等待。极易引起接口超时。

可能的优化方案：

1.减小线程休眠的时间——10ms/次

时间间隔依旧存在，多等待的时间差还是会造成无效的等待。

2.通过客户端阻塞的方式等待Redis

Redis BLPOP 命令移出并获取列表的第一个元素， 如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。

第4节 优化方案

通过BLPOP命令获取Redis元素，当有元素进入列表则立刻返回，否则阻塞有限的时间。避免多次轮询造成的无效等待时间。

验证优化方案：

1.启动Redis Server

2.启动客户端1，使用BLPOP监听Redis key，60s无元素则超时返回。

如上图所示，60s内test内无任何元素，则客户端1超时。

3.60s内向test添加元素，验证BLPOP非超时情况

启动客户端1，执行以下命令

BLPOP test 60

在60s内启动客户端2，执行以下命令

从执行结果可知，客户端1在客户端2输入元素后，立刻获取“I Love Marketing”元素值并退出阻塞。

结论：通过以上优化方案，避免线程频繁从阻塞态向可运行态调度，减少轮询时间差带来的无效等待时间，提升并发性。