基于发布与订阅的消息系统那么多，为什么 Kafka 会是一个更好的选择呢？
咱们先来简单的看看mq的一个对比图吧。
| 特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
|---|---|---|---|---|
| 生产者消费者模式 | 支持 | 支持 | 支持 | 支持 |
| 发布订阅模式 | 支持 | 支持 | 支持 | 支持 |
| 请求回应模式 | 支持 | 支持 | 不支持 | 不支持 |
| Api完备性 | 高 | 高 | 高 | 高 |
| 多语言支持 | 支持 | 支持 | java | 支持 |
| 单机吞吐量 | 万级 | 万级 | 万级 | 十万级 |
| 消息延迟 | 无 | 微秒级 | 毫秒级 | 毫秒级 |
| 可用性 | 高（主从） | 高（主从） | 非常高（分布式） | 非常高（分布式） |
| 消息丢失 | 低 | 低 | 理论上不会丢失 | 理论上不会丢失 |
| 文档的完备性 | 高 | 高 | 教高 | 高 |
| 提供快速入门 | 有 | 有 | 有 | 有 |
| 社区活跃度 | 高 | 高 | 中 | 高 |
| 商业支持 | 无 | 无 | 商业云 | 商业云 |
从中可以看的出来，kafka在数据处理方面的优势还是很大的，下面咱们再来详细看看kafka都有哪些特性。
Kafka 可以无缝地支持多个生产者，不管客户端在使用单个主题还是多个主题。所以它很适合用来从多个前端系统收集数据，并以统一的格式对外提供数据，例如常见的埋点上报。
另外针对生产者模式，kafka也可以接受各种各样的数据源，最终都汇集到一个统一的消费者服务进行处理，这个在目前大数据处理场景中是至关重要的。
除了支持多个生产者外，Kafka 也支持多个消费者从一个单独的消息流上读取数据，而且消费者之间互不影响。这与其他队列系统不同，其他队列系统的消息一旦被一个客户端读取，其他客户端就无法再读取它。另外，多个消费者可以组成一个群组，它们共享一个消息流，并保证整个群组对每个给定的消息只处理一次。
不过需要额外注意的是，一般在一个消费组里面，一个topic的一个partition只能由一个消费者进行处理，也就是说不会存在群组内多个消费者同时读取一个partition的情况。这是保证一个partition内消息有序性的前提！
Kafka 不仅支持多个消费者，还允许消费者非实时地读取消息，这要归功于 Kafka 的数据保留特性。消息被提交到磁盘，根据设置的保留规则进行保存。每个主题可以设置单独的保留规则，以便满足不同消费者的需求，各个主题可以保留不同数量的消息。消费者可能会因为处理速度慢或突发的流量高峰导致无法及时读取消息，而持久化数据可以保证数据不会丢失。消费者可以在进行应用程序维护时离线一小段时间，而无需担心消息丢失或堵塞在生产者端。消费者可以被关闭，但消息会继续保留在 Kafka 里。消费者可以从上次中断的地方继续处理消息。
一个topic内的消息是以partition为单位进行存储的，作为高可用架构的消息队列，一个partition也会存在多个副本进行数据备份容灾处理。磁盘存储也在一定程度上较低kafka的部署和运维成本。
还有个比较有意思的是：kafka之所以这么快完全归功于他的顺序写磁盘特性。
为了能够轻松处理大量数据，Kafka 从一开始就被设计成一个具有灵活伸缩性的系统，这在如今分布式系统中不可或缺的。用户在开发阶段可以先使用单个 broker，随着业务可以再扩展到包含 3 个 broker 的小型开发集群，然后随着数据量不断增长，部署到生产环境的集群可能包含上百个 broker。对在线集群进行扩展丝毫不影响整体系统的可用性。也就是说，一个包含多个 broker 的集群，即使个别 broker失效，仍然可以持续地为客户提供服务。
要提高集群的容错能力，那么就需要配置较高的复制系数。不过这也会影响消息写入的效率，所以在高可用和高性能之间还是要做出一定的抉择。
上面提到的所有特性，让 Kafka 成为了一个高性能的发布与订阅消息系统。通过横向扩展生产者、消费者和 broker，Kafka 可以轻松处理巨大的消息流。在处理大量数据的同时，它还能保证亚秒级的消息延迟。
咱们这篇内容主要是先来简单的认识一下kafka 的特性，以及常用mq的一些简单对比。下一篇咱们来看看kafka的一些应用场景以及如何选择一个合适的消息队列。