Sincronizar objetos entre dos sistemas dispares, ¿el mejor enfoque?

Question

Estoy trabajando para sincronizar dos objetos comerciales entre un iPhone y un sitio web utilizando una carga útil basada en XML y me encantaría solicitar algunas ideas para una rutina óptima.

Sin embargo, la naturaleza de esta pregunta es bastante genérica y puedo ver que es aplicable a una variedad de sistemas diferentes que necesitan sincronizar objetos comerciales entre una entidad web y un cliente (computadora de escritorio, teléfono móvil, etc.)

Los objetos comerciales se pueden editar, eliminar y actualizar en ambos lados. Ambas partes pueden almacenar el objeto localmente, pero la sincronización solo se inicia en el lado del iPhone para la visualización desconectada. Todos los objetos tienen una marca de tiempo updated_at y created_at y están respaldados por un RDBMS en ambos lados (SQLite en el lado del iPhone y MySQL en la web ... nuevamente, no creo que esto importe demasiado) y el teléfono graba la última vez que se intentó la sincronización. De lo contrario, no se almacenan otros datos (por el momento).

¿Qué algoritmo usaría para minimizar la charla de red entre los sistemas para la sincronización? ¿Cómo manejaría las eliminaciones si " eliminaciones suaves " no son una opción? ¿Qué cambios en el modelo de datos agregaría para facilitar esto?

Answer 1

El enfoque más simple: al sincronizar, transfiera todos los registros donde updated_at > = @last_sync_at . Desventaja: este enfoque no tolera muy bien la inclinación del reloj.

Probablemente sea más seguro mantener una columna de número de versión que se incrementa cada vez que se actualiza una fila (para que el sesgo del reloj no estropee su proceso de sincronización) y un número de versión sincronizado por última vez (de modo que se puedan generar cambios potencialmente conflictivos identificado). Para que este ancho de banda sea eficiente, mantenga una memoria caché en cada base de datos de la última versión enviada a cada par de replicación para que solo se transmitan las filas modificadas. Si se trata de una topología en estrella, las hojas pueden usar un esquema simplificado donde la última versión sincronizada se almacena en cada tabla.

Se requiere alguna forma de borrado suave para admitir la sincronización de borrados, sin embargo, esto puede ser en forma de una "lápida". registro que contiene solo la clave de la fila eliminada. Las lápidas solo se pueden eliminar de forma segura una vez que esté seguro de que todas las réplicas las han procesado; de lo contrario, es posible que una réplica rezagada resucite un registro que creía que se había eliminado.

Answer 2

Entonces, en resumen, creo que sus preguntas se relacionan con la sincronización desconectada.

Entonces, esto es lo que creo que debería suceder:

Sincronización inicial Usted recupera los datos y cualquier información asociada con ellos (versiones de fila, sumas de verificación de archivos, etc.). es importante que almacene esta información y la deje intacta hasta la próxima sincronización exitosa. Se deben realizar cambios en una COPIA de estos datos.

Seguimiento de cambios Si se trata de filas de bases de datos, la idea es que básicamente debe realizar un seguimiento de las operaciones de inserción, actualización y eliminación. Si se trata de archivos de texto como xml, entonces es un poco más complicado. Si es probable que varios usuarios editen este archivo al mismo tiempo, entonces tendría que tener una herramienta de diferencias, para que los conflictos se puedan detectar en un nivel más granular (en lugar de todo el archivo).

Comprobación de conflictos Nuevamente, si solo se trata de filas de bases de datos, los conflictos son fáciles de detectar. Puede tener otra columna que se incremente cada vez que se actualice la fila (creo que mssql tiene esto incorporado no estoy seguro acerca de mysql). Entonces, si la copia que tiene tiene un número diferente al que está en el servidor, entonces tiene un conflicto. Para archivos o cadenas, una suma de verificación hará el trabajo. Supongo que también podría usar la fecha modificada, pero asegúrese de tener una medición muy precisa para evitar errores. por ejemplo: digamos que recupero un archivo y lo guarda tan pronto como lo recuperé. Digamos que la diferencia horaria es de 1 milisegundo. Luego hago cambios en el archivo y luego trato de guardarlo. Si el último tiempo modificado modificado es exacto solo a 10 milisegundos, existe una buena posibilidad de que el archivo que recuperé tenga la misma fecha de modificación que el que guardó, por lo que el programa cree que no hay conflicto y sobrescribe sus cambios. Por lo tanto, generalmente no uso este método solo para estar seguro. Por otro lado, las posibilidades de una colisión de suma de comprobación / hash después de una modificación menor son casi nulas.

Resolver conflictos Ahora esta es la parte difícil. Si este es un proceso automatizado, deberá evaluar la situación y decidir si desea sobrescribir los cambios, perderlos o recuperar los datos del servidor nuevamente e intentar rehacer los cambios. Afortunadamente para ti, parece que habrá interacción humana. Pero todavía es mucho dolor codificar. Si se trata de filas de la base de datos, puede verificar cada columna individual y compararla con los datos del servidor y presentarla al usuario. La idea es presentar los conflictos al usuario de una manera muy granular para no abrumarlos. La mayoría de los conflictos tienen diferencias muy pequeñas en muchos lugares diferentes, así que preséntele al usuario una pequeña diferencia a la vez. Entonces, para los archivos de texto, es casi lo mismo, pero más cien veces más complicado. Entonces, básicamente, tendría que crear o usar una herramienta de diferencias (la comparación de texto es un tema completamente diferente y es demasiado amplio para mencionarla aquí) que le permite conocer los pequeños cambios en el archivo y dónde están de manera similar a la de un base de datos: donde se insertó, eliminó o editó el texto. Luego presente eso al usuario de la misma manera. básicamente, para cada pequeño conflicto, el usuario tendría que elegir si desea descartar sus cambios, sobrescribir los cambios en el servidor o realizar una edición manual antes de enviarlo al servidor.

Entonces, si ha hecho las cosas bien, el usuario debe recibir una lista de conflictos, si los hay. Estos conflictos deben ser lo suficientemente granulares para que el usuario decida rápidamente. Entonces, por ejemplo, el conflicto es un cambio de ortografía, sería más fácil para el usuario elegir entre la ortografía de palabras en lugar de darle al usuario todo el párrafo y decirle que hubo un cambio y que tienen que decidir qué hacer. , el usuario tendría que buscar este pequeño error ortográfico.

Otras consideraciones: Validación de datos: tenga en cuenta que debe realizar la validación después de resolver un conflicto