Saya sudah mulai melihat pendekatan untuk sinkronisasi data di antara seperangkat sejawat. Rekan sebaya harus dapat bekerja dengan cara yang terputus dan kemudian menyinkronkan bersama untuk menggabungkan perubahan lokal mereka.
Rekan seharusnya dapat menggabungkan pembaruan lokal dengan "gabungan tiga arah" . Jadi, pada sinkronisasi, teman sebaya harus tahu fakta mana yang lebih baru, tetapi jika tidak ada aturan ketat, mereka harus bisa menggabungkan fakta berdasarkan akar yang sama.
Ketika rekan independen membuat perubahan, mereka dapat "mencap waktu" mereka dengan "jam". Saya menggunakan istilah "jam" dan "cap waktu" tetapi saya tidak bermaksud jam waktu dinding. Maksud saya semacam urutan parsial peristiwa yang membuat kausalitas jelas. Ini adalah hubungan "terjadi sebelumnya" di antara peristiwa yang membentuk grafik asiklik terarah (DAG).
Sepertinya cara "biasa" untuk melakukan pembuatan pemesanan parsial ini adalah dengan menggunakan jam vektor . Namun, ini bisa menjadi sangat besar. Perkembangan yang lebih baru seperti jam pohon interval menyediakan penyimpanan perangko waktu yang lebih kompak.
Yang saya sama sekali tidak jelas tentang mengapa protokol sinkronisasi tampaknya tidak "hanya" menyimpan DAG secara eksplisit. (Atau apakah mereka?)
Peer dapat secara mandiri membuat cap waktu dengan membuat UUID secara acak (atau dengan cara lain, seperti <peer-name> + <local-monotonically-increasing-counter>). Pemesanan cap waktu ini sepenuhnya jelas untuk rekan itu.
Saat 2 rekan saling menyinkronkan, mereka dapat menyetujui cap waktu baru. Sekali lagi, pemesanan cap waktu ini jelas bagi kedua rekan.
Sekarang ada persyaratan untuk melewati yang terjadi sebelum DAG antara rekan-rekan, tetapi persyaratan penyimpanan dan bandwidth ini kecil. Poin waktu adalah titik grafik. Karena itu mereka memiliki 1 atau 2 tepi masuk (1 untuk acara pada klien dan 2 untuk sinkronisasi antara klien). Ini dibatasi dan tidak tergantung pada jumlah rekan di jaringan.
Untuk menggunakan titik waktu individual, Anda memerlukan grafik titik waktu yang mengarah ke ini. Namun, sejauh yang saya bisa lihat, setiap rekan yang dapat mengetahui titik waktu (telah menghasilkan sendiri, atau menghasilkannya dengan rekan lain, atau telah diberitahu oleh rekan lain saat menyinkronkannya) juga telah memiliki kesempatan untuk mengetahui tentang sejarah yang mengarah ke titik waktu itu. Saya pikir mungkin ada bukti induktif untuk ini.
Mengingat bahwa menyimpan dan menyinkronkan DAG secara eksplisit tampak sederhana: apakah ini digunakan dalam praktik? Jika tidak, mengapa jam vektor lebih disukai?
Catatan
Peer to peer
Saya lebih suka solusi peer to peer daripada solusi server klien.
Topologi akhir yang mungkin akan banyak klien terhubung ke kelompok server yang jauh lebih kecil yang mereplikasi di antara mereka sendiri. Namun, alangkah baiknya memiliki solusi umum yang mendukung topologi khusus ini daripada solusi yang memerlukan topologi spesifik ini.