1. Topic Replication Factor

TopicReplication

  • 数据复制(Data Replication)通过向多个broker写入
    相同的数据来帮助防止数据丢失(prevent data loss)

  • 复制因子是主题设置，在创建主题时指定，
    主题的复制因子(replication factor)应该大于1，通常在2和3之间；

  • 复制因子为1：没复制，用于开发目的，测试或生产时应避免使用；

  • 3是常用的复制因子为，在broker loss和replication overhead间提供适当的平衡；

TopicReplicationSuccess

  • 这样某broker发生故障(down)，另一个代理可提供数据(serve data)；

  • 如具有2个分区，且复制因子为2的主题A；

  • 我们失去(lose) broker 102，结果：broker101和103仍然可提供数据；

TopicReplicationFailure

2. Partition Leader and Replica

  • 对于给定的主题分区，集群指定一个Kafka broker负责向客户端
    发送和接收数据，该broker被称为该主题分区的leader broker；

  • 存储该分区(storing)的复制数据(replicated data)的任何其它
    broker都称为副本,故每个分区都有一个leader和多个副本replica；

3. ISR In Sync Replica

  • 同步副本是与partition的leader broker保持同步的副本，
    任何与leader不同的(not up to date)副本都是不同步的(out of sync)；

InSyncReplica

  • Broker 101作为分区0的leader，Broker 102作为分区1的leader，
    Broker 102 是分区0的Replica，Broker 103是分区1的Replica，
    若leader broker发生fail，其中一个Replica通过选举当选为新的分区leader

  • 在任何时候，只有一个broker可成为给定分区的领导者；

  • 生产者智能想分区领导者发送数据，其它broker将复制(replicate)数据；

  • 故每个分区有一个领导者和多个ISR(同步副本，in-sync replica)；

4. Producer Ack Setting

  • 生产者仅将数据写入分区的当前leader broker；

  • 生产者还必须指定acknowledgment ack level，
    以指定消息是否必须写入最少数量的replica才能被视为成功写入；

Kafka Version Ack Default Value

Kafka < v3.0

acks=1

Kafka >= v3.0

acks=all

  • 生产者可选择接受数据写入的确认；
    choose to receive acknowledgment of data write；

Type Memo

acks=0

生产者不会等待确认(可能数据丢失)

acks=1

生产者将等待领导者确认(有限的数据丢失)

acks=all

Leader + Replica确认(无数据丢失)

4.1. acks=0

Ack0

  • acks=0，生产者在消息发送时就认为消息"写入成功"，而根本不等待broker接受它；

  • 若broker offline或发生异常，我们将不知道，且会丢失数据，
    这对可能丢失消息(potentially lose msg)的数据很有用，
    如指标收集，并产生最高的吞吐量设置，因network overhead最小化；

4.2. acks=1

Ack1

  • acks=1，当消息仅由leader acknowledge时(确认)，
    生产者认为消息"写入成功"；

  • 请求领导者响应(request leader response)，
    但复制replication不能保证，因发生在后台；

  • 若没收到确认ack，生产者可重试该请求；

  • 若leader broker意外离线offline unexpectedly，
    但副本尚未复制数据，我们就会丢失数据；

4.3. acks = all

AckAll

  • acks=all，当消息被所有同步副本(ISR)接受时，生产者认为消息"写入成功"；

  • 分区的主副本(lead replica)会检查check是否有足够的同步副本
    (in-sync replica)来安全写入消息(safely writing msg)
    (由broker setting的min.insync.replicas控制)；

  • 该请求将存储在缓冲区中，直到领导者观察到(leader observe)follower replica
    已复制该消息，此时成功的确认(acknowledgement)将发送回客户端；

  • min.insync.replicas可在主题和broker-level配置，当数据写入
    所有同步副本(min.insync.replicas)时，数据被视为已提交(commit)；

  • 值2意味至少2个ISR broker代理(含leader)必须响应他们拥有的数据；

TopicReplicationIsrMsgSafety

5. Topic Durability Availability

  • 通常，对N的复制因子，主题数据的持久性可承受(withstand)可永久丢失最多
    (permanently lose up to)(N - 1)个broker，但仍然可恢复数据；

  • 对可用性，相对复制，此处采用三个主题复制因子说明：

  • Read读取：只要一个分区已启动并被视为ISR，该主题将可用于读取；

  • Write写入：A：当acks=0 和 acks=1，
    只要一个分区已启动并被视为ISR，该主题就可用于写入；

Replica Memo

B：acks=all

min.insync.replicas=1(默认)

主题必须至少有一个分区作为ISR(含reader)，故可容忍2个broker down

min.insync.replicas=2

主题必须至少有2个ISR启动，故最多可容忍1个broker down关闭
(在复制因子默认3的情况下)，且保证每次写入数据时，数据至少会被写入两次；

min.insync.replicas=3

对相应的复制因子3来说，没太多意义，不能容忍任何broker宕机down

  • 总之当acks=all带有replication.factor=N和
    min.insync.replicates=M时，
    可容忍(N-M)个broker出于主题可用性的目的而宕机；

6. Consumer Replica Fetching

  • 领导者的默认生产者和消费者行为：producer只能向分区的Leader Broker写入数据；
    Consumer将从分区引导器(partition leader broker)中读取分区信息；

DefaultFetching

  • 但从Kafka 2.4后，可将消费者配置为从同步副本(in-sync replica)
    中读取(通常是最接近的 usually closest replica)；

  • 从最接近的同步副本(closest ISR)读取数据可提高请求延迟(improve request latency)，
    还可降低网络成本，因为在大多数云环境中，跨数据中心的网络请求会产生费用；

IsrFetching

7. Preferr Leader

  • preferr leader是在主题创建时为分区指定的leader broker，而非replica；

  • Leader Election：主题创建时决定那个broker时领导的过程；
    称为首选领导者选举(preferred leader election)；

  • 当preferr leader宕机，作为ISR(同步复制副本)的任何分区都有资格称为新的leader，
    但不是preferr leader，在恢复preferr leader broker并使其分区数据恢复同步后，
    preferr leader将重新获得该分区的领导权(regain leadership)；