kafka介绍

Apache Kafka

Apache Kafka不是消息代理的实现。 而是一个分布式流媒体平台。

与基于队列和交换的RabbitMQ不同，Kafka的存储层是使用分区的事务日志实现的。 Kafka还提供用于实时处理流的Streams API和可轻松与各种数据源集成的Connector API。 但是，这些不在本文的讨论范围之内。
云供应商为Kafka的存储层提供了替代解决方案。 这些解决方案包括Azure事件中心，在某种程度上还包括AWS Kinesis数据流。 Kafka的流处理功能也有特定于云的开源替代方案，但是同样，这些不在本文的讨论范围之内。

话题 Topic

Kafka没有实现队列的概念。 相反，Kafka将记录的集合存储在称为主题的类别中。

对于每个主题，Kafka维护消息的分区日志。 每个分区都是一个有序的，不可变的记录序列，在该记录中连续附加消息。

当这些分区到达时，Kafka会将消息附加到这些分区。 默认情况下，它使用循环分区程序在各个分区之间均匀分布消息。

生产者可以修改此行为以创建消息的逻辑流。 例如，在多租户应用程序中，我们可能想根据每个消息的租户ID创建逻辑消息流。 在物联网场景中，我们可能希望不断将每个生产者的身份映射到特定分区。 确保来自同一逻辑流的所有消息都映射到同一分区，以确保将其传递给消费者。

使用者通过维持这些分区的偏移量（或索引）并顺序读取它们来消费消息。

单个使用者可以使用多个主题，并且使用者可以扩展到可用分区的数量。

因此，在创建主题时，应仔细考虑该主题上消息传递的预期吞吐量。 一起工作以消费主题的一组消费者称为消费群体。 Kafka的API通常会处理消费者组中消费者之间的分区处理与消费者当前分区偏移量的存储之间的平衡。

而rabbitmq通过exchange和routingkey，将消息和队列进行绑定，实现将消息路由发送到正定的队列，并由消费者（订阅key）的消费者处理消费、

使用Kafka实现消息传递模式

Kafka的实现非常适合pub / sub模式。

生产者可以将消息发送到特定主题，而多个消费者组可以使用同一条消息。 每个消费者组可以单独扩展以处理负载。 由于使用者维护其分区偏移量，因此他们可以选择具有持久性的订阅，该持久性订阅在重新启动或临时订阅期间保持其偏移量，这将丢弃偏移量，并在每次启动时从每个分区中的最新记录重新启动。

但是，它不适用于消息队列模式。 当然，我们可以只包含一个消费者组来模拟一个经典消息队列。 然而，这有多个缺点。本文的第2部分将详细讨论。

请务必注意，Kafka会将邮件保留在分区中，直到预定的时间，无论消费者是否消费了这些邮件。 这种保留意味着消费者可以自由地重读过去的消息。 此外，开发人员还可以使用Kafka的存储层来实现各种机制，例如事件源和审核日志。