消息队列是分布式系统中重要的中间件，在高性能、高可用、低耦合等系统架构中扮演着重要作用。分布式系统可以借助消息队列的能力，轻松实现以下功能：
针对业务交易数据，有延迟消息、队列模式消费、异地容灾，多消息主题等场景，可以选用TDMQ/Pulsar。
ZooKeeper是一个分布式开源的应用程序协调服务，可以实现统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等工作。Kafka里的ZooKeeper主要有一下几个作用：
broker服务器启动时会注册到NameServer上，消息中间件性能跟服务端、客户端参数、使用场景等方面上有很大关系，NameServer主要用来管理brokers以及路由信息。并且两者之间保持心跳监测机制，而且，每一台NameServer都存有全部的broker集群信息和生产者/消费者客户端的请求信息。以此来保证NameServer知道broker的存活状态。在系统上线前，还需要根据实际应用场景进行压测调优。
Pulsar的多层架构影响了存储数据的方式。Pulsar将Topic分区划分为分片（Segment），然后将这些分片存储在Apache BookKeeper的存储节点上，以提高性能、可伸缩性和可用性。Pulsar的分布式日志以分片为中心，借助扩展日志存储（通过Apache BookKeeper）实现，内置分层存储支持，因此分片可以均匀地分布在存储节点上。由于与任一给定Topic相关的数据都不会与特定存储节点进行捆绑，因此很容易替换存储节点或缩扩容。另外，集群中最小或最慢的节点也不会成为存储或带宽的短板。
日志处理、大数据处理等场景，高吞吐量、低延迟的特性考虑，Kafka依旧是一个较好的选型。
Broker负责管理消息存储分发，主从数据同步，为消息建立索引，提供消息查询等能力。
一个Kafka集群由多个Broker和一个ZooKeeper集群组成，Broker作为Kafka节点的服务器。同一个消息主题Topic可以由多个分区Partition组成，分区物理存储在Broker上。负载均衡考虑，同一个Topic的多个分区存储在多个不同的Broker上，为了提高可靠性，每个分区在不同的Broker会存在副本。
近几年出现了一些关注度较高的消息队列中间件选型，如Kafka、Pulsar、RocketMQ等，首先从宏观上做一些对比：
pull类型的消息队列更适合高吞吐量的场景，允许消费者自己进行流量控制，根据消费者实际的消
客户端消费者获取消息的方式，Kafka和RocketMQ是通过长轮询Pull的方式拉取消息，RabbitMQ、Pulsar、NSQ都是通过Push的方式。
RocketMQ是阿里开源的消息中间件，它是一个开源的分布式消息传递和流式数据平台。总共有四大部分：NameServer，Broker，Producer，Consumer。
其他一些业务自定义的使用场景，由于后台技术栈是Golang，可以考虑采用NSQ进行定制开发或研究学习。
消息队列是分布式系统中重要的中间件，在高性能、高可用、低耦合等系统架构中扮演着重要作用。本文对Kafka、Pulsar、RocketMQ、RabbitMQ、NSQ这几个消息队列组件进行了一些调研，并整理了相关资料，为业务对MQ中间件选型提供参考。