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