Improvements Made in KoP 2.9.0 - Pulsar Summit Asia 2021

Kafka 迁移 Pulsar 利器
详解 KoP 新进展

关于我
• Github Handle: https://github.com/BewareMyPower

• StreamNative software engineer

• Apache Pulsar committer

• Apache BookKeeper, Pulsar Go Client contributor

• KoP core maintainer

Agenda
1. 为什么需要 KoP

2. KoP 的基本设计

3. KoP 2.9 最新进展

4. 总结和展望

Kafka & Pulsar
为什么需要 KoP
Producer
Producer
Producer
Broker
从 MQ ⽤户的⻆度看，它们是类似的。
Topic-A
Topic-B …
Consumer
Consumer
Consumer
Partition-0
Partition-1
Partition-2
…

Kafka vs. Pulsar 存储层
Client
Leader
 
Broker
Follower
 
Broker
FETCH
PRODUCE
Kafka
Follower
 
Broker
FETCH
Client
SEND
Broker
Broker Broker
Bookie
Bookie Bookie
Pulsar
• 计算层（Broker）和存储层（Bookie）分离。

• Broker 与 Broker 是对等的，Bookie 与 Bookie 是对等的。

• 强⼀致，读写分离，扩缩容简单……

ADD_ENTRY
ADD_ENTRY
ADD_ENTRY
为什么需要 KoP

需求：从 Kafka 迁移到 Pulsar
⽅法 1：推动⽤户更换客户端

• 需要⽤户重新编写代码

• 当前 Pulsar ⽣态与 Kafka 存在⼀定差距
⽅法 2：使⽤ Pulsar Adaptor for Apache Kafka

优点：⽤户⽆需修改现有代码，只需替换 JAR 包

缺点：

• 只适⽤于 Java 客户端

• 对 Kafka Offset 的处理存在缺陷

• ⽤户仍然需要学习⼀些 Pulsar 客户端的配置
⽅法 3：使⽤ KoP（Kafka-on-Pulsar）

• ⽤户⽆需修改现有 Kafka 应⽤的代码

• 兼容绝⼤多数 Kafka ⽣态

• 直接访问 Pulsar Broker 的资源
为什么需要 KoP

如何启⽤ KoP？
1. 从 https://github.com/streamnative/kop/releases 下载 NAR 包或者⾃⾏
编译。

2. 进⼊ Pulsar 安装⽬录，新建 protocols ⽬录，将 NAR 包放⼊该⽬录。

3. 在 broker.conf 或者 standalone.conf 中进⾏配置并启动 broker。
版本选择：

• KoP x.y.z.m 兼容 Pulsar x.y.z，⽐如 KoP 2.9.1.2 兼容 Pulsar 2.9.1

• KoP master 分⽀不保证与现有的稳定 Pulsar release 兼容

• KoP branch-x.y.z 分⽀保证与 Pulsar x.y.z 兼容

• 不建议使⽤低于 2.8 版本的 KoP，若 Pulsar 版本低于 2.8，优先考虑升级 Pulsar

KoP 的基本设计
Pulsar 2.5 引⼊了 Protocol Handler，本质上是⼀个 NAR 包。

Broker 在启动时会根据配置加载对应的 Protocol Handler。
Protocol Handler
• initialize：初始化配置

• start：共享 BrokerService 对象（掌控⼀切 Broker 资源）

• newChannelInitializers：在指定端⼝启动服务。

• getProtocolDataToAdvertised：发布到 ZK 的元数据。

KoP 的基本设计
Topic 和 Partition 的映射
Kafka Pulsar
persistent://public/default/my-topic-
partition-0
• Whether to persist the message
• Tenant/Namespace
• Short topic name
• Partition suffix
KoP 通过配置来兼容短 topic 名，同时⽀持直接访问其他 namespace。

以下为默认配置：

# 默认短 topic 所在租户和命名空间
kafkaTenant=public
kafkaNamespace=default

KoP 的基本设计
认证（Authentication）
Kafka
Client KoP
SASL_HANDSHAKE
Kafka
Client KoP
SASL_AUTHENTICATE
需要在 Pulsar 端开启认证的基础上加上配置

saslAllowedMechanisms=<mechanism>
其中 mechanism ⽀持：

1. PLAIN：基于 JWT 的认证

2. OAUTHBEARER：基于第三⽅ Oauth 2 服务的认证

细节详⻅：https://github.com/streamnative/kop/blob/master/docs/security.md
1. 验证请求中的 mechanism 是否⽀持。

2. 根据 mechanism 创建对应的 SaslServer
使⽤创建的 SaslServer 验证请求中的 token

KoP 的基本设计
Kafka Offset vs. Pulsar Message ID
Kafka Offset 是⼀个 64 位整型，表示消息存储的位置。
Segment Offset 0 Offset 1 Offset 2 …
Pulsar：

• Segment ⼜称为 Ledger，可以分布于多个 bookie 节点。

• 基本存储单位是 Entry，对应⼀个 batched message。

• 单个 batch 的每个 single message 即 Kafka Offset 对应的 message。
Offset Ledger id
8 字节 8 字节
Entry id
8 字节
Batch

Index
4 字节
Kafka

KoP 的基本设计
Kafka Offset 的实现：基于 Broker Entry Metadata
Broker
Bookie
Broker Entry
Metadata
Message
Metadata
Payload
Raw Message
Pulsar
Client
KoP 是 Broker 的⼀部分，因此能直接访问到 Index 信息，⽤于：

• FETCH 请求：⼆分查找找到 Offset 对应的消息，创建 non-durable cursor。

• PRODUCE 请求：解析出 Index，作为 Offset 返回给 Kafka 客户端。

• LIST_OFFSET 请求：

1. Latest：读取 Interceptor 中最新的 Index 并加 1（Log End Offset）

2. Earliest or Timestamp：⼆分查找找到 Offset 对应的消息，解析 Index

• COMMIT_OFFSET 请求：仅仅将 Offset 信息写⼊ Offset topic。（2.8.0 开始）

KoP 的基本设计
Group Coordinator 实现整体移植⾃ Kafka 的实现，除了：

• 使⽤ Pulsar Producer 和 Consumer 读写 offset topic。

• 使⽤ Namespace Bundle Listener 替代 Leader ISR 变更事件。
• 每台 broker 都拥有（own）⼀些 bundle range

• Topic 会按名字哈希到其中⼀个 bundle range，它的 owner 就是 topic 的
owner broker

• Bundle 可能分裂，broker 也有可能宕机，因此 ownership 会发⽣变化
KoP 的 offset topic 会存放在单独的命名空间。

以下为默认配置：

# 默认短 topic 所在租户和命名空间
kafkaMetadataTenant=public
kafkaMetadataNamespace=__kafka

KoP 的基本设计
针对特定场景的性能优化
KoP 默认⽀持：

• Kafka 客户端和 Pulsar 客户端访问同⼀个 topic

• Kafka Consumer 的 group id 和 Pulsar Consumer 的 subscription name 独⽴。

实现⽅式：

• ⽣产时需要将 Kafka 格式的消息转换成 Pulsar 格式

• 消费时需要将 Pulsar 格式的消息转换成 Kafka 格式

代价：

• 吞吐受到格式转换的影响，吞吐上限仅能达到 50 到 70 MB/s。

KoP 的基本设计
针对特定场景的性能优化
加上配置

entryFormat=kafka
实现⽅式：

• ⽣产时将消息直接写⼊ BK

• 消费时跳过 Metadata 部分，直接返回给客户端。

优点：

• 吞吐接近 Pulsar 客户端，可以增加磁盘来扩展吞吐。

代价：

• 不⽀持 Kafka 客户端和 Pulsar 客户端共同访问⼀个 topic KoP 2.8.0.1，100 分区，2 ⽣产者，2 消费者，磁盘吞吐 800MB/s

KoP 2.9 新特性概览
同时适⽤于 2.8.x.y 的新特性：

• ⽀持 Authorization

• 基于租户的 Group Coordinator

• ⽀持多个 listener（*）

• Kafka format 下⽀持 Kafka 客户端消费 Pulsar 客户端⽣产的消息

• ⽀持 0.9，0.10 和 0.11 版本 Kafka 客户端

仅适⽤于 2.9.x.y 的新特性：

• ⽀持多个 listener

• Kafka format 下⽀持 Kafka 客户端和 Pulsar 客户端的交互

鉴权（Authorization）
KoP 2.9 新特性
只实现认证的缺陷：⼀旦客户端通过了认证，那么它就拥有了所有的权限，⽆法精细控制。

在 Pulsar 中，更糟糕的是，客户端拥有了访问其他命名空间下 topic 的权限，使得 Pulsar 配置的认证体系形同虚设。
Kafka 的鉴权更加精细，对于认证得到的 authorization ID，由 ACL 操作和资源类型共同来决定权限。

• ACL 操作：READ，WRITE，CREATE，DELETE……

• 资源类型：TOPIC，GROUP，CLUSTER……

Pulsar 则仅由认证得到的 role 来决定它具有哪些权限。（可以⽤ REST API 来配置）

• 权限：canProduce，canConsume，allowTopicOperation……
Kafka
Client KoP
1. 经过完整的认证流程
2. SaslServer ⽣成 authorization ID（对应 Pulsar 的 role）

鉴权（Authorization）
KoP 2.9 新特性
请求类型 ACL 操作资源类型 Pulsar 权限处理
FETCH,
OFFSET_COMMIT
READ TOPIC canConsume
PRODUCE WRITE TOPIC canProduce
METADATA,
LIST_OFFSET,
OFFSET_FETCH
DESCRIBE TOPIC canLookup
CREATE_TOPICS,
DELETE_TOPICS,
CREATE_PARTITIONS
CREATE, DELETE,
ALTER
TOPIC
allowNamespaceOperatio
n
⽤户需要使⽤ pulsar-admin 来在 Pulsar 端为 topic 授予权限。
Kafka 请求的 ACL 操作和资源类型和 Kafka 实现⼀致，其对应的 Pulsar 鉴权处理如下（只列举部分）：

基于租户的 Group Coordinator
KoP 2.9 新特性
KoP 基于 Pulsar 的租户管理实现了 topic 之间的资源隔离，但是所有的 Kafka topics 都写往同⼀个 offset topic。
Consumer B
Tenant-B/NS-B/topic
Consumer A
Tenant-A/NS-A/topic
public/__kafka/consumer_offsets
OFFSET_COMMIT
OFFSET_COMMIT
KoP 禁⽌来客户端往 offset topic 进⾏写⼊，仅能通过 KoP ⾃身，因此跳过了权限控制。

基于租户的 Group Coordinator：懒加载
KoP 2.9 新特性
Consumer B
Tenant-B/NS-B/topic
Consumer A
Tenant-A/NS-A/topic
Tenant-A/__kafka/consumer_offsets
Tenant-B/__kafka/consumer_offsets
OFFSET_COMMIT
OFFSET_COMMIT
理想实现：在调⽤ Group Coordinator 时根据 tenant 动态创建每个 tenant 对应的 Group Coordinator。

基于租户的 Group Coordinator：懒加载
KoP 2.9 新特性
处理⽅式：

• 不开启认证：仍然使⽤ kafkaMetadataTenant 作为租户名，⾏为和之前⼀样。

• 开启认证（PLAIN mechanism）：

1. 将 username 视为为 tenant 或者 tenant/namespace，取得其中的 tenant。

2. 验证 tenant 是否存在。
实际情况：Group Coordinator 还会处理 JOIN_GROUP 和 SYNC_GROUP 请求，这些请求不携带 topic 信息。
Consumer A
Tenant-A/NS-A/topic
org.apache.kafka.common.security.plain.PlainLoginModule
required username=”Tenant-A" password="token:xxx";
KoP
org.apache.kafka.common.security.plain.PlainLoginModule
required username=”Tenant-A/NS-A" password="token:xxx";
Authenticate

多 listener（Kafka 的实现）
KoP 2.9 新特性
当 Kafka 部署在容器化环境中，往往⾄少需要⼀个内⽹ listener 和外⽹的 listener：

• 内部流量直接访问 Kafka

• 外部流量可以通过 proxy 或者 load balancer

Kafka 在 KIP-103 实现了内部和外部流量的分离，其示例配置如下：
listener.security.protocol.map=REPLICATION:PLAINTEXT,INTERNAL_PLAINTEXT:PLAINTEXT, INTERNAL_SASL:SASL_PLAINTEXT
advertised.listeners= REPLICATION://broker1.replication.local:9093 ,INTERNAL_PLAINTEXT://
broker1.local:9094,INTERNAL_SASL://broker1.local:9095
listeners=REPLICATION://10.1.1.5:9093,INTERNAL_PLAINTEXT://10.1.1.5:9094,INTERNAL_SASL://10.1.1.5:9095

多 listener（KoP 2.8 的临时解决⽅案）
KoP 2.9 新特性
Pulsar 2.8 以及之前，要实现多个 listener 的 lookup，必须显式配置 listener name。

Broker 端未提供对 Protocol Handler 发布的元数据的查找 API，因此KoP 必须复⽤ Pulsar 的 advertisedListeners 配置。
kafkaListeners=kafka_internal://localhost:9092,kafka_external://localhost:9093
kafkaProtocolMap=kafka_internal:PLAINTEXT,kafka_external:PLAINTEXT
advertisedListeners=pulsar://pulsar://localhost:6650,kafka_internal://pulsar://
localhost:9092,kafka_external://pulsar://localhost:9093
瑕疵：

1. 需要复⽤ advertisedListeners。

2. 配置怪异。

多 listener（KoP 2.9 的实现）
KoP 2.9 新特性
Pulsar 2.9 的较⼤改动：

1. 得益于 PIP-95 Smart Listener，Pulsar 实现多 listener 的 lookup ⽆需显式配置 listener name。

2. Broker 端暴露了接⼝可以访问 Protocol Handler 写⼊的元数据。

3. Broker 发布到 ZK 的 listener 数据格式和校验⽅式发⽣了变化。
kafkaAdvertisedListeners=kafka_internal://localhost:9092,kafka_external://localhost:9093
advertisedListeners=pulsar://pulsar://localhost:6650,kafka_internal://pulsar://
localhost:9092,kafka_external://pulsar://localhost:9093
KoP 2.9：
KoP 2.8：

Kafka format 下 Pulsar ⽣产，Kafka 消费
KoP 2.9 新特性
entryFormat=kafka
实现⽅式：

• ⽣产时将消息直接写⼊ BK（实际上仍然添加了 Pulsar Message Metadata，其包含属性 entry.format=kafka）

• 消费时跳过 Metadata 部分，直接返回给客户端。
解决⽅案：

在解码时，根据 Metadata 部分进⾏处理：

1. 若包含 entry.format 属性且其值为 kafka，则直接返回消息给客户端。

2. 否则将 payload 部分视为 Pulsar 格式，进⾏消息格式转换。

Kafka format 下 Kafka ⽣产，Pulsar 消费（2.9 独有）
KoP 2.9 新特性
entryFormat=kafka
本质问题：Pulsar 客户端需要⽀持消费⾮标准格式的数据。
PIP-96 ⽀持了为 Pulsar 客户端（Java）配置
MessagePayloadProcessor，⼀旦配置，则使⽤它来处理接
收到的原始数据。

由于该接⼝需要在 pulsar-client-api 包进⾏定义，为了避免引⼊
额外依赖，使⽤了 MessagePayload 和
MessagePayloadContext 对 payload 和元数据进⾏了抽象。把 payload 视为 batch，处理 batch 的单条消息（下标为 i）
把 payload 视为消息本身

KoP 2.9 新特性
entryFormat=kafka
KoP 实现了 KafkaPayloadProcessor，⽀持 Pulsar Consumer 消费 Kafka 格式的消息。

⽤户需要：

1. 导⼊ kafka-payload-processor 包的依赖。

2. 修改创建 consumer 的代码，配置 KafkaPayloadProcessor。
注：⽬前 release CI 存在问题，2.9.1.2 版本是⼿动本地 Maven 构建。在将来版本可以直接从 Maven 仓库下载。

KoP 2.9 新特性
缺陷：只⽀持 Java 客户端，且需要修改代码。

Q1：为什么不直接在 Broker 端进⾏转码？

A1：Broker 端负责分发消息的 dispatcher 是共⽤⼀个线程处理，若转码⽐较耗时，会影响整个集群。

Q2：既然默认 entry format 已经⽀持 Pulsar 客户端和 Kafka 客户端交互，为什么还要费⼒实现 Kafka format 下两者的交互？

A2：KoP 定位更多是过渡阶段的产品。若后期业务从 Kafka 客户端迁移到 Pulsar 客户端，那么必须具备消费旧数据的能⼒。
entryFormat
Kafka Producer
 
Kafka Consumer
Kafka Producer
 
Pulsar Consumer
Pulsar Producer
 
Kafka Consumer
pulsar
⽣产：转码（KoP 端） 
消费：转码（KoP 端）
⽣产：转码（KoP 端）
消费：转码（KoP 端）
kafka ⽆转码
消费：转码（Client
端）

多版本 Kafka 客户端测试框架
KoP 2.9 新特性
KoP 依赖于 kafka-clients 2.0，由于 Maven 不能依赖同⼀个 artifact 的多版本，导致单测只能覆盖 Kafka 2.0 客户端。

过去的多客户端测试是基于 Docker 的，在容器中运⾏⼀个其他版本或者其他语⾔的 Kafka 客户端连接。

问题：

• 测试过于简陋，仅覆盖很基本的⽣产消费

• 维护成本⾼，不⽅便在 IDE 中进⾏调试

• 不同环境下容器访问宿主机⽹络的 IP 存在差异

• 更新 Docker 镜像耗时且麻烦

KoP 2.9 新特性
Maven Shaded Plugin：

• ⽀持将依赖整个包含到⼀个 uber JAR 中。

• ⽀持对依赖的 package 进⾏重命名。

KoP 2.9 新特性
基于该框架，KoP 引⼊了多版本 Kafka 客户端的依赖并加⼊单测。

在此基础上，兼容了 Kafka 0.9，0.10 和 0.11 客户端。（在此之前仅⽀持 1.0 以上客户端）
模块：

• kafka-client-api：提供⼀层公共的 Producer 和 Consumer 接⼝的抽象

• kafka-0-9：依赖 Kafka 0.9.0.0 客户端的实现

• kafka-1-0：依赖 Kafka 1.0.0 客户端的实现



• kafka-client-factory：基于 Kafka 版本动态创建不同依赖的 Producer 和 Consumer 实现
KoP 对 Kafka 协议的⽀持以官⽅ Java 客户端的⾏为为准，少量⾮官⽅客户端（⽐如 Golang Sarama）在早期版本对 Kafka
协议的实现不正确，需要配置 entryFormat=mixed_kafka 来代替 entryFormat=kafka。

其他新特性和重要 bug 修复
KoP 2.9 新特性
其他新特性

• ⽀持 non-partitioned topic

• 基于列出全量 topic 仅限定在指定命名空间内部

• ⽀持 KoP 从旧版本（低于 2.8）升级到 2.8 以上时跳过旧数据

• ⽀持 FETCH 请求的最⼩字节数量（minBytes）和最⼤等待时间
（maxWaitMs）

• ……
重要 BUG 修复和优化

• 修复同⼀个 topic 多个 group 订阅时⼤量创建 non-durable cursor 的问题

• 修复⼤量创建 MetadataCache 实例的问题

• 修复 Pulsar IO 线程在特定条件下会永远卡死的问题

• 修复默认 format 下内存暴涨导致整个集群频繁 GC 的问题

• 优化启动流程，避免 K8s 环境下 KoP 启动可能依赖其他节点的问题

• ……

总结和展望
总结：

• 2021 年 6 ⽉ 18 ⽇，KoP 2.8.0.1 发布，成为第⼀个 GA（Generally Available for production）版本。

• 2021 年 12 ⽉ 29 ⽇，KoP 2.9.1.1 发布，期间超过 10 个贡献者总共贡献了超过 160 个 PR，包括新特性，bug 修复和⽂档。

• 社区有不少⽤户对 KoP 进⾏压⼒测试和性能测试，进⾏了相应的反馈。

下⼀步⼯作计划：

• 稳定性测试，主动模拟经历各种异常场景 KoP 能否稳定运⾏。

• 性能测试，⽐较 2.9 有没有引⼊导致性能倒退的修改。

• 完善 Transaction 的实现。

• 规范引⼊新 feature 的流程。

贡献者 GitHub Handle（字⺟序）

• BewareMyPower

• Demogorgon314

• EronWright

• Huanli-Meng

• aloyszhang

• eolivelli

• gaoran10

• lordcheng10

• timmyyuan

• wangjialing218

• wenbingshen

• wuzhanpeng

Improvements Made in KoP 2.9.0 - Pulsar Summit Asia 2021

More Related Content

What's hot (20)

More from StreamNative (20)

Improvements Made in KoP 2.9.0 - Pulsar Summit Asia 2021