1.公司级的消息平台

大公司倾向于采用多种消息技术，比如Kafka、ActiveMQ、RabbitMQ等。这些不同的集群可能由不同的团队负责，以容纳它们自身团队的业务。有些公司希望整合这些技术，构建一个公司级的消息平台，这个平台是中心化的，但是为各团队的使用保有了足够的个性化和弹性。

Pulsar提供以下能力：

（1）支持所有的消息场景：流、消息队列等等。

（2）多租户、粒度访问控制、跨区域复制、云原生支持等特性使Pulsar成为一个理想的多租户平台。

还有一些其他的有点：

（1）简化操作，一个组织只需要学习一种技术，以及维护一个系统，就可以服务多个团队。

（2）有利于团队和系统间的集成。团队间消息系统的微服务桥接是一个耗时的工程，在大部分场景中表现特别慢。让所有的团队都在一个消息平台上工作，微服务间的集成就变得更简单了。

（3）可以为相同团队的所有服务创建一个catalog，易于被发现。

2.任务队列

大部分公司都有使用任务队列系统的需求，需要提交一个任务后，确保任务被执行，包括异常处理。通常情况洗啊，我们需要为特定的任务限制资源容量，支持分布式任务在一组worker进程中。比如视频转码，生成图片缩略图，UI的点击按钮触发的请求在10毫秒内返回响应。

Pulsar原生支持共享订阅以及独立确认。共享订阅支持在多个消费者之间分发无序的分布式消息，然而对确认机制需要每个消费者把自己消费的数据标记为已消费。

这个特性通过Pulsar的水平扩展中已被简化。最值得注意的是：为了做到快速处理，Pulsar的设计避免了数据重组，使新增的节点可以即刻处理集群负载。

微服务架构中，服务间通信是必要的，有一种方法是直接调用API，这就需要满足以下条件：

（1）一个服务发现系统：服务注册时，将实例添加到可用实例列表中。

（2）负载均衡系统：在实例之间进行请求的负载均衡。

（3）网络策略定义：网络中服务访问策略控制。

（4）中心化的配置中心：可以共享所欲服务的配置。

（5）重试和断路器机制：请求处理过程中生成一些失败的响应。

另一点，Pulsar在topic和消息之间并不是直接api，每个客户端需从所有服务的实例以负载均衡的形式获取一个topic信息，每个请求发送器都可以接收topic的响应。如果服务A的一个实例发送一个消息到与服务B共享的Topic中，那么服务A的这个实例会收到响应信息。

其他消息系统也能完成这个操作，但只有Pulsar会提供以下令人叫绝的特性。

（1）在其他的消息系统中，如果系统增长到5k到50k个实例，让每个实例都获取topic的响应是不现实的，成本也是极其昂贵的。大多数都会对topic进行重新排序，并把多个服务相应复用几个topic，强制实例读取和过滤大部分的消息，这就变得昂贵了。

（2）Pulsar有极佳的水平扩展能力，为了响应大请求的到来，可以在分钟级扩容。

一些关键的应用程序需要有最高级别的容错保证。Pulsar提供了这种在一个系统中运行这些关键应用程序的能力。

（1）消息保存在多Bookkeeper节点中，以多副本的形式存在。像RabbitMQ或者是ActiveMQ这样的消息系统在原始设计中并不会有这个特性，当前写操作已经被返回成功时，大多数副本都是后台进行复制的。

（2）只有当应用得到一个响应时，消息才能确保写入到磁盘。如果机器断电，消息就丢失了。一些系统为了性能考虑，并不提供这种弹性能力，用户就没办法选择最合适的用例。Pulsar就提供了对应场景的选择性参数。

这种用例常用于银行、支付、订单系统中。这些应用希望消除这些持有副本的节点重启时内存数据丢失的风险。Pulsar就支持这种需求。