【一图流思维导图】kafka (出现背景/ 核心概念/Kafka的集群架构/优秀架构思考-总结高并发、高可用、高性能/实际应用)

参照 大白话 kafka 架构原理

kafka消息队列

出现背景

解耦合

异步处理

• 秒杀活动

  • 1: 风险控制 、2： 库存锁定 、3： 生成订单 、4： 短信通知 、5： 更新数据

通过消息系统将秒杀活动业务拆分开

将不急需处理的业务放在后面慢慢处理

• 秒杀活动

  • 1： 风险控制 、2： 库存锁定 、3: 消息系统 、4: 生成订单 、5： 短信通知 、6： 更新数据

流量的控制

• 1. 网关在接受到请求后，就把请求放入到消息队列里面
• 2.后端的服务从消息队列里面获取到请求，完成后续的秒杀处理流程。然后再给用户返回结果
• 优点：控制了流量 缺点：会让流程变慢

核心概念

生产者

• Producer 往Kafka集群生成数据

消费者

• Consumer 往Kafka里面去获取数据，处理数据、消费数据 Kafka的数据是由消费者自己去拉去Kafka里面的数据

主题

• topic

分区

• partition 默认一个topic有一个分区（partition），自己可设置多个分区（分区分散存储在服务器不同节点上）

Kafka的集群架构

broker

• 一个kafka服务器就是一个broker

partition

• Topic只是逻辑上的概念，partition在磁盘上就体现为一个目录。

Consumer Group

• 消费组 消费数据的时候，都必须指定一个group id，指定一个组的id假定程序A和程序B指定的group id号一样，那么两个程序就属于同一个消费组。

• 特殊:

  • 同一个消费者成员，只有一个能消费topic
  • 同一个topic,重新指定一个group id号以后，可以消费
  • 不同消费组之间没有影响，消费组需自定义，消费者名称程序自动生成（独一无二）

Controller

• Kafka节点里面的一个主节点，借助zookeeper。

kafka写数据

• 顺序写（追加写）

  • 保证写数据性能

零拷贝机制

• 消费者读取数据流程：

  • 消费者发送请求给kafka服务
  • kafka服务去os cache缓存读取数据（缓存没有就去磁盘读取数据）
  • 从磁盘读取了数据到os cache缓存中
  • os cache复制数据到kafka应用程序中
  • kafka将数据（复制）发送到socket cache中
  • socket cache通过网卡传输给消费者

• linux sendfile技术

  • 1.消费者发送请求给kafka服务
  • 2.kafka服务去os cache缓存读取数据（缓存没有就去磁盘读取数据）
  • 3.从磁盘读取了数据到os cache缓存中
  • 4.os cache直接将数据发送给网卡
  • 5.通过网卡将数据传输给消费者

Kafka日志分段保存

• topic_a

  • 三个分区

    • 服务器1

      • 目录topic_a-0

        • kafka数据就是message

        • 数据存储在log文件里

          • .log结尾的就是日志文件
          • 在kafka中把数据文件就叫做日志文件

        • （分段存储）

          • 一个分区下面默认有n多个日志文件

            • 一个日志文件默认1G

    • 服务器2

      • 目录topic_a-1

    • 服务器3

      • 目录topic_a-2:

Kafka二分查找定位数据

• 一条消息就有两个位置

  • offset：相对偏移量（相对位置）

    • 存在物理磁盘上面，在position Position

  • position：磁盘物理位置

• 稀疏索引

  • kafka每当写入了4k大小的日志（.log），就往index里写入一个记录索引。其中会采用二分查找。

高并发网络设计

• NIO

  • Reactor网络设计模式

Kafka冗余副本保证高可用

• 创建主题时，可以指定分区，也可以指定副本个数

• 副本是有角色的：leader partition

  • 1、写数据、读数据操作都是从leader partition去操作的。
  • 2、会维护一个ISR（in-sync- replica ）列表，但是会根据一定的规则删除ISR列表里面的值

• 生产者发送消息流程

  • 消息首先要写入到leader partition中
  • 写完了以后，还要把消息写入到ISR列表里面的其它分区，写完后才算这个消息提交
  • follower partition：从leader partition同步数据

优秀架构思考-总结

高并发、高可用、高性能

• 高可用：多副本机制

• 高并发：网络架构设计

  • 三层架构：多selector -> 多线程 -> 队列的设计（NIO）

• 高性能：

  • 写数据

    • 把数据先写入到OS Cache
    • 写到磁盘上面是顺序写，性能很高

  • 读数据：

    • 根据稀疏索引，快速定位到要消费的数据
    • 零拷贝机制 减少数据的拷贝 减少了应用程序与操作系统上下文切换

实际应用

coordinator

• 每个consumer group都会选择一个broker作为自己的coordinator

• 他是负责监控这个消费组里的各个消费者的心跳，以及判断是否宕机，然后开启rebalance的

• 运行流程

  • 1）每个consumer都发送JoinGroup请求到Coordinator
  • 2）然后Coordinator从一个consumer group中选择一个consumer作为leader
  • 3）把consumer group情况发送给这个leader
  • 4）接着这个leader会负责制定消费方案
  • 5）通过SyncGroup发给Coordinator
  • 6）接着Coordinator就把消费方案下发给各个consumer
  • 他们会从指定的分区的 leader broker开始进行socket连接以及消费消息

Rebalance

• consumer group靠coordinator实现了Rebalance

• 策略

  • range

    • range策略就是按照partiton的序号范围

      • p0~3 consumer1
      • p4~7 consumer2
      • p8~11 consumer3

  • round-robin

    • 轮询分配

      • consumer1: 0,3,6,9
      • consumer2:1,4,7,10

  • sticky

    • 尽可能保证在rebalance的时候，让原本属于这个consumer 的分区还是属于他们，然后把多余的分区再均匀分配过去，这样尽可能维持原来的分区分配的策略

      • consumer1：0-3 consumer2: 4-7 consumer3: 8-11
      • 假设consumer3挂了
      • consumer1：0-3，+8,9 consumer2: 4-7，+10,11

controller如何管理整个集群

• 1: 竞争controller的 /controller/id
• 2：controller服务监听的目录：/broker/ids/ 用来感知 broker上下线 /broker/topics/ 创建主题，我们当时创建主题命令，提供的参数，ZK地址。
• /admin/reassign_partitions 分区重分配 ……

时间轮机制

延时任务

Broker管理

• LEO

  • 在kafka里面，无论leader partition还是follower partition统一都称作副本（replica）。
  • 每次partition接收到一条消息，都会更新自己的LEO，也就是log end offset，LEO其实就是最新的offset + 1

• HW

  • 高水位 LEO有一个很重要的功能就是更新HW，如果follower和leader的LEO同步了，此时HW就可以更新 HW之前的数据对消费者是可见，消息属于commit状态。HW之后的消息消费者消费不到。

其他

• Kafka的核心原理
  如何去评估一个集群资源
  搭建了一套kafka集群 -》 介绍了简单的一些运维管理的操作。
  生产者（使用，核心的参数）
  消费者（原理，使用的，核心参数）
  broker内部的一些原理

XMind - Trial Version