异步系统的性能调优记录(redis做消息队列)

无意中发现了一个巨牛的人工智能教程，忍不住分享一下给大家。教程不仅是零基础，通俗易懂，而且非常风趣幽默，像看小说一样！觉得太牛了，所以分享给大家。点这里可以跳转到教程。

系统背景：

生产者往redis丢消息，消费者从redis取消息发送

 

redis使用list作为消息队列，队列数N个

 

每种接入系统分配2种（发送，重发），分别3个固定队列，优先级高中低，该3个队列由一个线程处理，通过分配的时间片大小去体现优先级

不同接入系统的线程之间没有优先级之分，交给CPU去调度

 

 

1、禁用keys XXXX

即使你再牛逼，这个都不能用，记住它的时间复杂度是O(N)，N是key的数量，你还敢用吗？？？？用了会肾疼

 

2、redis操作LPUSH    BRPOP   时间复杂度都是O(1)

BRPOP 是一个阻塞的列表弹出原语。 它是 RPOP 的阻塞版本，因为这个命令会在给定list无法弹出任何元素的时候阻塞连接。 该命令会按照给出的 key 顺序查看 list，并在找到的第一个非空 list 的尾部弹出一个元素。

当没有元素可以被弹出时返回一个 nil 的多批量值，并且 timeout 过期。

当有元素弹出时会返回一个双元素的多批量值，其中第一个元素是弹出元素的 key，第二个元素是 value。

 

起始用的RPOP命令，后台monitor  redis，rpop命令从早刷到晚，虽然说redis机器没出现什么瓶颈，但是总感觉这样频繁的去刷redis不太理智，所以改为BRPOP，阻塞读取，超时1秒，这样减少客户端对redis的请求

 

3、重发队列优化

起初重发是pop完没达到发送条件，push回去，一旦出现大量重发数据，这样的操作会对redis造成一定的影响，读写太频繁，从业务上因为重发时间间隔都是秒为单位的，所以这里每次取到数据后会休眠一秒，这里牺牲点逻辑也是合理的，因为系统不会依靠重发去提高TPS和可靠性的，做好监控，重发队列数据激增，必然是系统出现问题了；这样一来重发对redis的IO请求也减少了

 

4、黑白名单

通过定时任务，每隔一段时间，将数据库里的数据刷新到JVM内存里，通过HASHSET存储，毕竟黑白名单数据量不会很大，这样减少对redis和mysql的访问；

此方法可以迁移到别的场景