站长网 系统 Kafka架构和高可用机制分析,阿里腾讯都在用

Kafka架构和高可用机制分析,阿里腾讯都在用

在一套kafka架构中有多个Producer,多个Broker,多个Consumer,每个Producer可以对应多个Topic,每个Consumer只能对应一个ConsumerGroup。 整个Kafka架构对应一个ZK集群,通过ZK管理集群配置,选举Leader,以及在consumer group发生变化时进行rebalance。

在一套kafka架构中有多个Producer,多个Broker,多个Consumer,每个Producer可以对应多个Topic,每个Consumer只能对应一个ConsumerGroup。

整个Kafka架构对应一个ZK集群,通过ZK管理集群配置,选举Leader,以及在consumer group发生变化时进行rebalance。

对于一个复杂的分布式系统,如果没有丰富的经验和牛逼的架构能力,很难把系统做得简单易维护,我们都知道,一个软件的生命周期中,后期维护占了70%,所以系统的可维护性是极其重要的, kafka 能成为大数据领域的事实标准,很大原因是因为运维起来很方便简单,今天我们来看下 kafka 是怎么来简化运维操作的。

kafka 使用多副本来保证消息不丢失,多副本就涉及到kafka的复制机制,在一个超大规模的集群中,时不时地这个点磁盘坏了,那个点cpu负载高了,出现各种各样的问题,多个副本之间的复制,如果想完全自动化容错,就要做一些考量和取舍了。我们举个例子说明下运维中面对的复杂性,我们都知道 kafka 有个 ISR集合,我先说明下这个概念:

kafka不是完全同步,也不是完全异步,是一种ISR机制:

1. leader会维护一个与其基本保持同步的Replica列表,该列表称为ISR(in-sync Replica),每个Partition都会有一个ISR,而且是由leader动态维护

2. 如果一个follower比一个leader落后太多,或者超过一定时间未发起数据复制请求,则leader将其重ISR中移除

3. 当ISR中所有Replica都向Leader发送ACK时,leader才commit,这时候producer才能认为一个请求中的消息都commit了。

在这种机制下,如果一个 producer 一个请求发送的消息条数太多,导致flower瞬间落后leader太多怎么办?如果 follower不停的移入移出 ISR 会不会影响性能?如果对这种情况加了报警,就有可能造成告警轰炸,如果我们不加报警,如果是broker 挂掉或者 broker 因为IO性能或者GC问题夯住的情况导致落后leader太多,这种真正需要报警情况怎么办呢?

今天我们来看下 kafka 是怎么在设计上让我们完全避免这种运维中头疼的问题的。

本文来自网络,不代表站长网立场,转载请注明出处:https://www.zwzz.com.cn/html/fuwuqi/xt/2021/0525/6262.html

作者: dawei

【声明】:站长网内容转载自互联网,其相关言论仅代表作者个人观点绝非权威,不代表本站立场。如您发现内容存在版权问题,请提交相关链接至邮箱:bqsm@foxmail.com,我们将及时予以处理。
联系我们

联系我们

0577-28828765

在线咨询: QQ交谈

邮箱: xwei067@foxmail.com

工作时间:周一至周五,9:00-17:30,节假日休息

返回顶部