ถึงแม้ว่าผมจะเคยเจอKafkaก่อนผมเพิ่งตระหนัก Kafka บางทีอาจจะใช้เป็น (พื้นฐานของการบริการ) CQRS , eventstore

หนึ่งในประเด็นหลักที่คาฟคาสนับสนุน:

• แน่นอนว่าการจับ / จัดเก็บเหตุการณ์ทั้งหมดของ HA
• สถาปัตยกรรมผับ / ย่อย
• ความสามารถในการเล่นซ้ำบันทึกเหตุการณ์ซึ่งช่วยให้ความสามารถสำหรับสมาชิกใหม่ที่จะลงทะเบียนกับระบบหลังจากข้อเท็จจริง

เป็นที่ยอมรับว่าฉันไม่ใช่ 100% ที่เชี่ยวชาญในการจัดหา CQRS / การจัดหากิจกรรม แต่ดูเหมือนว่าใกล้เคียงกับร้านค้าที่ควรจะเป็น สิ่งที่ตลกคือ: ฉันไม่สามารถพบได้มากนักเกี่ยวกับการใช้คาฟคาในการเป็นสถานที่จัดงานดังนั้นฉันอาจจะพลาดอะไรบางอย่างไป

ดังนั้นอะไรที่ขาดหายไปจากคาฟคาเพื่อให้เป็นอีเวนต์ที่ดี? มันจะทำงานอย่างไร ใช้มันผลิตหรือไม่ สนใจข้อมูลเชิงลึกลิงก์และอื่น ๆ

โดยทั่วไปสถานะของระบบจะถูกบันทึกตามธุรกรรม / เหตุการณ์ที่ระบบเคยได้รับแทนที่จะบันทึกเพียงสถานะปัจจุบัน / สแน็ปช็อตของระบบซึ่งเป็นสิ่งที่มักจะทำ (คิดว่ามันเป็นบัญชีแยกประเภททั่วไปในการบัญชี: การทำธุรกรรมทั้งหมดรวมถึงสถานะสุดท้าย) ซึ่งจะช่วยให้ทุกสิ่งที่ยอดเยี่ยม แต่เพียงอ่านบนลิงก์ที่มีให้

Kafka มีวัตถุประสงค์เพื่อเป็นระบบส่งข้อความซึ่งมีความคล้ายคลึงกันหลายอย่างกับร้านค้าอีเวนต์

คลัสเตอร์คาฟก้าจะเก็บข้อความที่เผยแพร่ทั้งหมดไม่ว่าจะถูกใช้ไปหรือไม่ก็ตามเป็นระยะเวลาที่กำหนดค่าได้ ตัวอย่างเช่นหากมีการตั้งค่าการเก็บรักษาไว้สองวันสำหรับสองวันหลังจากข้อความที่เผยแพร่จะพร้อมใช้งานเพื่อการบริโภคหลังจากนั้นจะถูกยกเลิกเพื่อเพิ่มพื้นที่ว่าง ประสิทธิภาพของคาฟคานั้นคงที่อย่างมีประสิทธิภาพเมื่อเทียบกับขนาดข้อมูลดังนั้นการเก็บรักษาข้อมูลจำนวนมากไม่ใช่ปัญหา

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

UPDATE

เอกสาร Kafka :

การจัดหากิจกรรมเป็นรูปแบบของการออกแบบแอปพลิเคชันซึ่งการเปลี่ยนแปลงสถานะจะถูกบันทึกเป็นลำดับของเรคคอร์ด การสนับสนุนของ Kafka สำหรับข้อมูลบันทึกที่มีขนาดใหญ่มากทำให้เป็นแบ็กเอนด์ที่ยอดเยี่ยมสำหรับแอปพลิเคชั่นที่สร้างขึ้นในสไตล์นี้

อัพเดท 2

ข้อกังวลประการหนึ่งของการใช้คาฟคาในการจัดหางานอีเวนต์คือจำนวนหัวข้อที่ต้องการ โดยทั่วไปในการจัดหากิจกรรมจะมีสตรีม (หัวข้อ) ของกิจกรรมต่อเอนทิตี (เช่นผู้ใช้ผลิตภัณฑ์ ฯลฯ ) วิธีนี้สถานะปัจจุบันของเอนทิตีสามารถสร้างใหม่ได้โดยการใช้เหตุการณ์ทั้งหมดในสตรีมอีกครั้ง แต่ละหัวข้อคาฟคาประกอบด้วยหนึ่งพาร์ติชั่นหนึ่งพาร์ติชั่นและแต่ละพาร์ติชั่นถูกเก็บไว้เป็นไดเรกทอรีในระบบไฟล์ จะมีแรงกดดันจาก ZooKeeper เมื่อจำนวน znode เพิ่มขึ้น

ฉันเป็นหนึ่งในนักเขียนดั้งเดิมของคาฟคา Kafka จะทำงานได้ดีเช่นเดียวกับบันทึกการจัดหากิจกรรม มันเป็นความผิดพลาดทนขนาดข้อมูลขนาดใหญ่และมีรูปแบบการแบ่งในตัว

เราใช้เพื่อการใช้งานหลายกรณีของแบบฟอร์มนี้ที่ LinkedIn ตัวอย่างเช่นระบบประมวลผลโอเพนซอร์สสตรีมของเรา Apache Samza มาพร้อมกับการสนับสนุนในตัวสำหรับการจัดหากิจกรรม

ฉันคิดว่าคุณไม่ค่อยได้ยินเกี่ยวกับการใช้ Kafka สำหรับการจัดหากิจกรรมเป็นหลักเนื่องจากคำศัพท์การจัดหากิจกรรมดูเหมือนจะไม่ค่อยแพร่หลายในพื้นที่เว็บผู้บริโภคที่ Kafka ได้รับความนิยมมากที่สุด

ฉันได้เขียนบิตเกี่ยวกับรูปแบบของการใช้งาน Kafka นี้ที่นี่

ฉันกลับมาที่ QA นี้ต่อไป และฉันไม่พบคำตอบที่มีอยู่เหมาะสมพอฉันจึงเพิ่มคำตอบนี้

TL; DR ใช่หรือไม่ขึ้นอยู่กับการใช้งานการจัดหากิจกรรมของคุณ

มีเหตุการณ์หลักสองประเภทที่มาจากระบบที่ฉันรับรู้

ตัวประมวลผลเหตุการณ์ดาวน์สตรีม = ใช่

ในระบบประเภทนี้เหตุการณ์ที่เกิดขึ้นในโลกแห่งความจริงและถูกบันทึกไว้เป็นข้อเท็จจริง เช่นระบบคลังสินค้าเพื่อติดตามแพลเลตของผลิตภัณฑ์ โดยทั่วไปจะไม่มีเหตุการณ์ที่ขัดแย้งกัน ทุกอย่างเกิดขึ้นแล้วแม้ว่ามันจะผิด (พาเลท Ie คือ 123456 วางบนรถบรรทุก A แต่ถูกกำหนดไว้สำหรับรถบรรทุก B) จากนั้นข้อเท็จจริงจะถูกตรวจสอบเพื่อหาข้อยกเว้นผ่านกลไกการรายงาน Kafka นั้นเหมาะสำหรับแอพพลิเคชั่นประมวลผลเหตุการณ์แบบดาวน์สตรีมประเภทนี้

ในบริบทนี้เป็นที่เข้าใจว่าเหตุใดคนคาฟคาจึงเรียกร้องให้เป็นโซลูชั่นการจัดหากิจกรรม เพราะมันค่อนข้างคล้ายกับวิธีที่ใช้ไปแล้วในตัวอย่างเช่นสตรีมการคลิก อย่างไรก็ตามผู้ที่ใช้คำว่า Event Sourcing (ซึ่งต่างจากการประมวลผลแบบสตรีม) น่าจะหมายถึงการใช้งานที่สอง

แอปพลิเคชันที่ควบคุมความจริง = ไม่

แอปพลิเคชันประเภทนี้ประกาศเหตุการณ์ของตนเองอันเป็นผลมาจากการร้องขอของผู้ใช้ที่ผ่านตรรกะทางธุรกิจ คาฟคาทำงานได้ไม่ดีในกรณีนี้ด้วยเหตุผลสองประการ

ขาดการแยกเอนทิตี

สถานการณ์นี้ต้องการความสามารถในการโหลดสตรีมเหตุการณ์สำหรับเอนทิตีที่เฉพาะเจาะจง เหตุผลทั่วไปสำหรับสิ่งนี้คือการสร้างแบบจำลองการเขียนชั่วคราวสำหรับตรรกะทางธุรกิจเพื่อใช้ในการประมวลผลคำขอ การทำเช่นนี้ไม่สามารถทำได้ใน Kafka การใช้หัวข้อต่อเอนทิตีอาจอนุญาตสิ่งนี้ยกเว้นกรณีนี้ไม่ใช่แบบเริ่มต้นเมื่ออาจมีเอนทิตีหลายพันหรือหลายล้านรายการ นี่เป็นเพราะข้อ จำกัด ทางเทคนิคใน Kafka / Zookeeper

หนึ่งในเหตุผลหลักที่ใช้รูปแบบการเขียนชั่วคราวในวิธีนี้คือการเปลี่ยนแปลงตรรกะทางธุรกิจราคาถูกและใช้งานง่าย

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

ขาดการตรวจสอบความขัดแย้ง

ประการที่สองผู้ใช้สามารถสร้างเงื่อนไขการแข่งขันเนื่องจากการร้องขอพร้อมกันกับเอนทิตีเดียวกัน อาจไม่เป็นที่พึงปรารถนาที่จะบันทึกเหตุการณ์ที่ขัดแย้งกันและแก้ไขหลังจากเหตุการณ์นั้น ดังนั้นจึงเป็นสิ่งสำคัญที่จะสามารถป้องกันเหตุการณ์ที่ขัดแย้งกัน เมื่อต้องการปรับขนาดการโหลดคำขอเป็นเรื่องปกติที่จะใช้บริการแบบไม่มีสถานะในขณะที่ป้องกันการเขียนที่ขัดแย้งโดยใช้การเขียนแบบมีเงื่อนไข (เขียนเฉพาะเมื่อเหตุการณ์เอนทิตีล่าสุดคือ #x) Aka Optimistic Concurrency Kafka ไม่สนับสนุนการเห็นพ้องด้วยในแง่ดี แม้ว่ามันจะสนับสนุนในระดับหัวข้อมันจะต้องลงไปถึงระดับเอนทิตีเพื่อให้มีประสิทธิภาพ ในการใช้คาฟคาและป้องกันเหตุการณ์ที่ขัดแย้งกันคุณจะต้องใช้ตัวเขียนที่ต่อเนื่องและสถานะในระดับแอปพลิเคชัน นี่คือข้อกำหนด / ข้อ จำกัด ทางสถาปัตยกรรมที่สำคัญ

ข้อมูลเพิ่มเติม

อัปเดตต่อความคิดเห็น

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

ดูเหมือนว่าคนส่วนใหญ่ใช้การจัดเก็บเหตุการณ์ของตัวเองบนฐานข้อมูลที่มีอยู่ สำหรับสถานการณ์ที่ไม่เผยแพร่เช่นผลิตภัณฑ์แบ็คเอนด์ภายในหรือผลิตภัณฑ์แบบสแตนด์อโลนมันมีเอกสารวิธีการสร้างที่จัดเก็บเหตุการณ์บน SQL อย่างดี และมีห้องสมุดอยู่ด้านบนของฐานข้อมูลชนิดต่าง ๆ นอกจากนี้ยังมีEventStoreซึ่งสร้างขึ้นเพื่อจุดประสงค์นี้

ในสถานการณ์แบบกระจายฉันเห็นการใช้งานที่แตกต่างกันสองอย่าง โครงการ Pantherของ Jet ใช้ Azure CosmosDBพร้อมคุณสมบัติ Change Feed เพื่อแจ้งเตือนผู้ฟัง การใช้งานที่คล้ายกันอีกอย่างที่ฉันเคยได้ยินเกี่ยวกับ AWS คือการใช้ DynamoDB พร้อมคุณสมบัติสตรีมเพื่อแจ้งผู้ฟัง คีย์พาร์ติชันอาจเป็นรหัสสตรีมสำหรับการกระจายข้อมูลที่ดีที่สุด (เพื่อลดปริมาณการจัดสรรพื้นที่ส่วนเกิน) อย่างไรก็ตามการเล่นซ้ำเต็มรูปแบบข้ามลำธารใน Dynamo นั้นมีราคาแพง (อ่านและคุ้มค่า) ดังนั้นสิ่งนี้จึงถูกตั้งค่าสำหรับ Dynamo Streams เพื่อทิ้งกิจกรรมลง S3 เมื่อผู้ฟังใหม่ออนไลน์หรือผู้ฟังที่มีอยู่ต้องการเล่นซ้ำแบบเต็มมันจะอ่าน S3 เพื่อให้ทันก่อน

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

คาฟคายังคงมีประโยชน์มากในสถานการณ์จำลอง มันเป็นปัญหาที่ไม่สำคัญที่จะเปิดเผยกิจกรรมของบริการแต่ละบริการอื่น ๆ โดยทั่วไปแล้ว Event store นั้นไม่ได้สร้างขึ้นมา แต่นั่นเป็นสิ่งที่ Kafka ทำได้ดี แต่ละบริการมีแหล่งที่มาของความจริงภายในของตัวเอง (อาจเป็นที่เก็บเหตุการณ์หรืออย่างอื่น) แต่ฟัง Kafka เพื่อรับรู้ว่าเกิดอะไรขึ้น "นอก" บริการอาจโพสต์กิจกรรมไปยัง Kafka เพื่อแจ้ง "นอก" ในสิ่งที่น่าสนใจที่บริการทำ

คุณสามารถใช้ Kafka เป็นร้านค้ากิจกรรมได้ แต่ฉันไม่แนะนำให้ทำเช่นนั้นถึงแม้ว่ามันอาจเป็นตัวเลือกที่ดี:

• คาฟคารับประกันอย่างน้อยหนึ่งครั้งในการจัดส่งและมีรายการซ้ำในที่จัดเก็บกิจกรรมที่ไม่สามารถลบได้ อัปเดต: ที่ นี่คุณสามารถอ่านได้ว่าทำไมมันถึงยากนักกับคาฟคาและข่าวล่าสุดเกี่ยวกับวิธีการทำให้พฤติกรรมนี้สำเร็จ: https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how -apache-Kafka-ไม่มัน /
• เนื่องจากการเปลี่ยนแปลงไม่ได้จึงไม่มีวิธีจัดการกับที่จัดเก็บเหตุการณ์เมื่อแอปพลิเคชันวิวัฒนาการและกิจกรรมต้องมีการเปลี่ยนแปลง (มีวิธีการเรียนการสอนเช่นการอัปโหลด แต่ ... ) ครั้งหนึ่งอาจบอกว่าคุณไม่จำเป็นต้องแปลงเหตุการณ์ แต่นั่นไม่ใช่ข้อสันนิษฐานที่ถูกต้องอาจมีสถานการณ์ที่คุณทำการสำรองข้อมูลดั้งเดิม แต่คุณอัปเกรดเป็นรุ่นล่าสุด นั่นเป็นข้อกำหนดที่ถูกต้องในสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์
• ไม่มีที่สำหรับเก็บสแนปชอตของเอนทิตี / มวลรวมและการเล่นซ้ำจะช้าลงและช้าลง การสร้างสแนปชอตจะต้องมีคุณสมบัติสำหรับการจัดเก็บเหตุการณ์จากมุมมองระยะยาว
• พาร์ติชั่นของ Kafka นั้นมีการกระจายและยากที่จะจัดการและสำรองข้อมูลเปรียบเทียบกับฐานข้อมูล ฐานข้อมูลนั้นง่ายกว่า :-)

ดังนั้นก่อนที่คุณจะตัดสินใจเลือกคุณจะคิดสองครั้ง การจัดเก็บกิจกรรมเป็นการรวมกันของแอปพลิเคชันเลเยอร์อินเทอร์เฟซ (การตรวจสอบและการจัดการ), SQL / NoSQL store และ Kafka ในฐานะนายหน้าเป็นทางเลือกที่ดีกว่าการทิ้ง Kafka จัดการทั้งสองบทบาทเพื่อสร้างโซลูชันที่สมบูรณ์

Event store เป็นบริการที่ซับซ้อนซึ่งต้องการมากกว่าสิ่งที่ Kafka สามารถเสนอได้หากคุณจริงจังกับการใช้ Event sourcing, CQRS, Sagas และรูปแบบอื่น ๆ ในสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์และมีประสิทธิภาพสูง

อย่าลังเลที่จะท้าทายคำตอบของฉัน! คุณอาจไม่ชอบสิ่งที่ฉันพูดเกี่ยวกับโบรกเกอร์ที่คุณชื่นชอบที่มีความสามารถในการซ้อนทับกันมากมาย แต่ถึงกระนั้นคาฟคาก็ไม่ได้ออกแบบมาเป็นอีเวนต์เก็บข้อมูล แต่เป็นโบรกเกอร์และบัฟเฟอร์ที่มีประสิทธิภาพสูงในเวลาเดียวกัน ตัวอย่างเช่น.

โปรดดูที่เฟรมเวิร์กโอเพนซอร์สไมโครซอฟท์ eventuate.io เพื่อค้นหาเพิ่มเติมเกี่ยวกับปัญหาที่อาจเกิดขึ้น: http://eventuate.io/

อัปเดตตั้งแต่วันที่ 8 ก.พ. 2018

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

1. อย่าใช้สปริง - มันยอดเยี่ยม (ฉันใช้ตัวเองมาก) แต่หนักและช้าในเวลาเดียวกัน และมันไม่ได้เป็นแพลตฟอร์มไมโครบริการเลย มันเป็นเพียงแค่กรอบที่จะช่วยให้คุณสามารถใช้งานได้ เฟรมเวิร์กอื่น ๆ คือ "เพียงแค่" REST ที่เบาหรือ JPA หรือเฟรมเวิร์กที่โฟกัสแตกต่างกัน ฉันขอแนะนำอาจเป็นแพลตฟอร์ม microservice ที่สมบูรณ์แบบโอเพ่นซอร์สที่ดีที่สุดในระดับพร้อมใช้งานซึ่งกลับมาที่รูท Java บริสุทธิ์: https://github.com/networknt

หากคุณสงสัยเกี่ยวกับประสิทธิภาพคุณสามารถเปรียบเทียบตัวเองกับชุดเบนช์มาร์กที่มีอยู่ https://github.com/networknt/microservices-framework-benchmark

2. อย่าใช้คาฟคาเลย :-)) มันเป็นเรื่องตลกครึ่งหนึ่ง ฉันหมายถึงในขณะที่คาฟคานั้นยอดเยี่ยม แต่ก็เป็นระบบศูนย์กลางอีกระบบหนึ่ง ฉันคิดว่าอนาคตอยู่ในระบบการส่งข้อความที่ไม่มีนายหน้า คุณอาจประหลาดใจ แต่มีระบบคาฟคาที่เร็วกว่า :-) แน่นอนคุณต้องลงไปที่ระดับต่ำกว่า ดูพงศาวดาร

3. สำหรับที่จัดเก็บกิจกรรมฉันขอแนะนำส่วนขยาย Postgresql ที่เหนือกว่าที่เรียกว่า TimescaleDB ซึ่งมุ่งเน้นที่การประมวลผลข้อมูลชุดเวลาที่มีประสิทธิภาพสูง (เหตุการณ์คือชุดเวลา) ในปริมาณมาก แน่นอนว่า CQRS, การจัดหากิจกรรม (เล่นซ้ำ, คุณสมบัติอื่น ๆ ) ถูกสร้างขึ้นในกรอบงาน light4j ซึ่งไม่ใช้กล่องซึ่งใช้ Postgres เป็นที่เก็บข้อมูลต่ำ

4. สำหรับการส่งข้อความลองดูที่ Chronicle Queue, Map, Engine, Network ฉันหมายถึงกำจัดโซลูชันcentric โบรคเกอร์ที่ล้าสมัยและไปกับระบบการส่งข้อความขนาดเล็ก Chronicle Queue นั้นเร็วกว่าคาฟคาจริงๆ แต่ฉันยอมรับว่ามันไม่ใช่ทั้งหมดในโซลูชันเดียวและคุณต้องทำการพัฒนาบางอย่างมิฉะนั้นคุณจะไปและซื้อรุ่น Enterprise (จ่ายหนึ่ง) ในที่สุดความพยายามในการสร้างจาก Chronicle เลเยอร์การส่งข้อความของคุณเองจะได้รับการชำระโดยลบภาระในการบำรุงรักษาคลัสเตอร์ Kafka

ใช่คุณสามารถใช้ Kafka เป็นร้านค้ากิจกรรมได้ มันทำงานได้ค่อนข้างดีโดยเฉพาะอย่างยิ่งกับการเปิดตัวKafka Streamsซึ่งเป็นวิธีที่ชาว Kafka ใช้ในการประมวลผลกิจกรรมของคุณให้เป็นสถานะสะสมที่คุณสามารถสอบถามได้

เกี่ยวกับ:

ความสามารถในการเล่นซ้ำบันทึกเหตุการณ์ซึ่งช่วยให้ความสามารถสำหรับสมาชิกใหม่ที่จะลงทะเบียนกับระบบหลังจากข้อเท็จจริง

นี่อาจเป็นเรื่องยุ่งยาก ฉันครอบคลุมรายละเอียดที่นี่: https://stackoverflow.com/a/48482974/741970

ใช่ Kafka ทำงานได้ดีในรูปแบบการจัดหาเหตุการณ์พิเศษ CQRS อย่างไรก็ตามคุณต้องระมัดระวังในการตั้งค่า TTL สำหรับหัวข้อและโปรดทราบเสมอว่า Kafka ไม่ได้ออกแบบมาสำหรับรุ่นนี้ แต่เราสามารถใช้งานได้เป็นอย่างดี

ฉันคิดว่าคุณควรพิจารณากรอบ axon พร้อมกับการสนับสนุน Kafka