前言

在实际生产中，都会用到集群，来解决单点故障问题，实现kafka的高可用。kafka的集群中每个节点称作一个broker。每个broker下，都应该有同样分区日志文件，这样，才能保证高可用。下面我们讲解kafka集群的原理和工作机制。

一、副本

在第一节中我们讲到，在创建主题时，我们会指定主题的副本。在单机版kafka中，我们只能指定为1。但是在集群中，我们可以指定多个副本。指定几个副本，就会在几个broker中创建几个主题和相应的分区，以此来实现集群的高可用。所以，副本的数量，不能大于broker的总个数，否则会报异常。

二、首领

当我们在集群中创建主题的副本时，那么主题下的所有分区都有了多个副本。这些副本里面，总需要有个领头羊，这个领头羊就称之为首领。首领的作用是对接生产者和消费者。生产者发送的消息，首先是首领的分区接受，然后再同步到其他副本里面去。消费者消费消息，也是消费的首领分区中的消息。
需要注意的是，一个主题下有多个分区，每个分区都有一个首领，也就是一个主题下会有多个首领。这些首领并不一定全部在一台服务器的分区上。比如:一个集群有3个broker。一个主题有3个分区，且有3个副本。那么，分区1的首领可能在broker1上，分区2的首领可能在broker2上，分区3的首领可能在broker3上。并不是所有的分区首领，都在同一台服务器上。
实际上，kafka在选择分区首领时，也是应用的"最少使用原则"：当一台服务器有分区首领，而另一台服务器没有分区首领时，那么新的分区首领，肯定会选择还没有首领的服务器，以此来达到均衡的效果。
由上述可知，分区首领中的数据，是最新最全的数据，由首领给其他副本复制数据。而分区首领又不一定在一台服务器上，可能分布在不同的broker之间。所以，kafka的数据复制同步机制必须保证完善，因为如果机制有缺陷，当一台broker挂掉之后，这个broker的分区首领数据还没有同步到其他副本时，就出现问题了。kafka的复制机制我们在下面进行讲解。

三、副本与服务器之间的关系

在我们的观念里，集群中每个broker中的主题下的分区，都在这个主题所在的broker服务器上。而在kafka集群中，一个broker的主题下的分区，可以分布在不同的broker上。
举例说明，假如现在有6个broker，即6台kafka服务器，创建一个主题，主题下有10个分区，并有3个副本。kafka的分区分配机制并不是3台broker上创建3套分区的副本，空余的3台broker没有分区副本，这也不符合kafka大数据，高并发的特点。kafka是把这总共30个分区，平均的分配在这6台kafka上，即每个broker上会分配5个分区副本。且同一个分区的3个副本，不会两两分配到同一台broker上。

四、kafka的复制机制

ISR机制:
主题下每个分区(Partition)的首领(Leader)，都会维护一个列表，这个列表里，存着该分区的其他副本，包括首领本身。每次进行副本之间的数据同步时，只有ISR维护的列表里所有的副本都同步完成时，首领才会把同步的消息设置为Commit状态，此时的消息才会被消费者所消费。
ISR中维护的副本列表，是动态变化的，如果某个副本在数据同步时超时没有响应，则ISR会将该副本剔除列表。当副本恢复正常时,ISR列表会再次把该副本加入队列，并将最新的ISR列表同步到zookeeper中持久化。
所以，ISR技术比起同步复制来说，其可以动态维护ISR列表，比同步效率更高。对于异步同步数据来说，更安全。
由上述可知，消费者能够消费的消息，都是首领已经同步到其他副本中的数据，如果没有同步的数据，是不会被消费者消费的。

五、kafka对数据安全性的保障策略

MQ中数据的安全性，主要包括两方面:消息丢失和数据重复消费。

• 最少同步副本
  server.properties配置文件中，有个属性为min.insync.replicas。该属性就是最少同步副本属性。默认值为1。也就是说，kafka中副本数最少可以是1。当分区副本为1时，数据还是不安全的，因为当该副本挂了之后，数据就丢失了。所以，可以把这个属性值调大，此时，如果副本中，只有一个副本能工作了，也就是副本数又成了1，则这个副本不会再接收生产者的消息，并给生产者返回NotEnoughReplicasException 异常。但是消费者可以继续消费该副本的消息，也就是说这个副本成为只读状态了。kafka通过这种机制，保证了各个副本之间的数据一致性。
• 不完全首领机制
  当一个首领分区挂掉之后，kafka会选择一个与分区首领数据同步的副本分区作为新的首领。这种的选举称为"完全的"。
  但是，在首领与其他副本进行数据同步时，假如首领挂掉了，部分数据没有同步到其他副本里，这种情况下，就称为"不完全的"。针对这种情况，kafka设定了unclean.leader.election参数，其默认值为true，就是不完全首领机制。它允许把数据不同步的副本选举为首领。这样做也就出现了数据丢失的情况。我们在实际业务开发中，需要自行进行取舍，如果设置为true，则数据会有丢失的情况。如果设置为false，则数据不同步的副本，不会成为首领。那么只能等待挂掉的首领重新启动，kafka才能正常使用。这期间造成的损失和数据丢失造成的损失孰重孰轻，需要我们自己进行衡量和取舍。

六、如何确定集群中要多少broker

想要确定需要几个broker。就需要事先知道我们的集群，要承载多少的数据量。比如，我们要用集群处理10TB的数据量，而每台服务器只能存储2TB数据量，则我们需要5个broker。这是只有一个副本的情况，如果两个副本，则需要成倍的broker。所以确定broker需要大概知道我们处理的业务量有多少。

七、ISR机制，最小同步副本机制，不完全首领机制比较

ISR机制强调的是首领往其他副本同步时其他副本如果挂掉时的策略。
最小同步副本和不完全首领机制侧重点是首领挂掉了kafka的处理策略。