在微服务架构和 SOA 架构百花齐放的今天，无论大数据工程师还是开发工程师，利用消息中间件实现可靠的消息传输，是应对复杂系统的一门必修课。
消息队列中间件的使用并不复杂，但消息队列的选型一直是个难点。比如：
-
不同业务场景下该如何选型消息队列？
-
流消息系统和队列消息系统的 producer 有何区别？
-
Kafka、RocketMQ、RabbitMQ 各自的优劣在哪？
在实际场景中，性能强大的 Kafka 支持排序保证，非常适合提取消息；而RocketMQ、RabbitMQ 拥有完善的队列特性，可以弥补 Kafka 的不足。
很多公司经常会在 Kafka 和 RabbitMQ 或 RocketMQ 之间做选择，这是因为在实时流式架构中，消息用例可被分为两类：队列和流。两者都不能舍弃，系统复杂度自然大大提高。
我的经验是，消息中间件的兼容之道，最关键一环就是消息队列选型。
除了老牌消息系统，新一代云原生消息系统 Apache Pulsar 支持流处理，同时它的共享订阅模式能将 topic 用作队列，向同一 topic 内的 consumer 提供多个虚拟队列并支持延迟发送消息。
冉冉升起的新星 Pulsar 支持三种订阅类型，很大程度上解决了现有开源消息系统的核心痛点：
-
排他性。只能有一个 Consumer，接收一个 Topic 所有的消息
-
共享性。可以同时存在多个 Consumer，每个 Consumer 处理 topic 中一部消息
-
Failover 特性。同一时刻只有一个有效的Consumer，其余的 Consumer 作为备用节点，在 Master Consumer 不可用后进行替代
