背景：被测服务在用户量增大的情况下，表现出很差的稳定性，因为近期在进行架构调整，消息中间件由rocketmq改为zookeeper。
在被测项目中zookeeper担任了消息存放的作用，但是消息过多时，zookeeper的节点直接被放满，崩溃，进不了zookeeper命令行，也无法重启进程。并且当消费者程序异常时，zookeeper不会再次通知，导致消息丢失。
而mq的削峰填谷、异步解耦的特性，使得消费者和生成者之前的耦合性降低，并且能够保证消费者异常时，消息不丢失。消费者与生产者独立存在，一方的异常不影响另外一方的运行。
延伸说明：
如何理解rocketmq中topic、queue？以及偏移量呢？
topic是一个逻辑集合，具有某种业务上共性的性质的消息会发到指定的topic中，需要取对应性质的消息也会到指定topic中取，如被测项目中的running top、finish top等。
要理解queue，首先要知道负载均衡这个概念，如果集群中有两个consumer，那我queue的应该是2的倍数，这样可以保持负载均衡。
要理解偏移量就需要知道mq顺序写随机读的一个概念，mq的消息实际上是从pagecache持久化到磁盘文件：commitlog中，顺序写入，因此consumer中读取的时候需要知道从哪里读，也就是通过偏移量来标识。
之前用错了mq的api，线上出过一次bug。因为consumer将本地偏移量上传至broker的时候，网络发生了闪断，偏移量上传失败，因此从0开始消费消息，也就是大量历史消息重复消费。换了api，偏移量先放在本地，定时同步后未发现该问题。从这里可以看出网络闪断是测试项目稳定性的一个重要手段。
