ข้อมูลหลักงานเบื้องหลัง

การสตรีมเหตุการณ์ด้วย Consumer Group

สตรีมเหตุการณ์แบบ append-only พร้อม consumer group การตอบรับ และการกู้คืนอัตโนมัติของข้อความที่ผู้บริโภคที่ล่มทิ้งไว้

ล็อกแบบ append-only
คงทน
consumer group ต่อสตรีม
N
ข้อความที่หายเมื่อล่ม
0
ขั้นที่ 1 จาก 5
เผยแพร่เหตุการณ์

เซอร์วิสคำสั่งซื้อต่อท้ายเหตุการณ์และได้ id ของมันกลับมา

เซสชันตัวอย่างplaying
# เผยแพร่เหตุการณ์
hotkv> XADD orders * type created order 1182 total 49.00
"1790985600123-0"

ตัวอย่างแบบแอนิเมชันพร้อมคำสั่ง HotKV จริงและคำตอบตัวอย่าง คลิกขั้นตอนใดก็ได้เพื่อข้ามไปยังขั้นนั้น คำสั่งและคำตอบยังคงเป็นภาษาอังกฤษ ตรงตามที่คุณพิมพ์และเห็นใน HotKV

ปัญหา

เซอร์วิสที่ตอบสนองต่อเหตุการณ์ต้องการมากกว่าคิว ผู้บริโภคอิสระหลายรายต้องการเหตุการณ์ชุดเดียวกัน แต่ละ consumer group ต้องแบ่งงานข้ามอินสแตนซ์ และเมื่ออินสแตนซ์ตายขณะถือข้อความอยู่ ต้องมีใครสักคนสังเกตและรับช่วงต่อ

HotKV จัดการอย่างไร

สตรีมคือล็อกแบบ append-only แต่ละ consumer group อ่านมันอย่างอิสระ ส่งแต่ละข้อความให้สมาชิกหนึ่งรายของกลุ่ม และคงสถานะค้างจนกว่าสมาชิกจะตอบรับ XAUTOCLAIM ส่งข้อความที่ค้างนานเกินไปให้ผู้บริโภคที่ยังทำงานปกติ

ทีละขั้นตอน

เกิดอะไรขึ้นบ้าง ทีละคำสั่ง

  1. 01

    เผยแพร่เหตุการณ์

    เซอร์วิสคำสั่งซื้อต่อท้ายเหตุการณ์และได้ id ของมันกลับมา

    XADD orders * type created order 1182 total 49.00
  2. 02

    สองกลุ่ม หนึ่งสตรีม

    การเรียกเก็บเงินและการจัดส่งต่างมีกลุ่มของตนเอง และต่างได้รับเหตุการณ์

    XGROUP CREATE orders billing 0 MKSTREAM
  3. 03

    บริโภค

    อินสแตนซ์การเรียกเก็บเงินอ่านข้อความใหม่ของกลุ่มตน บล็อกจนกว่าจะมีอะไรเข้ามา

    XREADGROUP GROUP billing billing-1 COUNT 10 BLOCK 5000 STREAMS orders >
  4. 04

    ตอบรับ

    เมื่อสร้างใบแจ้งหนี้แล้ว การเรียกเก็บเงินตอบรับ และข้อความออกจากรายการที่ค้าง

    XACK orders billing 1790985600123-0
  5. 05

    กู้คืนจากการล่ม

    อินสแตนซ์การจัดส่งตัวหนึ่งตายขณะถือข้อความ หลังว่าง 60 วินาที อินสแตนซ์ที่ยังปกติรับข้อความเหล่านั้นไป

    XAUTOCLAIM orders shipping shipping-2 60000 0-0 COUNT 25
เหมาะกับงานแบบไหน

สถานการณ์จริง

ไปป์ไลน์คำสั่งซื้อ

คำสั่งซื้อไหลไปยังการเรียกเก็บเงิน การจัดส่ง และการวิเคราะห์ แต่ละส่วนอ่านสตรีมเดียวกันตามจังหวะของตนเอง

ฟีดการตรวจสอบและกิจกรรม

การกระทำของผู้ใช้ถูกต่อท้ายสตรีมและเล่นซ้ำโดยเซอร์วิสใดก็ตามที่ต้องการประวัติ

การรับข้อมูล IoT

ข้อความจากอุปกรณ์ถูกบัฟเฟอร์ในสตรีมและประมวลผลโดยกลุ่มเวิร์กเกอร์ที่ขยายตามโหลด

อยู่ในตัว

สิ่งที่คุณได้รับ

ล็อกแบบ append-only

รายการได้ id ที่เรียงตามเวลา และตัดแต่งตามความยาวหรืออายุได้

XADDXTRIM

Consumer group

แต่ละกลุ่มได้ทุกข้อความ และแบ่งงานข้ามสมาชิกของกลุ่ม

XGROUPXREADGROUP

การตอบรับ

ข้อความคงสถานะค้างจนกว่าจะถูกตอบรับ

XACKXPENDING

การกู้คืนอัตโนมัติ

ข้อความที่ว่างนานเกินไปถูกผู้บริโภคอีกตัวรับไป

XAUTOCLAIMXCLAIM
ข้อมูลอ้างอิง:XADDXREADGROUPXACKXAUTOCLAIM

คำถามที่พบบ่อย

เล่นเหตุการณ์เก่าซ้ำได้ไหม

ได้ XRANGE อ่านส่วนใดของสตรีมก็ได้ด้วย id และ consumer group ใหม่เริ่มจากจุดเริ่มต้นได้

จะหยุดสตรีมไม่ให้โตไม่สิ้นสุดได้อย่างไร

ตัดแต่งด้วย XTRIM หรือด้วยตัวเลือก MAXLEN หรือ MINID ของ XADD

XADD หลีกเลี่ยงเหตุการณ์ซ้ำได้ไหม

XADD รองรับ producer id แบบ idempotent (IDMP) การเผยแพร่ซ้ำจึงไม่สร้างรายการที่สอง ดูข้อมูลอ้างอิงของ XADD

กรณีใช้งานที่เกี่ยวข้อง

งานเบื้องหลัง

คิวงาน

คิว FIFO ที่ไม่ทำงานหายเมื่อเวิร์กเกอร์ตาย โดยผู้ผลิตและผู้บริโภคทำงานขนานกัน

สำรวจ
เรียลไทม์

แชตและการแจ้งเตือนแบบเรียลไทม์

กระจายข้อความไปยังไคลเอนต์ที่เชื่อมต่ออยู่ทุกรายแบบเรียลไทม์ พร้อมแชนเนลแบบชาร์ดสำหรับคลัสเตอร์และสตรีมสำหรับประวัติ

สำรวจ
เอเจนต์

การประสานงานหลายเอเจนต์

เอเจนต์ผู้วางแผน นักวิจัย และนักเขียนที่ส่งต่องานผ่านสตรีมงานที่คงทน แบ่งปันผลลัพธ์และหน่วยความจำ และไม่ทำงานหายเลย

สำรวจ

ลองกับเวิร์กโหลดของคุณเอง

HotKV ใช้โปรโตคอลของ Redis คุณจึงชี้ไคลเอนต์ที่มีอยู่มาที่ HotKV แล้วรันคำสั่งเดียวกันนี้ได้

ขอสิทธิ์เข้าใช้งานก่อนใครถัดไป: Pub/Sub Messaging