数据流演进之路(从Kafka到Pulsar)| 青训营笔记

102 阅读2分钟

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

消息队列

应用场景

MQ消息通道

image.png

EventBridge事件总线

image.png

Data Platform 流数据平台

image.png

主流消息队列的横向对比

image.png

Kafka详解

架构

image.png

Zookeeper

image.png

Broker

image.png

Controller选举(比较特殊的broker)

image.png

Coordinator

image.png

高可用(多副本)

  • 副本同步机制 image.png

    • 提供lsr副本复制机制,提供热备功能

    (注:ISR:in sync replica,一直在同步数据的副本)

    • 写入端提供ack=0,-1,1机制,控制副本同步强弱
    • 1:leader副本写入成功,producer即认为写成功
    • 0:producer发送后即为成功
    • -1:ISR中所有副本都成功,producer才认为写成功
  • 副本切换机制

    • 提供clean\unclean副本选举机制 都优先选取lsr中的副本作为leader,若找不到:

clean:partition不可用

unclean:选取其他存活副本

Q:kafka如何保证消息不丢?

  • 3副本情况下,结合ISR和ack配置 min.insync.replica = 2 , ack = -1
  • 5副本同理

集群扩缩容

  • 目标:分布均匀(partiton在各个broker之间的分布、broker之间replica的数量分布)

image.png

  • 扩容步骤 image.png
  • 缩容步骤

image.png

  • 扩缩容存在的问题

    耗时长、期间集群不稳定且无法进行其他运维操作

未来发展趋势

去除zookeeper依赖

为什么?

  • 元数据存取耗时、更新网络开销大
  • 违背高内聚、低耦合原则(zk易宕机,难维护,且耦合性差)
  • zk无法兼顾broker之间的通信状态,导致网络分区复杂度高
  • 并发访问zk问题多

依赖KRaft

Process.Roles等于什么就是什么(broker,controller等),为null时默认zookeeper模式。

关于运维/调优

单机吞吐

image.png

集群参数配置

image.png

pulsar详解

架构

image.png

pulsar proxy

Pulsar客户端连接集群方式

Pulsar client->Broker/Proxy

作用

Proxy提供类似GateWay代理能力,解耦客户端和Broker,保障Broker安全

pulsar broker

image.png

pulsar storage

segment在不同存储中有不同抽象

image.png

image.png

pulsar IO 连接器

个人认为可理解为一个接口

pulsar function

一个轻量级计算框架

Bookeeper

架构

image.png

概念

image.png

读一致性、写一致性与读写优化

image.png image.png

image.png

BK with pulsar

partiton和broker之间只是映射关系,broker在扩缩容过程中只需要更改映射即可

Pulsar 功能介绍

生产模式

image.png

消费模式

image.png

多租户

体现在uri中

插件

image.png

生态

image.png