รูปแบบเอาต์บ็อกซ์สำหรับการเผยแพร่เหตุการณ์ที่เชื่อถือได้
เรียนรู้ว่ารูปแบบเอาต์บ็อกซ์แบบทรานแซกชันรับประกันความสอดคล้องระหว่างการเขียนฐานข้อมูลกับเหตุการณ์ Kafka อย่างไร และหลีกเลี่ยงการสูญเสียข้อมูลจากการเขียนสองทาง
รูปแบบเอาต์บ็อกซ์สำหรับการเผยแพร่เหตุการณ์ที่เชื่อถือได้ เป็นบทเรียน Apache Kafka & Stream Processing Fundamentals ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน Apache Kafka & Stream Processing Fundamentals และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส Apache Kafka & Stream Processing Fundamentals มีบทเรียนทั้งหมด 4 บทเรียน
บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ
The Dual-Write Problem
A service often needs to update its database and publish a Kafka event. Doing both as separate steps risks one succeeding and the other failing.
This dual-write problem leaves the database and Kafka inconsistent.
Why You Can't Just Try-Catch
If you commit the DB then publish, a crash in between loses the event.
If you publish then commit, a failed commit emits a phantom event. There is no atomic transaction spanning a relational DB and Kafka by default.
The Outbox Idea
The outbox pattern records the event in the same database transaction as the business change, in a dedicated outbox table.
One atomic commit now contains both the state change and the intent to publish.
The Outbox Table
A typical outbox schema captures everything needed to build the Kafka record.
CREATE TABLE outbox (
id UUID PRIMARY KEY,
aggregate_type VARCHAR,
aggregate_id VARCHAR,
event_type VARCHAR,
payload JSONB,
created_at TIMESTAMP DEFAULT now()
);Writing Atomically
Within one transaction, write the business row and the outbox row together.
BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 'a1';
INSERT INTO outbox (id, aggregate_type, aggregate_id, event_type, payload)
VALUES (gen_random_uuid(), 'account', 'a1', 'DebitMade',
'{"amount":100}');
COMMIT;Relaying to Kafka
A separate relay reads new outbox rows and publishes them to Kafka.
Two common approaches: poll the table, or use Change Data Capture to stream the inserts.
CDC + Debezium
Debezium has a dedicated Outbox Event Router SMT. It tails the DB transaction log, picks up outbox inserts, and routes each to the right Kafka topic — no polling, low latency.
At-Least-Once Delivery
The relay guarantees at-least-once delivery: an event is never lost, but it may be published more than once after a crash and retry.
Therefore consumers must be idempotent.
Idempotent Consumers
Use the event id (or aggregate id + version) to deduplicate downstream.
// Pseudocode
if (alreadyProcessed(event.id)) {
return; // skip duplicate
}
apply(event);
markProcessed(event.id);Ordering & Partitioning
To preserve per-aggregate order, use the aggregate_id as the Kafka message key.
All events for one account then land on the same partition and are consumed in order.
Pros & Cons
Pros: no dual-write loss, works with any DB, decouples publishing.
Cons: extra table and relay, at-least-once duplicates, slight latency. Still the standard solution for reliable event publishing.
Quick Check
Test your understanding of the outbox pattern.
Recap
You learned the outbox pattern.
- Solves the dual-write problem by committing state + event atomically.
- A relay (polling or CDC/Debezium) publishes outbox rows to Kafka.
- Delivery is at-least-once, so consumers must be idempotent.
- Key by aggregate id to preserve ordering.
เรียนรู้ Apache Kafka & Stream Processing Fundamentals ด้วย AI tutor — ฟรี
เขียนและเรียกใช้โค้ดจริงในเบราว์เซอร์ของคุณ รับความช่วยเหลือทันทีจาก AI tutor 24/7 และเรียนรู้ต่อจากที่คุณหยุดบนเว็บหรือในแอป
- คอร์ส
- 12
- บทเรียน
- 48
คำถามที่พบบ่อย
บทเรียน “รูปแบบเอาต์บ็อกซ์สำหรับการเผยแพร่เหตุการณ์ที่เชื่อถือได้” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “รูปแบบเอาต์บ็อกซ์สำหรับการเผยแพร่เหตุการณ์ที่เชื่อถือได้” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส Apache Kafka & Stream Processing Fundamentals ให้อัปเกรดเป็น CoddyKit PRO คอร์ส Apache Kafka & Stream Processing Fundamentals มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “รูปแบบเอาต์บ็อกซ์สำหรับการเผยแพร่เหตุการณ์ที่เชื่อถือได้”
เรียนรู้ว่ารูปแบบเอาต์บ็อกซ์แบบทรานแซกชันรับประกันความสอดคล้องระหว่างการเขียนฐานข้อมูลกับเหตุการณ์ Kafka อย่างไร และหลีกเลี่ยงการสูญเสียข้อมูลจากการเขียนสองทาง คุณปฏิบัติ Apache Kafka & Stream Processing Fundamentals ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน Apache Kafka & Stream Processing Fundamentals หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน Apache Kafka & Stream Processing Fundamentals บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน
บทเรียน “รูปแบบเอาต์บ็อกซ์สำหรับการเผยแพร่เหตุการณ์ที่เชื่อถือได้” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน Apache Kafka & Stream Processing Fundamentals นี้ได้ไหม
ได้ บทเรียน Apache Kafka & Stream Processing Fundamentals ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- การสร้างแหล่งเหตุการณ์ด้วย Kafka
- การดักจับการเปลี่ยนแปลงข้อมูล (CDC)
- รูปแบบการสื่อสารของไมโครเซอร์วิส
- รูปแบบเอาต์บ็อกซ์สำหรับการเผยแพร่เหตุการณ์ที่เชื่อถือได้