Redis Pub/Sub:คู่มือแนะนำ

เผยแพร่/สมัครสมาชิก (หรือ ผับ/ย่อย ) เป็นรูปแบบวิศวกรรมซอฟต์แวร์ที่ใช้มานานหลายทศวรรษ แต่มักต้องการเซิร์ฟเวอร์การส่งข้อความเฉพาะและความรู้เฉพาะทางจึงจะมีประโยชน์

Redis pub/sub เป็นการนำรูปแบบการเผยแพร่/สมัครไปใช้แบบลีนและเรียบง่าย ซึ่งเป็นคุณลักษณะของเซิร์ฟเวอร์ Redis ทั้งหมดตั้งแต่เปิดตัว 2.0 ซึ่งหมายความว่าใช้งานง่ายทุกที่ที่มีการนำ Redis ไปใช้ และสามารถสร้างระบบผับ/ย่อยที่รวดเร็วและเรียบง่ายได้อย่างรวดเร็วโดยการปรับใช้ Redis

เพื่อให้เข้าใจว่า Redis pub/sub เหมาะสมกับแอปหรือไม่ สิ่งสำคัญอันดับแรกคือต้องเข้าใจการออกแบบและเป้าหมายของ pub/sub จากนั้นจึงพิจารณารายละเอียดของการนำ Redis pub/sub ไปใช้

ภาพรวม Pub/sub

การออกแบบ Pub/sub:การแยก “publishers” ออกจาก “subscribers”

การลดการพึ่งพาและการแบ่งความรู้เป็นเป้าหมายหลักในการออกแบบซอฟต์แวร์ที่ปรับขนาดได้ รูปแบบข้อความเผยแพร่/สมัครรับข้อมูล AKA pub/sub แยกส่วนต่างๆ ของซอฟต์แวร์ที่เผยแพร่ ข้อความจากส่วนต่างๆ ของซอฟต์แวร์ของคุณที่ดำเนินการ ข้อความ มาดูตัวอย่างกันดีกว่า:

ตัวอย่างของ “ผู้เผยแพร่”

• แอปที่ให้คุณส่งข้อความไปยังห้องสนทนา
• ตู้คอนเทนเนอร์พร้อมประกาศสถานะหรือบริการ
• แอพประกาศราคาซื้อขายหุ้น
• เซ็นเซอร์อุณหภูมิในบ้านของคุณกำลังประกาศการอ่าน
• ผู้ประกาศข้อความในเกมที่มีผู้ใช้หลายคน (“Elon ถูกกินโดย grue”)

ตัวอย่างของ “subscribers”

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

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

ในผับ/ย่อย ผู้เผยแพร่ไม่จำเป็นต้องรู้เกี่ยวกับผู้ติดตาม – ส่งข้อความไปยังช่อง (มักเรียกว่า หัวข้อ ในระบบอื่นๆ) และ moveson ผู้ติดตามที่บังเอิญฟังช่องนั้นเมื่อข้อความถูกเผยแพร่จะได้รับ

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

เป้าหมายของ Pub/sub:ปรับขนาดการแสดงโฆษณา ไม่ใช่ภาระงาน

Pub/sub เป็นรูปแบบที่ใช้ในซอฟต์แวร์การปรับขนาด สิ่งสำคัญคือต้องเข้าใจว่าการปรับขนาดประเภทใดที่ช่วยได้บ้าง ความแตกต่างที่สำคัญระหว่างข้อความผับ/ย่อย การเข้าคิว .

ในรูปแบบการจัดคิว คิว (หรือ รายการ ใน Redis) บัฟเฟอร์ข้อความที่จะประมวลผลในขณะที่กลุ่มผู้ปฏิบัติงานเปิดรายการออกจากรายการและจัดการ ในโมเดลนี้ การปรับขนาดของพูลของผู้ปฏิบัติงานจะปรับความเร็วด้วยการประมวลผลคิวของคุณ เนื่องจากแต่ละข้อความจะถูกส่งไปยังผู้ปฏิบัติงานเพียงคนเดียว พนักงานทุกคนจัดการกับข้อความที่ระบุในลักษณะเดียวกัน

ในทางกลับกัน ระบบพยายามส่งข้อความของช่องทั้งหมดไปยังสมาชิกทุกคนในผับ/ย่อย เป็นรูปแบบแบบกลุ่มต่อกลุ่ม โดยที่สมาชิกแต่ละคนต่างทำอะไรบางอย่างที่ไม่เหมือนใครกับข้อความ คนหนึ่งเขียนลงในบันทึกที่ทนทาน คนหนึ่งส่งไปยังช่อง Slack คนหนึ่งส่งเสียงกริ่งในสำนักงานขายในพื้นที่ ฯลฯ

กล่าวโดยย่อ ผับ/ย่อยจะปรับขนาดข้อความ การจัดส่ง และการจัดคิวปรับขนาดข้อความการประมวลผลภาระงาน . Redis มักใช้สำหรับเป้าหมายทั้งสองนี้ SeeSidekiq สำหรับตัวอย่างยอดนิยมของการเข้าคิวกับ Redis

รายละเอียดผับ/ย่อยของ Redis

Pub/sub เป็นรูปแบบที่มีมาช้านานแล้ว และแม้ว่ารูปแบบหลักจะเหมือนกัน แต่คุณลักษณะเฉพาะจะแตกต่างกันอย่างมากตั้งแต่การนำไปใช้งานจนถึงการนำไปใช้

Redis pub/sub เป็นการใช้งานที่เบาและรวดเร็ว เพื่อให้เข้าใจการออกแบบได้ดีที่สุด ควรดูคุณลักษณะบางอย่างที่ไม่ใช่ ส่วนหนึ่งของผับ Redis/sub:

• ไม่มีการคงอยู่หรือการแคชค่า
• ไม่มีการรับประกันการจัดส่ง
• ยังไม่มีการเพิ่มประสิทธิภาพคลัสเตอร์… เลย

ไม่มีการคงอยู่:“แต่ฉันคิดว่ามันเป็นเหมือนห้องสนทนา…”

ต่างจากการดำเนินการ Redis ส่วนใหญ่ ซึ่งอาจเขียนลงดิสก์ Redispub/sub ไม่คงอยู่ ข้อความที่เผยแพร่จะถูกส่งต่อโดยตรงไปยังสมาชิกแล้วทิ้งโดยไม่มีการบันทึกในหน่วยความจำหรือออนดิสก์ของ Redis

บางครั้งอาจทำให้ผู้ใช้ใหม่ที่ได้ยินว่า Redis pub/sub is มักใช้ในการติดตั้งห้องสนทนา พวกเราหลายคนคิดว่าเครื่องมืออย่าง Slack เป็นห้องสนทนา คุณเข้าสู่ระบบและดูข้อความล่าสุดแล้วรับข้อความใหม่ทั้งหมด อันที่จริง "การดูข้อความล่าสุด" ไม่ได้เป็นส่วนหนึ่งของผับ/ย่อยเลย และต้องจัดการด้วยวิธีอื่น Pub/sub อำนวยความสะดวกในการส่งข้อความใหม่เท่านั้น ในแง่นี้ p/sub ก็เหมือนกับการสตรีมแบบสด เมื่อคุณเปิดใช้งาน คุณจะเริ่มได้รับข้อมูล แต่คุณไม่ได้เรียนรู้อะไรเกี่ยวกับสิ่งที่เกิดขึ้นก่อนที่คุณจะเปิด นอกเหนือจากนั้น:Internet Relay Chat (IRC) ใช้รูปแบบ pub/sub โดยไม่มีประวัติหรือการเก็บรักษาข้อความในตัว นั่นคือเหตุผลที่คำเปรียบเทียบห้องสนทนาจึงเป็นเรื่องธรรมดา

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

ไม่มีการรับประกันการจัดส่ง

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

ระบบการส่งข้อความอื่นๆ บางระบบใช้ใบตอบรับการอ่านหรือ "acks" หรืออาจเก็บบัฟเฟอร์สำหรับสมาชิกที่ป้องกันการขาดการเชื่อมต่อในช่วงเวลาสั้นๆ Redis เลือกตัวเลือกง่ายๆ ที่นี่:หากคุณพลาดข้อความ แสดงว่าคุณพลาดข้อความ ข้อความที่ ต้อง ถึงผู้รับจะต้องส่งด้วยวิธีอื่น

การแลกเปลี่ยนนี้ฟังดูแย่กว่าที่เป็นอยู่ การยกเลิกข้อความตอบรับและการบัฟเฟอร์เฉพาะผู้สมัครสมาชิกทำให้ Redis pub/sub ประมวลผลข้อความ มาก ได้อย่างรวดเร็วและมีหลายระบบที่ได้ประโยชน์จากการส่งข่าวสารในช่วงอากาศดี

ตอนนี้การปรับขนาดคลัสเตอร์ไม่มีประสิทธิภาพ…

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

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

คำตอบสั้น ๆ สำหรับสิ่งนี้คือใช้เฉพาะ pub/sub บนเซิร์ฟเวอร์ Redis แต่ละตัวหรือบนคลัสเตอร์เฉพาะขนาดเล็กของ pub/sub – ทั้งสองตัวเลือกนี้สามารถจัดการกับข้อความจำนวนมากได้ Redis Cluster ระยะยาวจะมีฟีเจอร์ที่ชาญฉลาดกว่าสำหรับการกำหนดเส้นทางข้อความเท่าที่จำเป็นเท่านั้น แต่ฟีเจอร์นั้นยังอยู่ในขั้นตอนการออกแบบ

สรุปผล

Redis pub/sub เป็นเครื่องมือที่มีประโยชน์สำหรับการปรับขนาดซอฟต์แวร์ การไม่มีคุณลักษณะแต่ละอย่างที่เราดูข้างต้นเป็นการแลกเปลี่ยนการออกแบบ ส่งผลให้ Redis ใช้งานง่ายและรวดเร็ว โดยต้องเสียการเป็นยาครอบจักรวาลสำหรับวัตถุประสงค์ในการส่งข้อความทั้งหมด

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

เมื่อภาพรวมระดับสูงเสร็จสมบูรณ์ คุณอาจพร้อมแล้วที่จะดูตัวอย่างโค้ดของ somepub/sub ลองดู Redis Pub/Sub:How To next.