kafka 的消费模式
1. 最多一次(at most once)：消息可能会丢失，但绝不会被重复发送。如果在 ack 超时或返回错误时 producer 不重试，则该消息可能最终不会写入 kafka，因此不会传递给 consumer。
2. 至少一次(at least once)：消息不会丢失，但有可能被重复发送。如果 producer 收到来自 Kafka broker 的确认（ack）或者 acks = all，则表示该消息已经写入到 Kafka 。但如果 producer ack 超时或收到错误，则可能会重试发送消息，客户端会认为该消息未写入 Kafka 。如果 broker 在发送 Ack 之前失败，但在消息成功写入 Kafka 之后，此重试将导致该消息被写入多次，可能导致重复的工作和不正确的结果。
3. 精确一次(exactly once)：消息不会丢失，也不会被重复发送。精确传递一次。将 offset 作为唯一 id 与消息同时处理，并且保证处理的原子性。消息只会处理一次，不丢失也不会重复。但这种方式很难做到。即使 producer 重试发送消息，消息也会保证最多一次地传递给最终consumer 。该语义是最理想的，但也难以实现，这是因为它需要消息系统本身与生产和消费消息的应用程序进行协作。例如如果在消费消息成功后，将 Kafka consumer 的偏移量 rollback ，我们将会再次从该偏移量开始接收消息。这表明消息传递系统和客户端应用程序必须配合调整才能实现 excactly-once 

kafka默认提供的交付可靠性是至少一次。比如出现网络瞬时抖动，Broker的应答没有成功发送回Producer端。那就需要Producer重复发送

在数学中，幂等的意思为：执行某个操作或函数能够执行多次，但每次得到的结果都是不变的。幂等最大的优势在于我们可以安全地重试任何幂等性操作，反正他们也不会破坏我们的系统状态。
幂等性是kafka 0.11.0.0 版本引入的新功能
指定幂等性：props.put("enable.idempotence", true) 或 props.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, true)

实现：
每个 Producer 在初始化时都会被分配一个唯一的 PID，这个 PID 对应用是透明的，完全没有暴露给用户。对于一个给定的 PID，sequence number 将会从0开始自增。Producer 在发送数据时，将会给每条 msg 标识一个 sequence number ，broker 也就是通过这个来验证数据是否重复。
这里的 PID 是全局唯一的，但是 Producer 故障后重新启动后会被分配一个新的 PID，这也是幂等性无法做到跨会话的一个原因。
broker上每个 Topic-Partition 也会维护 pid-seq 的映射，并且每次 Commit 都会更新 lastSeq。这样Record Batch 到来时，broker 会先检查 Record Batch 再保存数据。如果 batch 中 baseSeq(第一条消息的seq)比Broker维护的序号(lastSeq)大1，则保存数据，否则不保存

幂等性的作用范围：（幂等性Producer）
1. 一个幂等性Producer能够保证某个主题的一个分区上不出现重复消息，它无法实现多个分区的幂等性。
2. 它只能实现单会话上的幂等性，不能实现跨会话的幂等性。会话可以理解为Producer进程的一次运行，当重启了Producer进程之后，幂等性会消失。

功能：决定生产者将消息发送到那个分区的算法
常见的分区策略：
1. 轮询策略。轮询策略有非常优秀的负载均衡表现，它总是能保证消息最大限度地被平均分配到所有分区上，故默认情况下它是最合理的分区策略
2. 随机策略
3. 按消息键保序策略（key-ordering策略）。保证同一个key的所有消息都进入到相同的分区里面，每个分区下的消息处理都是有顺序的
kafka默认分区策略：如果指定了key，默认按消息键保序策略；如果没有指定key，则使用轮询策略

Kafka中可以将Topic从物理上划分成一个或多个分区（Partition），每个分区在物理上对应一个文件夹，以”topicName_partitionIndex”的命名方式命名，该文件夹下存储这个分区的所有消息(.log)和索引文件(.index)，这使得Kafka的吞吐率可以水平扩展

kafka中Producer端压缩、Broker端保持、Consumer端解压缩

Properties props = new Properties(); 
props.put("compression.type", "gzip"); // 开启GZIP压缩 
表明该Producer的压缩算法使用的是GZIP

Broker端也会进行解压缩，每个压缩过的消息集合在Broker端写入时都要发生解压缩操作，目的就是对消息执行各种验证

kafka只对“已提交”的消息做有限度的持久化保证
已提交消息定义：当kafka的若干个Broker成功地接收到一条消息并写入到日志文件后，他们会告诉生产者程序这条消息已成功提交。此时，这条消息在kafka看来就正式变为“已提交”消息了。可选设置有1个Broker成功写入就算已提交，也可选所有Broker成功写入算已提交。

设置acks=all。acks是Producer的一个参数，代表对“已提交”消息的定义。如果设置为all，则表明所有副本Broker都要接受到消息，才算“已提交”。

有限度持久化保证：假设消息保存在N个kafka Broker上，那么这个前提条件就是这N个Broker中至少有1个存活。只要这个条件成立，kafka就能保证消息永远不丢失

producer永远要使用带有回调通知的发送API，也就是说不要使用 producer.send(msg)，而要使用 producer.send(msg, callback)。callback可以告知消息是否提交成功，如果是那些瞬时错误，重试就可以。如果是消息不合格造成，那么可以调整消息格式后在此发送。

consumer端：如果是多线程异步处理消费消息，consumer程序不要开启自动提交位移，而是要应用程序手动提交位移。

1. 确定协调者和获取集群元数据
2. 连接协调者，令其执行组成员管理操作
3. 执行实际的消息获取