kafak入门指南：一文学习KAFKA-CSDN博客

本文链接：https://blog.csdn.net/ZHANGtaohander/article/details/136766199

Kafka是一个分布式、高吞吐量的消息队列系统，通过分区、复制和Zookeeper协调实现高可靠性和扩展性。它支持发布/订阅模式，用于解耦应用、异步处理和流量控制。Kafka的数据持久化、不丢失机制和弹性设计使其在各种IT场景中发挥关键作用。

摘要由CSDN通过智能技术生成

kafka

kafka是一个分布式，高吞吐量，高拓展性的消息队列。分布式，分区，多副本，多订阅这的日志系统（分布式MQ系统）。发送消息者为Producer，消息接收者为Consumer。Kafka集群由多个kafka实例组成，每个实例（Server）叫做broker。无论是kafka集群，还是producer和consumer都依赖于Zookeeper来保证系统可用性，zk中保存了一些元（mate）信息。
kafka的特点：
可靠性：分布式，分区，复制，容错
可扩展性：kafka消息传递系统轻松缩放，无需停机
耐用性：kafka使用分布式提交日志，这个以为这他会尽可能的快速将数据持久化到磁盘上，因此它是持久的。
性能：kafka对于发布订阅和消息订阅都具有高吞吐量。

应用解耦
- 应用和应用之间如果使用接口进行交互，这属于一种强耦合的调用关系，假如接口调用失败，则整个过程都失败。这里加入消息队列作为一个中转，调用者把调用接口的行为变为向消息队列发送消息，生产者发送成功后，他的使命就完成了。他不关心消息是否被及时消费。而消息的消费者在合适的时间取出消息进行消费即可。
异步处理
- 异步处理就是多应用对消息队列的同一消息进行处理，并发处理消息，比起串行处理，效率大大提高。
限流削峰
- 比如秒杀这种业务场景，用消息队列做一个容器，这个容器是能放十条消息（限制队列长度即可实现），后台只需要慢慢消费这十条消息即可，避免了大量请求直接涌向后台接口，把后台接口搞崩掉。
消息驱动的系统
- 系统分为消息队列，消息生产者，消息消费者，生产者负责生产消息，消费者（多个）负责对消息进行处理。就是一种系统设计理念。通过消息队列做到解耦合，也做到了缓冲，削峰的作用。

end to end
- role : producer kafka consumer
- feature
  - 消息发送者发送消息，消息消费者消费消息，当消息被消费之后，队列中就不在保存消息。所以消息消费者不可能消费到已经被消费的消息。
subscibe/publish
- role : topic subscriber publisher
- feature
  - 每个消息可以有多个订阅者。也就是一个消息可以被不同的订阅者消费。
  - 发布者和订阅者有时间上的依赖。针对某个Topic的订阅者，订阅者必须订阅之后才能消费该主题发布的消息。
  - 订阅者必须提前订阅该角色主题，并保持在线运行。

kafka数据不丢失原理(ack)
- 生产者端是靠ack校验机制保证数据不丢失的。
  - ack的三个值（0，1，-1）
  - 0：生产者只负责发送消息，不关心消息是否被kafka成功接收。
  - 1：生产者需要保证数据成功发送到指定topic的分片的主副本上，然后kafka会给出ack响应。
  - -1（all）：生产者需要确保消息成功发送到kafka指定topic的分片的所有副本中，并且都给出ack响应，才可以认为消息发送成功了。
broker端如何保证消息不丢失
- broker端主要是通过数据的副本机制和ack为-1来保证数据不丢失。
broker端主要是通过数据的副本机制和ack为-1来保证数据不丢失。
- 1：消费者去连接kafka集群，kafka根据消费者的groupId找到其上次消费的位置（偏移量），如果该消费者是第一次消费，默认从监听的时间开始监听消息。（这里可以配置不同消费机制，也可以从头消费）
- 2：消费者开始获取数据，之后进行业务处理，然后提交偏移量给kafka。

数据存储在副本中，副本被某个broker节点进行管理，最终的数据是存储在磁盘中，那么数据是存储在一个文件中还是分文件存储？
是分文件来存储的。每个文件存储1GB的数据。
在一个文件段中主要由两个文件构成。一个是index，一个是log。index是log的索引文件。
文件名是此文件存储消息的起始偏移量。
为什么kafka要进行分文件来存储数据呢？
- 1）保证每个文件不至于过大，这样读取效率会更高。
- 2）kafka仅仅是一个临时存储数据的中介，默认情况下kafka会删除过期数据（时间为7天）。如果放在一个文件中，删除时需要遍历文件内容，效率低，操作麻烦。分文件的话只需要用文件的最后修改时间判断即可。

To publish (write) and subscribe to (read) streams of events, including continuous import/export of your data from other systems.
To store streams of events durably and reliably for as long as you want.
To process streams of events as they occur or retrospectively.
And all this functionality is provided in a distributed, highly scalable, elastic, fault-tolerant, and secure manner. Kafka can be deployed on bare-metal hardware, virtual machines, and containers, and on-premises as well as in the cloud. You can choose between self-managing your Kafka environments and using fully managed services offered by a variety of vendors.

server : a Kafka cluster is highly scalable and fault-tolerant: if any of its servers fails, the other servers will take over their work to ensure continuous operations without any data loss
client : They allow you to write distributed applications and microservices that read, write, and process streams of events in parallel, at scale, and in a fault-tolerant manner even in the case of network problems or machine failures. Kafka ships with some such clients included, which are augmented by dozens of clients provided by the Kafka community: clients are available for Java and Scala including the higher-level Kafka Streams library, for Go, Python, C/C++, and many other programming languages as well as REST APIs.