前言
咱们在工作中常常会用到异步音讯，次要应用两种音讯模式：
- 音讯队列
- 公布 / 订阅
音讯队列 ：多个生产者能够向同一个音讯队列发送音讯，然而一个音讯只能被一个消费者生产。
公布 / 订阅 ：一个音讯能够被多个订阅者并发的获取和解决。
Kafka 和 RabbitMQ 都能满足如上的个性，那么咱们应该如何抉择应用哪一个？这两个 MQ 有什么差异性？在什么样的场景下适宜应用 Kafka，什么场景下适宜应用 RabbitMQ？你是否有这样的纳闷？心愿这篇文章可能帮忙到你。
如何抉择？
开发语言
Kafka：Scala，反对自定义的协定。
RabbitMQ：Erlang，反对 AMQP、MQTT、STOMP 等协定。
提早队列
如果你有以下这样的需要场景：
- 生成订单 60 秒后，给用户发短信。
- 用户 7 天未登录给用户做召回推送。
- 下单 15 分钟后，未进行付款就敞开订单。
请抉择 RabbitMQ，官网已提供提早队列插件（x-delayed-message），开箱即用。
音讯程序性
如果你的需要场景是须要保障音讯是有序的，例如：传递的音讯是 MySQL binlog，这种音讯不容许是错乱的。
请抉择 Kafka，它可能保障发送到雷同主题分区的所有音讯都可能依照程序解决。
优先级队列
如果你的需要场景是须要保障音讯执行的优先级，例如：首先须要解决 VIP 客户的问题，而后再解决一般客户的问题。
请抉择 RabbitMQ，创立队列时可设置 x-max-priority。
音讯留存
如果你的需要场景是生产后的音讯不马上删除而是心愿可能多保留一段时间。
请抉择 Kafka，它可能给每个主题配置超时工夫，只有没有达到超时工夫的音讯都会保留下来，请释怀 Kafka 的性能不依赖于存储大小，实践上它存储音讯简直不会影响性能。
音讯过滤
如果你的需要场景是对接管的音讯采取肯定的过滤规定进行过滤。
请抉择 RabbitMQ，因为它反对音讯路由。不过对于 Kafka 而言，也能够通过其余形式实现。
可伸缩行
如果你的需要场景是对伸缩方面、吞吐量方面有极大的要求。
请抉择 Kafka。
小结
本文纯属抛砖引玉，有问题，欢送批评指正。
心愿在两者的应用抉择上可能给你带来一些思路。
举荐浏览
- 分布式事务之最终一致性实现计划
- 对于分布式事务的了解
- 答复两个被频繁问到的代码写法问题
- 我是怎么写 Git Commit message 的？