Bộ nhớ đệm và đồng bộ hóa dữ liệu trong phát triển di động: khái niệm, chiến lược và cách hoạt động

Xử lý Dữ liệu trong Ứng dụng Di động: Mẫu Repository và Data Source

Mẫu Repository là một cách tiếp cận kiến trúc nơi một lớp kho lưu trữ duy nhất quản lý tất cả các thao tác dữ liệu, trừu tượng hóa các API REST từ xa và bộ lưu trữ cục bộ Room hoặc SwiftData. Cách xử lý dữ liệu này cho phép ứng dụng lấy thông tin trước tiên từ Memory Cache hoặc Disk Cache, sau đó từ mạng, giảm thời gian phản hồi. Trong phát triển di động, Repository đã trở thành tiêu chuẩn thực tế nhờ các khuyến nghị của Google và Apple.

Remote Data Source và Local Data Source

Remote Data Source cung cấp thông tin cập nhật từ máy chủ qua các yêu cầu HTTP. Local Data Source là bộ lưu trữ cục bộ trên thiết bị, được triển khai qua Room trên Android hoặc SwiftData trên iOS. Kho lưu trữ kết hợp cả hai nguồn: đầu tiên kiểm tra bộ nhớ đệm cục bộ, và khi không có dữ liệu, yêu cầu từ API từ xa. Tổ chức xử lý dữ liệu này cho phép ứng dụng hoạt động ở chế độ ngoại tuyến và giảm tải cho máy chủ.

Ví dụ Repository trong Kotlin

class UserRepository(
    private val remoteDataSource: UserRemoteDataSource,
    private val localDataSource: UserLocalDataSource
) {
    suspend fun getUsers(): List<User> {
        localDataSource.getCachedUsers()?.let { return it }
        val users = remoteDataSource.fetchUsers()
        localDataSource.cacheUsers(users)
        return users
    }
}

Ví dụ Repository trong Swift

class UserRepository {
    private let remote: UserRemoteDataSource
    private let local: UserLocalDataSource
    
    func getUsers() async throws -> [User] {
        if let cached = await local.getCached() { return cached }
        let users = try await remote.fetch()
        await local.save(users)
        return users
    }
}

Lưu trữ Đệm Dữ liệu: LRU Cache, Disk Cache và Memory Cache

LRU Cache (Least Recently Used) là một thuật toán lưu trữ đệm nơi, khi đạt đến giới hạn, phần tử không được truy cập lâu nhất sẽ bị xóa. Trong ứng dụng di động, LRU Cache được sử dụng cho hình ảnh, phản hồi API và các đối tượng được tuần tự hóa. Lưu trữ đệm dữ liệu phù hợp làm giảm số lượng yêu cầu mạng và tăng tốc độ tải nội dung. Bộ nhớ đệm trong ứng dụng di động là một thành phần thiết yếu cho hiệu suất cao.

Memory Cache so với Disk Cache

Memory Cache lưu trữ dữ liệu trong RAM — truy cập cực kỳ nhanh, nhưng dung lượng bị giới hạn bởi kích thước heap của ứng dụng. Disk Cache lưu thông tin trên hệ thống tệp — chậm hơn nhưng có thể chứa nhiều hơn và tồn tại giữa các phiên. Chiến lược tối ưu trong phát triển di động là bộ nhớ đệm hai cấp: Memory Cache cho dữ liệu nóng và Disk Cache cho dữ liệu lạnh. Khi xử lý dữ liệu, bộ nhớ đệm cấp một trong bộ nhớ được kiểm tra trước, sau đó đến bộ nhớ đệm cấp hai trên đĩa.

Ví dụ Triển khai LRU Cache

class MemoryCache<K, V>(
    private val maxSize: Int = 100
) {
    private val cache = LinkedHashMap<K, V>(0, 0.75f, true)

    fun get(key: K): V? = cache[key]

    fun put(key: K, value: V) {
        if (cache.size >= maxSize) {
            cache.remove(cache.keys.first())
        }
        cache[key] = value
    }
}

Chiến lược Vô hiệu hóa Bộ nhớ đệm

Bộ nhớ đệm TTL (Time To Live) tự động xóa một mục sau một khoảng thời gian xác định — phù hợp cho dữ liệu API. Vô hiệu hóa dựa trên sự kiện xóa bộ nhớ đệm khi nhận được thông báo push về các thay đổi. Trong ứng dụng di động, việc lựa chọn chiến lược lưu trữ đệm phụ thuộc vào loại dữ liệu: hình ảnh được lưu trữ đệm trong thời gian dài, trong khi bảng tin yêu cầu vô hiệu hóa thường xuyên. Coil trên Android và Kingfisher trên iOS đã tích hợp sẵn LRU Cache để làm việc với hình ảnh.

Hàng đợi Ngoại tuyến: Offline Queue và Sync Manager

Offline Queue là một cấu trúc dữ liệu lưu trữ các thao tác của người dùng (tạo, cập nhật, xóa) trong cơ sở dữ liệu cục bộ khi thiết bị ngoại tuyến. Khi kết nối được khôi phục, Sync Manager áp dụng tuần tự các thao tác này lên máy chủ. Loại đồng bộ hóa dữ liệu này đảm bảo rằng không có thay đổi nào bị mất trong thời gian mất mạng tạm thời. Trong phát triển di động, Offline Queue là một thành phần quan trọng cho các ứng dụng có kết nối không ổn định.

Kiến trúc Offline Queue

Hàng đợi được xây dựng trên một bảng trong Room hoặc SwiftData với các trường: loại thao tác, nội dung yêu cầu JSON, dấu thời gian và trạng thái. Sync Manager là một dịch vụ nền xử lý các thao tác đang chờ xử lý, gửi chúng đến máy chủ, cập nhật trạng thái và xóa các mục thành công. Đồng bộ hóa dữ liệu qua WorkManager trên Android hoặc BGTaskScheduler trên iOS tiếp tục ngay cả sau khi khởi động lại thiết bị. Sử dụng Offline Queue kết hợp với xử lý dữ liệu phù hợp đảm bảo trải nghiệm người dùng liền mạch.

Ví dụ Offline Queue trong Kotlin

@Entity
data class SyncOperation(
    @PrimaryKey val id: Long,
    val endpoint: String,
    val method: String,
    val body: String,
    val createdAt: Long
)

class SyncManager(
    private val dao: SyncOperationDao,
    private val api: ApiService
) {
    suspend fun syncPending() {
        dao.getPendingOperations().forEach { op ->
            try {
                api.execute(op.endpoint, op.method, op.body)
                dao.delete(op.id)
            } catch (e: Exception) {
                // retry on next cycle
            }
        }
    }
}

Chính sách Thử lại và Thời gian chờ

Backoff theo cấp số nhân giữa các lần thử lại (1s, 2s, 4s, 8s) bảo vệ máy chủ khỏi quá tải và ngăn chặn thử lại vô hạn. Giới hạn 5 lần thử ngăn tràn hàng đợi. Đồng bộ hóa dữ liệu trong ứng dụng di động với hỗ trợ tính đẳng năng phía máy chủ cho phép thử lại an toàn, tránh trùng lặp. Điều này đặc biệt quan trọng đối với giao dịch tài chính và đơn hàng.

Đồng bộ hóa Dữ liệu: Conflict Resolution và Schema Migration

Conflict Resolution là một tập hợp các chiến lược cho các tình huống khi cùng một dữ liệu được sửa đổi trên các thiết bị khác nhau đồng thời. Đồng bộ hóa dữ liệu cơ bản yêu cầu chọn một cách tiếp cận: Last-Write-Wins (ghi cuối cùng thắng), tạo phiên bản (phiên bản cao hơn thắng) hoặc giải quyết thủ công. Trong các kịch bản phức tạp, CRDT (Conflict-Free Replicated Data Types) được sử dụng, đảm bảo sự hội tụ toán học của dữ liệu.

Chiến lược Giải quyết Xung đột

Last-Write-Wins là đơn giản nhất để triển khai nhưng có thể làm mất thay đổi của người dùng. Version Vector — mỗi bản ghi lưu trữ số phiên bản và định danh thiết bị; xung đột phát sinh khi các phiên bản không khớp. CRDT là chiến lược đáng tin cậy nhất nhưng phức tạp: dữ liệu hội tụ toán học về một trạng thái duy nhất mà không cần điều phối viên trung tâm. Đồng bộ hóa dữ liệu trong ứng dụng di động dựa trên CRDT được sử dụng trong chỉnh sửa cộng tác trong Google Docs và đồng bộ hóa ghi chú Notion.

Schema Migration: Cập nhật Cơ sở dữ liệu An toàn

Khi một ứng dụng được cập nhật, cấu trúc cơ sở dữ liệu cục bộ thay đổi: các cột, bảng, chỉ mục được thêm vào. Schema Migration là quá trình chuyển đổi cơ sở dữ liệu hiện có sang lược đồ mới mà không mất dữ liệu. Room hỗ trợ di chuyển thông qua lớp Migration với phiên bản cũ và mới. SwiftData sử dụng VersionedSchema để mô tả các thay đổi. Đồng bộ hóa dữ liệu phù hợp giữa các phiên bản ứng dụng yêu cầu các bước di chuyển phải được kiểm tra một cách đẳng năng.

Ví dụ Schema Migration trong Room

val migration1to2 = object : Migration(1, 2) {
    override fun migrate(database: SupportSQLiteDatabase) {
        database.execSQL("ALTER TABLE users ADD COLUMN avatar_url TEXT")
    }
}

@Database(
    entities = [User::class],
    version = 2
)
abstract class AppDatabase : RoomDatabase() {
    abstract fun userDao(): UserDao
}

Ví dụ Conflict Resolution trong Swift

enum ConflictStrategy {
    case lastWriteWins
    case versionVector
    case crdt
}

struct VersionedDocument {
    let id: String
    let version: Int
    let data: Data
    let editedBy: String
    
    func resolve(with remote: VersionedDocument) -> VersionedDocument {
        return version >= remote.version ? self : remote
    }
}

Room và SwiftData cho Lưu trữ Cục bộ

Room là thư viện của Google cho lưu trữ cục bộ trên Android, được xây dựng trên SQLite và cung cấp các chú thích cho mô tả truy vấn khai báo. SwiftData là framework của Apple cho iOS, macOS, watchOS và visionOS, kế thừa của Core Data với cú pháp Swift Macro ngắn gọn. Cả hai công cụ đều giải quyết nhiệm vụ xử lý dữ liệu trên thiết bị, nhưng với các cách tiếp cận khác nhau để tổ chức mã. Bộ nhớ đệm trong ứng dụng di động thường được xây dựng trên các công nghệ này.

Room: DAO, Entities và Type Converters

Room sử dụng chú thích @Entity cho bảng và @Dao cho truy vấn. DAO đóng gói tất cả các thao tác SQL với kiểm tra tại thời điểm biên dịch — lỗi cú pháp SQL được phát hiện trước khi chạy. Type Converter chuyển đổi các kiểu phức tạp (Date, List) thành kiểu nguyên thủy SQLite. Xử lý dữ liệu hiện đại trong ứng dụng Android được xây dựng xung quanh Room + Flow, cung cấp cập nhật UI phản ứng khi bộ nhớ đệm hoặc cơ sở dữ liệu cục bộ thay đổi.

SwiftData: @Model và @Query

SwiftData sử dụng macro @Model để định nghĩa thực thể và @Query để quan sát dữ liệu. Framework tự động theo dõi các phụ thuộc và cập nhật giao diện khi có thay đổi. Di chuyển lược đồ sử dụng VersionedSchema mô tả tất cả các phiên bản. Đồng bộ hóa dữ liệu giữa SwiftData và máy chủ được triển khai thông qua Sync Manager tùy chỉnh đăng ký cập nhật qua @Query.

Ví dụ Mô hình trong SwiftData

@Model
final class UserModel {
    var id: String
    var name: String
    var email: String
    var updatedAt: Date
    
    init(id: String, name: String, email: String) {
        self.id = id
        self.name = name
        self.email = email
        self.updatedAt = Date()
    }
}

So sánh Room vs SwiftData