Redpanda: Nền tảng streaming dữ liệu tương thích Kafka

Database thường trả lời câu hỏi “trạng thái hiện tại là gì?”, còn Redpanda/Kafka rất phù hợp để trả lời “những sự kiện gì đã xảy ra và cần được xử lý bởi ai?”. Redpanda là nền tảng streaming dữ liệu tương thích với Apache Kafka — được thiết kế lại từ đầu bằng C++ để nhanh hơn, nhẹ hơn và dễ vận hành hơn.

Lịch sử: Từ Vectorized đến Redpanda#

Câu chuyện của Redpanda bắt đầu từ năm 2019, khi Alex Gallego thành lập công ty Vectorized. Hành trình của anh khá đặc biệt:

Học cybersecurity tại NYU, sau đó làm việc tại FactSet (nơi anh học C++), rồi trở thành kỹ sư đầu tiên của YieldMo — nơi anh bực bội với giới hạn của Apache Storm trong xử lý real-time
Thành lập Concord Systems — ứng dụng xử lý real-time hiệu năng cao viết bằng C++, được Akamai mua lại năm 2016
Tại Akamai, anh thiết kế storage engine cải thiện hiệu năng so với Kafka — nền móng cho Redpanda sau này

Các mốc quan trọng:

Thời điểm	Sự kiện
2019	Thành lập công ty Vectorized
2020	Công bố mã nguồn, giới thiệu sản phẩm
01/2021	Gọi vốn $15.5M Seed + Series A (Lightspeed dẫn đầu, GV tham gia)
2021	Đổi tên công ty thành Redpanda
02/2022	$50M Series B (GV dẫn đầu)
06/2023	$100M Series C (Lightspeed dẫn đầu)
03/2025	Kafka 4.0 bỏ ZooKeeper, chuyển hoàn toàn sang KRaft
04/2025	$100M Series D (GV dẫn đầu), định giá$ 1 tỷ

[!NOTE] Triết lý thiết kế của đội ngũ Redpanda là “60 seconds to WOW” — mọi thứ từ lúc dựng cluster đến khi xử lý event thật không quá 60 giây, để developer không bị cản trở bởi công việc vận hành.

Vấn đề mà Kafka để lại#

Kafka (LinkedIn mở nguồn năm 2011) là chuẩn công nghiệp cho streaming — nhưng kiến trúc gốc của nó mang theo chi phí:

JVM: Kafka viết bằng Scala/Java chạy trên JVM — tốn RAM, có GC pause, và cần tuning nhiều tham số
ZooKeeper: phải vận hành một cluster ZooKeeper riêng để quản lý metadata
Tail latency: p99.999 (99.999% request nhanh nhất) có thể tụt xuống hàng giây khi tải cao
Vận hành phức tạp: nhiều thành phần, nhiều config, khó tối ưu cho phần cứng

Redpanda nhìn vào những điểm đó và thiết kế lại từ đầu.

Kiến trúc: Thiết kế lại từ đầu#

graph TB
    P[Producer / Kafka Client] --> B["Redpanda Broker<br/>(C++ · Seastar · không JVM)"]
    B --> S["Partition<br/>(append-only log)"]
    B --> R["Raft Quorum<br/>(thay thế ZooKeeper)"]
    S --> C[Consumer / Kafka Client]
    B --> T["Redpanda Console<br/>(UI quản lý)"]

Viết bằng C++ trên Seastar — framework hiệu năng cao của ScyllaDB, dùng mô hình thread-per-core (mỗi core CPU một thread riêng, không dùng chung memory giữa các core)
Không JVM, không ZooKeeper — Redpanda tự quản lý metadata bằng giao thức Raft (leader election nhanh, ít tài nguyên hơn)
Single binary + CLI rpk — cài đặt, cấu hình, vận hành đều gọn hơn nhiều so với Kafka
Kafka API compatible — producer, consumer và phần lớn hệ sinh thái Kafka dùng được nguyên vẹn, thường chỉ cần đổi endpoint broker

Hiệu năng: Vì sao nhanh hơn 10x?#

Tail latency là gì? (ELI5)#

Tưởng tượng p99.999 nghĩa là “99.999% request hoàn thành dưới ngưỡng X”. Với 100 request thì nghe rất tốt — nhưng với 10 triệu request, vẫn có 1.000 request nằm ở phần “đuôi” chậm nhất. Nếu 1.000 request đó là lệnh giao dịch trị giá hàng triệu đô, bạn có chấp nhận không? Đó chính là lý do tail latency quyết định chất lượng streaming platform.

Kết quả benchmark#

Redpanda công bố bài test so sánh latency p99.999 end-to-end với Kafka, dùng acks=all (ghi vào tất cả replica trước khi xác nhận):

Workload	Kafka p99.999	Redpanda p99.999
10 MB/s (10K msg/s)	215 ms	12 ms
40 MB/s (40K msg/s)	103 ms	52 ms
50 MB/s (50K msg/s)	236 ms	14 ms
75 MB/s (75K msg/s)	1.801 ms	17 ms
100 MB/s (100K msg/s)	1.725 ms	21 ms
200 MB/s (200K msg/s)	1.945 ms	27 ms
0,5 GB/s (500K msg/s)	3.015 ms	61 ms
1 GB/s (1M msg/s)	3.840 ms	174 ms
1,25 GB/s (1,25M msg/s)	3.797 ms	238 ms

Trong 9 kịch bản test, Redpanda nhanh hơn Kafka từ 196% đến 10.847% — có kịch bản Kafka mất 1,8 giây, Redpanda chỉ 16 mili giây.

[!TIP] Đây là benchmark do chính Redpanda công bố — nên đọc với tinh thần phản biện và luôn tự test trên workload của bạn. Con số “10x” là khẳng định của họ, không phải sự thật tuyệt đối.

Vì sao nhanh?#

Thread-per-core + shared-nothing: mỗi core một thread ghim cố định, không lock, không context switch — đúng mô hình của Seastar
Tự quản lý bộ nhớ thay vì page cache: Redpanda biết chính xác lượng dữ liệu đọc/ghi cho từng request, dùng cache riêng DMA-aligned thay vì phụ thuộc page cache của OS
Tận dụng Linux hiện đại: io_uring (I/O bất đồng bộ), O_DIRECT, DPDK (xử lý packet hiệu quả hơn)
Tự động tuning kernel: rpk redpanda tune all và rpk iotune tự benchmark phần cứng và sinh config tối ưu — không cần tự mày mò
Profile-Guided Optimization (PGO) từ bản 26.1: giảm tới 47% latency p999 và 15% CPU trên cùng phần cứng
Write caching từ bản 24.1: giảm tới 90% latency khi chấp nhận đánh đổi độ bền dữ liệu

Ứng dụng thực tế#

Event streaming: truyền sự kiện giữa các service, ví dụ OrderCreated, PaymentCompleted, UserLoggedIn
Microservices: làm “xương sống” giao tiếp bất đồng bộ, giảm phụ thuộc trực tiếp giữa các service
Real-time analytics: thu thập clickstream, log, metrics, giao dịch… rồi đưa vào hệ thống phân tích gần như tức thời
Data pipelines: tầng trung gian giữa database/API và hệ thống downstream như data warehouse, lake hoặc search engine
IoT: nhận lượng lớn telemetry từ thiết bị và phân phối đến hệ thống xử lý
CDC (Change Data Capture): lấy thay đổi từ PostgreSQL/MySQL rồi stream sang hệ thống khác
AI/ML streaming: đưa dữ liệu realtime vào pipeline xử lý hoặc inference

Ngoài ra, nhờ latency thấp, Redpanda được dùng trong giao dịch thuật toán, real-time gaming, SIEM, và các hệ thống IoT nhạy cảm với độ trễ.

Ví dụ: Hệ thống thương mại điện tử#

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

Thay vì Order Service gọi trực tiếp từng service, nó chỉ publish một event:

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

json

Redpanda lưu và phân phối event này cho nhiều consumer. Payment, Inventory, Analytics… xử lý độc lập — nếu một service chậm, các service khác không bị ảnh hưởng.

Bắt đầu nhanh#

# Chạy Redpanda bằng Docker
docker run -d --name redpanda -p 9092:9092 \
  docker.redpanda.com/redpandadata/redpanda:latest \
  redpanda start

# Tạo topic và produce/consume bằng rpk
rpk topic create orders
rpk topic produce orders
rpk topic consume orders --group my-group

bash

Code Kafka hiện có dùng được nguyên vẹn — chỉ cần đổi endpoint broker sang Redpanda.

Hệ sinh thái#

Redpanda Console: UI quản lý cluster, xem data pipeline, debug không cần command line
Schema Registry: quản lý schema cho event (tương thích Confluent)
Tiered storage: tự động chuyển dữ liệu cũ từ NVMe sang object storage rẻ hơn
WASM transforms: chạy transform dữ liệu realtime bằng WebAssembly ngay trong broker
Redpanda Cloud / BYOC: bản managed, hoặc tự host trong cloud của bạn
Kafka Connect tương thích: dùng lại toàn bộ connector hiện có

Khi nào chọn Redpanda, khi nào chọn Kafka?#

Tiêu chí	Redpanda	Kafka
Độ trễ (tail latency)	Rất thấp (ms)	Cao hơn khi tải lớn
Footprint & vận hành	Nhẹ, single binary, không ZooKeeper	Nặng hơn, nhiều thành phần
Hệ sinh thái	Tương thích Kafka API	Chuẩn công nghiệp, lớn nhất
Trưởng thành	Mới hơn (từ 2019)	10+ năm production
Tài nguyên phần cứng	Ít hơn cùng workload	Cần nhiều RAM hơn (JVM)

Nếu bạn đang vận hành Kafka và khổ sở với ZooKeeper, JVM tuning hay tail latency — Redpanda là lựa chọn thay thế “drop-in” đáng cân nhắc. Nếu bạn cần hệ sinh thái rộng nhất và sự trưởng thành của chuẩn công nghiệp, Kafka vẫn rất mạnh.

Kết luận#

Redpanda chứng minh rằng tương thích API không có nghĩa là phải chịu đựng kiến trúc cũ. Bằng cách viết lại Kafka API bằng C++ trên Seastar — không JVM, không ZooKeeper, thread-per-core — Redpanda mang lại độ trễ thấp hơn hẳn và vận hành đơn giản hơn, trong khi các ứng dụng Kafka hiện có vẫn chạy nguyên vẹn.