Đồng bộ hóa dữ liệu trong ứng dụng di động - nhiều thiết bị, nhiều người dùng

Tôi đang tìm cách xây dựng ứng dụng di động đầu tiên của mình. Một trong những tính năng cốt lõi của ứng dụng là nhiều thiết bị / người dùng sẽ có quyền truy cập vào cùng một dữ liệu - và tất cả chúng sẽ có quyền CRUD.

Tôi tin rằng kiến ​​trúc nên liên quan đến một máy chủ trung tâm nơi lưu trữ tất cả dữ liệu. Các thiết bị sẽ sử dụng API để tương tác với máy chủ để thực hiện các hoạt động dữ liệu của nó (ví dụ: thêm bản ghi, chỉnh sửa bản ghi, xóa bản ghi).

Tôi tưởng tượng một kịch bản trong đó đồng bộ hóa dữ liệu sẽ trở thành một vấn đề. Giả sử ứng dụng sẽ hoạt động khi không được kết nối với Internet và do đó không thể giao tiếp với máy chủ trung tâm này. Vì thế:

1. Người dùng A đang ngoại tuyến và chỉnh sửa bản ghi # 100
2. Người dùng B đang ngoại tuyến và chỉnh sửa bản ghi # 100
3. Người dùng C đang ngoại tuyến và xóa bản ghi # 100
4. Người dùng C truy cập trực tuyến (có lẽ, bản ghi số 100 sẽ bị xóa trên máy chủ)
5. Người dùng A và B lên mạng, nhưng hồ sơ họ chỉnh sửa không còn tồn tại

Tất cả các loại kịch bản tương tự như trên có thể đi lên.

Làm thế nào điều này thường được xử lý? Tôi dự định sử dụng MySQL, nhưng tôi tự hỏi liệu nó không phù hợp với vấn đề như vậy.

Tôi hiện đang làm việc trên một ứng dụng di động / máy tính để bàn / phân phối với chính xác các yêu cầu và vấn đề tương tự.

Trước hết, các yêu cầu này không phải là vốn có đối với các ứng dụng di động, nhưng đối với mọi giao dịch máy chủ-máy khách bị ngắt kết nối (lập trình song song, đa luồng, bạn sẽ nhận được điểm). Như vậy, tất nhiên, đây là những vấn đề điển hình cần giải quyết trong các ứng dụng di động.

Nói chung, tất cả điều này có nghĩa là bạn có một bản ghi dữ liệu tiềm năng được phân phối cho n khách hàng, những người có thể chỉnh sửa nó cùng một lúc. Những gì bạn cần là

1. một cơ chế kiểm soát / khóa phiên bản thích hợp,
2. một quyền thích hợp / quản lý truy cập,
3. một chiến lược đồng bộ hóa / bộ nhớ đệm thích hợp

Đối với (1) bạn có thể áp dụng một số mẫu: Có hai chiến lược khóa được sử dụng thường xuyên: Khóa ngoại tuyến lạc quan và Khóa ngoại tuyến bi quan . Một số trong số này được áp dụng trong các "mẫu" điều khiển phiên bản khác nhau, chẳng hạn như MultiVersion Concurrency Control (MVCC), sử dụng bộ đếm (loại "dấu thời gian" rất đơn giản) cho mỗi bản ghi dữ liệu, được cập nhật mỗi khi thay đổi bản ghi .

(2) và (3) là những vấn đề rất rộng, cần được xử lý độc lập với (1). Một số lời khuyên từ kinh nghiệm của tôi:

• Sử dụng công nghệ máy khách-máy chủ trừu tượng hóa hầu hết các vấn đề cho bạn. Tôi đặc biệt khuyên dùng một số công nghệ web như CouchDb , xử lý (1) thông qua Khóa ngoại tuyến lạc quan + MVCC, (2) qua API Web và (3) qua bộ nhớ đệm http rất tốt.

• Cố gắng không tự phát minh ra mọi thứ nếu bạn có thể dựa vào các công nghệ và phương pháp đã được chứng minh. Tôi tin rằng bất kỳ giờ nào dành cho việc nghiên cứu và so sánh các công nghệ / mẫu hiện có sẽ tốt hơn nhiều so với việc cố gắng thực hiện (các) hệ thống của riêng bạn.

• Cố gắng sử dụng các công nghệ đồng nhất nếu có thể. Theo "đồng nhất", ý tôi là các công nghệ đã được xây dựng với cùng các nguyên tắc, ví dụ như các kịch bản sử dụng web 2.0. Một ví dụ: Sử dụng CouchDb và REST Client (API Web) thích hợp với chiến lược lưu trữ cục bộ là lựa chọn tốt hơn so với sử dụng SQL cho các ứng dụng di động.

• Tôi thực sự khuyên bạn không nên sử dụng MySQL vì đây là công nghệ không được thực hiện rõ ràng cho các tình huống sử dụng như vậy. Nó hoạt động, nhưng bạn tốt hơn nhiều với một hệ thống cơ sở dữ liệu đã bao trùm phong cách giao tiếp và giao tiếp web (chẳng hạn như nhiều Cơ sở dữ liệu NoQuery).

Nhân tiện, tôi đã giải quyết cho CouchDb với một máy khách cục bộ tùy chỉnh hoạt động dựa trên API CouchDb, hoạt động và chia tỷ lệ đẹp. Tôi đã chuyển từ sử dụng MSQL + (N) Hibernate và trả giá cao vì không đưa ra lựa chọn đúng (nghĩa là không thực hiện đủ nghiên cứu) ngay từ đầu.

Đầu tiên, bạn đã đề cập đến cả API và cơ sở dữ liệu (MySQL). Tôi rất khuyên bạn nên sử dụng API và đừng cố giao tiếp trực tiếp giữa các cơ sở dữ liệu. Đó là tuyến đường sau sẽ không có quy mô tốt.

Một điểm khởi đầu tốt mà bạn nên xem xét là sử dụng Apache CouchDB . Nó không có lược đồ, dựa trên HTTP và JSON và có cơ chế sao chép rất tốt. Chúng tôi sử dụng nó để giải quyết một vấn đề tương tự.

Cơ chế sao chép của CouchDB sử dụng cùng API HTTP mà bất kỳ máy khách nào khác sử dụng. Vì vậy, về bản chất, nó cung cấp bản sao qua API.

Đối với iOS, tôi khuyên bạn nên sử dụng dự án Couchbase Lite . Nó hoạt động rất tốt để đồng bộ dữ liệu. Đối với Android, cùng một công ty thực hiện dự án Couchbase Lite đã nói ở trên đang làm việc với một ưu đãi tương tự - Couchbase Lite cho Android . Nó không hoàn chỉnh như phiên bản iOS và còn một số công việc phải hoàn thành.

Tuy nhiên, có một vài điều cần xem xét với CouchDB.

1. Bạn sẽ cần phải cung cấp giải quyết xung đột của riêng bạn. May mắn thay, nếu xung đột xảy ra, CouchDB giữ các phiên bản xung đột và chọn và xung đột tùy ý, nhưng có tính xác định để có phiên bản chính. Vì vậy, bạn có thể xem xét trì hoãn giải quyết xung đột cho phiên bản ban đầu của mình.
2. Cơ chế sao chép được tạo để sao chép cơ sở dữ liệu, không đồng bộ hóa mỗi lần. Vì vậy, nếu bạn có nhiều tài liệu bị xóa, việc sao chép của bạn từ máy chủ sang máy khách sẽ mất nhiều thời gian hơn. Có một cách để tránh điều này bằng cách sử dụng "xoay cơ sở dữ liệu." Điều này về cơ bản loại bỏ xóa cũ.
3. Bạn không thể kiểm soát thứ tự sao chép. Tuy nhiên, bạn có thể thực hiện một số giải pháp thông minh để cải thiện hiệu suất sao chép, chẳng hạn như sử dụng sao chép được lọc để lấy một số tài liệu trước hoặc thậm chí truy cập trực tiếp vào máy chủ theo yêu cầu.
4. Bản sao sẽ không xảy ra trong nền trên iOS. Bạn có thể sử dụng SDK iOS để cung cấp một số trường hợp sao chép nền.

Cuối cùng, nếu bạn không muốn sử dụng CouchDB, ít nhất bạn có thể sử dụng nó làm tài liệu tham khảo tốt cho cách bạn có thể tạo thuật toán đồng bộ hóa bằng API HTTP. Đề xuất của tôi sẽ là bắt đầu với CouchDB và sau đó, nếu bạn cần một cái gì đó tùy chỉnh hơn, để xem xét việc tự lăn.