分布式基础概念-消息中间件[Kafka]

2023-12-13 09:54:17 浏览数 (1)

Kafka架构设计

Consumer Group：消费者组，消费者组内每个消费者负责消费不同分区的数据，提高消费能力。逻辑上的一个订阅者。

Topic：可以理解为一个队列，Topic 将消息分类，生产者和消费者面向的是同一个 Topic。

Partition：为了实现扩展性，提高并发能力，一个Topic 以多个Partition的方式分布到多个 Broker上，每个 Partition 是一个 有序的队列。一个 Topic 的每个Partition都有若干个副本（Replica），一个Leader 和若干个Follower。生产者发送数据的对象，以及消费者消费数据的对象，都是 Leader。Follower负责实时从 Leader 中同步数据，保持和 Leader 数据的同步。Leader 发生故障时，某个Follower 还会成为新的 Leader

Zookeeper：Kafka 集群能够正常工作，需要依赖于 Zookeeper，Zookeeper 帮助 Kafka 存储和管理 集群信息。

如图所示：

image.png

Kafka高性能高吞吐的原因

  1. 磁盘顺序读写：保证了消息的堆积
    1. 顺序读写，磁盘会预读，预读即在读取的起始地址连续读取多个页面，主要时间花费在了传输时间，而这个时间两种读写可以认为是一样的。
    2. 随机读写，因为数据没有在一起，将预读浪费掉了。需要多次寻道和旋转延迟。而这个时间可能是传输时间的许多倍。
  2. 零拷贝：避免 CPU 将数据从一块存储拷贝到另外一块存储的技术
    1. 读取磁盘文件数据到内核缓冲区
    2. 将内核缓冲区的数据copy到用户缓冲区
    3. 将用户缓冲区的数据copy到socket的发送缓冲区
    4. 将socket发送缓冲区中的数据发送到网卡、进行传输
    5. 传统的数据复制：
    6. 零拷贝：磁盘文件->内核空间读取缓冲区->网卡接口->消费者进程
  3. 分区分段 索引

Kafka的message消息实际上是分布式存储在一个一个小的segment中的，每次文件操作也是直接操作的segment。为了进一步的查询优化，Kafka又默认为分段后的数据文件建立了索引文件，就是文件系统上的.index文件。这种分区分段 索引的设计，不仅提升了数据读取的效率，同时也提高了数据操作的并行度

  1. 批量压缩：多条消息一起压缩，降低带宽
  2. 批量读写
  3. 直接操作page cache，而不是JVM、避免GC耗时及对象创建耗时，且读写速度更高，进程重启、缓存也不会丢失

Kafka的副本同步机制

如图：

  • LEO：下一条待写入位置
  • firstUnstableOffset：第一条未提交数据
  • LastStableOffset：最后一条已提交数据
  • LogStartOffset：起始位置
  • isolation.level=read_committed：只能消费到LastStableOffset，read_committed可以消费到HW的上一条

一个partition对应的ISR中最小的LEO作为分区的HW，consumer最多只能消费到HW所在的位置leader收消息后会更新本地的LEO，leader还会维护follower的LEO即remote LEO，follower发出fetch同步数据请求时(携带自身的LEO)、leader会更新remote LEO，更新分区的HW，然后将数据响应给follower、follower更新自身HW(取响应中的HW和自身的LEO中的较小值)，LEO 1

  • ISR：如果一个follower落后leader不超过某个时间阈值，那么则则ISR中，否则将放在OSR中。

同步副本时，follower获取leader的LEO和LogStartOffset，与本地对比、如果本地的LogStartOffset超出了leader的值，则超过这个值的数据删除，再进行同步，如果本地的小于leader的、则直接同步

Kafka消息高可靠解决方案

消息发送：

  • ack：0、不重试，1、lead写入成功就返回了，all/-1、等待ISR同步完再返回
  • unclean.leader.election.enable : false，禁止选举ISR以外的follower为leader
  • tries > 1，重试次数
  • min.insync.replicas > 1：同步副本数，没满足该值前、不提供读写服务、写操作会异常

消费：

  • 手工提交offset
  • broker：减小刷盘间隔
  • 事务消息

Kafka的rebalance机制

consumer group中的消费者与topic下的partion重新匹配的过程何时会产生rebalance：

  • consumer group中的成员个数发生变化
  • consumer消费超时
  • group订阅的topic个数发生变化
  • group订阅的topic的分区数发生变化

coordinator：通常是partition的leader节点所在的broker，负责监控group中consumer的存活，consumer维持到coordinator的心跳，判断consumer的消费超时

  • coordinator通过心跳返回通知consumer进行rebalance
  • consumer请求coordinator加入组，coordinator选举产生leader consumer
  • leader consumer从coordinator获取所有的consumer，发送syncGroup(分配信息)给到coordinator
  • coordinator通过心跳机制将syncGroup下发给consumer
  • 完成rebalance

leader consumer监控topic的变化，通知coordinator触发rebalance

如果C1消费消息超时，触发rebalance，重新分配后、该消息会被其他消费者消费，此时C1消费完成提交offset、导致错误

解决：coordinator每次rebalance，会标记一个Generation给到consumer，每次rebalance该Generation会 1，consumer提交offset时，coordinator会比对Generation，不一致则拒绝提交

历史相关精彩内容

  • 直击灵魂的面试之MQ七连问

如有问题，欢迎加微信交流：w714771310，备注- 技术交流 。或关注微信公众号【码上遇见你】。

分布式 kafka 基础 数据 消息中间件

0 人点赞