Kafka 应对场景：消息持久化、吞吐量是第一要求、状态由客户端维护、必须是分布式的。Kafka 认为 broker 不应该阻塞生产者，高效的磁盘顺序读写能够和网络 IO 一样快，同时依赖现代 OS 文件系统特性，写入持久化文件时并不调用 flush，仅写入 OS pagecache，后续由 OS flush。
这些特性决定了 Kafka 没有做“确认机制”，而是直接将生产消息顺序写入文件、消息消费后不删除（避免文件更新），该实现充分利用了磁盘 IO，能够达到较高的吞吐量。代价是消费者要依赖 Zookeeper 记录队列消费位置、处理同步问题。没有消费确认机制，还导致了 Kafka 无法了解消费者速度，不能采用 push 模型以合理的速度向消费者推送数据，只能利用 pull 模型由消费者来拉消息（消费者承担额外的轮询开销）。
消息生产分为同步模式和异步模式
producer.type：消息发送类型同步还是异步，默认为同步
消息确认分为三个状态
(a)0：生产者只负责发送数据
(b)1：某个partition的leader收到数据给出响应
(c)-1：某个partition的所有副本都收到数据后给出响应
在同步模式下
(a)生产者等待10S，如果broker没有给出ack响应，就认为失败。
(b)生产者重试3次，如果还没有响应，就报错。
在异步模式下
(a)先将数据保存在生产者端的buffer中。Buffer大小是2万条。
(b)满足数据阈值或者数量阈值其中的一个条件就可以发送数据。
(c)发送一批数据的大小是500条。
Kafka消息保证生产的信息不丢失和重复消费问题
（1）使用同步模式的时候，有3种状态保证消息被安全生产，在配置为1（只保证写入leader成功）的话，如果刚好leader partition挂了，数据就会丢失。
（2）还有一种情况可能会丢失消息，就是使用异步模式的时候，当缓冲区满了，如果配置为0（还没有收到确认的情况下，缓冲池一满，就清空缓冲池里的消息），
数据就会被立即丢弃掉。
在数据生产时避免数据丢失的方法：
（1）在同步模式的时候，确认机制设置为-1，也就是让消息写入leader和所有的副本。
（2）在异步模式下，如果消息发出去了，但还没有收到确认的时候，缓冲池满了，在配置文件中设置成不限制阻塞超时的时间，也就说让生产端一直阻塞，这样也能保证数据不会丢失。
