golang 压测redis 消息队列

用 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 的已经很厉害了，某些金融公司，几百万注册用户（活跃度不够），峰值写并发也只有几千而已。一般系统都应该是读操作多于写操作，当然具体情况应该具体分析^_^。