问题一：Kafka如何保证系统的可用性？
Kafka如何保证系统的可用性？
参考回答：
Kafka通过多副本机制来保证系统的可用性。在创建Topic时，可以指定--replication-factor参数来设置副本数，例如设置为3表示每个分区都有3个副本。在Kafka中，只有Leader是负责读写的节点，Follower会定期从Leader上Pull数据以保持同步。ISR是Leader负责维护的与其保持同步的Replica列表。如果一个Follower落后太多，Leader会将它从ISR中移除。此外，通过设置acks=all，可以确保Leader在收到ISR中所有Replica的ACK后才向Producer发送ACK，从而进一步保证数据的可靠性和系统的可用性。
关于本问题的更多问答可点击原文查看：
https://developer.aliyun.com/ask/628393
问题二：ZooKeeper 的作用？详细说一下
ZooKeeper 的作用？详细说一下
参考回答：
目前，Kafka 使用 ZooKeeper 存放集群元数据、成员管理、Controller 选举，以及其他一些管理类任务。之后，等 KIP-500 提案完成后，Kafka 将完全不再依赖于 ZooKeeper。
• 存放元数据是指主题分区的所有数据都保存在 ZooKeeper 中，其他“人”都要与它保持对齐。
• 成员管理是指 Broker 节点的注册、注销以及属性变更等 。
• Controller 选举是指选举集群 Controller，包括但不限于主题删除、参数配置等。
一言以蔽之:KIP-500 ，是使用社区自研的基于 Raft 的共识算法，实现 Controller 自选举。
同样是存储元数据，这几年基于Raft算法的etcd认可度越来越高。
越来越多的系统开始用它保存关键数据。比如，秒杀系统经常用它保存各节点信息，以便控制消费 MQ 的服务数量。还有些业务系统的配置数据，也会通过 etcd 实时同步给业务系统的各节点，比如，秒杀管理后台会使用 etcd 将秒杀活动的配置数据实时同步给秒杀 API 服务各节点。
关于本问题的更多问答可点击原文查看：
https://developer.aliyun.com/ask/628394
问题三：Replica副本的作用？
Replica副本的作用？
参考回答：
Kafka 只有 Leader 副本才能 对外提供读写服务，响应 Clients 端的请求。Follower 副本只是采用拉(PULL)的方 式，被动地同步 Leader 副本中的数据，并且在 Leader 副本所在的 Broker 宕机后，随时准备应聘 Leader 副本。
• 自 Kafka 2.4 版本开始，社区可以通过配置参数，允许 Follower 副本有限度地提供读服务。
• 之前确保一致性的主要手段是高水位机制， 但高水位值无法保证 Leader 连续变更场景下的数据一致性，因此，社区引入了 Leader Epoch 机制，来修复高水位值的弊端。
关于本问题的更多问答可点击原文查看：
https://developer.aliyun.com/ask/628395
问题四：为什么Kafka不支持读写分离?
为什么Kafka不支持读写分离?
参考回答：
• 自 Kafka 2.4 之后，Kafka 提供了有限度的读写分离。
• 场景不适用。读写分离适用于那种读负载很大，而写操作相对不频繁的场景。
• 同步机制。Kafka 采用 PULL 方式实现 Follower 的同步，同时复制延迟较大。
关于本问题的更多问答可点击原文查看：
https://developer.aliyun.com/ask/628396
问题五：如何防止Kafka重复消费？
如何防止Kafka重复消费？
参考回答：
• 代码层面每次消费需提交offset；
• 通过Mysql的唯一键约束，结合Redis查看id是否被消费，存Redis可以直接使用set方法；
• 量大且允许误判的情况下，使用布隆过滤器也可以。
关于本问题的更多问答可点击原文查看：
