Redpanda：兼容 Kafka 的流式数据平台

数据库通常回答「当前状态是什么？」，而 Redpanda/Kafka 非常适合回答「发生了什么事件，需要谁来处理？」。Redpanda 是一个兼容 Apache Kafka 的流式数据平台——用 C++ 从零重新设计，更快、更轻量、更易于运维。

历史：从 Vectorized 到 Redpanda#

Redpanda 的故事始于 2019 年，Alex Gallego 创立了 Vectorized 公司。他的经历相当特别：

在 NYU 学习网络安全，之后在 FactSet 工作（在那里学会了 C++），随后成为 YieldMo 的第一位工程师——在那里他对 Apache Storm 在实时处理上的局限感到不满
创立 Concord Systems —— 用 C++ 编写的高性能实时处理应用，2016 年被 Akamai 收购
在 Akamai 期间，他设计了一个性能优于 Kafka 的存储引擎——这正是 Redpanda 的雏形

关键里程碑：

时间	事件
2019	创立 Vectorized
2020	开源并发布产品
2021/01	完成 $1550 万 Seed + A 轮融资（Lightspeed 领投，GV 参投）
2021	公司更名为 Redpanda
2022/02	$5000 万 B 轮融资（GV 领投）
2023/06	$1 亿 C 轮融资（Lightspeed 领投）
2025/03	Kafka 4.0 弃用 ZooKeeper，全面迁移到 KRaft
2025/04	$1 亿 D 轮融资（GV 领投），估值$ 10 亿

[!NOTE] Redpanda 团队的设计理念是「60 seconds to WOW」 —— 从搭建集群到真正处理事件，全程不超过 60 秒，让开发者永远不被运维工作挡住。

Kafka 遗留的问题#

Kafka（2011 年由 LinkedIn 开源）是流式处理的行业标准——但它最初的设计架构也带来了实实在在的成本：

JVM：Kafka 用 Scala/Java 编写、运行在 JVM 上——占用大量内存、有 GC 停顿，还需要大量调优
ZooKeeper：必须单独运维一个 ZooKeeper 集群来管理元数据
尾部延迟：高负载下 p99.999（99.999 百分位）可能恶化到秒级
运维复杂：组件多、配置多，很难针对硬件做优化

Redpanda 看到这些痛点，选择从零重新设计。

架构：彻底的重新设计#

graph TB
    P[Producer / Kafka Client] --> B["Redpanda Broker<br/>(C++ · Seastar · 无 JVM)"]
    B --> S["Partition<br/>(append-only log)"]
    B --> R["Raft Quorum<br/>(替代 ZooKeeper)"]
    S --> C[Consumer / Kafka Client]
    B --> T["Redpanda Console<br/>(管理 UI)"]

基于 Seastar 用 C++ 编写 —— ScyllaDB 的高性能框架，采用 thread-per-core 模型（每个 CPU 核心一个专属线程，核心之间不共享内存）
无 JVM、无 ZooKeeper —— Redpanda 使用 Raft 协议自行管理元数据（leader 选举更快、资源消耗更少）
单一二进制 + rpk CLI —— 安装、配置、运维都比 Kafka 简单得多
兼容 Kafka API —— producer、consumer 以及大部分 Kafka 生态工具都能直接使用，通常只需要改 broker 端点

性能：为什么快 10 倍？#

什么是尾部延迟？（大白话解释）#

假设 p99.999 表示「99.999% 的请求在阈值 X 内完成」。100 个请求时听起来很棒——但如果有 1000 万个请求，仍有 1000 个请求落在最慢的「尾部」。如果这 1000 个请求是价值数百万美元的交易，你能接受吗？这正是尾部延迟决定流式平台质量的原因。

基准测试结果#

Redpanda 公布了与 Kafka 的 p99.999 端到端延迟对比（使用 acks=all，即写入所有副本后才确认）：

工作负载	Kafka p99.999	Redpanda p99.999
10 MB/s（1 万 msg/s）	215 ms	12 ms
40 MB/s（4 万 msg/s）	103 ms	52 ms
50 MB/s（5 万 msg/s）	236 ms	14 ms
75 MB/s（7.5 万 msg/s）	1,801 ms	17 ms
100 MB/s（10 万 msg/s）	1,725 ms	21 ms
200 MB/s（20 万 msg/s）	1,945 ms	27 ms
0.5 GB/s（50 万 msg/s）	3,015 ms	61 ms
1 GB/s（100 万 msg/s）	3,840 ms	174 ms
1.25 GB/s（125 万 msg/s）	3,797 ms	238 ms

在 9 个测试场景中，Redpanda 比 Kafka 快 196% 到 10,847% —— 某个场景下 Kafka 需要 1.8 秒，而 Redpanda 只需 16 毫秒。

[!TIP] 这是 Redpanda 自己发布的基准测试——请带着批判的眼光阅读，并务必在自己真实的工作负载上测试。「10 倍」是他们的说法，不是绝对的真理。

为什么快？#

Thread-per-core + shared-nothing：每个核心一个固定线程——没有锁、没有上下文切换，正是 Seastar 的模型
自管内存而非页面缓存：Redpanda 精确知道每个请求读写多少数据，使用自有的 DMA 对齐缓存，而不是依赖操作系统的 page cache
善用现代 Linux：io_uring（异步 I/O）、O_DIRECT、DPDK（更高效的数据包处理）
内核自动调优：rpk redpanda tune all 和 rpk iotune 会自动对硬件做基准测试并生成优化配置——无需手动摸索
Profile-Guided Optimization（PGO）自 26.1 起：同一硬件上 p999 延迟最多降低 47%，CPU 利用率提升 15%
Write caching自 24.1 起：在可以牺牲部分持久性保证时，延迟最多降低 90%

实际应用场景#

事件流：在服务之间传递事件，例如 OrderCreated、PaymentCompleted、UserLoggedIn
微服务：作为异步通信的「骨干」，减少服务之间的直接耦合
实时分析：收集点击流、日志、指标、交易……并送入近乎实时的分析系统
数据管道：数据库/API 与数据仓库、数据湖、搜索引擎等下游系统之间的中间层
物联网（IoT）：接收海量设备遥测数据并分发给处理系统
CDC（变更数据捕获）：捕获 PostgreSQL/MySQL 的变更并流式传输到其他系统
AI/ML 流式处理：将实时数据送入处理管道或推理系统

凭借低延迟，Redpanda 还被用于算法交易、实时游戏、SIEM 以及对延迟敏感的 IoT 系统。

示例：电商系统#

graph LR
    Order["Order Service"] -->|publish| Topic["topic: orders"]
    Topic --> Payment["Payment Service"]
    Topic --> Inventory["Inventory Service"]
    Topic --> Analytics["Analytics"]
    Analytics --> Lake["Data Lake"]

Order Service 不再直接调用各个服务，而是只发布一个事件：

{
  "order_id": 12345,
  "user_id": 789,
  "total": 599000,
  "status": "created"
}

json

Redpanda 存储并把这个事件分发给多个消费者。Payment、Inventory、Analytics……各自独立处理——即使某个服务变慢，其他服务也不会受影响。

快速开始#

# 用 Docker 运行 Redpanda
docker run -d --name redpanda -p 9092:9092 \
  docker.redpanda.com/redpandadata/redpanda:latest \
  redpanda start

# 用 rpk 创建 topic 并进行生产/消费
rpk topic create orders
rpk topic produce orders
rpk topic consume orders --group my-group

bash

现有 Kafka 代码可以直接使用——只需把 broker 端点指向 Redpanda。

生态系统#

Redpanda Console：管理集群、查看数据管道、无需命令行即可调试的 UI
Schema Registry：事件 Schema 管理（兼容 Confluent）
Tiered storage：自动把旧数据从 NVMe 迁移到更便宜的云对象存储
WASM transforms：直接在 broker 内用 WebAssembly 做实时数据转换
Redpanda Cloud / BYOC：托管版，或者在自己的云环境中部署
兼容 Kafka Connect：可复用现有 connector

该选 Redpanda 还是 Kafka？#

维度	Redpanda	Kafka
尾部延迟	极低（毫秒级）	高负载时更高
占用与运维	轻量、单一二进制、无 ZooKeeper	更重、组件更多
生态系统	兼容 Kafka API	行业标准、最庞大
成熟度	较新（2019 年起）	生产环境 10+ 年
硬件资源	相同负载下占用更少	JVM 需要更多内存

如果你正在运维 Kafka，并且为 ZooKeeper、JVM 调优或尾部延迟所困扰——Redpanda 是值得考虑的「即插即用」替代方案。如果你需要最庞大的生态和最成熟的行业标准，Kafka 依然非常强大。

结论#

Redpanda 证明了 API 兼容并不意味着要继承旧架构。通过在 Seastar 上用 C++ 重写 Kafka API——无 JVM、无 ZooKeeper、thread-per-core——Redpanda 在保持现有 Kafka 应用不变的同时，实现了显著更低的延迟和更简单的运维。