Giải quyết xung đột cho đồng bộ hai chiều


24

Làm cách nào để bạn quản lý đồng bộ hóa hai chiều giữa máy chủ cơ sở dữ liệu 'chính' và nhiều máy chủ 'phụ', đặc biệt là giải quyết xung đột, giả sử không phải lúc nào cũng có kết nối?

Ví dụ: tôi có một ứng dụng di động sử dụng CoreData làm 'cơ sở dữ liệu' trên iOS và tôi muốn cho phép người dùng chỉnh sửa nội dung mà không cần kết nối Internet. Đồng thời, thông tin này có sẵn trên một trang web mà các thiết bị sẽ kết nối. Tôi phải làm gì nếu / khi dữ liệu trên hai máy chủ DB bị xung đột?
(Tôi gọi CoreData là máy chủ DB, mặc dù tôi biết rằng nó hơi khác một chút.)

Có bất kỳ chiến lược chung nào để xử lý vấn đề này không? Đây là các tùy chọn tôi có thể nghĩ đến:
1. Luôn sử dụng dữ liệu phía máy khách là mức ưu tiên cao hơn
2. Tương tự cho phía máy chủ
3. Cố gắng giải quyết xung đột bằng cách đánh dấu dấu thời gian chỉnh sửa của từng trường và thực hiện chỉnh sửa mới nhất

Mặc dù tôi chắc chắn tùy chọn thứ 3 sẽ mở ra cơ hội cho một số tham nhũng dữ liệu tàn phá.

Tôi biết rằng định lý CAP liên quan đến điều này, nhưng tôi chỉ muốn sự nhất quán cuối cùng, vì vậy nó không loại trừ hoàn toàn, phải không?

Câu hỏi liên quan: Các mẫu thực hành tốt nhất để đồng bộ hóa dữ liệu hai chiều . Câu trả lời thứ hai cho câu hỏi này có lẽ không thể thực hiện được.


Câu trả lời:


14

Giải pháp thông thường để biết "thay đổi nào là chính xác" là đồng hồ vectơ . Về cơ bản, bạn theo dõi các bộ đếm cho từng kho lưu trữ dữ liệu và từ chối các thay đổi nếu chế độ xem của một khách hàng cụ thể khác với trạng thái của người khác mà nó đang kết nối.

Câu hỏi lớn mà bạn phải trả lời là cách bạn giải quyết các khoản tiết kiệm bị từ chối. Điều này thường có nghĩa là một số loại hoạt động hợp nhất.

Lưu ý rằng đồng hồ vector không sử dụng dấu thời gian thời gian thực. Các vấn đề liên quan đến đồng bộ hóa đồng hồ thời gian thực ít nhất cũng khó như đồng bộ hóa dữ liệu.


1
Thật tuyệt, đây là thứ tôi đang tìm kiếm
K.Steff

10

Đây là vấn đề của Byzantine Generals , không thể giải quyết được. Bạn không bao giờ có thể đảm bảo đồng bộ hóa hai máy chủ nếu bạn không thể đảm bảo rằng tại một thời điểm nào đó trong tương lai , bạn sẽ có đủ băng thông đáng tin cậy để thực hiện đồng bộ hóa tất cả trong một lần.


Ok, nhưng làm thế nào để những kẻ này có được hiệu ứng tương tự: Phát triển
Syncpoint

3
Họ chỉ đơn giản cho rằng bạn sẽ có một kết nối đáng tin cậy đủ băng thông đôi khi trong tương lai.
DeadMG

1

Tôi đoán không có cách tiêu chuẩn để làm điều đó, mỗi hệ thống sử dụng các chính sách riêng để giải quyết xung đột.

Tôi đã thực hiện một số mô phỏng bằng hai thiết bị, máy tính và điện thoại và Bảng tính Google để kiểm tra cách Google Docs tự động xử lý xung đột. Đây là một số trường hợp:

Trường hợp 1

  1. Máy tính và điện thoại đang ngoại tuyến
  2. Máy tính chỉnh sửa ô có giá trị 'máy tính' và sau điện thoại chỉnh sửa ô có giá trị 'điện thoại'
  3. Máy tính trở nên trực tuyến
  4. Điện thoại trở nên trực tuyến và cả máy tính và điện thoại hiển thị 'điện thoại'.

Trường hợp 2

  1. Máy tính và điện thoại đang ngoại tuyến
  2. Máy tính chỉnh sửa ô có giá trị 'máy tính' và sau điện thoại chỉnh sửa ô có giá trị 'điện thoại'
  3. Điện thoại trở thành trực tuyến
  4. Máy tính trở nên trực tuyến và cả máy tính và điện thoại hiển thị 'máy tính'.

Vì vậy, ít nhất máy chủ Google Docs sử dụng dữ liệu cuối cùng mà nó nhận được có mức độ ưu tiên cao hơn độc lập khi nó được tạo (dấu thời gian của máy khách). Tôi cũng đã kiểm tra xem họ có đồng bộ hóa trong nền không, và rõ ràng là họ không, vì vậy kết quả giải quyết xung đột là minh bạch cho người dùng.

Mặt khác, GIT không tự động xử lý xung đột mà thay vào đó, ủy quyền cho người dùng cuối cùng đang cố gắng thay đổi kho lưu trữ cách thực hiện hợp nhất.

Tôi sẽ sử dụng phương pháp Google Docs nếu nó chỉ đồng bộ hóa ở mặt trước, với việc người dùng trực quan hóa dữ liệu. Nếu không, người dùng có thể ngạc nhiên rằng trong khi điện thoại của anh ta tự động kết nối với WiFi, thì sự thay đổi không đồng bộ thành cuộc họp mà sau khi anh ta chỉnh sửa lại trên PC của mình đã phát trực tiếp.

Tôi sẽ sử dụng phương pháp dấu thời gian của khách hàng, ghi đè các xung đột với lần chỉnh sửa cuối cùng, nếu bạn cần đồng bộ hóa nền, có thể tin tưởng vào dấu thời gian của khách hàng và chi phí hợp nhất không mong muốn nhỏ hơn chi phí yêu cầu người dùng chọn phiên bản nào anh ta muốn để giữ.

Tôi sẽ sử dụng cách tiếp cận GIT bằng cách khác, bằng cách hiển thị cửa sổ bật lên trong ứng dụng khách tiếp theo ở phía trước, yêu cầu người dùng chọn phiên bản nào để giữ hoặc tạo cơ hội hoàn nguyên hợp nhất.


1
Tôi đồng ý rằng cách tiếp cận từng trường hợp là cách thích hợp để đến đây. Cách "tốt nhất" (phương pháp git) không phải lúc nào cũng có thể áp dụng được, vì người dùng có thể không muốn xem lại / hợp nhất các thay đổi
K.Steff
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.