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

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

ความสามารถของ CID ในการแจ้งเตือนแบบ Push ทันที

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

CID เป็นพารามิเตอร์แบบเลือกใช้ที่ใช้เพื่อ ระบุคำขอ Push ที่เฉพาะเจาะจง เมื่อมีการส่งคำขอซ้ำโดยใช้ CID เดิม:

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

คุณลักษณะสำคัญ

กรณีการใช้งาน

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

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

Single Push พร้อม 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
    }
  }'

            

Batch Push พร้อม 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
        }
      }
    ]
  }'

            

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

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

              
              {
  "msg_id": "2460001"
}

            

การ Push ซ้ำด้วย CID เดิม

              
              {
  "msg_id": "2460001" // ส่งกลับ msg_id จากการ Push ครั้งแรก
}

            

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

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

            

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

แนวทางปฏิบัติที่แนะนำ

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

Q: สามารถใช้ CID เดียวกันกับ appkeys ที่ต่างกันได้หรือไม่?
A: ได้ CID จำเป็นต้องไม่ซ้ำกันภายใต้ appkey เดียวกันเท่านั้น

Q: CID รับประกันความไม่ซ้ำกันในระดับสากลหรือไม่?
A: CID จำเป็นต้องไม่ซ้ำกันภายใต้ 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 ได้อย่างมีประสิทธิภาพ เพื่อสร้างระบบการแจ้งเตือนแบบ Push ที่มีความเสถียรมากขึ้น และแก้ปัญหาการ Push ซ้ำได้อย่างสมบูรณ์