Kafka浅学
Kafka应用场景？
异步解耦
流量消锋
Kafka消息队列特点？
Kafka吞吐量高：因为他存储数据时，磁盘顺序存储，磁盘的顺序存储速度很快。
Kafka持久化消息：这些消息日志可以被重复读取和永久保留
可以运行时动态扩展伸缩：Kafka是分布式系统：它以集群的方式运行，
早期依赖Zookeeper对于Kafka的作用是什么？
Zookeeper是分布式协调服务。
Zookeeper作用：用于在Kafka集群中不同节点之间通信，保存着集群 broker、 topic、 partition等元数据。负责提交偏移量、broker故障发现， partition leader选举，负载均衡。
队列模式、发布订阅模式？
Kafka每个组里只有一个consumer可以消费消息。
队列模式：
所有消费者设置在一个组中，每个组只有一个consumer可以消费。
发布订阅模式：
极限一点，每个消费者都单独设置为一组，每个组都只有一个消费者，所有组就都会消费消息。变成发布订阅。
推送与拉取？
Pull模式主动拉取消息好处：consumer可以自主决定是否批量的从broker 拉取数据控制消费速度。
Pull模式缺点：如果broker没有可供消费的消息，consumer会不断轮询，直到新消息到达Kafka有个参数可以让consumer阻塞到 新消息到达(也可以阻塞到消息的数量达到某个特定的量在拉取)。
push模式：虽然实时性高，但不知道消费者消费速度，容易压垮消费者。
消费者如何不自动提交偏移量，由应用提交？
将auto.commit.offset设为false。
消息消费完成后: kafka对象.commitSync() 或者异步提交commitAsync()
kafka分布式下，如何保证消息的顺序消费？
Kafka分布式的单位是partition（一个topic里至少有一个partition基本单位存消息），同一个partition保证顺序。不同partition之间不能保证顺序。
所以：
发消息的时候要发送到同一个partition中，并且设置参数：前一个消息发送后一个消息才能发送。
生产者 发送1条消息的时候，可以指定send方法(topic, partition, key) 3个参数。partiton和key是可选的。如果你指定了partition，那就是所有消息发往同1个partition，就是有序的。
不指定key，轮训决定发到那个patotion
指定key，对key hash 具有同1个key的所有消息，会发往同1个partition。
kafka如何重复不消费数据？
为什么会重复消费？：在消费完数据之后，回复给broker的offet失败，会认为这个消息没有被消费。
重复消费如果能保证幂等性能（消费一次和消费多次的影响结果一致）就没问题。
场景：
如redis来setkey，天然幂等性（因为key在set一遍不重复没关系）没问题。
如消费逻辑是数据要加记录，就要在消费时先查一遍是否被消费过。消费过了，就不再消费了。
可以利用数据库的唯一键约束来保证重复消费数据的幂等性不会重复插入多条。因为有唯一键约束了，重复数据插入只会报错。
kafka如何保证消息不丢失？
卡夫卡主要有三个角色，生产者、broker、消费者。
保证消息不丢失，就要保证生产者成功发消息给broker，并且broker要成功刷消息到磁盘，最后消费者成功消费了消息。
一般情况下：消费者不太可能消费消息丢失。因为消费者是消费完消息完在手动回复给broker offset。（不要默认自动提交offset）（这样也存在了重复消费问题）
生产者保证消息到达broker。
1，用异步回调函数监听发送结果，如果失败了回掉函数重试发送。
2，生产者本身有重试参数，retries = 次数，注意设置时间间隔不要太短。
broker保证消息持久化到磁盘。
broker刷消息到磁盘是按照一定消息量和时间间隔批量刷入的。刷盘之前broker奔溃，需要用partition的follower和asks参数解决。
高可用的Kafka集群，每个partition有唯一的leeder，leeder去处理请求，follower同步leader数据。
参数1: acks，结合partition的follower机制保证数据可靠。
acks = 0 ：生产者不需要等待broker响应就认为消息发送成功。（延迟最低，存在丢失）
acks = 1 ：broker中leeder partition 不等待他的follower同步，就给生产者响应成功。（此情况；leeder挂了，其他follower没有副本就会消息）
acks = -1 ：broker中leeder partition 需要等待它的所有follower同步完成，在给生产者响应成功。（性能很低）
参数2: replication.factor >= 3 表示保证每个partition至少要有三个副本
参数3: min.insync.replicas > 1 表示同步的副本数量要大于1，才认为发送成功
kafka消息积压？
生产者没指定key可能会发送到不同partition（以前轮训，现在随机） ，数据倾斜导致的积压
生产者出了问题一直发送消息
消费者消息有问题，一直消费失败，重新消费消息。没有向后提交偏移量。
消费者数量不够，跟不上生产者。