การออกแบบสถาปัตยกรรมคิวข้อความที่ปรับขนาดได้

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

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

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

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

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

ในระยะสั้น:

นี่เป็นปัญหาที่ยาก อย่าประดิษฐ์ล้อใหม่

มีเทคโนโลยีมากมายที่สามารถแก้ไขเลเยอร์คิวข้อความได้ พวกเขารวมถึง

• ZeroMQ
• RabbitMQ
• Apache Kafka
• Redis กับ BLPOP หรือ PUBSUB (ฉันถามว่าจะทำอย่างไรที่นี่ )
• การใช้งาน AMQP อื่น ๆ นอกเหนือจาก RabbitMQ

ฉันคิดว่ามันออกจากขอบเขตสำหรับผมที่จะหารือเกี่ยวกับข้อบกพร่องของแต่ละคนไม่น้อยเพราะผมไม่ได้จริงๆเรียกร้องความเชี่ยวชาญในการทำดีนี้ไอไม่ได้ใช้กระต่ายไอ

แม้ว่าคุณจะไม่ต้องการใช้เทคโนโลยีเหล่านี้อ่านเอกสารของพวกเขา

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

เรียนรู้เกี่ยวกับรูปแบบคิวการแลกเปลี่ยนของ RabbitMQ / AMQP การกำหนดเส้นทางอาจเกิดขึ้นกับคุณ - ได้รับการสนับสนุนจาก Redis PUBSUB แต่ฉันจำไม่ได้ว่าได้รับการสนับสนุนจาก ZeroMQ - และ fanouts เป็นสิ่งที่ร้านค้าของฉันใช้งานอยู่ .

วิธีการเลือกหนึ่ง

ฉันทำงานที่การเริ่มต้นซึ่ง SLA เป็นเรื่องปกติสำหรับเว็บแอป - การหยุดทำงานบางอย่างไม่เป็นไรตราบใดที่เราสามารถกู้คืนบริการได้อย่างรวดเร็วด้วยการสูญเสียข้อมูลเล็กน้อย เราไม่ต้องคิดเกี่ยวกับปัญหาการปรับขนาดเช่น Twitter หรือ Tumblr ดังนั้นเราจึงไม่ต้องคิดเกี่ยวกับปริมาณงาน ที่ถูกกล่าวว่าหากคุณกำลังใช้ SLA คล้ายกับของฉันการพิจารณาเหล่านี้จะคำนึงถึง:

• ห้องสมุดลูกค้าทำงานได้จริง? มันง่ายในการรักษาการเชื่อมต่อในพวกเขา? (ZeroMQ, Redis: ใช่ RabbitMQ: ไม่)
• การตรวจสอบและการจัดการง่ายจากเซิร์ฟเวอร์คอนโซลหรือไม่ (Redis: ใช่ RabbitMQ: ใช่ ZeroMQ: ไม่ใช่ที่ฉันจำได้ แต่เราไม่ได้ใช้มันนานขนาดนั้น)
• ไคลเอนต์สนับสนุนคิวภายในเพื่อให้การสูญหายของข้อมูลเพียงเล็กน้อยเกิดขึ้นในช่วงเวลาสั้น ๆ ? (ZeroMQ, Redis: ใช่ RabbitMQ: ไม่)

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