BullMQ มีข้อดีข้อเสียอะไร และควรใช้เมื่อใด?

Question

IT Interview Practice · Accepted Answer

BullMQ คือ job queue สำหรับ Node.js ที่ใช้ Redis เป็นที่เก็บข้อมูล หากจะประเมินว่าเหมาะหรือไม่ ให้เริ่มจาก **งานที่เสร็จหลังตอบ HTTP ได้ และต้องติดตามสถานะหรือลองใหม่**

ลองดูรายงานขนาดใหญ่ การสร้างรายงานภายใน request อาจทำให้ผู้ใช้รอจน timeout Queue ช่วยให้แอปพลิเคชันรับงาน คืน job ID แล้วแยกไปประมวลผล

## 1. ดูสิ่งที่เปลี่ยนเมื่องานย้ายเข้า queue

```text
[User] -> [API: submit job] -> [Redis / BullMQ] -> [Worker]
                |                                   |
          [Return job ID]                       [Saved report]
```

Producer ส่งงาน ส่วน worker ทำงาน ผู้ใช้ตรวจความคืบหน้าและดาวน์โหลดรายงานที่บันทึกไว้เมื่อพร้อม

รายงานยังต้องใช้เวลาประมวลผลเหมือนเดิม สิ่งที่ดีขึ้นคืออายุงานไม่ผูกกับการเปิด HTTP request ค้างไว้ และจัดการ worker แยกจาก API server ได้

## 2. จับคู่ประโยชน์กับข้อกำหนด

| ความต้องการ | ความสามารถของ BullMQ | สิ่งที่แอปพลิเคชันยังต้องตัดสินใจ |
| --- | --- | --- |
| ฟื้นจากข้อผิดพลาดชั่วคราว | Retry พร้อม backoff | ข้อผิดพลาดใดควรลองใหม่และหยุดเมื่อใด |
| ทำงานภายหลังหรือตามเวลา | Delayed job และ scheduling | ความแม่นยำของเวลาและพฤติกรรมหลังระบบหยุด |
| ควบคุมโหลดประมวลผล | Concurrency และ rate limit | ขีดจำกัดที่ปลอดภัยต่อฐานข้อมูลและบริการภายนอก |
| เพิ่มกำลังงานเบื้องหลัง | เพิ่ม worker | ระบบถัดไปสามารถรับโหลดที่เพิ่มได้หรือไม่ |

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

## 3. เข้าใจข้อแลกเปลี่ยนสำคัญด้านความถูกต้อง

Worker อาจบันทึกรายงานแล้ว crash ก่อนระบุว่า job เสร็จ Retry จึงอาจทำงานซ้ำ กรณีเดียวกันนี้ร้ายแรงกว่าสำหรับการหักเงินหรือส่งการแจ้งเตือน

ใช้ตัวระบุทางธุรกิจที่คงที่สำหรับงานที่ขอ เมื่อทำซ้ำด้วยตัวระบุเดิม ให้ใช้ผลเดิมหรือแทนที่ผลอย่างปลอดภัย แทนสร้างผลทางธุรกิจอีกครั้ง นี่คือ idempotency สำหรับผลภายนอก ใช้ความสามารถของผู้ให้บริการเมื่อมี และตรวจสอบผลที่ยังไม่แน่นอน ดู [Idempotent jobs](https://docs.bullmq.io/patterns/idempotent-jobs)

หากการบันทึกระเบียนฐานข้อมูลต้องสร้าง job ด้วย ให้คำนึงถึงช่องว่างระหว่างการเขียนสองครั้ง Outbox บันทึกคำสั่งใน transaction เดียวกับระเบียนธุรกิจ แล้ว publisher ค่อยส่งเข้า queue ภายหลัง การส่งอาจซ้ำได้ จึงยังต้องมี idempotency ใน worker

## 4. รวมการดูแล Redis และ worker เป็นต้นทุน

Redis เก็บงานที่รออยู่ จึงต้องสนใจ persistence นโยบายหน่วยความจำ และแผนกู้คืน กำหนดนโยบาย noeviction สำหรับ queue เพราะการลบ key เงียบ ๆ เพื่อคืนหน่วยความจำไม่เหมาะกับงานที่ต้องคงอยู่ ทดสอบกู้คืนจริง อย่าสรุปว่าปลอดภัยเมื่อแอปเริ่มใหม่แล้วจะครอบคลุม Redis ล้มเหลวทุกแบบ ดู [แนวทาง production](https://docs.bullmq.io/guide/going-to-production)

เก็บไฟล์รายงานใหญ่ในที่จัดเก็บที่เหมาะสม และส่งเพียง reference ใน job กำหนดอายุระเบียนงานที่เสร็จและล้มเหลวเพื่อควบคุมการใช้ Redis

งาน CPU หนักอาจบล็อก event loop ของ worker จนต่ออายุ lock ไม่ทัน Job อาจถูกมองว่า stalled และถูกประมวลผลอีก ใช้ worker thread หรือ processor ที่แยกออกอย่างเหมาะสม และติดตาม stalled job ดู [Stalled jobs](https://docs.bullmq.io/guide/jobs/stalled)

## 5. ให้คำแนะนำตามเงื่อนไข

- เลือก BullMQ เมื่อแอป Node.js ต้องมีงานเบื้องหลังที่ติดตามได้ มี retry และขยาย worker แยกกันได้ โดยทีมดูแล Redis อย่างเชื่อถือได้
- รักษางาน local เล็กน้อยให้เรียบง่าย เมื่อไม่ต้องบันทึกติดตามอย่างคงทนหรือทำงานอิสระ
- ประเมิน durable event log หากต้องการให้ consumer อิสระหลายตัว replay ระยะยาว มากกว่าทำงานใน queue ให้เสร็จ

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

**จำไว้:** BullMQ จัดการการประสานงานของ job แอปพลิเคชันรับผิดชอบความถูกต้องทางธุรกิจ และทีมยังต้องดูแลการทำงานของ queue

ความต้องการ	ความสามารถของ BullMQ	สิ่งที่แอปพลิเคชันยังต้องตัดสินใจ
ฟื้นจากข้อผิดพลาดชั่วคราว	Retry พร้อม backoff	ข้อผิดพลาดใดควรลองใหม่และหยุดเมื่อใด
ทำงานภายหลังหรือตามเวลา	Delayed job และ scheduling	ความแม่นยำของเวลาและพฤติกรรมหลังระบบหยุด
ควบคุมโหลดประมวลผล	Concurrency และ rate limit	ขีดจำกัดที่ปลอดภัยต่อฐานข้อมูลและบริการภายนอก
เพิ่มกำลังงานเบื้องหลัง	เพิ่ม worker	ระบบถัดไปสามารถรับโหลดที่เพิ่มได้หรือไม่

1. ดูสิ่งที่เปลี่ยนเมื่องานย้ายเข้า queue

2. จับคู่ประโยชน์กับข้อกำหนด

3. เข้าใจข้อแลกเปลี่ยนสำคัญด้านความถูกต้อง

4. รวมการดูแล Redis และ worker เป็นต้นทุน

5. ให้คำแนะนำตามเงื่อนไข

คำถามที่เกี่ยวข้อง