Kafka | 青训营笔记

小刘新鲜事儿
77 阅读4分钟

这是我参与「第四届青训营 」笔记创作活动的第8天

1. Kafka中的角色

1.1 Zookeeper

image.png

Observer是为了扩展读能力

  • 提供一致性：

    • 写入（强一致性）
    • 读取（会话一致性）

  • 提供可用性：

    • 一半以上节点存活即可读写

  • 提供功能：

    • watch机制
    • 持久/临时节点能力

  • Zookeeper中存储了Kafka的哪些数据呢？

    • Broker Meta信息（临时节点）
    • Controller信息（临时节点）
    • Topic信息（持久节点）
    • 集群Config信息（持久节点）

1.2 Broker

image.png

  • 若干个Broker节点组成Kafka集群

  • Broker作为消息的接收模块，使用React网络模型进行消息数据的接收

  • Broker作为消息的持久化模块，进行消息的副本复制以及持久化

    • 每个Broker中，会有Leader Partition，也会有Follower Partition，同一个分区的Leader和Follower往往会分布在不同的Broker节点上，是为了单机节点宕机的数据容灾
    • Follower会从Leader处进行一个数据同步，并且持久化到本地磁盘中

  • Broker作为高可用模块，通过副本间的Failover（失效转移）进行高可用保证

    • Follower会从Leader定期同步数据，相当于在网络正常的情况下，Follower拥有Leader的大部分数据甚至是全量数据，所以，在单机故障的情况下，可以通过副本的Failover来保证高可用

1.3 Controller

① Controller选举

image.png

通俗化的理解，Controller就是一个特殊的Broker。在Broker启动的时候，会尝试往Zookeeper中去创建一个临时节点，因为Zookeeper提供的写能力是强一致性的，那么三个节点中，只会有一个节点写入成功，相当于是分布式锁的概念，抢到锁的Broker节点就是Controller节点

  • Broker启动会尝试去Zookeeper中注册Controller节点

  • 注册上Controller节点的Broker即为Controller

  • 其余Broker会watch Controller节点，若节点出现异常则重新注册

② Controller作用

image.png

  • Broker重启/宕机时，负责副本的Failover切换
  • Topic创建/删除时，负责Topic meta信息广播
  • 集群扩缩容时，进行状态控制
  • Partition/Replica状态机维护

1.4 Coordinator

Coordinator也是一个特殊的Broker，负责对消费端的控制

  • 负责Topic-Partition <-> Consumer的负载均衡
  • 根据不同场景提供不同的分配策略
    • Dynamic Membership Protocol
    • Static Membership Protocol
    • Incremental Cooperative Rebalance

2. Kafka高可用

  • 副本同步机制

    • 提供isr副本复制机制，提供热备功能
    • 写入端提供ack=0,-1,1机制，控制副本同步强弱

  • 副本切换机制

    • 提供clean/unclean副本选举机制

2.1 Kafka副本的ISR机制

image.png

  • AR

    • Assign Replica，已经分配的所有副本

  • OSR

    • Out Sync Replica，很久没有同步数据的副本

  • ISR

    • 一直都在同步数据的副本

    • 可以作为热备进行切换

    • min.insync.replicas最少isr数量配置

      • 图中有3个副本，如果Broker1和Broker2都宕机了，只有Broker0一个副本了，再往Broker0里边写数据就不安全了，因为只有一个副本，如果再发生宕机，相当于不可写也不可读了。
      • min.insync.replicas表示至少有多少个可用的isr成员，如果配置的是2，其中一个发生宕机，就不可写。也就是说，必须得有下限，不然保证不了数据的一致性，相当于可用性和一致性做了一个协调

我们可以假设一个场景，一个分区的 AR 集合为【0,1,2,3,4,5】，其中 leader-replica 是 0，其中【1,2,3】作为 follower 和 leader 的数据保持同步，而【4,5】未能和 leader 保持同步，那么此时，ISR=【0,1,2,3】，OSR=【4,5】。如果此时副本 4 追上了 leader-replica，也就是和 leader 保持到了同步。那么此时，ISR=【0,1,2,3,4】，OSR=【5】。从上面的场景我们就可以明白，ISR 动态维护了一个和 leader 副本保持同步副本集合，ISR 中的副本全部都和 leader 的数据保持同步。

2.2 Kafka写入Ack机制

  • Ack = 1

    • Leader副本写入成功，Producer即认为写入成功

  • Ack = 0

    • Producer发送后即认为成功

  • Ack = -1

    • ISR中所有副本都成功，Producer才认为写入成功

问题：3副本情况下，如何结合min.insync.replica以及ack的配置，来保证写入kafka系统中的数据不丢失？如果是5副本呢？

答：①min.insync.replica=2，②ack=-1

2.3 Kafka副本

① Kafka副本同步

用来维护Consumer数据的可见性

  • LEO
    • Log End Offset，日志最末尾的数据
  • HW
    • ISR中最小的LEO作为HW
    • HW的消息为Consumer可见的消息

image.png

② Kafka副本选举

如果Leader副本宕机了，会选取符合条件的副本

  • Clean选举
    • 优先选取ISR中的副本作为Leader
    • 如果ISR中无可用副本，则Partition不可用
    • 侧重于数据一致性强的
  • Unclean选举
    • 优先选取ISR中的副本作为Leader
    • 如果ISR中无可用副本，则选择其他存活副本
    • 也侧重于数据一致性强的，如果不能保证数据一致性，也可以保证可用性
avatar
文章
阅读
粉丝