1.为什么要使用 Kafka，起到什么作用
Kafka是一个高吞吐量、分布式、基于发布订阅的消息系统，它主要用于处理实时数据流
Kafka 设计上支持高吞吐量的消息传输，每秒可以处理数百万条消息。它能够在处理大量并发请求时，保持低延迟和高效率，非常适合大规模的数据流平台。因为 Kafka 具有极高的吞吐量，适用于需要即时响应的应用程序，如实时分析、监控、日志收集等。
Kafka 提供了生产者和消费者之间的解耦功能。生产者和消费者不直接通信，而是通过 Kafka 消息中间件进行数据交换，从而实现系统间的解耦。这种机制帮助简化了系统设计和开发，并提高了系统的可维护性。
Kafka 将数据持久化到磁盘中，即使在系统崩溃后，数据依然不会丢失。Kafka 还支持副本机制（Replication），通过将数据分布到多个节点来实现容错和高可用性。
缓冲和削峰：上游数据时有突发流量，下游可能扛不住，或者下游没有足够多的机器来保证冗余，kafka在中间可以起到一个缓冲的作用，把消息暂存在kafka中，下游服务就可以按照自己的节奏进行慢慢处理。
2.Kafka 数据一致性怎么保证
1.副本机制 (Replication)
Kafka 通过副本机制来保证数据的持久性和一致性。每个 Kafka 分区都有多个副本，这些副本分布在不同的节点（Broker）上。副本的存在确保了即使某些节点发生故障，数据也不会丢失，且系统能够保证较高的可用性和一致性。
副本机制如何保证一致性：
Leader 和 Follower：每个分区都有一个主副本（Leader）和多个备份副本（Follower）。所有对分区的读写操作都由 Leader 进行，Follower 则跟随 Leader，复制其数据。
同步复制 (In-sync Replicas, ISR)：Kafka 会维护一个“同步副本列表”（ISR），即在指定时间内，所有同步副本都会确保与 Leader 数据一致。只有在 ISR 列表中的副本才会被认为是“有效副本”。
数据一致性：写入操作必须同步到所有 ISR 中的副本后，才会被认为是成功的。这样即使某个副本发生故障，只要Leader 副本和 ISR 中的其他副本依然存在，数据不会丢失。
2.消息写入和确认机制
在 Kafka 中，生产者写入消息后，可以选择不同的确认级别（acks）来控制数据一致性：
acks=0：生产者不等待任何确认，意味着数据可能丢失。
acks=1：生产者等待 Leader 副本的确认。
acks=all（或 acks=-1）：生产者等待所有 ISR 中的副本确认，确保所有副本的数据都一致，保证最高的数据一致性。
但是acks=1或acks=all（或 acks=-1）这种情况，数据可能会有重复写入。
3.事务支持 (Exactly Once Semantics, EOS)
Kafka 提供了事务支持，可以保证“精确一次语义”。即使在生产者重试发送消息或消费时发生故障，Kafka 也能确保消息的准确性，不会出现重复消费或丢失消息。通过事务机制实现对多个topic的多个partition的原子性写入，即处于一个事务内的所有消息，要么全部写成功，要么全部写失败。
4.消费者偏移管理 (Consumer Offset Management)
消费者在消费 Kafka 消息时，会记录每个消息的消费偏移量。Kafka 提供了两种方式来管理消费偏移量：
自动提交：消费者在消费消息后，自动提交偏移量，这种方式可能在故障恢复时导致消息丢失或重复消费。
手动提交：消费者自己控制何时提交偏移量，这样可以确保在处理完消息后，再提交偏移量，减少数据丢失或重复消费的风险。
Kafka 会将消费者的偏移量存储在一个特殊的主题中。消费者可以在故障恢复时，通过检查偏移量来确保消息的准确消费。Kafka 通过消费者组管理多个消费者的偏移量，确保每个消息只被一个消费者处理，保证了消息的处理顺序和一致性。
5.消息顺序性
Kafka保证消息在分区内按照写入顺序存储，消费者按照消息的偏移量offset顺序消费，确保数据的一致性。
3.大数据为什么非要使用 Kafka，不使用别的消息队列
高吞吐量。Kafka将来自生产者的数据分为不同分区进行存储，批量处理并顺序写入磁盘，能够处理大规模的数据量。
低延迟。Kafka能够提供相对较低的延迟，实时处理数据。
可扩展性。Kafka具有很好的扩展性，可以增加更多的Broker节点数，也可以增加主题的分区数，使得Kafka能够处理更多的数据。
高并发。Kafka支持多生产者和多消费者同时读写，使得数据的处理效率更高。
4.Flink 消费 Kafka 时，Source 的并行度和 Kafka 分区的关系
Source并行度和Kafka分区的关系，通常Source并行度不能超过Kafka主题的分区数，且分区数最好是Source并行度的倍数
首先是从分区分配策略来考虑，分区分配策略中的范围轮询策略在分区数不是Source并行度倍数时，较前面的并行度实例往往会消费过多的数据，容易产生数据倾斜，所以分区数最好是Source并行度的倍数
再来是从时间窗口触发条件来考虑，通常对于事件时间窗口，我们会设定水位线来触发下游算子的窗口计算，当上游最小的水位线达到下游时间窗口界限时，窗口计算才会触发，如果分区数少于Source并行度，上游最小水位线永远无法触发窗口计算
5.Kafka 中如何保证消息的顺序性？
Kafka保证顺序消费的方法主要有两种：全局有序和局部有序。
全局有序
全局有序是指一个Topic下的所有消息都按照生产顺序进行消费。要实现全局有序，可以将一个Topic设置为只有一个Partition，这样所有消息都会发送到这个Partition中，从而保证消息的顺序性。此外，消费者（Consumer）也需要使用单线程或保证顺序的线程模型来消费消息。
局部有序
局部有序是指一个Topic下的消息，只需要满足同一业务字段的消息按照生产顺序进行消费。例如，订单系统中同一个订单ID的消息需要按照顺序消费。要实现局部有序，可以在发送消息时指定Partition Key，Kafka会对其进行Hash计算，根据计算结果决定放入哪个Partition。这样相同Partition Key的消息会放在同一个Partition中，从而保证顺序性。
6.Kafka 是如何实现高吞吐率的
首先最重要的一点就是，顺序写入与顺序读取。操作系统和磁盘在顺序写入时的性能远高于随机写入，因为磁盘头移动的距离最短，IO操作效率最大；而按照顺序来读取消费数据，也保证了高效的数据访问速度。
分布式架构与分区机制。每个区的数据存储是独立的，可以充分利用多台机器的并行处理能力，提高数据的写入和读取速度；而每个分区的副本分布在不同的broker上，保证了高可用和负载均衡，同时也能在多个节点上并行处理数据。
kafka将消息存储在磁盘上，而不是内存中。kafka利用零拷贝技术将磁盘中的数据直接从磁盘传输到网络中，减少了不必要的数据拷贝操作，提高了数据传输效率降低系统负载。
页缓存是一种重要的高速磁盘缓存，是计算机随机存取器RAM中的一块区域，主要是负责用户空间与磁盘文件之间的高效读写。页缓存减少了连续读写磁盘文件的次数，操作系统自动控制文件块的缓存与回收生命周期，用访问RAM的缓存代替访问磁盘区域的机制，增强查询效率。
kafka支持批量数据传输，这种批量操作能够显著减少网络传输的开销，提高数据写入和读取的效率。
Kafka 支持对消息进行压缩，压缩可以减少网络带宽的消耗，并提高吞吐量。
7.Kafka 到底会不会丢失数据？
Kafka 在设计上具有非常高的可靠性和容错能力，但在某些情况下，它确实可能丢失数据。
kafka怎么保证数据不丢失
数据持久化。Kafka将消息持久化到磁盘，即使Broker宕机，消息也不会丢失副本机制。Kafka支持多副本机制，每个分区可以有多个副本，分布在不同的Broker上，Leader负责处理读写请求，Follower同步数据进行备份。
确认机制和Leader选举。生产者可以配置ACK机制为-1，生产数据时，所有ISR副本确认后才被认为发送成功；当Leader副本失效时，Kafka会从ISR副本集合中进行Leader选举但即使提供了多种机制，数据仍然可能丢失比如生产者将ACK配置为0，生产数据后不需要任何确认就被认为发送成功；比如Broker配置不当或ISR不足，Leader宕机时，无法进行Leader选举；再比如，对于生产者生产的数据，Kafka会以日志形式持久化，但日志并不会一直持有，需要清理，如果日志清理策略设置不当，消息可能过早被删除。
8.项目中 Kafka 主题的分区数是如何确定的
选择合适的分区数量可以达到高度并行读写和负载均衡的目的，在分区上达到负载均衡是实现吞吐量的关键。需要根据每个分区的生产者和消费者的期望吞吐量进行估计。
首先要从吞吐量和数据量进行预估，如果业务需要高吞吐量的数据处理，通常需要更多分区来进行并行处理数据，大的数据量需要处理也同样需要更多的分区来均衡负载。
还要从消费者组的角度考虑。每个分区只能被同一消费者组中的一个消费者消费，以及根据分区分配策略考量，分区数最好是消费者组消费者数量的倍数。
还要从系统资源角度考虑，每个分区都会占用一定的Broker资源，确保Broker有足够的资源来支持所需的分区数，同时要预留一定的分区扩展空间，Kafka允许分区数的增加，考虑未来的业务增长和数据量增加可能需要进行分区扩展的操作。
9.Kafka 分区数可以增加或减少吗？为什么？
分区数是可以增加的，Kafka支持直接增加主题的分区数。Kafka本身就具有可扩展性，增加分区数的操作可以提高吞吐量，提高集群的并行处理能力，但分区数增加后，消费者的数量也应该调整，避免资源的浪费。
分区数不可以减少，Kafka不支持直接减少主题的分区数，因为分区数的减少，减少分区数的数据或许会发生数据丢失，数据重新分配也会花费额外的开销，可能导致消息顺序被打乱，且会影响集群的性能。
如果需要减少分区数，可以创建新的主题，将现有主题的数据迁移到具有较少分区数的新主题，来确保数据的完整性。
10.Kafka 数据积压的解决方案
Kafka 数据积压的产生通常是由于生产者的消息写入速度过快、消费者的消费能力不足、Kafka 集群的资源瓶颈、消费者处理逻辑的复杂性、配置不匹配等多种因素综合作用的结果。
提高消费者的并行度是解决数据积压的直接方式之一
如果消费者的处理能力不足，导致消费速度较慢，可能会造成数据积压。
提升消费者的处理能力是解决积压的另一种方法
Kafka 分区的数量直接影响消费者的并行性。如果 Kafka 中的分区数较少，无法充分利用消费者的并行处理能力。增加 Kafka 分区数可以提高 Kafka 的吞吐量，从而减少积压
如果消息在 Kafka 中滞留太久，可能会导致积压并消耗不必要的存储资源。设置合理的消息过期和清理策略可以帮助控制数据积压
11.项目中监控了 Kafka 的哪些 Metrics（指标）？
集群中的Broker的数量、主题数量、分区数量等基本信息
实时的消息的生产速率和消费速率
各个Broker的CPU、内存使用情况
某个主题具体的分区数、副本数、ISR状态、每个分区的滞后情况等
=========================================================================
Kafka使用的过程中可能会遇到各种各样的问题，比如系统资源使用率高、集群节点宕机等，进而影响我们生产业务正常开展。为了不让消息队列失控，增加监控是非常有必要的。
1）首先是基础指标，这是监控系统常见的监控指标：
CPU、内存、硬盘、网络 I/O 等资源使用情况，Kafka 提供了 BytesIn/BytesOut 指标来监控带宽使用率；
TCP 连接数、文件描述符使用情况；
JVM 监控指标，Kafka 也是一个 JVM 进程，需要监控堆内存使用情况、FULL GC 频率和时长、JVM 线程数等；
网络延迟。
2）然后就是Broker指标：
UnderReplicatedPartitions
ISRShrink/ISRExpand 表示 ISR 收缩和扩容的频率。
ActiveControllerCount 表示当前 Broker 节点是否是 Controller 节点，集群健康的情况下，有且仅有一个 Broker 节点这个指标值是 1。
offlinePartitionCount 表示处于不可用状态的 Partition 的数量，也就是 Partition 没有活跃的 Leader节点的数量。
LeaderElectionRateAndTimeMs 表示选举新 Leader 的频率（每秒多少次）和集群中无 Leader 节点的时长。
UncleanLeaderElectionsPerSec 这个指标有数据时，代表可能有消息丢失。
TotalTimeMs
3）Producer指标：
request-latency-avg 平均请求时间，这个指标包括生产者发送消息到收到响应的延迟，这个指标会影响 Producer 端的吞吐量。
waiting-threads 发送缓存区中阻塞的用户线程数，如果这个指标变高，意味着生产者被阻塞的线程数变高，需要排查原因。
4）Consumer指标：
records-lag 消费者在当前分区上落后于生产者的数量，如果这个值变大，有可能当前这个分区的消息量突增，也可能消费者消费能力下降，需要关注。
