Comencé a buscar enfoques para la sincronización de datos entre un conjunto de pares. Los pares deben poder trabajar de forma desconectada y luego sincronizarse para fusionar sus cambios locales.
Los pares deberían poder fusionar las actualizaciones locales con una "fusión de tres vías" . Por lo tanto, en la sincronización, los pares deben saber qué hechos son más recientes, pero donde no hay un orden estricto, deben poder fusionar los hechos en función de la raíz común.
Cuando los pares independientes hacen cambios, pueden "marcarlos" con un "reloj". Uso el término "reloj" y "marca de tiempo" pero no me refiero a un reloj de pared. Me refiero a algún tipo de ordenamiento parcial de eventos que aclara la causalidad. Es la relación "sucedido antes" entre los eventos lo que forma un gráfico acíclico dirigido (DAG).
Parece que la forma "habitual" de construir esta ordenación parcial es mediante el uso de un reloj vectorial . Sin embargo, estos pueden llegar a ser muy grandes. Desarrollos más recientes, como los relojes de árbol de intervalos, proporcionan un almacenamiento más compacto de las marcas de tiempo.
Lo que no estoy del todo claro es por qué los protocolos de sincronización aparentemente no "simplemente" almacenan el DAG explícitamente. (¿O ellos?)
Los pares pueden crear independientemente una marca de tiempo generando aleatoriamente un UUID (o por otros medios, como <peer-name> + <local-monotonically-increasing-counter>). El orden de esta marca de tiempo es completamente claro para ese compañero.
Cuando 2 pares se sincronizan entre sí, pueden acordar una nueva marca de tiempo. Nuevamente, el orden de esta marca de tiempo es claro para ambos pares.
Ahora hay un requisito para pasar lo sucedido antes de DAG entre pares, pero los requisitos de almacenamiento y ancho de banda son pequeños. Los puntos de tiempo son vértices gráficos. Como tal, tienen 1 o 2 bordes entrantes (1 para un evento en un cliente y 2 para una sincronización entre clientes). Esto es limitado e independiente del número de pares en la red.
Para usar un punto de tiempo individual, necesita la gráfica de los puntos de tiempo que conducen a esto. Sin embargo, por lo que puedo ver, cualquier par que puede conocer un punto de tiempo (lo ha generado él mismo, o lo ha generado con otro par, o se lo ha dicho otro par al sincronizar con él) también ha tenido Una oportunidad para conocer la historia previa a ese momento. Creo que probablemente haya una prueba inductiva para esto.
Dado que almacenar y sincronizar el DAG parece explícitamente simple: ¿se usa esto en la práctica? Si no, ¿por qué se prefieren los relojes vectoriales?
Notas
De igual a igual
Prefiero una solución de igual a igual que una solución de servidor de cliente.
La topología final probable será que muchos clientes se conecten a un grupo mucho más pequeño de servidores que se replican entre ellos. Sin embargo, sería bueno tener una solución general que respalde esta topología en particular en lugar de una solución que requiera esta topología específica.