จะประสาน cron job ระหว่างหลายโหนด NestJS ได้อย่างไร?

Question

IT Interview Practice · Accepted Answer

ก่อนอื่นต้องนิยามว่า “มีเพียง node เดียวรัน cronjob” หมายถึงอะไร **การป้องกันการทำงานพร้อมกันกับการป้องกันผลทางธุรกิจซ้ำเป็นคนละข้อกำหนด** Scheduler ร่วมช่วยประสานการทำงาน แต่ตัวงานต้องปลอดภัยแม้ crash แล้ว retry

ลองพิจารณางานออกใบแจ้งหนี้รายวันที่ deploy บน NestJS สาม node เราต้องการให้งานตามเวลาทำงาน โดยไม่สร้างใบแจ้งหนี้อีกใบเมื่อ worker เริ่มใหม่

## 1. เข้าใจว่าทำไมทุก node เริ่มงาน

แต่ละ instance ของแอปพลิเคชันลงทะเบียน cron callback ของตัวเอง เมื่อถึงเวลา ทุก instance จึงเริ่มได้อย่างอิสระ:

```text
00:00 -> Node A -> invoice task
      -> Node B -> invoice task
      -> Node C -> invoice task
```

ตัวแปร isRunning แบบ local มีอยู่ใน process เดียว NestJS waitForCompletion ป้องกัน callback ซ้อนกันใน instance นั้นได้ แต่ไม่ประสานกับ node อื่น ใส่ตัวแปรเดียวกันในทั้งสาม node ก็ยังเป็นการตัดสินใจแยกกันสามครั้ง ดู [การตั้งเวลางานใน NestJS](https://docs.nestjs.com/techniques/task-scheduling)

เราจึงต้องมีจุดร่วมในการตัดสินใจว่างานใดมีอยู่และใครมีสิทธิ์ประมวลผล

## 2. เลือกรูปแบบการประสานงาน

| สถานการณ์ | ทางเลือกที่ควรประเมิน | ความรับผิดชอบที่ยังเหลือ |
| --- | --- | --- |
| แพลตฟอร์มมีงานตามเวลาอยู่แล้ว | แยกการตั้งเวลาออกจาก web instance | กำหนดการทำงานซ้อน การกู้คืน และกรณีพลาดรอบ |
| ทีมใช้ BullMQ อยู่แล้ว | Job Scheduler ร่วมและ queue เฉพาะ | กำหนด concurrency ร่วมและ retry ที่ปลอดภัย |
| งานเดิมต้องอยู่บน node ของแอปพลิเคชัน | Lock หรือ lease ร่วม | จัดการเจ้าของ การหมดอายุ และ worker เก่าอย่างถูกต้อง |

สำหรับตัวอย่างใบแจ้งหนี้ หากมี Redis และ BullMQ อยู่แล้ว scheduler ร่วมที่ใช้ scheduler ID คงที่เป็นทางเลือกที่เหมาะสม แยกตารางเวลาออกจาก worker เพื่อไม่ให้การเพิ่ม web node สร้างตารางเวลาอิสระเพิ่ม

ใน BullMQ เวอร์ชันที่รองรับ ให้กำหนด global concurrency ของ queue เฉพาะเป็นหนึ่ง ซึ่งจำกัดจำนวน active job ข้าม worker ส่วน local concurrency หนึ่งต่อ worker ยังเปิดให้หลาย worker ทำคนละ job พร้อมกันได้ ดู [Global concurrency](https://docs.bullmq.io/guide/queues/global-concurrency)

กำหนดว่าจะทำอย่างไรหากงานเมื่อวานยังไม่เสร็จ: รอ ข้าม หรือรวมรอบ ระบุเขตเวลาและจะทำชดเชยวันที่พลาดหลังระบบหยุดหรือไม่

## 3. ปกป้องใบแจ้งหนี้ ไม่ใช่แค่ตัว job

สมมติว่า worker สร้างใบแจ้งหนี้แล้ว crash ก่อนบันทึกว่า job เสร็จ การกู้คืนอาจรันซ้ำทั้งที่มีใบแจ้งหนี้อยู่แล้ว

```text
[Create invoice] -> [Crash before completion]
                              |
                            [Retry]
                              |
                  [Same business key: reuse result]
```

ใช้ business key ที่คงที่ เช่น ลูกค้ารวมกับรอบบิล สำหรับงานในฐานข้อมูลภายใน unique constraint และ transaction ช่วยผูกการสร้างใบแจ้งหนี้กับระเบียนว่างานเสร็จแล้ว Retry จึงพบผลเดิมแทนการสร้างใบใหม่

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

## 4. เข้าใจขอบเขตของสิ่งที่ lock รับประกันได้

ต้องขอ shared lock แบบ atomic ใช้ token ระบุเจ้าของ กำหนดเวลาหมดอายุและต่ออายุ ปลด lock เฉพาะเมื่อ token ยังตรงกัน มิฉะนั้น worker เก่าอาจปลด lock ของ worker ใหม่

การหมดอายุทำให้มีอีกกรณี: worker ที่หยุดชั่วคราวกลับมาหลัง lease หมดอายุ ขณะ worker ใหม่ทำงานแล้ว การเขียนที่สำคัญอาจต้องใช้ fencing token ซึ่งเป็นเลขเจ้าของที่เพิ่มขึ้นและปลายทางตรวจเพื่อปฏิเสธ worker เก่า แค่ตั้ง timeout ยาวไม่ได้ขจัดความเสี่ยงนี้

ถ้าระบบประสานงานใช้ไม่ได้ ต้องตัดสินใจว่างานควรรอแทนการทำโดยไม่มีสิทธิ์ครอบครองหรือไม่ สำหรับงานที่มีผลสำคัญ การรอมักปลอดภัยกว่า

## 5. ทดสอบกรณีล้มเหลว

ทดสอบหลาย node, crash หลังสร้างใบแจ้งหนี้, หยุดนานกว่า lease, ขาดการเชื่อมต่อ Redis และ rolling deployment บันทึกวันที่ธุรกิจ worker ครั้งที่ลอง และผลลัพธ์ เพื่อแยกการลองซ้ำออกจากผลทางธุรกิจซ้ำ

**จำไว้:** ประสานตารางเวลา → จำกัดการทำงานร่วม → ทำให้การกระทำทางธุรกิจ retry ได้ปลอดภัย → ทดสอบกู้คืน “มี active job เดียว” ยังไม่พิสูจน์ว่ามีผลทางธุรกิจเพียงครั้งเดียว

สถานการณ์	ทางเลือกที่ควรประเมิน	ความรับผิดชอบที่ยังเหลือ
แพลตฟอร์มมีงานตามเวลาอยู่แล้ว	แยกการตั้งเวลาออกจาก web instance	กำหนดการทำงานซ้อน การกู้คืน และกรณีพลาดรอบ
ทีมใช้ BullMQ อยู่แล้ว	Job Scheduler ร่วมและ queue เฉพาะ	กำหนด concurrency ร่วมและ retry ที่ปลอดภัย
งานเดิมต้องอยู่บน node ของแอปพลิเคชัน	Lock หรือ lease ร่วม	จัดการเจ้าของ การหมดอายุ และ worker เก่าอย่างถูกต้อง

1. เข้าใจว่าทำไมทุก node เริ่มงาน

2. เลือกรูปแบบการประสานงาน

3. ปกป้องใบแจ้งหนี้ ไม่ใช่แค่ตัว job

4. เข้าใจขอบเขตของสิ่งที่ lock รับประกันได้

5. ทดสอบกรณีล้มเหลว

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