Sync Engine: khái niệm chính, loại hình và cơ chế hoạt động

Công cụ đồng bộ là gì?

Sync Engine — là lớp kiến trúc giữa cơ sở dữ liệu cục bộ và API từ xa, quản lý luồng dữ liệu theo cả hai hướng. Nhiệm vụ của nó: theo dõi thay đổi, gửi chúng lên máy chủ, nhận thay đổi từ máy chủ và giải quyết xung đột. Người dùng tương tác với dữ liệu cục bộ, còn Sync Engine đồng bộ chúng liền mạch với máy chủ.

Sync Engine có hai loại: tích hợp sẵn (Firebase Firestore, Couchbase Lite, Realm) và tùy chỉnh — được viết cho logic nghiệp vụ cụ thể. Engine tích hợp sẵn cung cấp chức năng offline-first và giải quyết xung đột có sẵn. Engine tùy chỉnh cho phép kiểm soát hoàn toàn định dạng dữ liệu, giao thức đồng bộ và chính sách xung đột.

Theo Sravan Karthik (2024), tác giả cuốn “Mobile Sync Engine Design Patterns”, Sync Engine tùy chỉnh phù hợp cho các ứng dụng có logic nghiệp vụ phức tạp (tài chính, y tế, IoT), nơi các quy tắc hợp nhất tùy chỉnh rất quan trọng. Đối với các kịch bản điển hình (ghi chú, trò chuyện, feed), Firebase Firestore hoặc Realm tích hợp sẵn là đủ.

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>
}

Giao diện này mô tả hợp đồng tối thiểu của Sync Engine: pull (tải thay đổi từ máy chủ), push (gửi thay đổi cục bộ), resolve (xử lý xung đột) và observe (theo dõi trạng thái đồng bộ). Sự trừu tượng hóa này cho phép thay đổi cách triển khai mà không ảnh hưởng đến tầng Presentation.

Các loại đồng bộ: đầy đủ, gia tăng và push

Full sync (đồng bộ đầy đủ) — mỗi phiên tải toàn bộ tập dữ liệu từ máy chủ. Triển khai đơn giản, nhưng không phù hợp với khối lượng lớn: tải 10.000 bản ghi mỗi khi mở ứng dụng tốn băng thông và pin. Full sync phù hợp cho dữ liệu tham khảo (danh sách quốc gia) với các bản cập nhật hiếm.

Incremental sync (đồng bộ gia tăng) — chỉ truyền các bản ghi đã thay đổi kể từ lần đồng bộ cuối. Máy chủ lưu dấu thời gian thay đổi cuối cùng cho mỗi bản ghi hoặc toàn bộ tập dữ liệu. Client truyền lastSyncTimestamp và nhận chỉ các bản ghi có updated_at > giá trị này. Theo Instagram Engineering (2024), incremental sync giảm 97% khối lượng dữ liệu truyền so với full sync.

Push sync (đồng bộ do máy chủ khởi tạo) — máy chủ tự thông báo cho client cần đồng bộ qua FCM (Firebase Cloud Messaging), WebSocket hoặc SSE (Server-Sent Events). Client không tốn tài nguyên vào việc polling định kỳ. Push sync là lựa chọn tối ưu cho ứng dụng thời gian thực: chat, thông báo, lượt thích. Google Firebase Firestore sử dụng WebSocket để đồng bộ thời gian thực với fallback tự động sang HTTP polling.

Phương pháp kết hợp — kết hợp các loại: khi khởi động ứng dụng dùng full sync cho dữ liệu cơ bản, sau đó incremental sync cho cập nhật, và cho các sự kiện quan trọng — push sync qua FCM. Điều này mang lại cả tốc độ và tiết kiệm tài nguyên.

Incremental sync — cách hoạt động của checkpoint và delta

Checkpoint — giá trị mà client lưu giữ giữa các phiên đồng bộ. Thông thường là updated_at của bản ghi cuối cùng được đồng bộ thành công. Ở lần đồng bộ tiếp theo, client gửi checkpoint cho máy chủ và máy chủ trả về tất cả bản ghi có updated_at sau checkpoint đó. Cursor-based pagination — phiên bản nâng cao, nơi máy chủ trả về con trỏ (con trỏ đến trang tiếp theo) cùng với dữ liệu.

Đồng bộ Delta — máy chủ tính toán diff giữa trạng thái dữ liệu hiện tại và ảnh chụp mà client đã thấy. Thay vì gửi tất cả bản ghi, chỉ truyền các thao tác (insert, update, delete). Điều này đặc biệt hiệu quả cho tập dữ liệu lớn, nơi chỉ có vài bản ghi thay đổi. Google Drive API (2025) sử dụng changes.list với pageToken để đồng bộ delta các tệp.

Chiến lược “delta trì hoãn” — trên client di động, các thay đổi không được gửi ngay lập tức mà được lưu vào Offline Queue. Khi đạt ngưỡng (10 thao tác hoặc 30 giây), một gói delta được tạo và gửi lên máy chủ. Theo Dropbox Mobile Engineering (2024), gộp delta đã giảm 65% số lượng yêu cầu HTTP và giảm 12% mức tiêu thụ pin.

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 lưu cả dấu thời gian và con trỏ phân trang cho danh sách dài. Checkpoint hai tham số đảm bảo không có bản ghi nào bị bỏ sót hoặc trùng lặp khi đồng bộ tập dữ liệu lớn.

Push sync — đồng bộ tức thì qua WebSocket và FCM

WebSocket — kết nối hai chiều liên tục giữa client và máy chủ. Máy chủ gửi cập nhật ngay khi dữ liệu thay đổi. WebSocket tối ưu cho ứng dụng thời gian thực: chat, phát trực tiếp, làm việc cộng tác. Nhược điểm: tốn pin và băng thông để duy trì kết nối (heartbeat). OkHttp WebSocket trên Android và URLSessionWebSocketTask trên iOS — các triển khai tích hợp sẵn.

Firebase Cloud Messaging (FCM) — push notification mà máy chủ gửi không phải để hiển thị cho người dùng mà để kích hoạt đồng bộ. Khi nhận silent push (data message), ứng dụng thức dậy và chạy Sync Engine. FCM không yêu cầu kết nối liên tục và tiết kiệm hơn WebSocket cho các thông báo hiếm.

SSE (Server-Sent Events) — kênh một chiều mà máy chủ gửi sự kiện cho client. Đơn giản hơn WebSocket trong triển khai nhưng không hỗ trợ giao tiếp hai chiều. EventSource API (JavaScript) và OkHttp SSE (Android) — các thư viện phổ biến. SSE phù hợp cho thông báo về dữ liệu mới khi client không cần gửi dữ liệu trở lại qua cùng kênh.

Theo WhatsApp Engineering (2024), Sync Engine của họ sử dụng kết hợp WebSocket cho phiên hoạt động và FCM để đánh thức ứng dụng trong nền: WebSocket ngắt kết nối sau 5 phút không hoạt động và các cập nhật tiếp theo được gửi qua silent push.

Snapshot sync và quản lý phiên bản dữ liệu

Snapshot-based sync — máy chủ định kỳ tạo ảnh chụp dữ liệu đầy đủ (snapshot) và gán cho nó một phiên bản. Client lưu số phiên bản hiện tại. Nếu phiên bản đã lỗi thời — tải snapshot mới. Đây là chiến lược đơn giản và đáng tin cậy, nhưng không hiệu quả cho các thay đổi thường xuyên — mỗi lần tải toàn bộ dữ liệu.

Quản lý phiên bản cấp bản ghi — mỗi bản ghi có trường version. Khi đồng bộ, client gửi phiên bản của tất cả bản ghi và máy chủ chỉ trả về những bản ghi có phiên bản thay đổi. Điều này hiệu quả hơn snapshot sync nhưng yêu cầu lưu trữ phiên bản trên client. Vector Clocks — kỹ thuật nâng cao cho hệ thống phân tán, nơi mỗi nút gán phiên bản riêng và xung đột được giải quyết theo thứ tự từng phần.

Snapshot với diff gia tăng — phương pháp kết hợp: snapshot đầy đủ hiếm (mỗi ngày một lần) + incremental sync giữa các lần đó. Khi khởi động sau thời gian dài vắng mặt, client tải snapshot; khi đồng bộ thường xuyên — chỉ tải delta. Phương pháp giống Git — mỗi commit dữ liệu có hash và client biết bắt đầu từ commit nào. Điều này được triển khai trong Couchbase Lite Sync Gateway (2024) và là chuẩn mực về độ tin cậy.

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)
    }

Quy tắc giải quyết phiên bản: nếu phiên bản khớp — không có thay đổi. Nếu phiên bản cục bộ mới hơn — bản cục bộ thắng. Nếu phiên bản máy chủ mới hơn — bản máy chủ thắng. Chỉ khi phiên bản bằng nhau nhưng dữ liệu khác nhau — gọi conflict resolver. Last Write Wins với cờ version — chiến lược đơn giản nhất nhưng đáng tin cậy.

Cách xây dựng Sync Engine cho ứng dụng di động

Bước 1: Xác định mô hình dữ liệu — những thực thể nào được đồng bộ, tần suất thay đổi, khối lượng bao nhiêu. Với mỗi thực thể, xác định chiến lược (incremental / full / push) và thời gian trễ đồng bộ cho phép.

Bước 2: Chọn giao thức — REST với checkpoint, GraphQL với Subscription hoặc gRPC với luồng hai chiều. GraphQL Subscription — lựa chọn phổ biến cho ứng dụng hiện đại: một giao thức cho cả pull và push. Apollo Client (2025) hỗ trợ đồng bộ ngoại tuyến qua bộ nhớ đệm trên thiết bị.

Bước 3: Triển khai Offline Queue — bộ nhớ cục bộ cho các thay đổi với khóa idempotency (xem bài viết “Offline Queue”). Hàng đợi là nền tảng của Sync Engine đáng tin cậy: không có nó, đồng bộ không đảm bảo gửi được thay đổi.

Bước 4: Chọn conflict resolver — LWW cho trường hợp đơn giản, CRDT cho chỉnh sửa cộng tác, Custom merge cho logic nghiệp vụ. Quy tắc: resolver phải có tính idempotent — áp dụng lại cùng thao tác phải cho cùng kết quả.

Bước 5: Giám sát và đo lường — ghi log mỗi lần đồng bộ: số lượng bản ghi, thời gian thực hiện, số lượng xung đột, lỗi. Firebase Crashlytics hoặc Sentry (2025) cho phép theo dõi lỗi đồng bộ trong thời gian thực.

Theo Realm Team (2024), Sync Engine điển hình cho ứng dụng di động xử lý 100–500 lần đồng bộ mỗi ngày trên mỗi thiết bị, truyền trung bình 50–200 KB dữ liệu mỗi phiên. Tối ưu hóa giao thức — nén Protobuf thay vì JSON — giảm thêm 40–60% khối lượng dữ liệu truyền.