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

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://xxlcube.blog.csdn.net/article/details/51504563
系统背景:
生产者往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的访问;
此方法可以迁移到别的场景



展开阅读全文

没有更多推荐了,返回首页