A 股疯了？交易所系统都被买崩了！
大家好，我是鸭鸭。
今天一早就被消息刷屏了。
——什么？大牛市来了？
——什么？券商系统崩了？
——什么？是上交所被买崩了？
今天这一上午，A 股可以说是跌宕起伏。早上A 股三大股指大幅高开。然而正当大家激情买入的时候，上午 10 点，上证指数成交量急剧萎缩 90%以上，指数直接拉成了横线。10:22 左右，更是出现交易异常情况，成交近乎停止。疑似是系统出现故障。直到 11 点半收盘前后，上交所交易才陆续恢复正常。
有业内人士分析，这和目前市场委托量非常大有关，撤单委托可能无法及时收到明确结果，属于正常现象。
最近几天， A 股在利好的刺激下，继续高开走强，重新站上 3000 点，白酒、地产板块甚至迎来 涨停！。所以这是太多人入场买卖导致把证券系统搞崩了？
鸭鸭这算不算是见证了历史？……
为有效优化和解决这类问题，一般交易所和券商系统都会采用分布式架构，以便在高峰期间更灵活地分散请求压力。
道理是相通的，今天我们就以 Kafka 为例来看下高可用性的实现思路。
面试题：Kafka 的高可用性是如何实现的？当 Broker 宕机时，如何保证服务不受影响？
回答重点
Kafka 的高可用性主要通过以下几个关键机制来实现：
1）多副本机制（Replication）：Kafka 中的每个分区都有多个副本（Replicas），这些副本分布在不同的 Broker 上。当一个 Broker 宕机时，其他持有该分区副本的 Broker 能够接管工作。
2）Leader-Follower 模式：每个分区有一个 Leader 副本和若干 Follower 副本。生产者和消费者只与 Leader 副本交互，而 Follower 副本则被用来备份数据。当 Leader 副本所在的 Broker 宕机时，一个新的 Leader 会被选举出来。
3）ZooKeeper 协调：Kafka 使用 ZooKeeper 进行分布式协调和元数据管理。当 Broker 宕机时，ZooKeeper 负责通知集群其他部分，并触发 Leader 选举过程。
当某个 Broker 宕机时，Kafka 保证服务不受影响的方式主要体现在以下几个方面：
1）自动选举新 Leader：ZooKeeper 会检测到 Broker 宕机，然后触发新 Leader 的选举过程。新的 Leader 选举出来后，继续对外提供服务。
2）数据冗余：由于存在多个副本，即使一个 Broker 宕机，其他副本仍然可以保证数据的完整性和高可用性。
3）分区再均衡（Rebalance）：Kafka 会将宕机 Broker 上的分区自动重新分配到其他可用的 Broker 上，确保整个集群负载均衡。
扩展知识
为了更好地理解 Kafka 的高可用性，以下是一些相关的扩展知识点：
1）ISR（In-Sync Replicas，同步副本集）：这是 Kafka 中用于维护高可用性的核心概念。ISR 是指所有与 Leader 副本保持同步的副本集合。只有在 ISR 中的副本才有可能被选为新的 Leader。
2）ACK 确认机制：Kafka 生产者在发送消息时可以指定不同的 ACK 确认机制，包括“0”表示不需要确认，“1”表示只需 Leader 确认，“-1”或“all”表示需要所有 ISR 成员确认。这种机制可以根据业务对延迟和容错的不同要求做出调整。
3）控制器（Controller）：集群中会有一个指定的 Broker 作为控制器，负责管理分区的 Leader 选举和分区状态变更。控制器也是通过 ZooKeeper 选举出来的，如果控制器宕机，会由 ZooKeeper 选出新的控制器。
4）惰性故障检测：Kafka 采取惰性故障检测机制避免无谓的 Broker 重启操作。当 ZooKeeper 检测到某个 Broker 宕机时，并不会马上重新选举和再平衡，而是等待一段时间以避免因短时间内的小故障导致的频繁重选。
最后
再来推荐下我们的面试刷题网站和小程序：面试鸭 ！已经有 8000+ 道面试题目啦，欢迎大家来阅读！