RabbitMQ กับ Redis แตกต่างกันอย่างไร
RabbitMQ เป็น Message Broker ในขณะที่ Remote Dictionary Server (Redis) เป็นหน่วยความจำที่เก็บข้อมูลคีย์-ค่า อย่างไรก็ตาม คุณสามารถเปรียบเทียบระหว่างสองเทคโนโลยีนี้ได้ เพราะคุณสามารถใช้ทั้งสองอย่างในการสร้างระบบการส่งข้อความเผยแพร่-สมัครรับข้อมูล (pub/sub) ในสถาปัตยกรรมระบบคลาวด์สมัยใหม่ แอปพลิเคชันจะถูกแยกออกเป็นส่วนย่อยๆ ที่อิสระจากกันที่เรียกว่าบริการ การรับส่งข้อความแบบ Pub/Sub มีการแจ้งเตือนเหตุการณ์ทันทีสำหรับระบบแบบกระจายเหล่านี้ RabbitMQ เป็น Message Broker แบบกระจายที่รวบรวมข้อมูลการสตรีมจากหลายแหล่งและกำหนดเส้นทางไปยังปลายทางที่แตกต่างกันสำหรับการประมวลผล Redis รองรับระบบแบบพุชที่ตัวเผยแพร่ข้อความกระจายข้อความให้ผู้สมัครรับข้อมูลทั้งหมดเมื่อมีเหตุการณ์เกิดขึ้น
วิธีการทำงาน: RabbitMQ เทียบกับ Redis
ทั้ง RabbitMQ และ Redis อนุญาตให้แอปพลิเคชัน ไมโครเซอร์วิส และส่วนประกอบซอฟต์แวร์แลกเปลี่ยนข้อความในรูปแบบต่างๆ
เวิร์กโฟลว์ RabbitMQ
RabbitMQ ใช้ Advanced Message Queuing Protocol (AMQP) เพื่อส่งข้อความอย่างปลอดภัยผ่าน Message Broker Message Broker ประกอบด้วยการแลกเปลี่ยนและคิว กระบวนการทำงานดังนี้:
- ผู้ผลิตข้อมูลส่งข้อความไปยัง RabbitMQ
- การแลกเปลี่ยนได้รับข้อมูลและกำหนดเส้นทางไปยังคิวตามลำดับตามกฎที่เรียกว่าการผูก
- ข้อความอยู่ในคิวจนกว่าผู้บริโภค RabbitMQ จะหยิบขึ้นมา
เมื่อคิวถึงความจุสูงสุด RabbitMQ จะป้องกันไม่ให้ผู้ผลิตเผยแพร่ข้อความจนกว่าผู้บริโภคจะจัดการกับข้อความที่ยังไม่ได้อ่าน RabbitMQ ยังสามารถกู้คืนข้อความหากการแลกเปลี่ยนล้มเหลวก่อนที่ผู้บริโภคจะอ่าน
ขั้นตอนการทำงานของ Redis
Redis ได้รับการออกแบบให้เป็นเซิร์ฟเวอร์โครงสร้างข้อมูลที่สนับสนุนโครงสร้างข้อมูลต่างๆ เช่น รายการ ชุด แฮช และบิตแมป อนุญาตให้แอปพลิเคชันไคลเอ็นต์เก็บ ดึง และประมวลผลข้อมูลเกือบทุกชนิด Redis จัดระเบียบข้อมูลที่ดเก็บไว้ในคู่ของคีย์-ค่า ซึ่งจัดสรรโครงสร้างสำหรับการสมัครสมาชิกแอปพลิเคชันไคลเอนต์
ตัวอย่างเช่น คุณสามารถแยกข้อมูลอีคอมเมิร์ซออกเป็นชื่อลูกค้า อีเมล สินค้าที่ซื้อ และคีย์ความคิดเห็น หลังจากนี้ คุณจะเผยแพร่ข้อมูลที่เกี่ยวข้องสำหรับแต่ละคีย์
Redis เปิดใช้งานการแลกเปลี่ยนข้อความการเก็บรักษาสั้นแบบเรียลไทม์ ทำงานดังนี้:
- ผู้ผลิตข้อมูลส่งข้อความไปยัง Redis
- โหนด Redis ตรวจสอบคีย์ข้อความเพื่อระบุผู้สมัครรับข้อมูลที่สนใจ
- Redis ส่งข้อความไปยังผู้สมัครรับข้อมูลที่เชื่อมต่อทั้งหมด
Message handling: RabbitMQ เทียบกับ Redis pub/sub
ทั้ง Redis และ RabbitMQ มีกลไกการเผยแพร่และสมัครรับข้อมูล (pub/sub) สำหรับแอปพลิเคชันเพื่อกระจายข้อความทั่วทั้งสภาพแวดล้อมคลาวด์ อย่างไรก็ตาม การจัดการข้อความแตกต่างกันอย่างมาก
อ่านเกี่ยวกับการรับส่งข้อความแบบ Pub/Sub »
การส่งข้อความ
RabbitMQ ใช้ Advanced Message Queuing Protocol (AMQP) เพื่อรองรับตรรกะการกำหนดเส้นทางที่ซับซ้อน สามารถส่งข้อความแบบจุดต่อจุดหรือจากผู้ผลิตรายเดียวไปยังผู้บริโภคจำนวนมาก โดยไม่คำนึงถึงวิธีการ ผู้บริโภคทุกคนส่งข้อความตอบรับไปยังผู้ผลิตเพื่อยืนยันการอ่านที่สำเร็จ หากผู้ผลิตไม่ได้รับการยืนยัน ผู้ผลิตจะทำการลองใหม่หลายครั้งในช่วงเวลาที่แตกต่างกัน
ในขณะเดียวกัน Redis ก็ส่งข้อความไปยังผู้สมัครรับข้อมูลที่เชื่อมต่อทั้งหมด ไม่รับประกันการส่งข้อความ ผู้สมัครรับข้อมูลต้องเชื่อมต่อกับเซิร์ฟเวอร์ Redis เพื่อรับข้อความขาเข้า หาก Redis ถูกตัดการเชื่อมต่อ อาจไม่สามารถเรียกคืนข้อความทั้งหมดได้
ขนาดข้อความ
RabbitMQ สามารถส่งข้อความขนาดใหญ่ขึ้นโดยไม่ประสบกับประสิทธิภาพที่ลดลงอย่างมาก เดิมทีได้รับการออกแบบมาเพื่อจัดการข้อความที่มีขนาดสูงสุด 2 GB แต่ต่อมาขีดจำกัดก็ลดลงเหลือ 128 MB
ในทางกลับกัน Redis ไม่ได้กำหนดขีดจำกัดสำหรับข้อความที่เก็บ แต่มีเวลาแฝงสูงสำหรับข้อความที่มีขนาดใหญ่กว่า 1 MB ดังนั้น นักพัฒนาจึงมักใช้ Redis เป็นแคชในการประมวลผลชุดข้อมูล เช่น สตริง แฮช รายการ และชุด
ความคงอยู่ของข้อความ
RabbitMQ รองรับข้อความถาวรและข้อความชั่วคราว เมื่อส่งข้อความไปยังคิวถาวร จะเขียนข้อมูลไปยังพื้นที่เก็บข้อมูลถาวรทันทีที่ถึง RabbitMQ ยังเขียนข้อความชั่วคราวไปยังดิสก์ แต่เฉพาะเมื่อเกินความจุของหน่วยความจำเท่านั้น
ในทางกลับกัน Redis ไม่รองรับข้อความถาวรตามค่าเริ่มต้น นักพัฒนาซอฟต์แวร์ต้องเปิดใช้คุณสมบัติที่เรียกว่า Redis Database (RDB) เพื่อถ่ายภาพสแน็ปช็อตเป็นระยะของ RAM และเก็บไว้ในดิสก์ การเปิดใช้งานการคงอยู่ของข้อมูลบน Redis จะเพิ่มค่าใช้จ่ายในการดำเนินการข้อมูล ซึ่งทำให้การส่งข้อความช้าลง อีกทางเลือกหนึ่งคือการใช้เทคนิคการกู้คืน เช่น การจำลองแบบอะซิงโครนัส
การเข้ารหัสข้อความ
RabbitMQ ใช้ SSL เพื่อเข้ารหัสข้อมูลที่อยู่ระหว่างการโอนย้ายระหว่างผู้ผลิต Broker และผู้บริโภค การเข้ารหัสข้อความช่วยให้องค์กรปกป้องข้อมูลที่เป็นความลับและลดความเสี่ยงของข้อมูล
ในขณะเดียวกัน Redis ไม่รองรับ SSL โดยกำเนิด เฉพาะ Redis เวอร์ชัน 6.0 และใหม่กว่าเท่านั้นที่รองรับ SSL หากต้องการเปิดใช้ SSL นักพัฒนาจะต้องได้รับใบรับรอง SSL จากคลัสเตอร์ Redis และสร้างใบรับรองไคลเอ็นต์สำหรับฐานข้อมูลของตน
ประสิทธิภาพ: RabbitMQ เทียบกับ Redis pub/sub
ความแตกต่างในการจัดการข้อความส่งผลต่อประสิทธิภาพของ RabbitMQ และ Redis ในสถานการณ์ต่างๆ
ความเร็ว
Redis เร็วกว่า RabbitMQ มากเนื่องจากประมวลผลข้อความในหน่วยความจำเป็นหลัก อย่างไรก็ตาม มีความเสี่ยงที่จะสูญเสียข้อความที่ยังไม่ได้อ่าน หากเซิร์ฟเวอร์ Redis ล้มเหลว
ในทางตรงกันข้าม เมื่อทำงานในโหมดถาวร RabbitMQ จะรอการรับทราบจากผู้บริโภคแต่ละรายก่อนที่จะส่งข้อความถัดไป RabbitMQ ยังใช้เวลาเพิ่มเติมในการเก็บข้อความบนดิสก์ ซึ่งทำให้ความเร็วในการแลกเปลี่ยนข้อความเฉลี่ยช้าลง
จากการเปรียบเทียบ Redis สามารถส่งข้อความได้มากถึงสิบล้านข้อความต่อวินาที ในขณะที่ RabbitMQ จัดการข้อความได้มากถึงหมื่นข้อความต่อวินาที
ความพร้อมใช้งาน
การคลัสเตอร์ซึ่งอนุญาตให้ระบบ Message Broker ทำซ้ำโหนดได้รับการจัดการแตกต่างกันใน RabbitMQ และ Redis
ด้วย RabbitMQ โหนดหลายโหนดที่มีข้อมูลและฟังก์ชันที่เกี่ยวข้องจะถูกจำลองแบบในคลัสเตอร์ อย่างไรก็ตาม คิวข้อความจะไม่ถูกจำลองแบบข้ามโหนดเหล่านี้ ซึ่งใช้ความสัมพันธ์แบบเพียร์ร่วมกัน ในการทำเช่นนั้น นักพัฒนาจะใช้คิวข้อความพิเศษที่สนับสนุนการจำลองแบบ
ในขณะเดียวกัน Redis Cluster เป็นคุณสมบัติที่เปิดตัวใน Redis เวอร์ชันที่ใหม่กว่า โดยจะคัดลอกข้อมูลจากโหนดผู้นำแต่ละโหนดไปยังผู้ติดตามหนึ่งคนหรือหลายคน เมื่อโหนดผู้นำล้มเหลว ผู้ติดตามจะเข้ามาแทนที่เพื่อจัดสรรการส่งข้อความที่มีความพร้อมใช้งานสูง
เมื่อใดควรใช้: RabbitMQ เทียบกับ Redis pub/sub
RabbitMQ มีประสิทธิภาพดีกว่า Redis ในหลายๆ ด้าน แต่ไม่ได้หมายความว่า RabbitMQ จะเป็นระบบกระจายข้อความที่ดีกว่าสำหรับทุกแอปพลิเคชัน
Redis ทำงานได้ดีขึ้นในแอปพลิเคชันระดับองค์กรที่ต้องการการประมวลผลข้อมูลแบบเรียลไทม์และการแคชที่มีเวลาแฝงต่ำ ด้วยพื้นที่เก็บข้อมูลในหน่วยความจำและการรองรับโครงสร้างข้อมูลที่หลากหลาย Redis จึงเหมาะสำหรับการประมวลผลข้อมูลระดับต่ำ ตัวอย่างเช่น สถาบันการเงินใช้ Redis เพื่อแคชข้อมูลการทำธุรกรรมเพื่อเปิดใช้งานการตรวจจับการฉ้อโกงแบบเรียลไทม์
ในขณะเดียวกัน ให้เลือก RabbitMQ หากคุณต้องการ Message Broker ไมโครเซอร์วิสโดยเฉพาะที่มีกลไกการสื่อสารแบบอะซิงโครนัสเพื่อรองรับการสร้างโค้ดและระบบ RabbitMQ ยังเหมาะสมกว่า Redis สำหรับการถ่ายโอนไฟล์ขนาดใหญ่ระหว่างแอปพลิเคชัน ตัวอย่างเช่น ระบบที่ต้องการส่งข้อมูลระหว่างไมโครเซอร์วิสจำนวนมากอย่างเสถียรอาจเลือก RabbitMQ ระบบจะได้รับประโยชน์จากความทนทานต่อความเสียหายของ RabbitMQ ความสามารถในการจัดการไฟล์ที่ใหญ่ขึ้น และกลไกการส่งข้อความที่รับประกัน
สรุปข้อแตกต่าง: RabbitMQ เทียบกับ Redis pub/sub
| RabbitMQ |
Redis |
|
| การส่งข้อความ |
รับประกันการส่งข้อความ รองรับตรรกะที่ซับซ้อน |
ไม่รับประกันการส่งข้อความ ต้องการการเชื่อมต่อที่ใช้งานจากผู้สมัครรับข้อมูล |
| ขนาดข้อความ |
จำกัดขนาดข้อความที่ 128 MB สามารถจัดการกับข้อความขนาดใหญ่ |
ไม่จำกัดข้อความ แต่ประสิทธิภาพจะลดลงสำหรับข้อความขนาดใหญ่ (มากกว่า 1 MB) |
| ความคงอยู่ของข้อความ |
รองรับข้อความถาวรและชั่วคราว เขียนข้อความถาวรไปยังดิสก์ |
ไม่รองรับข้อความถาวรตามค่าเริ่มต้น |
| การเข้ารหัสข้อความ |
รองรับการเข้ารหัส SSL |
การเข้ารหัส SSL พร้อมใช้งานใน Redis เวอร์ชัน 6.0 ขึ้นไป |
| ความเร็ว |
สูงสุดพันข้อความต่อวินาที |
สูงสุดล้านข้อความต่อวินาที |
| ความพร้อมใช้งาน |
สร้างโหนด Peer-to-Peer หลายโหนดในคลัสเตอร์ |
ใช้โมเดลผู้นำ-ผู้ตามในการคลัสเตอร์ |
AWS สามารถช่วยข้อกำหนด RabbitMQ และ Redis ของคุณได้อย่างไร
Amazon Web Services (AWS) ให้บริการที่มีการจัดการเพื่อเรียกใช้ระบบตัวรับส่งข้อความโอเพนซอร์สตามขนาด คุณสามารถตั้งค่าบริการเผยแพร่และสมัครรับข้อมูล (pub/sub) ได้อย่างง่ายดายและผสานเข้ากับบริการอื่นๆ ของ AWS
ต่อไปนี้คือข้อเสนอของ AWS ที่คุณสามารถใช้กับ Redis และ RabbitMQ:
- ด้วย Amazon MemoryDB คุณสามารถเพิ่มความทนทานเมื่อคุณส่งข้อความบน Redis คุณสามารถเรียกใช้ฟีดข้อมูลการสตรีมที่มีภาวะการทำงานพร้อมกันสูง เพื่อนำเข้ากิจกรรมผู้ใช้และรองรับคำขอหลายล้านรายการต่อวันสำหรับแอปพลิเคชันสื่อและความบันเทิง
- ด้วย Amazon MQ คุณสามารถจัดสรรตัวรับส่ง RabbitMQ ของคุณโดยไม่มีการตั้งค่าที่ใช้เวลานาน โดยจะเข้ารหัสข้อความ RabbitMQ ระหว่างการส่งและที่เหลือ ซึ่งช่วยให้แน่ใจว่าไปป์ไลน์ข้อมูลที่มีความพร้อมใช้งานสูงทั่วทั้ง AWS Availability Zone
แทนที่จะใช้ Redis หรือ RabbitMQ คุณสามารถใช้ Amazon Simple Notification Service (SNS) เพื่อสร้างระบบการส่งข้อความแบบ Pub/Sub คุณส่งข้อความจากแอปพลิเคชันของคุณไปยังลูกค้าหรือแอปพลิเคชันอื่นได้โดยตรงในลักษณะที่ปรับขนาดได้และประหยัดค่าใช้จ่าย
Amazon SNS มีคุณสมบัติหลายอย่าง:
- การส่งข้อความกลุ่มต่อกลุ่มแบบพุชที่มีอัตราการโอนถ่ายข้อมูลสูงระหว่างระบบแบบกระจาย ไมโครเซอร์วิส และแอปพลิเคชันแบบไม่ต้องใช้เซิร์ฟเวอร์ที่ขับเคลื่อนด้วยเหตุการณ์
- การเข้ารหัสข้อความและความเป็นส่วนตัวของการรับส่งข้อมูล
- ส่งข้อความความสามารถต่างๆ แบบกระจายออกตามหมวด AWS เช่น การวิเคราะห์, การประมวลผล, คอนเทนเนอร์, ฐานข้อมูล, Internet of Things (IoT), แมชชีนเลิร์นนิง, ความปลอดภัย และพื้นที่เก็บข้อมูล
เริ่มต้นใช้งาน pub/sub Redis และ RabbitMQ บน AWS โดยสร้างบัญชีวันนี้
