Resolusi konflik untuk sinkronisasi dua arah

Bagaimana Anda mengelola sinkronisasi dua arah antara server database 'utama' dan banyak server 'sekunder', dalam resolusi konflik tertentu, dengan asumsi koneksi tidak selalu tersedia?

Misalnya, saya memiliki aplikasi seluler yang menggunakan CoreData sebagai 'basis data' di iOS dan saya ingin mengizinkan pengguna mengedit konten tanpa koneksi internet. Pada saat yang sama, informasi ini tersedia di situs web tempat perangkat akan terhubung. Apa yang harus saya lakukan jika / ketika data pada dua server DB dalam konflik?
(Saya merujuk ke CoreData sebagai server DB, meskipun saya sadar itu adalah sesuatu yang sedikit berbeda.)

Apakah ada strategi umum untuk menangani masalah seperti ini? Ini adalah opsi yang dapat saya pikirkan:
1. Selalu menggunakan data sisi klien sebagai prioritas yang lebih tinggi
2. Sama untuk sisi server
3. Cobalah untuk menyelesaikan konflik dengan menandai cap waktu edit setiap bidang dan lakukan pengeditan terbaru

Meskipun saya yakin opsi ke-3 akan membuka ruang untuk beberapa kerusakan data yang merusak.

Saya sadar bahwa teorema CAP menyangkut hal ini, tetapi saya hanya ingin konsistensi akhirnya, sehingga tidak mengesampingkannya sepenuhnya, kan?

Pertanyaan terkait: Pola praktik terbaik untuk sinkronisasi data dua arah . Jawaban kedua untuk pertanyaan ini mengatakan itu mungkin tidak dapat dilakukan.

Solusi yang biasa untuk mengetahui "perubahan mana yang benar" adalah jam vektor . Anda pada dasarnya melacak penghitung untuk setiap repositori yang menyimpan data, dan menolak perubahan jika pandangan klien tertentu tentang keadaan orang lain berbeda dari rekan yang terhubung dengannya.

Pertanyaan besar yang harus Anda jawab adalah bagaimana Anda akan menyelesaikan penyelamatan yang ditolak. Ini umumnya berarti semacam operasi penggabungan.

Perhatikan bahwa jam vektor tidak menggunakan cap waktu waktu nyata. Masalah yang terlibat dalam sinkronisasi jam waktu nyata setidaknya sama sulitnya dengan sinkronisasi data.

Ini adalah masalah Jenderal Bizantium , yang tidak dapat dipecahkan. Anda tidak pernah dapat menjamin menyinkronkan kedua server jika Anda tidak dapat menjamin bahwa pada suatu waktu di masa mendatang , Anda akan memiliki bandwidth yang cukup andal untuk melakukan sinkronisasi semuanya sekaligus.

Saya kira tidak ada cara standar untuk melakukannya, setiap sistem menggunakan kebijakan mereka sendiri untuk resolusi konflik.

Saya membuat beberapa simulasi menggunakan dua perangkat, komputer dan telepon, dan Google Spreadsheet untuk memeriksa bagaimana Google Docs menangani konflik secara otomatis. Berikut beberapa kasus:

Kasus 1

1. Komputer dan telepon sedang offline
2. Komputer mengedit sel dengan nilai 'komputer' dan setelah telepon mengedit sel dengan nilai 'telepon'
3. Komputer menjadi online
4. Telepon menjadi online dan komputer dan telepon menampilkan 'telepon'.

Kasus 2

1. Komputer dan telepon sedang offline
2. Komputer mengedit sel dengan nilai 'komputer' dan setelah telepon mengedit sel dengan nilai 'telepon'
3. Telepon menjadi online
4. Komputer menjadi online dan komputer dan telepon menampilkan 'komputer'.

Jadi, setidaknya server Google Documents menggunakan data terakhir yang diterima sebagai prioritas lebih tinggi secara independen saat dibuat (stempel waktu klien). Saya juga menguji apakah mereka melakukan sinkronisasi di latar belakang, dan ternyata tidak, sehingga hasil resolusi konflik transparan bagi pengguna.

GIT di sisi lain, tidak menangani konflik secara otomatis, tetapi mendelegasikan kepada pengguna terakhir yang mencoba mengubah repositori bagaimana penggabungan harus dilakukan.

Saya akan menggunakan pendekatan Google Documents jika tidak apa-apa hanya menyinkronkan di latar depan, dengan pengguna memvisualisasikan data. Jika tidak, pengguna mungkin akan terkejut bahwa ketika teleponnya terhubung secara otomatis ke WiFi, perubahan tidak sinkron ke pertemuan yang setelah diedit kembali pada PC-nya ditayangkan.

Saya akan pergi untuk pendekatan timestamp klien, mengatasi konflik dengan yang terakhir diedit, jika Anda memerlukan sinkronisasi latar belakang, dapat mempercayai cap waktu klien dan biaya penggabungan yang tidak diinginkan lebih kecil daripada biaya meminta pengguna untuk memilih versi yang diinginkannya untuk menjaga.

Saya akan menggunakan pendekatan GIT jika tidak, dengan menampilkan sembulan di klien berikutnya di latar depan yang meminta pengguna untuk memilih versi mana yang akan disimpan atau memberikan kesempatan untuk mengembalikan penggabungan.