วิธีหลีกเลี่ยงการส่งการแจ้งเตือนซ้ำ: การวิเคราะห์เชิงลึกของฟีเจอร์ CID

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

ฟีเจอร์ CID ในการพุชแบบทันที

คุณสมบัติหลัก

CID เป็นพารามิเตอร์เสริม ใช้สำหรับระบุคำขอพุชแต่ละครั้ง เมื่อใช้ CID เดิมในการร้องขอซ้ำ:

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

คุณสมบัติสำคัญ

กรณีใช้งานที่เหมาะสม

1. การลองส่งซ้ำเมื่อเครือข่ายมีปัญหา: ใช้ CID เดิมในการลองส่งซ้ำ
2. รับประกัน Idempotency: มั่นใจว่าข้อความเดียวกันจะไม่ถูกส่งซ้ำ
3. ติดตามคำขอ: ใช้ CID เพื่อติดตามสถานะของการพุชแต่ละครั้ง

ตัวอย่างคำขอ

พุชเดี่ยวพร้อม CID

              
              curl --insecure -X POST -v https://pushapi-sgp.engagelab.com/v4/push \
  -H "Content-Type: application/json" \
  -u "AppKey:MasterSecret" \
  -d '{
    "options": {
      "cid": "order-notify-20230701-001",
      "time_to_live": 60
    }
  }'

            

พุชแบบกลุ่มพร้อม CID

              
              curl --insecure -X POST -v https://pushapi-sgp.engagelab.com/v4/push/batch/regid \
  -H "Content-Type: application/json" \
  -u "AppKey:MasterSecret" \
  -d '{
    "requests": [
      {
        "options": {
          "cid": "user-12345-notification",
          "time_to_live": 60
        }
      }
    ]
  }'

            

การจัดการการตอบกลับ

พุชครั้งแรกสำเร็จ

              
              {
  "msg_id": "2460001"
}

            

พุชซ้ำด้วย CID เดิม

              
              {
  "msg_id": "2460001" // คืนค่า msg_id ของการส่งครั้งแรก
}

            

CID รูปแบบไม่ถูกต้อง

              
              {
  "error": {
    "code": 23003,
    "message": "CID format does not meet requirements"
  }
}

            

คำอธิบายรหัสข้อผิดพลาด

แนวทางปฏิบัติที่ดีที่สุด

1. ธุรกิจสำคัญควรใช้ CID: เช่น การแจ้งเตือนการชำระเงิน แจ้งเตือนสำคัญ ฯลฯ
2. สร้างรหัสที่มีความหมาย: เช่น businessType-userID-timestamp (เช่น payment-12345-202307011030)
3. กลไกลองส่งซ้ำ: เมื่อเกิดข้อผิดพลาดเครือข่าย ใช้ CID เดิมในการลองส่งซ้ำ
4. พุชแบบกลุ่มใช้ CID แยกแต่ละรายการ: เพื่อความสะดวกในการติดตาม
5. ฝั่งไคลเอนต์บันทึก CID: เพื่อช่วยในการขจัดข้อความซ้ำและตรวจสอบสถานะ

ฟีเจอร์ CID ในงานที่ตั้งเวลา

คุณสมบัติหลัก

CID ใช้ได้กับการสร้างงานที่ตั้งเวลา เพื่อป้องกันการสร้างงานซ้ำ:

• หากใช้ CID เดิมซ้ำ ระบบจะคืนค่า schedule_id ที่เคยสร้างไว้
• ป้องกันระบบสร้างงานที่ตั้งเวลาเดียวกันซ้ำ

คุณสมบัติสำคัญ

ตัวอย่างคำขอ

              
              curl --insecure -X POST -v https://pushapi-sgp.engagelab.com/v4/schedules \
  -H "Content-Type: application/json" \
  -u "AppKey:MasterSecret" \
  -d '{
    "cid": "daily-reminder-202307",
    "trigger": {
      "daily": {
        "start": "2023-07-01",
        "time": "09:00:00"
      }
    }
  }'

            

การจัดการการตอบกลับ

สร้างครั้งแรกสำเร็จ

              
              {
  "schedule_id": "0123456789"
}

            

สร้างซ้ำด้วย CID เดิม

              
              {
  "schedule_id": "0123456789" // คืนค่า schedule_id ของการสร้างครั้งแรก
}

            

แนวทางปฏิบัติที่ดีที่สุด

1. รหัสงานตามรอบเวลา: เพิ่มข้อมูลรอบเวลาใน CID (เช่น weekly-report-2023w27)
2. สรุปพารามิเตอร์งานใน CID: ใส่ hash ของพารามิเตอร์สำคัญ (เช่น birthday-reminder-md5(params))
3. ระบบกระจายใช้ CID เดียวกัน: ป้องกันการสร้างงานซ้ำจากหลายอินสแตนซ์
4. อัปเดตงานใช้ CID ใหม่: เมื่อมีการเปลี่ยนแปลงงาน

กระบวนการจัดการของ EngageLab

graph TD
    A[Receive Request] --> B{Contains CID?}
    B -->|Yes| C[Query Redis]
    B -->|No| D[Normal Processing]
    C --> E{CID Exists?}
    E -->|Yes| F[Return Stored msg_id/schedule_id]
    E -->|No| G[Process Request]
    G --> H[Store CID → ID Mapping]
    H --> I[Return New ID]

คำถามที่พบบ่อย

Q: ทำไม CID มีอายุการใช้งาน 1 ชั่วโมง?
A: เพียงพอสำหรับกรณีลองส่งซ้ำทั่วไป และป้องกันการเก็บข้อมูลไม่จำกัด ธุรกิจสำคัญสามารถขยายระยะเวลาขจัดซ้ำได้ด้วย log ของตนเอง

Q: สามารถใช้ CID เดียวกันข้าม appkey ได้หรือไม่?
A: ได้ CID ต้องไม่ซ้ำกันเฉพาะภายใต้ appkey เดียวกัน

Q: CID ต้องไม่ซ้ำกันทั่วโลกหรือไม่?
A: ไม่จำเป็น ต้องไม่ซ้ำกันเฉพาะภายใต้ appkey เดียวกันเท่านั้น

Q: ตรวจสอบรูปแบบ CID อย่างไร?
A: ใช้ regular expression: /^[a-zA-Z0-9_-]{1,64}$/

สรุป

การใช้พารามิเตอร์ CID อย่างถูกต้องจะช่วยให้คุณ:

1. ✅ ป้องกันข้อความซ้ำจากการลองส่งซ้ำในเครือข่าย
2. ✅ รับประกัน idempotency สำหรับข้อความธุรกิจสำคัญ
3. ✅ ลดความซับซ้อนของการติดตามข้อความในระบบกระจาย
4. ✅ เพิ่มความน่าเชื่อถือของระบบโดยรวม

ข้อแนะนำสำคัญ:

• ข้อความธุรกิจสำคัญควรใช้ CID
• ใช้รูปแบบชื่อ business-entity-time
• ฝั่งไคลเอนต์ควรมีตรรกะขจัดซ้ำตาม CID
• ตรวจสอบรหัสข้อผิดพลาดที่เกี่ยวข้องกับ CID

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