用 redis 的 list 数据结构作为轻量级的消息队列, 对于小系统确实是小而美, 可控能力强.
当然与 kafka 和 rabbitmq 相比它还有很多缺陷, 在服务进行生产和消费的时候, 还需要加上部分逻辑进行处理.
自己写了点 golang 代码, 压力测试 redis 列表的性能.
机器配置: 双核, 4G
测试数据: 100w
压力测试源码 (https://github.com/wenfh2020/mytest/tree/master/go/redis/redis_list)
生产者 , 生产 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 的已经很厉害了, 某些金融公司, 几百万注册用户 (活跃度不够), 峰值写并发也只有几千而已. 一般系统都应该是读操作多于写操作, 当然具体情况应该具体分析 ^_^.
来源: http://www.tuicool.com/articles/7VFjqaY