当业务需要系统间调用解耦时，MQ 是一个很好的方案，目前选择最多的当属Kafka和阿里的RocketMQ, 两种中间件都可以使用，都是备选方案，摆在面前，怎么选择？
一. 方法论-评估和选择备选方案的方法
按优先级选择，即架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素，将质量属性按照优先级排序，首先挑选满足第一优先级的，如果方案都满足，那就再看第二优先级……以此类推。
二.RocketMQ和Kafka到底有什么区别
1、适用场景
kafka适合做日志处理
rocketmq适合处理业务
2、性能
kafka单机写入TPS号称在百万条/秒
RocketMQ大约是10万/秒
3、可靠性
kafka使用异步刷盘，异步Replication
rocketmq支持异步/同步刷盘，异步/同步Replication
结论：rocketmq所支持的同步方式提升了数据的可靠性
4、实时性
均支持pull长轮询，rocketmq的实时性更好
5、支持的队列数
kafka单机超过64个队列/分区，消息发送性能降低严重
rocketmq单机支持最高5万个队列，性能稳定
结论：长远来看，rocketmq胜出，这也是适合业务处理的原因之一
6、消息顺序性
kafka某些配置下，支持消息顺序，但是一台broker宕机后，就会产生消息乱序
rocketmq支持严格的消息顺序，在顺序消息场景下，一台broker宕机后，消息发送会失败，但是不会乱序
7、消息失败重试机制
kafka消费失败不支持重试
rocketmq支持定时重试
8、定时/延时消息
kafka不支持定时消息
rocketmq都支持
9、分布式事务消息
kafka不支持
alimq支持分布式事务消息，rocketmq
10、消息查询机制
kafka不支持消息查询
rocketmq支持根据message ID查询，也支持消息内容查询，tag查询
11、消息回溯
kafka理论上可以按照offset回溯消息
rocketmq支持按照时间来回溯消息，精度毫秒
三. 为什么阿里会自研RocketMQ？
（1）Kafka的业务应用场景主要定位于日志传输；对于复杂业务支持不够
（2）阿里很多业务场景对数据可靠性、数据实时性、消息队列的个数等方面的要求很高。
kafka针对海量数据，但是对数据的正确度要求不是十分严格。而阿里巴巴中用于交易相关的事情较多，对数据的正确性要求极高，Kafka不合适
（3）当业务成长到一定规模，采用开源方案的技术成本会变高.
开源方案无法满足业务的需要；旧版本、自开发代码与新版本的兼容都可能是问题；运维角度，Kafka使用 scala 编写，而阿里是java系。Kafka 的后续维护是个问题。
（4）阿里在团队、成本、资源投入等方面约束性条件几乎没有.
综上，阿里选择自己开发RocketMQ更多是业务的驱动，当业务更多的需要以下功能的支持时，kafka 不能满足或者 ActiveMQ 等其他消息中间件不能满足，财大气粗能力又强业务还复杂，所以就自己开发了。
