当业务需要系统间调用解耦时，MQ是一个很好的解决方案。目前选择最多的当属Kafka和阿里的RocketMQ
| 性能指标 | kafka | RocketMQ |
|---|---|---|
| 适用场景 | 日志处理 | 适合处理业务 |
| 性能 | 单击写入TPS号称在百万条/秒 | 大约10万条/秒 |
| 可靠性 | 使用异步刷盘，异步复制(Replication) | 支持异步/同步刷盘，异步/同步复制(Replication)。RocketMQ 所支持的同步方式提升了数据的可靠性 |
| 实时性 | 支持pull长轮询 | 均支持pull长轮询，RocketMQ 的实时性更好 |
| 支持队列数 | 单机超过64个队列/分区，消息发送性能降低严重 | 单机支持最高5万个队列，性能稳定(这也是适合业务处理的原因之一) |
| 消息顺序性 | 某些配置下，支持消息顺序，但是一台broker宕机后，就会产生消息乱序 | 支持严格的消息顺序，在顺序消息场景下，一台broker宕机后，消息发送会失败，但是不会乱序 |
| 消息失败重试机制 | 消费失败不支持重试 | 支持定时重试 |
| 定时/延时消息 | 不支持定时消息 | 定时/延时都支持 |
| 分布式事务消息 | 不支持 | 支持 |
| 消息查询机制 | 不支持 | 支持根据 message ID 查询，也支持消息内容查询，tag查询 |
| 消息回溯 | 理论上可以按照offset回溯消息 | 支持按照时间来回溯消息，精度毫秒 |
总结：
- Kafka更适用于日志传输，对复杂业务支持不够；复杂业务还得使用RocketMQ
- Kafka主要是针对海量数据场景使用的，对数据的正确度要求不是十分严格。对于交易相关的，对数据可靠性、实时性、消息队列的个数要求很高的业务场景，RocketMQ更合适
- 当业务成长到一定规模时，必然要修改源码。kafka是使用scala编写的，而RocketMQ是使用Java编写的，用java编写的软件修改起来，维护成本更低
备注：TPS：Transaction Per Second，每秒事务处理量