当三个节点中某个节点宕机后，集群首先会怎样做？没错，正如我们下面所说的，集群发现有Partition的Leader失效了，这个时分就要从ISR列表中重新选举Leader。假设ISR列表为空是不是就不可用了？并不会，而是从Partition存活的正本中选择一个作为Leader，不过这就有潜在的数据丧失的隐患了。

所以，只需将Topic正本个数设置为和Broker个数一样，Kafka的多正本冗余设计是可以保证高可用的，不会出现一宕机就不可用的状况（不过需求留意的是Kafka有一个保护策略，当一半以上的节点不可用时Kafka就会中止）。那细心一想，Kafka上是不是有正本个数为1的Topic？

成绩出在了 __consumer_offset 上， __consumer_offset 是一个 Kafka 自动创立的 Topic，用来存储消费者消费的 offset （偏移量）信息，默许 Partition 数为50。而就是这个Topic，它的默许正本数为1。假设一切的 Partition 都存在于同一台机器上，那就是很清楚的单点缺点了！当将存储 __consumer_offset 的 Partition 的 Broker 给 Kill 后，会发现一切的消费者都中止消费了。

这个成绩怎样处置？

第一点 ，需求将 __consumer_offset 删除，留意这个Topic时Kafka内置的Topic，无法用命令删除，我是经过将 logs 删了来完成删除。

第二点 ，需求经过设置 offsets.topic.replication.factor 为3来将 __consumer_offset 的正本数改为3。经过将 __consumer_offset 也做正本冗余后来处置某个节点宕机后消费者的消费成绩。

最后，关于为什么 __consumer_offset 的 Partition 会出现只存储在一个 Broker 上而不是散布在各个 Broker 上感到困惑。

【编辑引荐】

这个开源文本辨认系统我粉了！

关于Kafka消费者的这些参数，你应该要知道？

微软正开发WSA子系统：Android运用可在Intel/AMD/ARM设备上运转

Linux文件系统管理

文件系统与磁盘常见优化方案和术语

(责任编辑：admin)