1: Kafka如何保证高可用性：

Kafka 基本的架构：由多个 broker 组成，每个 broker 是一个机器节点；你创建一个 topic，这个 topic可以划分为多个 partition，每个 partition 可以存在于不同的 broker 上，每个 partition就放一部分数据。每个 partition 的数据都会同步到其它机器上，形成自己的多个 replica 副本。这就是天然的分布式消息队列，就是说一个 topic 的数据，是分散放在多个机器上的，每个机器就放一部分数据。

所有 replica 会选举一个 leader 出来，那么生产和消费都跟这个 leader 打交道，然后其他 replica 就是follower。写的时候，leader 会负责把数据同步到所有 follower 上去，读的时候就直接读 leader上的数据即可。一般情况只能读写 leader，follower在leader不宕机的情况下只负责同步数据。

如果某个 broker 宕机了，那个 broker 上面的 partition 在其他机器上都有副本的。如果这个宕机的 broker上面有某个 partition 的 leader，那么此时会从 follower 中重新选举一个新的 leader出来，大家继续读写那个新的 leader 即可。这就有所谓的高可用性了。

2 Kafka如何保证一致性

一致性：若某条消息对consumer可见，那么即使Leader挂了，在新Leader上数据依然可见。

ISR (In-Sync Replicas)是Leader在Zookeeper中动态维护基本保持同步的Replica列表，该列表中保存的是与Leader副本保持消息同步的所有副本对应的Follower节点id。ISR冗余备份机制核心逻辑围绕HW值、LEO值展开。

LEO（last end offset）日志末端偏移量，记录了该副本对象底层日志文件中下一条消息的位移值。

HW（highwatermark），高水印值，任何一个副本对象的HW值一定不大于其LEO值，而小于或等于HW值的所有消息被认为是“已提交的”或“已备份的”。consumer只能消费已提交的消息，HW之后的数据对consumer不可见。

3 Kafka如何保证顺序性

Kafka只能保证partition内部有序，不保证整个topic有序。

乱序场景一
因为一个topic可以有多个partition，kafka只能保证partition内部有序。可能需要顺序的数据分布到了不同的partition，导致处理时乱序

解决方案
1、可以设置topic 有且只有一个partition
2、根据业务需要，需要顺序的 指定为同一个partition
3、根据业务需要，比如同一个订单，使用同一个key，可以保证分配到同一个partition上

乱序场景二
对于同一业务进入了同一个消费者组之后，用了多线程来处理消息，会导致消息的乱序

解决方案
消费者内部根据线程数量创建等量的内存队列，对于需要顺序的一系列业务数据，根据key或者业务数据，放到同一个内存队列中，然后线程从对应的内存队列中取出并操作

4 Kafka如何保证不丢消息

消费端：
消费者消费到了这个消息，消费者自动提交了 offset，让 Kafka以为你已经消费好了这个消息，但其实你才刚准备处理这个消息，你还没处理，你自己就挂了，此时这条消息就丢了。
处理方法：关闭自动提交offset，在处理完之后自己手动提交 offset，就可以保证数据不会丢。但是此时确实还是可能会有重复消费。注意保证幂等性。

Kafka集群：
分布式高可用，多台机器多个replica。数据落磁盘。

生产端：
设置acks = -1。acks参数有三种设置

acks = 0 : 意味着producer不等待leader同步完成的确认，继续发送下一条(批)信息，容易丢数据。
acks = 1（默认）：意味着producer要等待leader成功收到数据并得到确认，才发送下一条message。此选项提供了较好的持久性较低的延迟性。如果Leader宕机，follower尚未复制，数据就会丢失。

acks = -1/all ：意味着producer得到所有follower(ISR)确认，才发送下一条数据。除极端ISR里没有任何follower的情况，都不会丢数据。

5 Kafka如何保证不重复消费

消费者消费后提交offset，如果宕机从offset继续消费
结合业务看，保证消费者幂等性。重复消费不可怕，保证幂等就行。

6 Kafka为什么速度快吞吐量大

1 顺序写，而不是随机写
2 零拷贝
3 分区分段+索引
4 批量读写，批量压缩