因为一次 Kafka 宕机引发的高可用问题，我明白了 Kafka 高可用原理！

Kafka宕机引发的高可用问题

问题要从一次Kafka的宕机开始说起。

所在的是一家金融科技公司，但公司内部并没有采用在金融支付领域更为流行的RabbitMQ，而是采用了设计之初就为日志处理而生的Kafka，所以我一直很好奇Kafka的高可用实现和保障。从Kafka部署后，系统内部使用的Kafka一直运行稳定，没有出现不可用的情况。

但最近系统测试人员常反馈偶有Kafka消费者收不到消息的情况，登陆管理界面发现三个节点中有一个节点宕机挂掉了。但是按照高可用的理念，三个节点还有两个节点可用怎么就引起了整个集群的消费者都接收不到消息呢？

要解决这个问题，就要从Kafka的高可用实现开始讲起。

Kafka的多副本冗余设计

不管是传统的基于关系型数据库设计的系统，还是分布式的如zookeeper、redis、Kafka、HDFS等等，实现高可用的办法通常是采用冗余设计，通过冗余来解决节点宕机不可用问题。

首先简单了解Kafka的几个概念：

• 物理模型

• 逻辑模型

• Broker（节点）：Kafka服务节点，简单来说一个Broker就是一台Kafka服务器，一个物理节点。

• Topic（主题）：在Kafka中消息以主题为单位进行归类，每个主题都有一个Topic Name，生产者根据Topic Name将消息发送到特定的Topic，消费者则同样根据Topic Name从对应的Topic进行消费。

• Partition（分区