Kafka的高可用性

• Kafka是由多个broker组成的，每个broker是一个节点，创建一个topic，这个topic可以划分为多个partition，每个partition可以存在于不同的broker上，每个partition就放一部分数据。

Kafka是天然的分布式消息队列，就是说一个topic的数据是分散放在多个机器上的，每个机器就放一部分数据。

1. 实际上RabbitMQ之类的，并不是分布式消息队列，它就是传统的消息队列，只不过提供了一些集群、HA（High
   Availability，高可用性）的机制而已，所以RabbitMQ一个queue的数据都是放在一个节点里面的，镜像集群下，也是每个节点都放在queue的完整数据。
2. Kafka
   0.8以前是没有HA机制的，就是任何一个broker宕机了，那个broker上的partition就废了，没法写也没法读，没有什么高可用性可言。
   比如说，我们假设创建了一个topic，指定其partition数量是3个，分别在三台机器上，但是如果第二台机器宕机了，会导致这个topic的1/3的数据就丢了，因此这个是做不到高可用的。
3. Kafka
   0.8以后提供HA机制，就是replica（复制品）副本机制。每个partition的数据都会同步到其他机器上，形成自己的多个replica副本。所有replica会选举一个leader出来，生产和消费都跟这个leader打交道，然后其他replica就是follower。写的时候。leader会负责把数据同步到所有的follower上去，读的时候就直接读leader上的数据即可。
   如果可以随意读写每个follower,那么就是考虑数据一致性的问题，系统复杂度太高很容易出现问题。Kafka会均匀的将一个partition的所有replica分布在不同的机器上，这样可以提高容错性。
4. 这样就实现了高可用性，因为如果某个broker宕机了，那个broker上面的partition在其它机器上都有副本的，如果这个宕机的broker上面有某个partition的leader，那么此时会从follower中重新选举一个新的leader出来，然后继续读写那个新的leader即可。
5. 写数据的时候，生产者就写leader，然后leader将数据落地写本地磁盘，接着其他follower自己主动从leader来pull数据，一旦所有follower同步好了数据，就会发送ack给leader，leader收到所有follower的ack之后，就会返回写成功的消息给生产者。
6. 消费的时候，只会从leader去读，但是只有当一个消息已经被所有follower都同步成功返回ack的时候，这个消息才会被消费者读到。