นี่คือสิ่งที่ฉันพบในขณะที่พยายามตอบคำถามเดียวกันนี้ อาจไม่ครอบคลุมและอาจไม่ถูกต้องในบางประเด็น
ในระยะสั้น RQ ได้รับการออกแบบให้เรียบง่ายกว่าเดิม คื่นช่ายได้รับการออกแบบให้มีความแข็งแรงมากขึ้น พวกเขายอดเยี่ยมทั้งคู่
- เอกสารประกอบ. เอกสารของ RQครอบคลุมโดยไม่ซับซ้อนและสะท้อนความเรียบง่ายโดยรวมของโครงการ - คุณจะไม่รู้สึกหลงทางหรือสับสน เอกสารของคื่นฉ่ายยังครอบคลุม แต่คาดว่าจะกลับมาเยี่ยมชมอีกครั้งเมื่อคุณตั้งค่าสิ่งต่างๆเป็นครั้งแรกเนื่องจากมีตัวเลือกมากเกินไปในการทำให้เป็นภายใน
การตรวจสอบ ดอกไม้ของคื่นฉ่ายและแผงควบคุม RQนั้นง่ายมากในการติดตั้งและให้ข้อมูลอย่างน้อย 90% ที่คุณต้องการ
การสนับสนุนนายหน้า คื่นช่ายเป็นผู้ชนะที่ชัดเจน RQ รองรับเฉพาะ Redis เท่านั้น ซึ่งหมายถึงเอกสารเกี่ยวกับ "นายหน้าคืออะไร" น้อยลง แต่ยังหมายความว่าคุณไม่สามารถเปลี่ยนโบรกเกอร์ได้ในอนาคตหาก Redis ไม่ทำงานให้คุณอีกต่อไป ยกตัวอย่างเช่นInstagram พิจารณาทั้ง Redis และ RabbitMQ กับคื่นฉ่าย นี่เป็นสิ่งสำคัญเนื่องจากโบรกเกอร์ที่แตกต่างกันมีการรับประกันที่แตกต่างกันเช่น Redis ไม่สามารถรับประกันได้ 100% ว่าข้อความของคุณจะถูกส่ง
ลำดับความสำคัญ RQs รุ่นคิวลำดับความสำคัญเป็นเรื่องง่ายและมีประสิทธิภาพ - แรงงานอ่านจากคิวในการสั่งซื้อ ขึ้นฉ่ายต้องใช้คนงานหลายคนเพื่อบริโภคจากคิวที่แตกต่างกัน ทั้งสองวิธีได้ผล
รองรับระบบปฏิบัติการ คื่นฉ่ายเป็นผู้ชนะที่ชัดเจนที่นี่เนื่องจาก RQ ทำงานบนระบบที่รองรับforkเช่นระบบ Unix เท่านั้น
รองรับภาษา RQ รองรับเฉพาะ Python ในขณะที่ Celery ให้คุณส่งงานจากภาษาหนึ่งไปยังภาษาอื่น
API คื่นฉ่ายมีความยืดหยุ่นสูงมาก (แบ็กเอนด์ผลลัพธ์หลายรูปแบบรูปแบบการกำหนดค่าที่ดีการรองรับผ้าใบเวิร์กโฟลว์) แต่โดยธรรมชาติแล้วพลังนี้อาจทำให้สับสนได้ ในทางตรงกันข้าม RQ api นั้นเรียบง่าย
รองรับงานย่อย ขึ้นฉ่ายรองรับงานย่อย (เช่นการสร้างงานใหม่จากภายในงานที่มีอยู่) ฉันไม่รู้ว่า RQ ทำหรือเปล่า
ชุมชนและความมั่นคง คื่นช่ายน่าจะเป็นที่ยอมรับมากขึ้น แต่ทั้งคู่เป็นโครงการที่มีการเคลื่อนไหว ในขณะที่เขียน Celery มีดาว ~ 3500 ดวงใน Github ในขณะที่ RQ มี ~ 2000 และทั้งสองโครงการแสดงให้เห็นถึงการพัฒนาที่กระตือรือร้น
ในความคิดของฉันคื่นฉ่ายไม่ซับซ้อนเท่าที่ชื่อเสียงอาจทำให้คุณเชื่อได้ แต่คุณจะต้อง RTFM
แล้วทำไมทุกคนถึงยอมแลกคื่นฉ่าย (เนื้อหาที่มีคุณสมบัติครบถ้วนมากกว่า) สำหรับ RQ? ในใจของฉันทุกอย่างลงไปที่ความเรียบง่าย ด้วยการ จำกัด ตัวเองไว้ที่ Redis + Unix ทำให้ RQ มีเอกสารประกอบที่ง่ายขึ้นโค้ดเบสที่ง่ายขึ้นและ API ที่ง่ายกว่า ซึ่งหมายความว่าคุณ (และผู้ที่อาจมีส่วนร่วมในโครงการของคุณ) สามารถให้ความสำคัญกับรหัสที่คุณสนใจแทนที่จะต้องเก็บรายละเอียดเกี่ยวกับระบบคิวงานไว้ในหน่วยความจำที่ใช้งานได้ เราทุกคนมีข้อ จำกัด เกี่ยวกับจำนวนรายละเอียดที่สามารถอยู่ในหัวของเราได้ในคราวเดียวและด้วยการลบความจำเป็นในการเก็บรายละเอียดคิวงานในนั้น RQ จะช่วยให้กลับไปที่รหัสที่คุณสนใจ ความเรียบง่ายนั้นมาพร้อมกับค่าใช้จ่ายของคุณสมบัติต่างๆเช่นคิวงานระหว่างภาษาการรองรับ OS แบบกว้างการรับประกันข้อความที่เชื่อถือได้ 100% และความสามารถในการเปลี่ยนนายหน้าข้อความได้อย่างง่ายดาย