十五个点，理解Apache Kafka
|
一个分布式系统肯定是可协调的，当事件发生时，节点必须以某种方式做出反应，控制器负责决定集群如何做出反应并指示节点做某事，它是功能不能过于复杂的Broker节点，最主要的职责是负责节点下线和重新加入时重平衡和分配新的分区leader。 控制器从ZooKeeper Watch事件中可以得知某个Broker节点实例下线(或者节点过期，一般发生于Broker长时间繁忙导致心跳异常)的情况，然后做出反应，决定哪些节点应成为受影响分区的新leader，然后通知每个相关的follower通过leaderAndlsr请求开始从新的leader复制数据。  从上面可以得知，原本作为分区leader的Broker节点实例重启后，它将不再担任任何分区的leader，消费者也不会从这个节点上读取消息，这导致了资源的浪费，幸运的是，Kafka有一个被称为优先副本(preferred leader replica)的概念-你可以理解成原先为该分区leader节点(通过broker id区分)的副本,如果该副本可用，Kafka会将集群恢复成之前状态，通过设置auto.leader.rebalance.enabled=true可以使得这个过程自动触发，默认值为true。 Broker节点下线通常都是短暂的，这意味着一段时间后会恢复，这就是为什么当一个节点离开集群时，与之关联的元数据不会被删除，如果它是一个分区的跟随者，系统也不会为此分区重新分配新的跟随者。 但是需要注意的是，恢复加入的节点不能立即拿回其上次的leader地位，它还没有资格。 十一、ISR 副本同步队列ISR(in-sync replicas)，它是由leader维护的，follower从leader同步数据是有延迟的，任意一个超过阈值都会被剔除出ISR列表, 存入OSR(Outof-Sync Replicas)列表中，新加入的follower也会先存放在OSR中。 一个follower想被选举成leader，它必须在ISR队列中才有资格,不过，在没有同步副本存在并且已有leader都下线的边缘情况下，可以选择可用性而不是一致性。 ISR列表维护标准如下：
十二、生产者acks设置 明显，存在一系列意外事件会导致leader下线，假如leader节点接收到生产者的消息，在存储并且响应ack后节点崩溃了,此时Kafka会从ISR列表中选举一个新的leader,但是由于生产者ack配置默认为1,意思是只考虑leader接收情况不考虑follower同步情况，最终导致部分消息丢失了，所以我们应该在生产者端设置acks=all，要求每条数据必须是写入所有副本之后，才能认为是写成功，另外一层意思是起码有一个leader和一个follower。不过这种设置影响集群性能，降低了吞吐量，使得生产者需要在发送下一批消息之前等待更多时间。  十三、水位 通过ack=all约定了leader节点在消息没有同步到所有的ISR列表前不会有任何返回，另外，节点会跟踪所有同步副本具有的最大偏移量，也就是高水位偏移量HW(high watermark offset)，consumer无法消费分区下leader副本中偏移量大于分区HW的任何消息。当某个副本成为leader副本时、broker出现崩溃导致副本被踢出ISR时、producer向leader写入消息后、leader处理follower fetch请求时，都会尝试更新分区HW，从而保证了数据一致性和正常消费时不会出现读取到旧值。  十四、脑裂 想象一下，当正常存活的controller控制器由于长时间GC-STW导致不可用，然后Zookeeper会认为/controller节点(节点3)已经过期随即删除并发送通知到其他broker节点，其他每个broker节点都尝试升级为控制器节点，假设节点2从竞争中胜出成功新的控制器节点并在ZK中创建/controller节点。 然后其他节点接收到通知，了解到节点2成为了新的控制器节点，除了还在GC暂停的节点3，或者通知压根没到达的节点3，也就是说节点3不知道leadership已经发生了变化，它还以为自己是控制器节点。此时，同时存在两个控制器，并行发出可能存在冲突的命令，导致严重的后果。 幸运的是，Kafka提供了epoch number的方式可以轻松区分出真实的控制器，它是自增长的序列号，信息存储在ZooKeeper中，显然序列号最大的那个节点才是真实的。  十五、什么时候应该使用Kafka 从上面几点可知，Kafka可以成为事件驱动架构的中心部分，使你可以真正将应用程序彼此分离。 
（编辑：衡阳站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
