Kafka กับ Redis แตกต่างกันอย่างไร
Redis เป็นที่เก็บข้อมูลคีย์-ค่าในหน่วยความจำ ในขณะที่ Apache Kafka เป็นเครื่องมือประมวลผลสตรีม อย่างไรก็ตาม คุณสามารถเปรียบเทียบระหว่างสองเทคโนโลยีนี้ได้ เพราะคุณสามารถใช้ทั้งสองอย่างในการสร้างระบบการส่งข้อความเผยแพร่-สมัครรับข้อมูล (pub/sub) ในสถาปัตยกรรมระบบคลาวด์สมัยใหม่ แอปพลิเคชันจะถูกแยกออกเป็นส่วนย่อยๆ ที่อิสระจากกันที่เรียกว่าบริการ การรับส่งข้อความแบบ Pub/Sub มีการแจ้งเตือนเหตุการณ์ทันทีสำหรับระบบแบบกระจายเหล่านี้ Kafka รองรับระบบการดึงข้อมูลที่ตัวเผยแพร่ข้อความและผู้สมัครรับข้อมูลใช้คิวข้อความร่วมกัน ซึ่งผู้สมัครรับข้อมูลจะดึงข้อความได้ตามที่ต้องการ Redis รองรับระบบแบบพุชที่ตัวเผยแพร่ข้อความกระจายข้อความให้ผู้สมัครรับข้อมูลทั้งหมดเมื่อมีเหตุการณ์เกิดขึ้น
วิธีการทำงาน: Kafka เทียบกับ Redis pub/sub
Apache Kafka เป็นแพลตฟอร์มการสตรีมเหตุการณ์ที่อนุญาตให้หลายแอปพลิเคชันสตรีมข้อมูลโดยอิสระจากกัน แอปพลิเคชันเหล่านี้เรียกว่าผู้ผลิตและผู้บริโภค เผยแพร่และสมัครข้อมูลไปยังและจากพาร์ติชันข้อมูลที่เรียกว่าหัวข้อ
ในขณะเดียวกัน Redis ได้รับการออกแบบให้เป็นฐานข้อมูลแบบใช้หน่วยความจำที่รองรับการถ่ายโอนข้อมูลที่มีเวลาแฝงต่ำระหว่างแอปพลิเคชัน เก็บข้อความทั้งหมดไว้ใน RAM แทนที่จะเป็นฮาร์ดดิสก์เพื่อลดเวลาในการอ่านและเขียนข้อมูล เช่นเดียวกับ Kafka ผู้บริโภคหลายรายสามารถสมัครรับสตรีม Redis เพื่อดึงข้อความได้
แม้ว่าคุณจะสามารถใช้ทั้งสองอย่างสำหรับการส่งข้อความแบบ Pub/Sub แต่ Kafka และ Redis จะทำงานต่างกัน
ขั้นตอนการทำงานของ Kafka
Apache Kafka เชื่อมต่อผู้ผลิตและผู้บริโภคผ่านคลัสเตอร์คอมพิวเตอร์ แต่ละคลัสเตอร์ประกอบด้วยนายหน้า Kafka หลายตัวที่อยู่บนเซิร์ฟเวอร์ที่แตกต่างกัน
Kafka สร้างหัวข้อและพาร์ติชันเพื่อวัตถุประสงค์เหล่านี้
- หัวข้อเพื่อจัดกลุ่มข้อมูลที่คล้ายกันซึ่งอยู่ในหัวข้อที่สนใจ เช่น อีเมล การชำระเงิน ผู้ใช้ และการซื้อ
- แบ่งพาร์ติชันข้ามนายหน้าต่างๆ เพื่อการจำลองแบบข้อมูลและความทนทานต่อข้อผิดพลาด
ผู้ผลิตเผยแพร่ข้อความถึงนายหน้า เมื่อนายหน้าได้รับข้อความ จะจัดหมวดหมู่ข้อมูลเป็นหัวข้อและเก็บข้อมูลในพาร์ติชัน ผู้บริโภคเชื่อมต่อกับหัวข้อที่เกี่ยวข้องและดึงข้อมูลจากพาร์ติชัน
ขั้นตอนการทำงานของ Redis
Redis ทำงานด้วยสถาปัตยกรรมไคลเอ็นต์เซิร์ฟเวอร์เป็นระบบฐานข้อมูล NoSQL ผู้ผลิตและผู้บริโภคเป็นคู่กันอย่างห่างๆ และไม่ต้องรู้จักกันเมื่อส่งข้อความ
Redis ใช้คีย์และโหนดหลัก-รองเพื่อวัตถุประสงค์เหล่านี้:
- คีย์เพื่อจัดกลุ่มข้อความที่คล้ายกัน ตัวอย่างเช่น “อีเมล” เป็นคีย์ที่ชี้ไปยังที่เก็บข้อมูลที่เก็บเฉพาะข้อความอีเมล
- โหนดหลัก-รองสำหรับการจำลองข้อความ
เมื่อผู้ผลิตส่งข้อความไปยังโหนดเฉพาะ Redis จะส่งข้อความไปยังผู้สมัครรับข้อมูลที่เชื่อมต่อทั้งหมดโดยการตรวจสอบรหัสข้อความ ผู้บริโภคต้องเริ่มต้นและรักษาการเชื่อมต่อกับเซิร์ฟเวอร์ Redis อยู่เสมอเพื่อรับข้อความ สิ่งนี้เรียกว่าความหมายของการส่งมอบที่เชื่อมต่อ
การจัดการข้อความ: Kafka เทียบกับ Redis pub/sub
Apache Kafka ช่วยให้นักพัฒนามีระบบการส่งข้อความแบบกระจายที่ปรับขนาดได้สูง ในขณะเดียวกัน Redis นำเสนอโครงสร้างข้อมูลที่สมบูรณ์ซึ่งช่วยให้แอปพลิเคชันสามารถพุชข้อมูลไปยังหลาย ๆ โหนดได้อย่างรวดเร็ว ทั้งสองระบบมีความแตกต่างกันหลายประการในกลไกการจัดคิวข้อความ
ขนาดข้อความ
Kafka และ Redis ทำงานได้ดีที่สุดเมื่อพวกมันส่งแพ็คเก็ตข้อมูลขนาดเล็กระหว่างผู้บริโภคและผู้สมัครรับข้อมูล
โดยเฉพาะอย่างยิ่ง Redis ไม่ได้ออกแบบมาเพื่อจัดการขนาดข้อมูลขนาดใหญ่โดยไม่ลดทอนอัตราการโอนถ่ายข้อมูล นอกจากนี้ยังไม่สามารถเก็บข้อมูลจำนวนมากได้ เนื่องจาก RAM มีความจุน้อยกว่าที่เก็บข้อมูลในดิสก์
ในขณะเดียวกัน Kafka สามารถรองรับข้อความขนาดใหญ่พอสมควรได้ แม้จะไม่ได้สร้างมาเพื่อทำเช่นนั้นโดยเฉพาะก็ตาม Kafka สามารถจัดการข้อความได้สูงสุด 1 GB หากบีบอัดข้อความและคุณกำหนดค่าสำหรับการเก็บแบบแบ่งชั้น แทนที่จะเก็บข้อความทั้งหมดไว้ในพื้นที่เก็บข้อมูลในเครื่อง จะใช้พื้นที่เก็บข้อมูลระยะไกลเพื่อเก็บไฟล์ข้อมูลบันทึกที่เสร็จสมบูรณ์
การส่งข้อความ
ผู้บริโภค Kafka ดึงข้อมูลจากคิวข้อความ ผู้บริโภค Kafka แต่ละรายจะติดตามข้อความที่อ่านด้วยการออฟเซ็ต ซึ่งจะอัปเดตเพื่อดึงข้อความถัดไป ผู้บริโภคสามารถตรวจจับและติดตามข้อความที่ซ้ำกันได้
ในทางกลับกัน Redis จะส่งข้อความไปยังผู้สมัครรับข้อมูลที่เชื่อมต่อโดยอัตโนมัติ ผู้สมัครรับข้อมูล Redis รอข้อความขาเข้าจากเซิร์ฟเวอร์ที่ส่งตรงถึงพวกเขาอย่างอดทน เนื่องจากเป็นการตั้งค่าการส่งแบบครั้งเดียว ผู้สมัครรับข้อมูล Redis จึงไม่สามารถตรวจจับข้อความที่ซ้ำกันได้
การเก็บรักษาข้อความ
Kafka จะ Retain ข้อความหลังจากที่ผู้บริโภคอ่านแล้ว ดังนั้น หากแอปพลิเคชันไคลเอ็นต์สูญเสียข้อมูลที่ดึงมา ก็สามารถขอข้อมูลนั้นอีกครั้งจากพาร์ติชันที่สมัครรับข้อมูลได้ ด้วยการตั้งค่านโยบายการ Retain ข้อความ ผู้ใช้สามารถกำหนดระยะเวลาที่ Kafka เก็บรักษาข้อมูลได้
ในทางกลับกัน Redis จะไม่เก็บข้อความหลังจากส่งแล้ว หากไม่มีผู้สมัครรับข้อมูลคนใดเชื่อมต่อกับสตรีม Redis จะละทิ้งข้อความนั้น ข้อความที่ถูกทิ้งไม่สามารถกู้คืนแม้ว่าผู้สมัครรับข้อมูลเชื่อมต่อกับ Redis ในภายหลัง
การจัดการกับข้อผิดพลาด
ทั้ง Kafka และ Redis อนุญาตให้แอปพลิเคชันลดการส่งข้อความที่ไม่น่าเชื่อถือ แต่ทำได้ต่างกัน
การจัดการข้อผิดพลาดใน Redis มุ่งเน้นไปที่การโต้ตอบระหว่างแอปพลิเคชันไคลเอนต์และบริการ Redis ด้วย Redis นักพัฒนาสามารถจัดการกับสถานการณ์ต่างๆ เช่น ไคลเอ็นต์หมดเวลา หน่วยความจำบัฟเฟอร์เกิน และขีดจำกัดสูงสุดของไคลเอ็นต์ เนื่องจากสถาปัตยกรรมฐานข้อมูลคู่คีย์-ค่า Redis จึงไม่สามารถจัดการข้อผิดพลาดของข้อความได้อย่างมีประสิทธิภาพเหมือนที่ Kafka ทำ
นักพัฒนา Kafka สามารถเก็บเหตุการณ์ที่ผิดพลาดในคิวจดหมายที่ไม่ทำงาน ลองใหม่หรือเปลี่ยนเส้นทางเพื่อให้ส่งข้อความที่สอดคล้องกันไปยังแอปพลิเคชันไคลเอ็นต์ นักพัฒนาสามารถใช้ Kafka Connect API เพื่อเริ่มงานตัวเชื่อมต่อใหม่โดยอัตโนมัติในข้อผิดพลาดบางอย่าง
ความแตกต่างด้านประสิทธิภาพ: Kafka เทียบกับ Redis pub/sub
โดยรวมแล้ว Apache Kafka มีประสิทธิภาพดีกว่า Redis ในการส่งข้อความแบบ Pub/Sub เนื่องจาก Kafka ได้รับการออกแบบมาสำหรับการสตรีมข้อมูลโดยเฉพาะ Redis มีกรณีการใช้งานที่แตกต่างกันหลายกรณีที่ไม่สามารถใช้ Kafka ได้
การทำงานแนวขนาน
การทำงานแนวขนานคือความสามารถของผู้บริโภคหลายคนในการรับข้อความเดียวกันพร้อมกัน
Redis ไม่รองรับการทำงานแนวขนาน
ในทางกลับกัน Kafka อนุญาตให้เผยแพร่ข้อความเดียวกันไปยังผู้บริโภคหลายคนพร้อมกัน โดยปกติแล้ว ผู้บริโภคในกลุ่มผู้บริโภค Kafka จะผลัดกันดึงข้อความใหม่จากพาร์ติชัน หากมีผู้บริโภครายเดียวในกลุ่มผู้บริโภคหลายกลุ่ม ระบบจะดึงข้อความทั้งหมด ด้วยการใช้ประโยชน์จากการตั้งค่าและการจำลองพาร์ติชันนี้ คุณสามารถกำหนดผู้บริโภคหนึ่งรายให้กับกลุ่มผู้บริโภคแต่ละกลุ่มในแต่ละพาร์ติชันเรพลิเคชัน สิ่งนี้ทำให้ผู้บริโภคทั้งหมดสามารถดึงลำดับข้อความที่คล้ายกันได้
อัตราการโอนถ่ายข้อมูล
อัตราการโอนถ่ายข้อมูลวัดจำนวนข้อความที่แต่ละระบบสามารถประมวลผลต่อวินาที
โดยทั่วไป Kafka มีอัตราการโอนถ่ายข้อมูลสูงกว่า Redis pub/sub Kafka จัดการกับปริมาณข้อมูลที่มีขนาดใหญ่กว่ามาก เนื่องจากไม่ต้องรอให้ผู้สมัครรับข้อมูลแต่ละรายได้รับข้อความก่อนจะไปต่อ แต่จะเก็บข้อความปัจจุบันไว้ในแคชหน่วยความจำและที่เก็บข้อมูลแทน ซึ่งจะปรับความเร็วในการอ่านให้เหมาะสม
อย่างไรก็ตาม ประสิทธิภาพของ Kafka อาจลดลงหากผู้ใช้ไม่ได้รับข้อความเร็วพอ เนื่องจากข้อความที่ยังไม่ได้อ่านในแคชจะถูกลบออกในที่สุด ในกรณีนี้ผู้บริโภคต้องอ่านจากดิสก์ซึ่งช้ากว่า
ในขณะเดียวกัน Redis ต้องรอการรับทราบสำหรับผู้บริโภคแต่ละราย ซึ่งลดอัตราการโอนถ่ายข้อมูลลงอย่างมากด้วยโหนดที่เชื่อมต่อมากขึ้น วิธีแก้ไขปัญหาคือการส่งคำขอหลายรายการด้วยกระบวนการที่เรียกว่าการวางไปป์ไลน์ แต่สิ่งนี้จะลดเวลาแฝงในการส่งข้อความ
เวลาแฝง
ทั้ง Kafka และ Redis เหมาะสำหรับการประมวลผลข้อมูลที่มีเวลาแฝงต่ำ Redis เสนอเวลาในการส่งข้อความที่ต่ำกว่าซึ่งมีหน่วยเป็นมิลลิวินาที ในขณะที่ Kafka เฉลี่ยสิบมิลลิวินาที
เมื่อพิจารณาว่า Redis อ่านและเขียนข้อมูลบน RAM เป็นหลัก จึงได้เปรียบ Kafka ในเรื่องความเร็ว อย่างไรก็ตาม Redis อาจไม่รักษาการดำเนินการข้อมูลที่มีเวลาแฝงต่ำเป็นพิเศษเมื่อจัดการกับข้อความขนาดใหญ่ ในขณะเดียวกัน Kafka ต้องการเวลามากขึ้นในการจำลองพาร์ติชันบนไดรฟ์ทางกายภาพต่างๆ เพื่อให้ข้อมูลคงอยู่ ซึ่งจะเพิ่มค่าใช้จ่ายในการส่งข้อความ
การปรับเวลาแฝงให้เหมาะสมสำหรับ Redis และ Kafka เป็นไปได้ แต่คุณต้องทำอย่างระมัดระวัง ตัวอย่างเช่น คุณสามารถบีบอัดข้อความ Kafka เพื่อลดเวลาแฝง แต่ผู้ผลิตและผู้บริโภคต้องใช้เวลามากขึ้นในการขยายขนาดข้อความ
เวลาแฝงใน Redis อาจเกิดได้จากหลายปัจจัย รวมถึงสภาพแวดล้อมการทำงาน การทำงานของเครือข่าย คำสั่งที่ช้า หรือการฟอร์ก เพื่อลดความล่าช้าในการฟอร์ก Redis แนะนำให้รันระบบการนำส่ง Pub/ย่อย บนอินสแตนซ์ EC2 สมัยใหม่ที่ใช้ Hardware Virtual Machine (HVM)
ความทนทานต่อความเสียหาย
Kafka เขียนข้อมูลทั้งหมดบนดิสก์เก็บข้อมูลของนายหน้าชั้นนำและทำซ้ำในเซิร์ฟเวอร์ต่างๆ เมื่อเซิร์ฟเวอร์ล้มเหลว ผู้สมัครรับข้อมูลหลายรายจะดึงข้อมูลจากพาร์ติชันสำรองข้อมูล
Redis ไม่สำรองข้อมูลตามค่าเริ่มต้น ซึ่งแตกต่างจาก Kafka และผู้ใช้ต้องเปิดใช้คุณสมบัตินี้ด้วยตนเอง Redis ใช้พื้นที่เก็บข้อมูลในหน่วยความจำ ซึ่งจะสูญเสียข้อมูลทั้งหมดเมื่อปิดเครื่อง เพื่อหลีกเลี่ยงปัญหานี้ นักพัฒนาซอฟต์แวร์จึงเปิดการคงอยู่ของฐานข้อมูล Redis (RDB) เพื่อจับภาพสแน็ปช็อตของข้อมูล RAM เป็นระยะและเก็บไว้ในดิสก์
เมื่อใดควรใช้: Kafka เทียบกับ Redis pub/sub
Apache Kafka เป็นตัวเลือกที่ดีกว่าสำหรับการสร้างแอปพลิเคชันที่สตรีมชุดข้อมูลขนาดใหญ่และต้องการความสามารถในการกู้คืนสูง เริ่มแรกได้รับการพัฒนาให้เป็นไปป์ไลน์ส่งข้อมูลแบบกระจายเดียวที่สามารถจัดการข้อความหลายล้านล้านข้อความที่ส่งผ่าน Kafka จำลองพาร์ติชันข้ามเซิร์ฟเวอร์ต่างๆ เพื่อป้องกันข้อมูลสูญหายเมื่อโหนดล้มเหลว องค์กรต่างๆ ใช้ Kafka เพื่อรองรับการสื่อสารแบบเรียลไทม์ระหว่างแอปพลิเคชัน อุปกรณ์ Internet of Things (IoT) บนมือถือ และไมโครเซอร์วิส นอกจากนี้ยังเป็นตัวเลือกที่ดีกว่าสำหรับการรวมข้อมูลบันทึก การประมวลผลสตรีม และงานการรวมข้อมูลบนคลาวด์อื่นๆ
ในขณะเดียวกัน Redis ให้การกระจายเหตุการณ์ที่มีเวลาแฝงต่ำเป็นพิเศษสำหรับแอปพลิเคชันที่ต้องการการถ่ายโอนข้อมูลทันทีแต่ทนต่อการสูญเสียข้อมูลเพียงเล็กน้อย โดยทั่วไปจะใช้ Redis เป็นแคชเซสชันเพื่อเก็บข้อมูลที่เข้าถึงบ่อยหรือส่งข้อความด่วน นอกจากนี้ยังเหมาะสำหรับการเก็บข้อมูลเกม อีคอมเมิร์ซ หรือโซเชียลมีเดียเพื่อให้ประสบการณ์การใช้งานราบรื่นยิ่งขึ้น
สรุปความแตกต่างระหว่าง Kafka เทียบกับ Redis pub/sub
| Apache Kafka |
Redis |
|
| ขนาดข้อความ |
รองรับขนาดข้อความสูงสุด 1 GB พร้อมการบีบอัดและการเก็บแบบแยกชั้น |
รองรับขนาดข้อความที่เล็กลง |
| การส่งข้อความ |
ผู้สมัครรับข้อมูลดึงข้อความจากคิว |
เซิร์ฟเวอร์ Redis ส่งข้อความไปยังผู้สมัครรับข้อมูลที่เชื่อมต่อ |
| การเก็บรักษาข้อความ |
Retain ข้อความไว้หลังจากการดึงข้อมูล |
ไม่ Retain ข้อความ |
| การจัดการกับข้อผิดพลาด |
การจัดการข้อผิดพลาดที่แข็งแกร่งในระดับการส่งข้อความ คิวจดหมายที่ไม่ทำงาน การลองเหตุการณ์ใหม่ และการเปลี่ยนเส้นทาง |
คุณต้องจัดการข้อยกเว้น Redis ที่ระดับแอปพลิเคชันด้วยการหมดเวลา ขีดจำกัดของไคลเอ็นต์ และความจุของบัฟเฟอร์หน่วยความจำ |
| การทำงานแนวขนาน |
Kafka รองรับการทำงานแนวขนาน ผู้บริโภคหลายรายสามารถเรียกข้อความเดียวกันพร้อมกันได้ |
ไม่รองรับการทำงานแนวขนาน |
| อัตราการโอนถ่ายข้อมูล |
มีอัตราการโอนถ่ายข้อมูลที่สูงขึ้นเนื่องจากการอ่าน/เขียนแบบอะซิงโครนัส |
อัตราการโอนถ่ายข้อมูลลดลงเนื่องจากเซิร์ฟเวอร์ Redis ต้องรอการตอบกลับก่อนที่จะส่งข้อความไปยังผู้สมัครรับข้อมูลรายอื่น |
| เวลาแฝง |
เวลาแฝงต่ำ ช้ากว่า Redis เล็กน้อยเนื่องจากการจำลองข้อมูลตามค่าเริ่มต้น |
เวลาแฝงต่ำมากเมื่อกระจายข้อความขนาดเล็ก |
| ความทนทานต่อความเสียหาย |
สำรองพาร์ติชันโดยอัตโนมัติไปยังนายหน้าต่างๆ |
ไม่สำรองข้อมูลตามค่าเริ่มต้น ผู้ใช้สามารถเปิดใช้งานการคงอยู่ของ Redis ได้ด้วยตนเอง ความเสี่ยงของการสูญหายของข้อมูลขนาดเล็ก |
AWS รองรับข้อกำหนด Kafka และ Redis ของคุณได้อย่างไร
Amazon Web Services (AWS) มีโครงสร้างพื้นฐานที่ปรับขนาดได้และมีการจัดการเพื่อรองรับความต้องการในการส่งข้อความแบบสมัครรับข้อมูล (pub/sub) ของคุณ
ใช้ Amazon Managed Streaming สำหรับ Apache Kafka (Amazon MSK) เพื่อนำเข้าและประมวลผลข้อมูลจำนวนมากแบบเรียลไทม์ได้อย่างง่ายดาย คุณสามารถสร้างบัสข้อมูลที่เข้าถึงแบบส่วนตัวเพื่อจัดเตรียมโหนดการสตรีมที่มีความพร้อมใช้งานสูงตามขนาด คุณยังสามารถเชื่อมต่อกับบริการ AWS อื่นๆ ได้อย่างราบรื่น เช่น AWS IoT Core Amazon Virtual Private Cloud (Amazon VPC) และ บริการวิเคราะห์ข้อมูลของ Amazon สำหรับ Apache Flink
ใช้ Amazon MemoryDB เพื่อให้พื้นที่เก็บข้อมูลในหน่วยความจำที่มีความพร้อมใช้งานสูงสำหรับเวิร์กโหลด Redis ของคุณ คุณสามารถเรียกใช้ฟีดข้อมูลการสตรีมพร้อมกันสูงเพื่อนำเข้ากิจกรรมของผู้ใช้ และคุณสามารถรองรับคำขอหลายล้านคำขอต่อวันสำหรับแอปพลิเคชันสื่อและความบันเทิง
แทนที่จะใช้ Redis หรือ Kafka คุณสามารถใช้ Amazon Simple Notification Service (Amazon SNS) เพื่อสร้างระบบการส่งข้อความแบบ Pub/Sub คุณสามารถส่งข้อความจากแอปพลิเคชันของคุณไปยังลูกค้าหรือแอปพลิเคชันอื่นๆ ได้โดยตรงด้วยวิธีที่ปรับขนาดได้และประหยัดค่าใช้จ่าย Amazon SNS มีคุณสมบัติหลายอย่าง เช่น
- การส่งข้อความกลุ่มต่อกลุ่มแบบพุชที่มีอัตราการโอนถ่ายข้อมูลสูงระหว่างระบบแบบกระจาย ไมโครเซอร์วิส และแอปพลิเคชันแบบไม่ต้องใช้เซิร์ฟเวอร์ที่ขับเคลื่อนด้วยเหตุการณ์
- การเข้ารหัสข้อความและความเป็นส่วนตัวของการรับส่งข้อมูล
- ความสามารถในการส่งข้อความแบบกระจายในหมวดหมู่ AWS เช่น การวิเคราะห์ การประมวลผล คอนเทนเนอร์ ฐานข้อมูล, Internet of Things (IoT), แมชชีนเลิร์นนิง ความปลอดภัย และพื้นที่เก็บข้อมูล
เริ่มต้นใช้งาน pub/sub Redis และ Kafka บน AWS โดยสร้างบัญชีวันนี้
