Cải thiện client-server chức năng đồng bộ hóa dữ liệu với đồng bằng châu thổ

Question

Ứng dụng
Tôi có một ứng dụng web mà hiện đang sử dụng cho các chức năng AppCache ẩn từ người dùng của hệ thống cần phải tạo ra các tài liệu ngoại tuyến. Tài liệu được tạo lần đầu tiên ngoại tuyến và khi truy cập internet khả dụng, người dùng có thể nhấp vào "đồng bộ hóa" sẽ gửi tài liệu tới máy chủ và lưu tài liệu dưới dạng bản sửa đổi. Cụ thể hơn, ứng dụng không lưu đồng bằng thay đổi dưới dạng bản sửa đổi (trường chính xác được sửa đổi) mà là toàn bộ tài liệu trong toàn bộ. Nói cách khác, một tài liệu "ảnh chụp" được lưu lại.

Sự cố
Người dùng có thể đăng nhập từ các trình duyệt và thiết bị khác nhau và làm việc trên tài liệu của họ. Khi họ nhấp vào "đồng bộ hóa", nếu tài liệu của máy chủ mới hơn, toàn bộ phiên bản của khách hàng sẽ bị ghi đè bởi máy chủ. Điều này dẫn đến một vấn đề chính được mô tả trong hình dưới đây.

Kịch bản trên xảy ra do việc thực hiện hiện tại mà không dựa vào đồng bằng châu thổ (thay đổi nhỏ) và thay vì dựa trên các phiên bản ảnh chụp.

Một số câu hỏi

1) Nghiên cứu của tôi cho thấy rằng tôi nên nâng cấp cơ chế "đồng bộ hóa" được thể hiện ở đồng bằng châu thổ (thay đổi nhỏ có thể được áp dụng một cách độc lập). Đây có phải là cách tiếp cận âm thanh không?

2) Mỗi ​​delta có được áp dụng độc lập không?

2) Theo nghiên cứu của tôi, các bản sửa đổi có giá trị bằng số và không phải là dấu thời gian. Giá trị này sẽ chính xác như thế nào? Làm cách nào để đảm bảo cả máy chủ và khách hàng đều đồng ý về số lượng bản sửa đổi phải là gì?

stack thông tin

• góc trên frontend
• IndexedDB để lưu các tài liệu tại địa phương (chế độ offline)
• Postgres DB với JSONB trong backend

Answer 1

gì mô tả của bạn là vấn đề kiểm soát phiên bản như trong this question. Sự lựa chọn là của bạn với cách giải quyết. Dưới đây là một vài ví dụ về các sản phẩm khác với vấn đề này:

• Google docs: Một làm cho chỉnh sửa ngoại tuyến, B làm cho chỉnh sửa trực tuyến, A đi trực tuyến, Sync, Google Docs kết hợp A và chỉnh sửa B
• của Apple lưu ý: Tương tự như Google Docs
• Git/Subversion: ném một lỗi, hãy yêu cầu người sử dụng để giải quyết xung đột
• Wunderlist: chỉnh sửa cuối ghi đè trước

Đối với trường hợp của bạn, giải pháp đơn giản nhất này là sử dụng cách tiếp cận Wunderlist, nhưng có vẻ như điều đó có thể gây ra vấn đề về khả năng sử dụng. Người dùng của bạn mong đợi điều gì sẽ xảy ra?

Trả lời câu hỏi của bạn trực tiếp:

1. Một tùy chỉnh thực hiện đồng bộ là cần thiết nếu bạn không muốn ghi đè.
2. Đây là quyết định về khả năng sử dụng, người dùng mong đợi điều gì?
3. Đúng, bản sửa đổi là số (ví dụ: r1, r2). Để nhận được thỏa thuận máy chủ, hãy thay đổi giá trị trả lại của yêu cầu đồng bộ hóa lần cuối. Bạn có thể trả lại toàn bộ mô hình cho khách hàng mỗi lần (hoặc chỉ 200 OK nếu xảy ra đồng bộ hóa bình thường). Nếu một mô hình được trả về cho máy khách, hãy cập nhật máy khách với mô hình mới nhất.

Trong mọi trường hợp, máy chủ phải luôn là nguồn gốc của sự thật. This post đưa ra một số lời khuyên tốt trên máy chủ/mobile toàn vẹn tham chiếu:

Để theo dõi chèn bạn cần một dấu thời gian tạo ... Để theo dõi cập nhật mà bạn cần phải theo dõi một timestamp LASTUPDATE trên các hàng của bạn ... Để theo dõi xóa bạn cần một tấm bia mộ.

Lưu ý rằng khi bạn thực hiện đồng bộ hóa, bạn cần kiểm tra độ lệch thời gian giữa máy chủ và thiết bị di động và bạn cần có phương pháp để giải quyết xung đột. Chèn là không có vấn đề lớn (họ không nên xung đột), nhưng cập nhật có thể xung đột, và xóa có thể xung đột với một bản cập nhật.