Sync Engine: แนวคิดหลัก ประเภท และกลไกการทํางาน

กลไกการซิงค์คืออะไร?

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

Sync Engine สามารถเป็น แบบในตัว (Firebase Firestore, Couchbase Lite, Realm) หรือ แบบกําหนดเอง — ที่เขียนขึ้นสําหรับตรรกะทางธุรกิจเฉพาะ เอ็นจิ้นในตัวมีฟังก์ชันการทํางานแบบ offline-first และการแก้ไขข้อขัดแย้งพร้อมใช้งาน เอ็นจิ้นแบบกําหนดเองให้การควบคุมรูปแบบข้อมูล โปรโตคอลการซิงค์ และนโยบายข้อขัดแย้งอย่างสมบูรณ์

ตาม Sravana Karthik (2024) ผู้เขียน «Mobile Sync Engine Design Patterns» Sync Engine แบบกําหนดเองเหมาะสมสําหรับแอปที่มีตรรกะทางธุรกิจซับซ้อน (การเงิน สุขภาพ IoT) ซึ่งกฎการรวมแบบกําหนดเองมีความสําคัญ สําหรับสถานการณ์ทั่วไป (บันทึก, แชท, ฟีด) Firestore หรือ Realm ในตัวก็เพียงพอ

interface SyncEngine {
    suspend fun pull(lastSyncTimestamp: Long): SyncResult
    suspend fun push(operations: List<QueuedOperation>): PushResult
    suspend fun resolve(conflicts: List<Conflict>): ResolutionResult
    fun observeSyncState(): Flow<SyncState>
}

อินเทอร์เฟซนี้อธิบายสัญญาขั้นต่ําของ Sync Engine: pull (โหลดการเปลี่ยนแปลงจากเซิร์ฟเวอร์), push (ส่งการเปลี่ยนแปลงในเครื่อง), resolve (จัดการข้อขัดแย้ง) และ observe (ตรวจสอบสถานะการซิงค์) นามธรรมนี้ช่วยให้เปลี่ยนการใช้งานได้โดยไม่ต้องแก้ไขเลเยอร์การนําเสนอ

ประเภทการซิงค์: เต็ม, เพิ่มหน่วย และพุช

การซิงค์แบบเต็ม (Full sync) — แต่ละเซสชันโหลดชุดข้อมูลทั้งหมดจากเซิร์ฟเวอร์ ใช้งานง่าย แต่ไม่สามารถยอมรับได้สําหรับปริมาณมาก: การดาวน์โหลด 10,000 เรคคอร์ดทุกครั้งที่เปิดแอปจะสิ้นเปลืองปริมาณการใช้งานและแบตเตอรี่ การซิงค์แบบเต็มเหมาะสมสําหรับข้อมูลอ้างอิง (รายชื่อประเทศ) ที่มีการอัปเดตน้อยครั้ง

การซิงค์แบบเพิ่มหน่วย — เฉพาะเรคคอร์ดที่เปลี่ยนแปลงตั้งแต่การซิงค์ครั้งล่าสุดเท่านั้นที่ถูกถ่ายโอน เซิร์ฟเวอร์เก็บประทับเวลาการเปลี่ยนแปลงล่าสุดสําหรับแต่ละเรคคอร์ดหรือทั้งชุด ไคลเอ็นต์ส่ง lastSyncTimestamp และรับเฉพาะเรคคอร์ดที่มี updated_at > ค่านั้น ตาม Instagram Engineering (2024) การซิงค์แบบเพิ่มหน่วยลดปริมาณข้อมูลที่ถ่ายโอนลง 97% เมื่อเทียบกับการซิงค์แบบเต็ม

การซิงค์แบบพุช (เซิร์ฟเวอร์เริ่มต้น) — เซิร์ฟเวอร์แจ้งให้ไคลเอ็นต์ทราบถึงความจําเป็นในการซิงค์ผ่าน FCM (Firebase Cloud Messaging), WebSocket หรือ SSE (Server-Sent Events) ไคลเอ็นต์ไม่ต้องสิ้นเปลืองทรัพยากรกับการสอบถามเป็นระยะ การซิงค์แบบพุชเป็นตัวเลือกที่เหมาะสมที่สุดสําหรับแอปเรียลไทม์: แชท, การแจ้งเตือน, ไลค์ Google Firebase Firestore ใช้ WebSocket สําหรับการซิงค์แบบเรียลไทม์โดยมีการสํารองอัตโนมัติเป็น HTTP polling

แนวทางแบบผสม — การรวมประเภท: การซิงค์แบบเต็มสําหรับข้อมูลพื้นฐานเมื่อเริ่มแอป, การซิงค์แบบเพิ่มหน่วยสําหรับการอัปเดต และสําหรับเหตุการณ์สําคัญ — การซิงค์แบบพุชผ่าน FCM ซึ่งให้ทั้งความเร็วและการประหยัดทรัพยากร

การซิงค์แบบเพิ่มหน่วย — จุดตรวจสอบและเดลต้าทํางานอย่างไร

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

การซิงค์แบบเดลต้า — เซิร์ฟเวอร์คํานวณความแตกต่างระหว่างสถานะข้อมูลปัจจุบันกับสแนปชอตที่ไคลเอ็นต์เห็นครั้งล่าสุด แทนที่จะส่งเรคคอร์ดทั้งหมด เฉพาะการดําเนินการ (insert, update, delete) เท่านั้นที่ถูกถ่ายโอน ซึ่งมีประสิทธิภาพโดยเฉพาะอย่างยิ่งสําหรับชุดข้อมูลขนาดใหญ่ที่มีการเปลี่ยนแปลงเพียงไม่กี่เรคคอร์ด Google Drive API (2025) ใช้ changes.list กับ pageToken สําหรับการซิงค์แบบเดลต้าของไฟล์

กลยุทธ์ «เดลต้ารอการดําเนินการ» — บนไคลเอ็นต์มือถือ การเปลี่ยนแปลงจะไม่ถูกส่งทันทีแต่ถูกบัฟเฟอร์ในคิวออฟไลน์ เมื่อถึงเกณฑ์ (10 การดําเนินการหรือ 30 วินาที) แพ็กเกจเดลต้าจะถูกสร้างและส่งไปยังเซิร์ฟเวอร์ ตาม Dropbox Mobile Engineering (2024) การรวมเดลต้าช่วยลดจํานวนคําขอ HTTP ลง 65% และลดการใช้แบตเตอรี่ลง 12%

data class SyncCheckpoint(
    val lastUpdated: Long,
    val pageToken: String?,
    val version: Int
)

suspend fun syncIncremental(checkpoint: SyncCheckpoint): SyncResult =
    api.pullChanges(
        since = checkpoint.lastUpdated,
        token = checkpoint.pageToken
    )

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

การซิงค์แบบพุช — การซิงค์ทันทีผ่าน WebSocket และ FCM

WebSocket — การเชื่อมต่อแบบสองทิศทางถาวรระหว่างไคลเอ็นต์และเซิร์ฟเวอร์ เซิร์ฟเวอร์ส่งการอัปเดตทันทีเมื่อข้อมูลเปลี่ยนแปลง WebSocket เหมาะสมที่สุดสําหรับแอปเรียลไทม์: แชท, สตรีมมิง, การทํางานร่วมกัน ข้อเสีย: การใช้แบตเตอรี่และปริมาณการใช้งานเพื่อรักษาการเชื่อมต่อ (heartbeat) OkHttp WebSocket บน Android และ URLSessionWebSocketTask บน iOS — การ implement ในตัว

Firebase Cloud Messaging (FCM) — การแจ้งเตือนแบบพุชที่เซิร์ฟเวอร์ส่งไม่ใช่เพื่อแสดงต่อผู้ใช้ แต่เพื่อกระตุ้นการซิงค์ เมื่อได้รับ silent push (ข้อความข้อมูล) แอปจะตื่นและเริ่ม Sync Engine FCM ไม่ต้องการการเชื่อมต่อถาวรและประหยัดกว่า WebSocket สําหรับการแจ้งเตือนที่น้อยครั้ง

SSE (Server-Sent Events) — ช่องทางทิศทางเดียวที่เซิร์ฟเวอร์ส่งเหตุการณ์ไปยังไคลเอ็นต์ ใช้งานง่ายกว่า WebSocket แต่ไม่รองรับการสื่อสารสองทิศทาง EventSource API (JavaScript) และ OkHttp SSE (Android) — ไลบรารียอดนิยม SSE เหมาะสําหรับการแจ้งเตือนเกี่ยวกับข้อมูลใหม่เมื่อไคลเอ็นต์ไม่จําเป็นต้องส่งข้อมูลกลับผ่านช่องทางเดียวกัน

ตาม WhatsApp Engineering (2024) Sync Engine ของพวกเขาใช้การรวมกันของ WebSocket สําหรับเซสชันที่ใช้งานอยู่และ FCM สําหรับปลุกแอปในพื้นหลัง: WebSocket ตัดการเชื่อมต่อหลังจากไม่มีการเคลื่อนไหว 5 นาที และการอัปเดตครั้งต่อมาจะถูกส่งผ่าน silent push

การซิงค์แบบสแนปชอตและการควบคุมเวอร์ชันข้อมูล

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

การควบคุมเวอร์ชันต่อเรคคอร์ด — แต่ละเรคคอร์ดมีฟิลด์ version ระหว่างการซิงค์ ไคลเอ็นต์ส่งเวอร์ชันของเรคคอร์ดทั้งหมด และเซิร์ฟเวอร์ส่งคืนเฉพาะเรคคอร์ดที่เวอร์ชันเปลี่ยนแปลงไป ซึ่งมีประสิทธิภาพมากกว่าการซิงค์แบบสแนปชอต แต่ต้องเก็บเวอร์ชันไว้บนไคลเอ็นต์ นาฬิกาเวกเตอร์ (Vector Clocks) — เทคนิคขั้นสูงสําหรับระบบกระจายที่แต่ละโหนดกําหนดเวอร์ชันของตนเองและข้อขัดแย้งถูกแก้ไขตามลําดับบางส่วน

สแนปชอตกับ diff แบบเพิ่มหน่วย — แนวทางแบบผสม: สแนปชอตเต็มที่น้อยครั้ง (วันละครั้ง) + การซิงค์แบบเพิ่มหน่วยระหว่างกัน เมื่อเริ่มต้นหลังจากไม่ได้ใช้งานนาน ไคลเอ็นต์โหลดสแนปชอต และระหว่างการซิงค์บ่อยครั้ง — เฉพาะเดลต้า แนวทางคล้าย Git — แต่ละ commit ข้อมูลมีแฮช และไคลเอ็นต์รู้ว่าจะเริ่มจาก commit ไหน ซึ่ง implement ใน Couchbase Lite Sync Gateway (2024) และเป็นมาตรฐานทองคําสําหรับความน่าเชื่อถือ

data class VersionedEntryT(
    val id: String,
    val data: T,
    val version: Long,
    val deleted: Boolean
)

fun SyncEngine.resolveVersion(local: VersionedEntry*, remote: VersionedEntry*): VersionedEntry* =
    when {
        local.version > remote.version -> local
        remote.version > local.version -> remote
        else -> resolveConflict(local, remote)
    }

กฎการแก้ไขเวอร์ชัน: ถ้าเวอร์ชันตรงกัน — ไม่มีการเปลี่ยนแปลง ถ้าเวอร์ชันในเครื่องใหม่กว่า — ในเครื่องชนะ ถ้าเวอร์ชันเซิร์ฟเวอร์ใหม่กว่า — เซิร์ฟเวอร์ชนะ เฉพาะเมื่อเวอร์ชันเท่ากันแต่ข้อมูลต่างกัน — ตัวแก้ไขข้อขัดแย้งจะถูกเรียก Last Write Wins พร้อมแฟล็กเวอร์ชัน — กลยุทธ์ที่ง่ายที่สุดแต่เชื่อถือได้

วิธีสร้าง Sync Engine สําหรับแอปมือถือ

ขั้นตอนที่ 1: กําหนดโมเดลข้อมูล — เอนทิตีใดที่ถูกซิงค์ เปลี่ยนแปลงบ่อยแค่ไหน และปริมาณเท่าใด สําหรับแต่ละเอนทิตี กําหนดกลยุทธ์ (เพิ่มหน่วย / เต็ม / พุช) และเวลาหน่วงการซิงค์ที่ยอมรับได้

ขั้นตอนที่ 2: เลือกโปรโตคอล — REST พร้อมจุดตรวจสอบ, GraphQL พร้อม Subscription หรือ gRPC พร้อมสตรีมสองทิศทาง GraphQL Subscriptions — ตัวเลือกยอดนิยมสําหรับแอปสมัยใหม่: โปรโตคอลเดียวสําหรับทั้ง pull และ push Apollo Client (2025) รองรับการซิงค์แบบออฟไลน์ผ่านแคชของอุปกรณ์

ขั้นตอนที่ 3: Implement คิวออฟไลน์ — พื้นที่จัดเก็บการเปลี่ยนแปลงในเครื่องพร้อมคีย์ idempotency (ดูบทความ «Offline Queue») คิวเป็นพื้นฐานของ Sync Engine ที่เชื่อถือได้: หากไม่มีคิว การซิงค์ไม่รับประกันการส่งมอบการเปลี่ยนแปลง

ขั้นตอนที่ 4: เลือกตัวแก้ไขข้อขัดแย้ง — LWW สําหรับกรณีง่าย, CRDT สําหรับการแก้ไขร่วมกัน, การรวมแบบกําหนดเองสําหรับตรรกะทางธุรกิจ กฎ: ตัวแก้ไขต้องมีคุณสมบัติ idempotent — การใช้การดําเนินการเดียวกันซ้ําต้องให้ผลลัพธ์เดียวกัน

ขั้นตอนที่ 5: การตรวจสอบและเมตริก — บันทึกการซิงค์แต่ละครั้ง: จํานวนเรคคอร์ด, เวลาดําเนินการ, จํานวนข้อขัดแย้ง, ข้อผิดพลาด Firebase Crashlytics หรือ Sentry (2025) ช่วยให้ติดตามข้อผิดพลาดการซิงค์แบบเรียลไทม์

ตาม Realm Team (2024) Sync Engine ทั่วไปสําหรับแอปมือถือประมวลผล 100–500 การซิงค์ต่อวันต่ออุปกรณ์ โดยถ่ายโอนเฉลี่ย 50–200 KB ต่อเซสชัน การเพิ่มประสิทธิภาพโปรโตคอล — ใช้การบีบอัด Protobuf แทน JSON — ลดปริมาณข้อมูลที่ถ่ายโอนอีก 40–60%