38

golang 压测redis 消息队列

 6 years ago
source link: https://studygolang.com/articles/13873?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

用 redis  的 list 数据结构作为轻量级的消息队列,对于小系统确实是小而美,可控能力强。

当然与kafka 和 rabbitmq 相比它还有很多缺陷,在服务进行生产和消费的时候,还需要加上部分逻辑进行处理。

自己写了点 golang 代码,压力测试 redis 列表的性能。

机器配置:双核,4G

测试数据:100w

压力测试源码( github

生产者 ,生产 100 w 条数据,平均,每秒能写 13817 条数据。

begin time: 2018-07-29 14:03:55.606

end    time: 2018-07-29 14:05:07.976

Produce message: 1000000

avg: 13817.860879118389

fyAzq2n.png!web
Ur6FbuV.png!web

代码片段

消费者 ,消费 100 w 条数据,平均每秒能读 9433  条数据左右。

begin time: 2018-07-29 14:46:11.166

end time: 2018-07-29 14:47:58.038

custom message: 1000000

avg: 9433

VFBZVza.png!web

负载

BvERNni.png!web

代码片段

总结:

以上生产和消费测试都是独立测试的,生产数据和消费数据,能达到 1w 左右的并发;如果生产者和消费者同时进行工作,各自并发能力还要下降 20% 左右。

讲真,一般的小企业业务系统,真正核心的业务数据(非流水,行为记录等日志型数据),写并发能达到 1 w 的已经很厉害了,某些金融公司,几百万注册用户(活跃度不够),峰值写并发也只有几千而已。一般系统都应该是读操作多于写操作,当然具体情况应该具体分析^_^。


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK