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

在一套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 是怎么在设计上让我们完全避免这种运维中头疼的问题的。

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!