RabbitMQ, Kafka和Pulsar (三)

接上两篇：

RabbitMQ, Kafka和Pulsar (一)

RabbitMQ, Kafka和Pulsar (二)

今天我们看看Pulsar

Pulsar算是非常新的一个挑战者，目标直指Kafka。官网的文档挺完善的，整个项目主要是用Java完成的，但因为比较新，所以网上很难找到有价值的讨论和问题的解决。

其实对比Pulsar和Kafka，就目前来看，很难看出优势在哪里，按照一般的理解，Pulsar最大优势是做到了将stream处理和queue处理融为一体，如图：

说是Kafka只是支持streaming的处理，其实下面所谓Queuing的处理在Kafka里也可以通过Consumer group和partition来实现，所以比较迷惑。

另外，Pulsar在Message retention和expiry有比Kafka更完善的支持，还有Acknowledge机制也更完善。

还有，消息的存储Pulsar也使用zookeeper或者bookkeeper来做，对比Kafka使用”offset“来实现消息回看的功能，pulsar有不通的做法：

Pulsar把最终使用消息的对象分为两种：

• Consumer：只能从topic的末尾读取消息，可以acknowledge消息。
• Listener： 能从topic的任何index开始读消息，但是不能acknowledge消息。

这种方法也挺好。

其实，我最感兴趣的是Pulsar引入的一个新概念：Subscription, 它的消息处理流程相较Kafka变成了：

Producer-topic-subscription-consumer (Kafka: Producer-topic-consumer group-consumer)

引入的这个Subscription非常有趣，支持三种模式：

• Exclusive：独占式
• Failover: 故障切换
• Shared： 共享式

分别对应上图。

其实一开始，我对Subscription抱有很大的期望，试想一下，如果Subscription能支持消息的过滤，那不就能实现路由了吗，这是Kafka真正欠缺的，因为资料匮乏，还去Pulsar的github上问了下，结果是不支持，说啥好呢：

https://github.com/apache/pulsar/issues/3302

既然无法实现消息路由，那对下列需求的实现就跟Kafka没啥两样了，不写了。

有两个主要的需求：

1. Notification, 希望client端（GUI）能直接使用Websocket接口和MQ通信，并且client端只能获取到跟在client端登录的用户相关的消息（不能是把所有消息都介入到client然后再做过滤）。
2. Log，要支持log的回看以及log的trace