Kafka整体架构

https://mp.weixin.qq.com/s/zxPz_aFEMrshApZQ727h4g 《kafka系统设计》

https://gitbook.cn/books/5ae1e77197c22f130e67ec4e/index.html 《kafka架构》

 

1. 重要概念和原理

1）producer （采用推模式）和 consumer（采用拉模式，拉模式可以更灵活的控制消费速率） 只跟 leader 交互，leader是某个topic partition leader所在的broker，问题来了，producer和consumer怎么知道topic partition在哪个broker，其实是每个broker都有这些信息，并且client端也会存储这个信息（是不是跟Jedis（Redis Cluster）相似, 对有 smart client 设计理念）

2）controller相当于是leader broker，主要负责 topic partition leader的选举和一些failover

 

2. 生产流程中架构设计

1）partition leader 通常会有一些follower， follower 会定期从leader拉数据（不采用leader推送给follower的原因是这样可以减轻leader的工作，毕竟leader还要跟生产和消费交互），leader通过单独的心跳线程检查follower存活，会维护一个ISR（In-Sync-Replicas）即只有follower offset跟leader差距在容忍范围内时，才可以在ISR队列，ISR信息存储在ZK上，每个topic partition的leader信息也存在ZK

2）HW(High Water) 是consumer可见的最大offset，其实是partition leader 和follower的最小的LEO，HW还是leader重新选举时需要用到的

3）LEO(LogEndOffset) 当前写入的最大offset

4）生产相关重要参数

a）request.required.acks  0-表示不等待leader  1-表示leader写入自己LEO后返回  -1-表示leader要等所有的ISR写入LEO再返回，要根据业务情况综合考虑，我们大部分场景是配置0

b) linger.ms 强制至少在这个时间后producer发送消息

c) buffer.memory 满足这个size后，producer才会发送消息，以上两个参数配合发送消息，保证吞吐率

5) leader高可用，leader信息会注册在ZK（Controller会watch这个节点），leader挂掉，Controller会第一时间从ISR中选择一个作为leader，如果ISR都挂了，则从其他follower里面选

 

3. 消费流程中的架构设计

注意 consumer client本身是单线程设计，所有的coordinator、rebalance、heartbeat等都是通过poll函数内部实现，由于是单线程，并没有锁出现

1）Consumer是通过Consumer Group做隔离的，可以认为 不同 Consumer Group的消费者是没关系的；在同一个Consumer Group中，每个topic partition只能被唯一一个consumer消费，

优点：这样可以保证同一个partition数据是顺序消费的，每个consumer不用都跟大量的broker通信，减少通信开销，同时也降低了分配难度，实现也更简单

缺点：这样设计的劣势是无法让同一个consumer group里的consumer均匀消费数据

注意：consumer数量多于partition数量，多余的consumer不会消费，但是consumer数量少的话，一个consumer是可以消费多个partition的

2）每个consumer是单线程拉取信息的，老版本消费offset上报之前是存到ZK，新版本后来为了去除zk依赖（因为zk不适用高并发下读写，并且有herd和split brain问题），现在offset是会上报给一个固定的topic里（是的，offset会在topic里并存在broker里），存储offset原因是当consumer重启或者rebalance，可以知道从哪里开始继续消费，默认消费规则是 latest，即从最新的消费offset继续；还可以有其他情况定制 earliest方式，比如想重新消费某个topic，可以把consumer先全停掉，然后把consumer offset置零，并设置earliest方式，就可以重新消费了

3）何时上报offset？若拉取后马上上报，可能会因为consumer挂掉而导致消息未消费；若消费完成再上报，上报时消费者挂掉，可能会造成重复消费

4）consumer高可用怎么做到的？老版本是zk监控并通知给Controller进行rebalance；新版本是会为每个consumer group分配一个broker作为group coordinator,  group coordinator（下面简称GC)主要负责consumer group的offset管理、维持heartbeat、加入或离开group，GC会选择一个consumer作为leader，leader会决定如何rebalance，由client端进行rebalance可以进一步减轻server的负担且更为灵活（但是流程复杂性会加大，GC发现某个consumer心跳超时会通知consumer leader，由consumer leader决定如何rebalance并上报给GC，其他consumer同GC通信时拿到rebalance信息）

 

4. Controller如何保证高可用的

controller节点会注册在ZK，所有broker监听这个节点，一旦挂掉，所有broker会竞争创建controller节点并且只有一个成功，成功的节点成为新的Controller