1 概述
1.1 编写目的
测试RocketMQ的写数据、读数据性能及稳定性
1.2 适用范围
对RocketMQ感兴趣的读者。
1.3 术语表
-
nameserver：
专为RocketMQ设计的轻量级名称服务。
-
producer：
消息生产者，负责生产消息，一般由业务系统负责生成消息。
-
consumer：
消息消费者，负责消费消息，一般是后台系统负责异步消息。
-
broker：
消息中转角色，负责存储消息，转发消息。
-
master：
broker中的主节点。
-
slave：
broker中的副节点。
-
异步复制：
消息写入master节点，再由master节点异步复制到slave节点，类似mysql中的master-slave机制。
-
同步双写：
消息同时写入master节点和slave节点。
-
异步刷盘：
Broker的一种持久化策略，消息写入pagecache后，直接返回。由异步线程负责将pagecache写入硬盘。
-
同步刷盘：
Broker的一种持久化策略，消息写入pagecache后，由同步线程将pagecache写入硬盘后，再返回。
-
TPS：
每秒钟发送的消息个数。
1.4 参考资料
官方网站上的：
1. RocketMQ用户指南
2. RocketMQ原理简介
3. RocketMQ最佳实践
2 性能测试目的
测试RocketMQ的写入、读取性能及稳定性。
3 测试环境
3.1 硬件环境（物理架构）
8台服务器（编号1~8）
- nameserver部署在1上
- 1~2用于部署producer
- 3~6用于部署broker
- 7~8用于部署consumer
每台服务器均为以下硬件配置
- CPU：E5-2420、8核*2、1.9G主频
- 内存：32G
- 硬盘：1T、RAID10
3.2 软件环境（逻辑架构）
每台服务器均为以下软件配置
- 操作系统：centos（内核 linux 2.6.32-358.el6.x86_64）
- JDK：1.6（Java HotSpot 64-Bit Server VM）
4 软件整体性能评价
4.1 预期指标
预期RocketMQ可以满足日常业务性能需求。
4.2 实际表现
经过测试，RocketMQ稳定性高，未出现无法写入或读取的情况，未出现内存占用过高的情况。2台master、2台slave组成的broker集群，消息大写为2kb时，写入速度可达每秒60多MB，日可处理数据量约为7.2亿条，性能可以满足需求。
5 测试过程与具体结论
1）测试场景一
1台生产者、1台broker、1台消费者，broker采用异步刷盘。消费者为1个线程，push消费模式。
测试线程数和消息大小对TPS和吞吐量的影响。
测试结果1： 
测试结果2： 
以上测试情况消费者均能及时消费（延迟很小）
结论1：
消息大小固定（2KB）时，随着生产者线程数的增加，TPS和吞吐量均会上升，
但当线程增加到数量后，TPS和吞吐量会有所下降。 
结论2：
生产者线程数（ 32个）固定时，随着消息大小的增加，TPS会先升后降，
吞吐量会逐渐提升。 
2）测试场景二
2台生产者，4台broker（2台master、2台slaver构成2个broker集群），2台消费者。每台生产者开启10个线程，消息均为2KB。每台消费者为1个线程，push消费模式。
测试broker主从模式和写盘模式对TPS和吞吐量的影响
1、异步复制、异步刷盘的测试结果： 
2、异步复制、同步刷盘的测试结果： 
3、同步双写、异步刷盘的测试结果： 
4、同步双写、同步刷盘的测试结果 
结论：
同步双写模式比异步复制模式性能稍低，但不明显。
同步刷盘模式比异步刷盘模式性能低很多。
3）测试场景三
2台生产者，4台broker（2台master、2台slave构成2个broker集群），2台消费者。每台生产者开启10个线程，消息大写均为2KB。每台消费者为1个线程，push消费模式。broker采用异步复制、异步刷盘模式。连续运行8小时。
测试稳定性。
测试结果：
所有消息均成功发送。具体结果可查看“rocketmq测试结果记录/2p-2m(异步复制-异步刷盘)-2s-2c-8小时稳定性测试”。
4）测试场景四
2台生产者，4台broker（2台master、2台slave构成2个broker集群），2台消费者。每台消费者为一个线程，push消费模式。broker采用异步复制、异步刷盘模式。
测试当前软硬件配置下broker极限写入速度。
以上测试情况消费者均能及时消费（延迟很小）。
结论：
当前软硬件配置下，broker集群可以达到60多MB的写入速度（如果继续增加消息大小。还可以提高写入速度）。