อดีตวิศวกรโครงสร้างพื้นฐานของ Reddit เพิ่งแบ่งปันแนวทางของพวกเขาในการแก้ไขปัญหา distributed queue ที่รบกวนแพลตฟอร์มโซเชียลมีเดียมากว่าทศวรรษที่ผ่านมา บทความดังกล่าวสัญญาว่าจะให้ข้อมูลเชิงลึกเกี่ยวกับวิธีที่พวกเขาจัดการกับปัญหาที่โหวตของผู้ใช้ ความคิดเห็น และการส่งโพสต์อาจหายไปเมื่อระบบล้มเหลว อย่างไรก็ตาม ชุมชนทางเทคนิคได้ตั้งคำถามเกี่ยวกับความสมบูรณ์ของคำอธิบายและการนำเสนอโซลูชัน
ปัญหาเดิมที่ Reddit
ในช่วงแรกๆ ของ Reddit แพลตฟอร์มพึ่งพา RabbitMQ อย่างมากในฐานะ message broker สำหรับจัดการการโต้ตอบของผู้ใช้ เมื่อผู้ใช้โหวตโพสต์ การกระทำนั้นจะเข้าสู่ distributed queue ก่อนที่จะไปถึงฐานข้อมูล สถาปัตยกรรมนี้ให้การขยายตัวแนวนอนและการควบคุมการไหล แต่มาพร้อมกับปัญหาความน่าเชื่อถืออย่างมาก การล่มของระบบอาจส่งผลให้ข้อมูลสูญหาย และเมื่อ queue เองล่ม โหวตและความคิดเห็นของผู้ใช้จะหายไปเฉยๆ
วิศวกรอธิบายว่าสิ่งที่ Reddit ต้องการจริงๆ คือ durable queues ที่ checkpoint สถานะงานไปยังที่เก็บข้อมูลถาวรอย่าง PostgreSQL ระบบเหล่านี้รวม task queues เข้ากับ durable workflows ทำให้งานที่ล้มเหลวสามารถดำเนินต่อจากขั้นตอนสุดท้ายที่เสร็จสิ้นแล้ว แทนที่จะเริ่มใหม่หรือหายไปทั้งหมด
สถาปัตยกรรมเดิมของ Reddit (เมื่อ 15+ ปีที่แล้ว):
- Message Broker: RabbitMQ
- Cache: ระบบคล้าย Redis
- Database: PostgreSQL
- Flow: การกระทำของผู้ใช้ → Queue + Cache → การตอบสนองที่สำเร็จ → ตัวประมวลผล Queue → Database + การคำนวณใหม่
คำถามของชุมชนเกี่ยวกับช่องว่างทางเทคนิค
ชุมชนทางเทคนิคได้ชี้ให้เห็นปัญหาหลายประการในการนำเสนอของบทความ นักวิจารณ์สังเกตว่าบทความไม่เคยอธิบายอย่างชัดเจนว่าผู้เขียนแก้ปัญหาเดิมอย่างไร แม้จะมีหัวข้อที่น่าสนใจ บทความมุ่งเน้นไปที่การอธิบาย durable queues เป็นแนวคิด แต่ขาดรายละเอียดเฉพาะเจาะจงเกี่ยวกับการใช้งานหรือการเปรียบเทียบกับโซลูชันที่มีอยู่
ฉันพลาดอะไรไปหรือเปล่า หรือบทความไม่เคยกล่าวถึงหัวข้อเลย โพสต์นี้เป็นการอธิบาย durable queues ที่ดี แต่ไม่เคยบอกอย่างชัดเจนว่าเป็นโซลูชันสำหรับปัญหา distributed queue และไม่ได้นิยามปัญหาดังกล่าวอย่างเฉพาะเจาะจง
นอกจากนี้ นักพัฒนาที่มีประสบการณ์ได้ตั้งคำถามว่า RabbitMQ เองเป็นปัญหาหรือไม่ โดยสังเกตว่าแม้แต่ 15 ปีที่แล้ว RabbitMQ ก็รองรับ durability และ transactions พร้อมความสามารถ rollback บางคนแนะนำว่าปัญหาที่อธิบายอาจเกิดจากการใช้ RabbitMQ อย่างไม่ถูกต้องมากกว่าข้อจำกัดของเทคโนโลยีเอง
 |
|---|
| การจราจรติดขัดเป็นสัญลักษณ์ของความแออัดและความไม่มีประสิทธิภาพที่เห็นในการจัดการ distributed queue management สะท้อนถึงความกังวลของชุมชนต่อแนวทางแก้ไขของบทความต้นฉบับ |
การอภิปราย Durable Workflows
บทความเปลี่ยนโฟกัสไปที่ durable workflows อย่างมาก ซึ่งแตกต่างจาก durable queues ธรรมดา Durable workflows ช่วยให้นักพัฒนาเขียนโค้ดที่สามารถหยุดชั่วคราวและดำเนินต่อการทำงานข้ามความล้มเหลวของระบบ โดยรักษาสถานะในที่เก็บข้อมูลถาวร เทคโนโลยีนี้ได้รับความนิยมกับแพลตฟอร์มอย่าง Temporal, DBOS, Inngest และ Restate ที่เสนอการใช้งานต่างๆ
อย่างไรก็ตาม สมาชิกชุมชนสังเกตว่า durable workflows ต้องการให้นักพัฒนาปรับโครงสร้างโค้ดของพวกเขารอบ custom async runtimes และการเขียนโปรแกรมแบบ callback-style นี่แสดงถึงการเปลี่ยนแปลงทางสถาปัตยกรรมที่สำคัญซึ่งเกินกว่าการทำให้ queues เชื่อถือได้มากขึ้น
หมายเหตุ: Durable workflows เป็นระบบที่สามารถหยุดชั่วคราวและดำเนินต่อกระบวนการที่ทำงานนานข้ามความล้มเหลวของระบบโดยบันทึกสถานะไปยังที่เก็บข้อมูลถาวรที่จุด checkpoint สำคัญ
แพลตฟอร์ม Durable Queue ที่กล่าวถึง:
- Temporal (https://temporal.io/)
- DBOS (https://www.dbos.dev/)
- Inngest (https://www.inngest.com/)
- Restate (https://restate.dev/)
 |
|---|
| โค้ด Python ตัวอย่างแสดงวิธีการใช้งาน durable queueing ซึ่งเป็นส่วนสำคัญของการปรับโครงสร้าง workflows ตามที่กล่าวไว้ในบทความ |
การแลกเปลี่ยนประสิทธิภาพและทางเลือกสมัยใหม่
การอภิปรายเผยให้เห็นข้อพิจารณาสำคัญเกี่ยวกับเมื่อใดควรเลือก durable queues มากกว่าโซลูชันแบบดั้งเดิม Durable queues โดยทั่วไปใช้ฐานข้อมูลเชิงสัมพันธ์อย่าง PostgreSQL สำหรับทั้ง message brokering และการจัดเก็บ ซึ่งให้การรับประกันที่แข็งแกร่งกว่า แต่อาจมี throughput ต่ำกว่าเมื่อเปรียบเทียบกับโซลูชันใน memory อย่าง Redis
ชุมชนยังตั้งคำถามเกี่ยวกับวิธีที่แนวทางนี้เปรียบเทียบกับแพลตฟอร์ม streaming สมัยใหม่อย่าง Kafka ซึ่งสามารถให้ทั้ง durability และประสิทธิภาพสูง บางคนโต้แย้งว่าการเลือกระหว่างเทคโนโลยี queuing ต่างๆ ขึ้นอยู่กับ use cases เฉพาะเจาะจงและรายละเอียดการใช้งานมากกว่าข้อจำกัดทางสถาปัตยกรรมพื้นฐาน
ข้อแลกเปลี่ยนทางเทคนิคที่สำคัญ:
- คิวแบบดั้งเดิม: ประสิทธิภาพสูง, การจัดเก็บในหน่วยความจำ ( Redis ), มีความเสี่ยงในการสูญเสียข้อมูล
- คิวแบบทนทาน: ประสิทธิภาพต่ำกว่า, การจัดเก็บแบบถาวร ( PostgreSQL ), รับประกันความทนทานของข้อมูล
- ประสิทธิภาพ: คิวแบบทนทานเหมาะสำหรับงานที่มีปริมาณต่ำแต่มีความสำคัญต่อธุรกิจ คิวแบบดั้งเดิมเหมาะสำหรับงานที่มีปริมาณสูงและขนาดเล็ก
บทสรุป
แม้ว่าบทความต้นฉบับจะมีเป้าหมายเพื่อแบ่งปันบทเรียนที่ได้จากการแก้ปัญหา distributed queue ที่ Reddit แต่กลับจุดประกายการอภิปรายที่กว้างขึ้นเกี่ยวกับวิวัฒนาการของเทคโนโลジี message queuing และการแลกเปลี่ยนที่เกี่ยวข้องในแนวทางต่างๆ การตอบสนองของชุมชนเน้นย้ำถึงความสำคัญของการให้รายละเอียดทางเทคนิคที่เป็นรูปธรรมและการยอมรับภูมิทัศน์ที่สมบูรณ์ของโซลูชันที่มีอยู่เมื่ออภิปรายความท้าทายด้านโครงสร้างพื้นฐาน การสนทนายังคงพัฒนาต่อไปรอบแนวปฏิบัติที่ดีที่สุดสำหรับการสร้างระบบกระจายที่เชื่อถือได้ในแอปพลิเคชันสมัยใหม่
อ้างอิง: How I solved a distributed queue problem after 15 years