Offline Queue: หลักการ กลยุทธ์ และกลไกการทำงาน

คิวออฟไลน์คืออะไร?

Offline Queue คือชุดคำสั่งของการดำเนินการ (สร้าง อัปเดต ลบ) ที่แอปพลิเคชันบันทึกในเครื่องเมื่ออุปกรณ์ไม่สามารถเข้าถึงเครือข่ายได้ เมื่อกู้คืนการเชื่อมต่อแล้ว คิวจะส่งการดำเนินการไปยังเซิร์ฟเวอร์ในลำดับเดียวกับที่ผู้ใช้ดำเนินการ

ลองนึกภาพสถานการณ์: ผู้ใช้แอปส่งข้อความพิมพ์ข้อความในรถไฟใต้ดินโดยไม่มีอินเทอร์เน็ต การแตะ «ส่ง» แต่ละครั้งจะถูกเพิ่มไปยัง Offline Queue เมื่อรถไฟออกจากอุโมงค์และเครือข่ายพร้อมใช้งาน ข้อความทั้งหมดจะถูกส่งโดยอัตโนมัติ ประสบการณ์ผู้ใช้ — ราบรื่น: พวกเขาไม่สังเกตว่าออฟไลน์อยู่ ยกเว้นความล่าช้าเล็กน้อยในการส่ง

ตามข้อมูลของ Uber Engineering (2024) คิวออฟไลน์ของพวกเขาประมวลผลมากกว่า 2 ล้านการดำเนินการต่อวันในภูมิภาคที่มีคุณภาพการเชื่อมต่อต่ำ คิวใช้พื้นที่จัดเก็บในเครื่อง Room ด้วยลำดับ FIFO และกลไกการส่งมอบที่รับประกันแบบ exactly-once

data class QueuedOperation(
    val id: String,
    val type: OperationType,
    val endpoint: String,
    val payload: String,
    val timestamp: Long,
    val retryCount: Int = 0,
    val idempotencyKey: String
)

แต่ละการดำเนินการมีข้อมูลทั้งหมดที่จำเป็นสำหรับการส่งซ้ำ: ปลายทาง เนื้อหาคำขอ การประทับเวลา และ idempotencyKey ฐานข้อมูล Room รับประกันความคงทนของคิวเมื่อเริ่มแอปใหม่และระบบปฏิบัติการล่ม

ทำไมต้องมีคิวการดำเนินการในแอปมือถือ

การรับประกันการส่งมอบ — วัตถุประสงค์หลักของคิว ผู้ใช้ต้องมั่นใจว่าการกระทำของตน (การส่งข้อความ การถูกใจ การสั่งซื้อ) จะเสร็จสมบูรณ์ แม้ว่าเครือข่ายจะไม่พร้อมใช้งานในขณะนั้นก็ตาม Offline Queue พร้อมกลไกการลองใหม่รับประกันการส่งมอบในที่สุด

UX ที่ดีขึ้นในสภาพการเชื่อมต่อที่ไม่ดี — ตามรายงาน GSMA Mobile Economy Report (2025) ผู้ใช้มือถือประมาณ 40% ทั่วโลกมีการเชื่อมต่ออินเทอร์เน็ตที่ไม่เสถียร Offline Queue ทำให้แอปสามารถใช้งานได้ในรถไฟใต้ดิน ลิฟต์ พื้นที่ห่างไกล — ทุกที่ที่การเชื่อมต่อไม่ต่อเนื่อง

ลดการสูญเสียข้อมูล — หากไม่มีคิว การกระทำทั้งหมดที่ทำแบบออฟไลน์จะสูญหายไป ผู้ใช้อาจกรอกแบบฟอร์มยาว แตะ «ส่ง» และเห็นข้อผิดพลาดเครือข่าย — ข้อมูลที่ป้อนทั้งหมดจะสูญหาย Offline Queue บันทึกข้อมูลและส่งเมื่อมีโอกาสแรก การบันทึกอัตโนมัติใน Google Docs เป็นตัวอย่างคลาสสิกของคิวออฟไลน์สำหรับเอกสาร

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

สถาปัตยกรรมคิวออฟไลน์: การจัดเก็บและการประมวลผล

สามชั้นของคิว: พื้นที่จัดเก็บ (ความคงทน), ตัวจัดตารางเวลา (scheduler) และตัวดำเนินการ (executor) พื้นที่จัดเก็บ — Room พร้อมตาราง QueuedOperation ตัวจัดตารางเวลา — WorkManager (Android) หรือ BGTaskScheduler (iOS) ที่เริ่มการซิงโครไนซ์เมื่อเครือข่ายพร้อมใช้งาน ตัวดำเนินการ — ตัววนซ้ำ FIFO แบบตามลำดับที่ส่งการดำเนินการทีละรายการ

ลำดับการประมวลผล — สำคัญอย่างยิ่งต่อความสอดคล้องของข้อมูล หากผู้ใช้สร้างระเบียนแล้วแก้ไข การดำเนินการทั้งสองต้องส่งในลำดับเดียวกัน มิฉะนั้น เซิร์ฟเวอร์จะได้รับการอัปเดตของระเบียนที่ไม่มีอยู่ก่อน — เกิดข้อผิดพลาด FIFO ตามลำดับ — ลำดับที่เข้มงวดพร้อมการควบคุมการพึ่งพาระหว่างการดำเนินการ

กลยุทธ์การรวม — หากคิวมี CREATE ตามด้วย DELETE ของอ็อบเจกต์เดียวกันทันที การดำเนินการทั้งสองสามารถลบได้โดยไม่ต้องส่ง: สถานะสุดท้ายคืออ็อบเจกต์ไม่ได้ถูกสร้างขึ้น ในทำนองเดียวกัน CREATE + UPDATE สามารถรวมเป็น CREATE เดียวกับข้อมูลล่าสุดได้ การเพิ่มประสิทธิภาพคิว ช่วยลดจำนวนคำขอ HTTP และเร่งการซิงโครไนซ์

ตามข้อมูลของ Android Developers (2025) WorkManager เป็นวิธีที่ต้องการในการจัดการ Offline Queue บน Android: รับประกันการทำงานแม้หลังจากรีสตาร์ทอุปกรณ์ รองรับข้อจำกัดเครือข่าย และอนุญาตให้กำหนดค่านโยบายการลองใหม่ผ่าน NetworkType.CONNECTED

class SyncWorker(
    private val context: Context,
    private val params: WorkerParameters
) : CoroutineWorker(context, params) {

    override suspend fun doWork(): Result = runCatching {
        queueRepository.processNextBatch(batchSize = 10)
        Result.success()
    }.getOrDefault(Result.retry())
}

CoroutineWorker ประมวลผลชุดการดำเนินการและส่งคืน Result.retry() เมื่อเกิดข้อผิดพลาด — WorkManager ลองใหม่โดยอัตโนมัติด้วย backoff แบบเลขชี้กำลัง นี่เป็นวิธีที่ง่ายที่สุดในการรับ Offline Queue ที่เชื่อถือได้บน Android

กลยุทธ์การลองใหม่: exponential backoff และนโยบายการลองใหม่

Exponential Backoff — กลยุทธ์การลองใหม่มาตรฐานด้วยช่วงเวลาที่เพิ่มขึ้น: 2 วินาที, 4 วินาที, 8 วินาที, 16 วินาที และต่อไปจนถึงเกณฑ์สูงสุด ซึ่งป้องกันการโอเวอร์โหลดซ้ำของเซิร์ฟเวอร์หากเซิร์ฟเวอร์ไม่พร้อมใช้งานชั่วคราว ไลบรารี Java Resilience4j (2024) มีการใช้งาน Retry ที่พร้อมใช้งานพร้อม backoff ที่ปรับแต่งได้

จำนวนครั้งสูงสุด — พารามิเตอร์ที่สำคัญ หากหลังจากลอง 5–10 ครั้งการดำเนินการล้มเหลว การลองเพิ่มเติมจะสิ้นเปลืองและไร้ประโยชน์ dead letter queue ได้รับการแนะนำ: หลังจากหมดจำนวนครั้ง การดำเนินการจะถูกย้ายไปยังตารางแยกต่างหากสำหรับการวิเคราะห์ด้วยตนเอง ตามข้อมูลของ Microsoft Patterns & Practices (2024) dead letter queue ช่วยลดความซับซ้อนในการแก้ไขปัญหาการซิงโครไนซ์และป้องกันไม่ให้การดำเนินการที่ผิดพลาดบล็อกคิว

Jitter — การแปรผันแบบสุ่ม — การเพิ่มตัวเลขสุ่มลงในช่วงเวลา backoff หากอุปกรณ์หนึ่งพันเครื่องกู้คืนเครือข่ายพร้อมกันหลังจากหยุดทำงาน อุปกรณ์ทั้งหมดจะเริ่มซิงโครไนซ์พร้อมกัน Jitter จะกระจายออกไปตามเวลา ป้องกัน Cache Stampede บนเซิร์ฟเวอร์ Jitter เต็มรูปแบบ: delay = random(0, backoff) — แนะนำโดย AWS (2024) สำหรับไคลเอ็นต์ API

การแก้ไขข้อขัดแย้ง: วิธีแก้ไขการชนกันของข้อมูล

Last Write Wins (LWW) — กลยุทธ์ที่ง่ายที่สุด: ในกรณีที่เกิดข้อขัดแย้ง การดำเนินการที่มีการประทับเวลาล่าสุดจะเป็นฝ่ายชนะ LWW ต้องการการซิงโครไนซ์เวลา — การประทับเวลาต้องสร้างบนเซิร์ฟเวอร์หรือใช้นาฬิกาแบบลอจิคัล (นาฬิกา Lamport) ข้อเสีย: ข้อมูลของผู้ใช้อาจถูกเขียนทับโดยข้อมูลของผู้ใช้อื่นโดยไม่มีการเตือน

OT (การแปลงเชิงปฏิบัติการ) — อัลกอริทึมที่ใช้โดย Google Docs และ Figma สำหรับการแก้ไขร่วมกันแบบเรียลไทม์ รวมถึงโหมดออฟไลน์ OT แปลงการดำเนินการเพื่อให้สามารถนำไปใช้กับสถานะเอกสารใดๆ ก็ได้ รับประกันความสอดคล้องโดยไม่ต้องล็อก CRDT (ประเภทข้อมูลจำลองแบบไร้ข้อขัดแย้ง) — ทางเลือกของ OT ที่กำลังได้รับความนิยมในแอปมือถือ: ข้อมูลถูกจัดโครงสร้างเพื่อให้ข้อขัดแย้งสามารถแก้ไขได้ทางคณิตศาสตร์โดยไม่ต้องใช้เซิร์ฟเวอร์กลาง

การรวมแบบกำหนดเอง — สำหรับแอปที่มีโมเดลข้อมูลง่าย (บันทึก, รายชื่อติดต่อ) สามารถใช้กฎการรวมแบบกำหนดเองได้ ตัวอย่างเช่น สำหรับบันทึก: หากข้อความถูกแก้ไขในสองเวอร์ชัน ให้รวมเป็นข้อความต่อเนื่องกับตัวคั่น ข้อขัดแย้งที่ผู้ใช้แก้ไข — หากการรวมอัตโนมัติเป็นไปไม่ได้ ให้แสดงทั้งสองเวอร์ชันแก่ผู้ใช้และให้เลือก Dropbox (2024) ใช้วิธีนี้สำหรับข้อขัดแย้งของไฟล์ออฟไลน์ โดยสร้างสำเนาด้วยคำนำหน้า «Conflicted Copy»

Idempotency keys — การป้องกันการทำซ้ำ

Idempotency Key — ตัวระบุการดำเนินการที่ไม่ซ้ำกันซึ่งเซิร์ฟเวอร์ใช้ตรวจจับคำขอที่ซ้ำกัน หากไคลเอ็นต์ส่งคำขอเดียวกันด้วยคีย์เดียวกัน เซิร์ฟเวอร์จะส่งคืนผลลัพธ์ของการดำเนินการที่เสร็จสมบูรณ์แล้วโดยไม่ต้องดำเนินการอีก ซึ่งมีความสำคัญอย่างยิ่งสำหรับ Offline Queue ที่การส่งซ้ำอาจเกิดขึ้นเนื่องจากข้อผิดพลาดของเครือข่าย

รูปแบบของ idempotency key คือ UUID หรือแฮชของพารามิเตอร์คำขอ เซิร์ฟเวอร์ต้องเก็บ คีย์ที่เสร็จสมบูรณ์พร้อมกับผลลัพธ์เป็นระยะเวลาหนึ่ง (ปกติ 24 ชั่วโมง) เพื่อตรวจจับรายการซ้ำ Stripe API (2024) เป็นตัวอย่างอ้างอิง: คีย์ถูกส่งในส่วนหัว Idempotency-Key และคำขอซ้ำด้วยคีย์เดียวกันจะส่งคืนการตอบสนองที่แคชไว้

การสร้างฝั่งไคลเอ็นต์ — คีย์ถูกสร้างบนไคลเอ็นต์ก่อนส่งการดำเนินการและเก็บในตาราง QueuedOperation เมื่อลองใหม่ คีย์จะไม่เปลี่ยนแปลง สถาปัตยกรรม exactly-once — การรวมกันของ idempotency key บนไคลเอ็นต์และการขจัดรายการซ้ำบนเซิร์ฟเวอร์เป็นวิธีเดียวที่จะรับประกันว่าการดำเนินการจะไม่ถูกดำเนินการสองครั้ง

fun createOperation(type: OperationType, payload: String): QueuedOperation =
    QueuedOperation(
        id = UUID.randomUUID().toString(),
        type = type,
        endpoint = type.endpoint,
        payload = payload,
        timestamp = currentTimeMillis(),
        idempotencyKey = UUID.randomUUID().toString()
    )

แต่ละการดำเนินการได้รับ UUID สองอัน: อันหนึ่ง — ตัวระบุระเบียนในคิว อันที่สอง — idempotency key สำหรับเซิร์ฟเวอร์ การขจัดรายการซ้ำฝั่งเซิร์ฟเวอร์ โดย idempotencyKey รับประกันว่าแม้ในการส่งซ้ำ คำสั่งซื้อจะไม่ถูกทำซ้ำ