Kafka 的 ack 机制（数据可靠性保证）
0：不等待 broker 返回确认消息
1：等待 topic 中某个 partition leader 保存成功的状态反馈
-1：等待 topic 中某个 partition 所有副本都保存成功的状态反馈
仅设置 acks=-1 也不能保证数据不丢失，当 Isr 列表中只有 Leader 时，同样有可能造成数据丢失。要保证数据不丢除了设置 acks=-1, 还要保证 ISR 的大小大于等于 2，具体参数设置：
l request.required.acks：设置为-1 等待所有 ISR 列表中的 Replica 接收到消息后采算写成功；
l min.insync.replicas: 设置为大于等于 2，保证 ISR 中至少有两个 Replica
注意：Producer 要在吞吐率和数据可靠性之间做一个权衡
如何保证 kafka 消费者消费数据是全局有序的
伪命题
如果要全局有序的，必须保证生产有序，存储有序，消费有序。
由于生产可以做集群，存储可以分片，消费可以设置为一个 consumerGroup，要保证全局有序，就需要保证每个环节都有序。
只有一个可能，就是一个生产者，一个 partition，一个消费者。这种场景和大数据应用场景相悖。
Kafka 数据一致性保证
一致性定义：若某条消息对 client 可见，那么即使 Leader 挂了，在新 Leader 上数据依然可以被读到。
HW-HighWaterMark: client 可以从 Leader 读到的最大 msg offset，即对外可见的最大 offset， HW=max(replica.offset)
对于 Leader 新收到的 msg，client 不能立刻消费，Leader 会等待该消息被所有 ISR 中的 replica 同步后，更新 HW，此时该消息才能被 client 消费，这样就保证了如果 Leader fail，该消息仍然可以从新选举的 Leader 中获取。
对于来自内部 Broker 的读取请求，没有 HW 的限制。同时，Follower 也会维护一份自己的 HW，Folloer.HW = min(Leader.HW, Follower.offset)
Kafka 在 zookeeper 上记录了哪些信息
一共在 zookeeper 上记录了这些节点：consumers、admin、config、controller、brokers、controller_epoch。
其中 controller_epoch 节点记录了 kafka 中的 center controller 选举的次数，这个值初始为 1，当 controller 挂掉后重新选举时这个值+1。
Controller 节点记录了中央控制器所在哪一台 broker 的信息。
Zookeeper 在 kafka 中的作用
(1) Controller 选举、
(2) 记录集群中有哪些 broker、
(3) 记录集群中有哪些 topic，topic 都有哪些 partition，副本在哪里，leader 是谁。