Kafka简介
kafka最早是由LinkedIn开发的，最开始是为了做海量日志收集用的，所以它的设计目标是高吞吐量，高性能。 但它的功能就相对单一，因为它最初只需做好这一件事就好了，目前kafka的应用场景也是在大数据采集，分布式日 志收集等，它已成为大数据领域的一个核心组件，因此它的生态也是非常完整的。
消息模型
Kafka采用发布-订阅模型（Pub/Sub），生产者将消息发布到主题（Topic），消费者订阅主题并消费消息。Kafka中的消息是以键值对的形式存储的，每条消息都有一个唯一的偏移量（Offset）用于标识其在分区中的位置。
集群架构
- Producer（生产者）：负责发布消息到Kafka的topic中
- Consumer（消费者）：从Kafka的topic中读取数据
- Broker（代理）：Kafka集群中的服务器节点
- Topic（主题）：消息的分类标识，生产者将消息发布到特定topic
- Partition（分区）：每个topic可以分为多个partition，实现水平扩展
- Consumer Group（消费者组）：多个消费者组成一个组来消费同一个topic的数据，每一个消息会被多个感兴趣的消费者组消费，但是在每一个消费者组内部，一个消息只会被消费一次。
单机服务下，Kafka已经具备了非常高的性能。TPS能够达到百万级别。但是，在实际工作中使用时，单机搭建的Kafka会有很大的局限性。
一方面：消息太多，需要分开保存。Kafka是面向海量消息设计的，一个Topic下的消息会非常多，单机服务很难存得下来。这些消息就需要分成不同的Partition，分布到多个不同的Broker上。这样每个Broker就只需要保存一部分数据。这些分区的个数就称为分区数。
另一方面：服务不稳定，数据容易丢失。单机服务下，如果服务崩溃，数据就丢失了。为了保证数据安全，就需要给每个Partition配置一个或多个备份，保证数据不丢失。Kafka的集群模式下，每个Partition都有一个或多个备份。Kafka会通过一个统一的Zookeeper集群作为选举中心，给每个Partition选举出一个主节点Leader，其他节点就是从节点Follower。主节点负责响应客户端的具体业务请求，并保存消息。而从节点则负责同步主节点的数据。当主节点发生故障时，Kafka会选举出一个从节点成为新的主节点。
最后：Kafka集群中的这些Broker信息，包括Partition的选举信息，都会保存在额外部署的Zookeeper集群当中，这样，kafka集群就不会因为某一些Broker服务崩溃而中断。
可靠性保证
Kafka通过以下机制来保证消息的可靠性：
- 副本机制：每个分区可以配置多个副本，确保在节点故障时数据不丢失。
- 确认机制：生产者可以配置消息发送的确认级别，包含acks=0/1/all：acks=0：无需确认，性能最高但可能丢消息；acks=1：Leader确认即可，性能和可靠性平衡；acks=all：所有ISR副本都确认，可靠性最高；
- 消费者偏移量管理：消费者可以手动或自动提交偏移量，确保消息不会被重复消费或丢失。
死信队列
Kafka本身没有内置的死信队列机制，但可以通过以下方式实现类似功能：
- 配置消息的TTL（Time-to-Live）：设置消息的过期时间，超过该时间后，消息会被自动删除。
- 使用单独的主题（Topic）作为死信队列：消费者在处理消息失败时，可以将消息发送到一个专门的死信主题中，供后续处理。
Broker与Partition
Kafka集群由多个Broker组成，每个Broker是一个独立的Kafka服务器节点。
每个Topic可以分为多个Partition，Partition是Topic的子集，用于实现水平扩展和并行处理。
每个Partition只能由一个Broker作为Leader负责处理读写请求，其他Broker作为Follower进行数据同步。
Partition的数量与Broker的数量无直接关系，可以根据需求进行配置，但建议每个Partition的数量不要超过Broker的数量。
一个Partition在同一时间只能被同一Consumer Group中的一个Consumer消费。
