为什么要用 Kafka 集群？kafka 如何不消费重复数据？

不用 zk，怎么管理集群元数据信息？

Offeset 极限是多少？过了极限又是多少？

Kafka的offset是Long型，如果累积到了最大值（Long.MAX_VALUE），那么再加1的话就会立即变成Long.MIN_VALUE

如何实现 exactly once？

一、Kafka 三种语义

在分布式系统中，构成系统的任何节点都是被定义为可以彼此独立失败的。比如在 Kafka 中，broker 可能会 crash，在 producer 推送数据至 topic 的过程中也可能会遇到网络问题。根据 producer 处理此类故障所采取的提交策略类型，有如下三种：

  1. at-least-once：如果 producer 收到来自 Kafka broker 的确认（ack）或者 acks = all，则表示该消息已经写入到 Kafka。但如果 producer ack 超时或收到错误，则可能会重试发送消息，客户端会认为该消息未写入 Kafka。如果 broker 在发送 Ack 之前失败，但在消息成功写入 Kafka 之后，此重试将导致该消息被写入两次，因此消息会被不止一次地传递给最终 consumer，这种策略可能导致重复的工作和不正确的结果。
  2. at-most-once：如果在 ack 超时或返回错误时 producer 不重试，则该消息可能最终不会写入 Kafka，因此不会传递给 consumer。在大多数情况下，这样做是为了避免重复的可能性，业务上必须接收数据传递可能的丢失。
  3. exactly-once：即使 producer 重试发送消息，消息也会保证最多一次地传递给最终consumer。该语义是最理想的，但也难以实现，因为它需要消息系统本身与生产和消费消息的应用程序进行协作。

二、Kafka 故障

理想状况，网络良好，代码没有错误，则 Kafka 可以保证 exactly-once，但生产环境错综复杂，故障几乎无法避免，主要有：

  1. Broker失败：Kafka 作为一个高可用、持久化系统，保证每条消息被持久化并且冗余多份（假设是 n 份），所以 Kafka 可以容忍 n-1 个 broker 故障，意味着一个分区只要至少有一个 broker 可用，分区就可用。Kafka 的副本协议保证了只要消息被成功写入了主副本，它就会被复制到其他所有的可用副本（ISR）。
  2. Producer 到 Broker 的 RPC 失败：Kafka 的持久性依赖于生产者接收broker 的 ack 。没有接收成功 ack 不代表生产请求本身失败了。broker 可能在写入消息后，发送 ack 给生产者的时候挂了，甚至 broker 也可能在写入消息前就挂了。由于生产者没有办法知道错误是什么造成的，所以它就只能认为消息没写入成功，并且会重试发送。在一些情况下，这会造成同样的消息在 Kafka 分区日志中重复，进而造成消费端多次收到这条消息。
  3. 客户端也可能会失败：Exactly-once delivery 也必须考虑客户端失败的情况。但是如何去区分客户端是真的挂了（永久性宕机）还是说只是暂时丢失心跳？追求正确性的话，broker 应该丢弃由 zombie producer 发送的消息。 consumer 也是如此，一旦新的客户端实例已经启动，它必须能够从失败实例的任何状态中恢复，并从安全点( safe checkpoint )开始处理，这意味着消费的偏移量必须始终与生成的输出保持同步。

三、保证 Exactly-once

3.1、依赖业务控制

对生产者：

  • 每个分区只有一个生产者写入消息，当出现异常或超时，生产者查询此分区最后一个消息，用于决定后续操作时重传还是继续发送。
  • 为每个消息增加唯一主键，生产者不做处理，由消费者根据主键去重。

对消费者：

  • 关闭自动提交 offset 的功能，不使用 Offsets Topic 这个内部 Topic 记录其 offset，而是由消费者自动保存 offset。将 offset 和消息处理放在一个事务里面，事务执行成功认为消息被消费，否则事务回滚需要重新处理。当出现消费者重启或者 Rebalance 操作，可以从数据库找到对应的 offset，然后调用 KafkaConsumer.seek() 设置消费者位置，从此 offset 开始消费。

kafka中的broker 是干什么的？

broker 是消息的代理，
Producers往Brokers里面的指定Topic中写消息，Consumers从Brokers里面拉取指定Topic的消息，然后进行业务处理，broker在中间起到一个代理保存消息的中转站。

kafka中的 zookeeper 起到什么作用？

zookeeper 是一个分布式的协调组件，早期版本的kafka用zk做meta信息存储，consumer的消费状态，group的管理以及 offset的值。
考虑到zk本身的一些因素以及整个架构较大概率存在单点问题，新版本中逐渐弱化了zookeeper的作用。新的consumer使用了kafka内部的group coordination协议，也减少了对zookeeper的依赖。

kafka follower如何与leader同步数据?

Kafka的复制机制既不是完全的同步复制，也不是单纯的异步复制。
完全同步复制要求All Alive Follower都复制完，这条消息才会被认为commit，这种复制方式极大的影响了吞吐率。
异步复制方式下，Follower异步的从Leader复制数据，数据只要被Leader写入log就被认为已经commit，这种情况下，如果leader挂掉，会丢失数据；
kafka使用ISR的方式很好的均衡了确保数据不丢失以及吞吐率。Follower可以批量的从Leader复制数据，而且Leader充分利用磁盘顺序读以及send file(zero copy)机制，这样极大的提高复制性能，内部批量写磁盘，大幅减少了Follower与Leader的消息量差。

kafka 为什么那么快？

  • Cache Filesystem Cache PageCache缓存
  • 顺序写：由于现代的操作系统提供了预读和写技术，磁盘的顺序写大多数情况下比随机写内存还要快。
  • Zero-copy：零拷技术减少拷贝次数
  • Batching of Messages：批量量处理。合并小的请求，然后以流的方式进行交互，直顶网络上限。
  • Pull 拉模式：使用拉模式进行消息的获取消费，与消费端处理能力相符。

kafka producer如何优化打入速度？

  • 增加线程
  • 提高 batch.size
  • 增加更多 producer 实例
  • 增加 partition 数
  • 设置 acks=-1 时，如果延迟增大：可以增大 num.replica.fetchers（follower 同步数据的线程数）来调解；
  • 跨数据中心的传输：增加 socket 缓冲区设置以及 OS tcp 缓冲区设置。

kafka producer发送数据，ack为0，1，-1分别是什么意思？

  • 1（默认） 数据发送到Kafka后，经过leader成功接收消息的的确认，就算是发送成功了。在这种情况下，如果leader宕机了，则会丢失数据。
  • 0 生产者将数据发送出去就不管了，不去等待任何返回。这种情况下数据传输效率最高，但是数据可靠性确是最低的。
  • -1producer需要等待ISR中的所有follower都确认接收到数据后才算一次发送完成，可靠性最高。当ISR中所有Replica都向Leader发送ACK时，leader才commit，这时候producer才能认为一个请求中的消息都commit了。

kafka的message格式是什么样的？

一个Kafka的Message由一个固定长度的header和一个变长的消息体body组成

  • header部分由一个字节的magic(文件格式)和四个字节的CRC32(用于判断body消息体是否正常)构成。
    当magic的值为1的时候，会在magic和crc32之间多一个字节的数据：attributes(保存一些相关属性，
    比如是否压缩、压缩格式等等);如果magic的值为0，那么不存在attributes属性
  • body是由N个字节构成的一个消息体，包含了具体的key/value消息

kafka中consumer group 是什么概念？

同样是逻辑上的概念，是Kafka实现单播和广播两种消息模型的手段。
同一个topic的数据，会广播给不同的group；
同一个group中的worker，只有一个worker能拿到这个数据。
换句话说，对于同一个topic，每个group都可以拿到同样的所有数据，但是数据进入group后只能被其中的一个worker消费。group内的worker可以使用多线程或多进程来实现，也可以将进程分散在多台机器上，worker的数量通常不超过partition的数量，且二者最好保持整数倍关系，因为Kafka在设计时假定了一个partition只能被一个worker消费（同一group内）。

Kafka中的消息是否会丢失和重复消费？

消息发送
Kafka消息发送有两种方式：同步（sync）和异步（async），
默认是同步方式，可通过producer.type属性进行配置。
Kafka通过配置request.required.acks属性来确认消息的生产

  • 0—表示不进行消息接收是否成功的确认；
  • 1—表示当Leader接收成功时确认；
  • -1—表示Leader和Follower都接收成功时确认；

综上所述，有6种消息生产的情况，消息丢失的场景：

  • acks=0，不和Kafka集群进行消息接收确认，则当网络异常、缓冲区满了等情况时，消息可能丢失；
  • acks=1、同步模式下，只有Leader确认接收成功后但挂掉了，副本没有同步，数据可能丢失；

消息消费
Kafka消息消费有两个consumer接口，Low-level API和High-level API：

  • Low-level API：消费者自己维护offset等值，可以实现对Kafka的完全控制；
  • High-level API：封装了对parition和offset的管理，使用简单；

如果使用高级接口High-level API，可能存在一个问题就是当消息消费者从集群中把消息取出来、并提交了新的消息offset值后，还没来得及消费就挂掉了，那么下次再消费时之前没消费成功的消息就“诡异”的消失了；

解决办法：
针对消息丢失：同步模式下，确认机制设置为-1，即让消息写入Leader和Follower之后再确认消息发送成功；异步模式下，为防止缓冲区满，可以在配置文件设置不限制阻塞超时时间，当缓冲区满时让生产者一直处于阻塞状态；

针对消息重复：将消息的唯一标识保存到外部介质中，每次消费时判断是否处理过即可。

为什么Kafka不支持读写分离？

在 Kafka 中，生产者写入消息、消费者读取消息的操作都是与 leader 副本进行交互的，从 而实现的是一种主写主读的生产消费模型。

Kafka 并不支持主写从读，因为主写从读有 2 个很明 显的缺点:

  • 数据一致性问题。数据从主节点转到从节点必然会有一个延时的时间窗口，这个时间 窗口会导致主从节点之间的数据不一致。某一时刻，在主节点和从节点中 A 数据的值都为 X， 之后将主节点中 A 的值修改为 Y，那么在这个变更通知到从节点之前，应用读取从节点中的 A 数据的值并不为最新的 Y，由此便产生了数据不一致的问题。
  • 延时问题。类似 Redis 这种组件，数据从写入主节点到同步至从节点中的过程需要经历网络→主节点内存→网络→从节点内存这几个阶段，整个过程会耗费一定的时间。而在 Kafka 中，主从同步会比 Redis 更加耗时，它需要经历网络→主节点内存→主节点磁盘→网络→从节点内存→从节点磁盘这几个阶段。对延时敏感的应用而言，主写从读的功能并不太适用。