Kafka可用与可靠机制

文章目录

• kafka的副本机制
• • • ACKS
    • In-Sync Replicas（ISR）
    • Unclean leader election
    • min.insync.replicas
    • acks=1的情况
    • acks=-1的情况
    • acks=-1和min.insync.replicas=2的情况
    • 同步机制
    • • • 1.follower不对外提供服务的原因
        • 2.幂等性的实现

          kafka的副本机制

          假如3分区，3副本的topic数据分布：

          ACKS

          请求完成之前，生产者要求收到的应答数量，可以控制发送数据是否持久化。

          • acks=0：生产者不会等待broker返回确认信息(生产者只要发送完数据即认为已经写入成功)。在这种情况下，无法保证服务器已收到记录，重试配置也不会生效(因为客户端通常不会知道任何故障)。
          • acks=1：此时只会等待leader将数据写入到本地日志后发送确认，不会等待所有follower的确认。在这种情况下，如果leader在确认记录后立即失败(follower还未同步数据)，数据将丢失。
          • acks=all或-1：会等待leader和所有处于ISR集合中的follower发送确认。all和-1相同，唯一区别在于如果需要启用幂等性，则需要设置为all。

            In-Sync Replicas（ISR）

            ISR简单来讲就是与leader保持同步状态的副本的集合。ISR集合里包含leader副本和0到多个follower副本。

            如果一个follower在设定的replica.lag.time.max.ms时间周期内时刻保持与leader的数据更新，则认为该follower是同步的，它将被leader保留在ISR列表中，反之将被从ISR中剔除。

            在下列场景中follower将会被移除ISR列表：

            • 与zookeeper的会话断开(zookeeper.session.timeout.ms)
            • follower未在指定时间内向leader发出fetch操作请求(replica.fetch.wait.max.ms，需要小于lag.time)
            • follower的数据更新时间与leader落后太多(replica.lag.time.max.ms)

              Unclean leader election

              是否允许将新leader切换到数据不同步的follower(故障切换时，unclean.leader.election.enable)

              默认false，不允许将leader切换到不同步的follower。

              min.insync.replicas

              生产者acks设置为all或-1时，指定必须写入成功的最小副本数。如果不能满足最小值，生产者将抛出异常。

              acks=1的情况

              生产者只会等待leader写入就返回。此时如果leader所在节点发生故障

              • 如果副本均在ISR中，只要ISR中有一个follower与leader同步，可以发生故障切换，不会丢数据
              • 如果副本均在ISR中，但follower均落后一点leader，此时如果发生切换，会丢数据。如果不允许切换，会停止服务。只需恢复broker，就不会丢数据

                acks=-1的情况

                生产者会等待leader和所有follower写入才返回。此时如果leader所在节点发生故障

                • 如果副本均在ISR中，可以正常切换，不会丢数据
                • 如果在之前有副本因为落后被踢出ISR集合，导致ISR集合中仅剩leader，此时如果发生切换，会丢数据。如果不允许切换，会停止服务。

                  此时如果副本均在ISR中，但稍微落后leader时，会增加对应的写入延迟。

                  acks=-1和min.insync.replicas=2的情况

                  生产者会等待leader和所有follower写入才返回。此时如果leader所在节点发生故障

                  • 如果副本集合中仅剩leader时，此时写入会直接抛出异常

                    同步机制

                    HighWatermark

                    标识特定的消息偏移量(offset)。

                    • 消费者只能消费到HW所在的位置
                    • 取分区ISR集合中最小的LEO为HW

                      Log End Offset

                      标识当前日志文件中下一条待写入的消息偏移量(offset)。

                      • 每个分区副本都各自有LEO，Leader和follower各自负责更新自己的LEO

                        1.刚开始，此时HW=2

                        leader和follower的LEO=2

                        2.生产者写入消息到leader，此时HW=2

                        leadeLEO=4，follower0和1 LEO=2

                        3.部分数据同步之后，HW=3

                        leader LEO=4，follower0 LEO=3，follower1 LEO=3

                        4.完全同步之后，HW=4

                        leader LEO=4，follower0 LEO=4，follower1 LEO=4

                        1.follower不对外提供服务的原因

                        由于副本同步不是完全同步的，ISR集合也随时在变化。

                        • 可能出现follower还没有从leader处拉取到最新消息，此时如果follower对外提供服务，客户端会看不到最新写入的消息。
                        • 也可能出现多个follower的数据不同步，此时如果多次消费看到的数据会产生不一致性。

                          2.幂等性的实现

                          引入PID(ProducerID)和SequenceNumber来避免消息重复发送