golang 压测redis 消息队列
wenfh2020 · · 7243 次点击 · · 开始浏览用 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
消费者,消费 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
总结:
以上生产和消费测试都是独立测试的,生产数据和消费数据,能达到 1w 左右的并发;如果生产者和消费者同时进行工作,各自并发能力还要下降 20% 左右。
讲真,一般的小企业业务系统,真正核心的业务数据(非流水,行为记录等日志型数据),写并发能达到 1 w 的已经很厉害了,某些金融公司,几百万注册用户(活跃度不够),峰值写并发也只有几千而已。一般系统都应该是读操作多于写操作,当然具体情况应该具体分析^_^。
有疑问加站长微信联系(非本文作者)
入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889
关注微信- 请尽量让自己的回复能够对别人有帮助
- 支持 Markdown 格式, **粗体**、~~删除线~~、
`单行代码` - 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
- 图片支持拖拽、截图粘贴等方式上传
收入到我管理的专栏 新建专栏
用 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
消费者,消费 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
总结:
以上生产和消费测试都是独立测试的,生产数据和消费数据,能达到 1w 左右的并发;如果生产者和消费者同时进行工作,各自并发能力还要下降 20% 左右。
讲真,一般的小企业业务系统,真正核心的业务数据(非流水,行为记录等日志型数据),写并发能达到 1 w 的已经很厉害了,某些金融公司,几百万注册用户(活跃度不够),峰值写并发也只有几千而已。一般系统都应该是读操作多于写操作,当然具体情况应该具体分析^_^。