ActiveMQ采用消息推送方式，因此最适合的场景是默认消息均可在短期内被消费。数据量越大，查找和消费消息就越慢，消息积压程度与消息速度成反比。服务器
1.吞吐量低。因为ActiveMQ须要创建索引，致使吞吐量降低。这是没法克服的缺点，只要使用彻底符合JMS规范的消息中间件，就要接受这个级别的TPS。并发
2.无分片功能。这是一个功能缺失，JMS并无规定消息中间件的集群、分片机制。而因为ActiveMQ是为企业级开发设计的消息中间件，初衷并非为了处理海量消息和高并发请求。若是一台服务器不能承受更多消息，则须要横向拆分。ActiveMQ官方不提供分片机制，须要本身实现。高并发
对TPS要求比较低的系统，可使用ActiveMQ来实现，一方面比较简单，可以快速上手开发，另外一方面可控性也比较好，还有比较好的监控机制和界面测试
TPS：是TransactionsPerSecond的缩写，也就是事务数/秒。它是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求而后服务器作出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。大数据
消息量巨大的场景。ActiveMQ不支持消息自动分片机制，若是消息量巨大，致使一台服务器不能处理所有消息，就须要本身开发消息分片功能（消息量巨大，Kafka就是为大数据量而生的）spa