client-server - tipos - modelo cliente servidor ventajas y desventajas

¿Patrón/algoritmo de sincronización cliente-servidor? (5)

Tengo la sensación de que debe haber patrones de sincronización cliente-servidor por ahí. Pero totalmente no pude google hasta uno.

La situación es bastante simple: el servidor es el nodo central, al que varios clientes se conectan y manipulan los mismos datos. Los datos se pueden dividir en átomos, en caso de conflicto, cualquiera que sea el servidor, tiene prioridad (para evitar que el usuario entre en la resolución de conflictos). Se prefiere la sincronización parcial debido a cantidades de datos potencialmente grandes.

¿Existen patrones / buenas prácticas para tal situación, o si no conoce alguna, cuál sería su enfoque?

A continuación se muestra cómo pienso ahora para resolverlo: Paralelamente a los datos, se llevará a cabo un diario de modificación, con todas las transacciones marcadas con la hora. Cuando el cliente se conecta, recibe todos los cambios desde la última verificación, en forma consolidada (el servidor recorre las listas y elimina las adiciones seguidas de eliminaciones, combina actualizaciones para cada átomo, etc.). Et voila, estamos al día.

La alternativa sería mantener la fecha de modificación para cada registro y, en lugar de realizar eliminaciones de datos, simplemente márquelas como eliminadas.

¿Alguna idea?

Como parte del equipo, realicé muchos proyectos que involucraban la sincronización de datos, por lo que debería ser competente para responder esta pregunta.

La sincronización de datos es un concepto bastante amplio y hay demasiado para discutir. Cubre una gama de diferentes enfoques con sus ventajas y desventajas. Aquí está una de las posibles clasificaciones basadas en dos perspectivas: Sincrónica / Asíncrona, Cliente / Servidor / Peer-to-Peer. La implementación de la sincronización depende en gran medida de estos factores, la complejidad del modelo de datos, la cantidad de datos transferidos y almacenados, y otros requisitos. Entonces, en cada caso particular, la elección debe ser a favor de la implementación más simple que cumpla con los requisitos de la aplicación.

Sobre la base de una revisión de las soluciones disponibles en el mercado, podemos delinear varias clases principales de sincronización, diferentes en granularidad de objetos sujetos a sincronización:

La sincronización de todo un documento o base de datos se utiliza en aplicaciones basadas en la nube, como Dropbox, Google Drive o Yandex.Disk. Cuando el usuario edita y guarda un archivo, la nueva versión del archivo se carga completamente en la nube, sobrescribiendo la copia anterior. En caso de conflicto, ambas versiones de los archivos se guardan para que el usuario pueda elegir qué versión es más relevante.
La sincronización de pares clave-valor se puede usar en aplicaciones con una estructura de datos simple, donde las variables se consideran atómicas, es decir, no se dividen en componentes lógicos. Esta opción es similar a la sincronización de documentos completos, ya que tanto el valor como el documento pueden sobrescribirse completamente. Sin embargo, desde la perspectiva del usuario, un documento es un objeto complejo compuesto de muchas partes, pero un par clave-valor no es más que una cadena corta o un número. Por lo tanto, en este caso podemos usar una estrategia más simple de resolución de conflictos, considerando el valor más relevante, si ha sido el último en cambiar.
La sincronización de datos estructurados como un árbol o un gráfico se utiliza en aplicaciones más sofisticadas donde la cantidad de datos es lo suficientemente grande como para enviar la base de datos en su totalidad en cada actualización. En este caso, los conflictos deben resolverse a nivel de objetos, campos o relaciones individuales. Estamos enfocados principalmente en esta opción.

Entonces, captamos nuestro conocimiento en este artículo que creo que podría ser muy útil para todos los interesados en el tema => Sincronización de datos en aplicaciones de iOS basadas en datos básicos ( http://blog.denivip.ru/index.php/2014/04/data-syncing-in-core-data-based-ios-apps/?lang=en )

Debe ver cómo funciona la gestión distribuida de cambios. Mire SVN, CVS y otros repositorios que administran el trabajo de deltas.

Tienes varios casos de uso.

Sincronizar cambios. El enfoque de cambio de registro (o historial delta) se ve bien para esto. Los clientes envían sus deltas al servidor; El servidor consolida y distribuye los deltas a los clientes. Este es el caso típico. Las bases de datos llaman a esto "replicación de transacciones".
El cliente ha perdido la sincronización. Ya sea a través de una copia de seguridad / restauración o debido a un error. En este caso, el cliente necesita obtener el estado actual del servidor sin pasar por los deltas. Se trata de una copia del master al detalle, deltas y performance maldita sea. Es una cosa de una sola vez; el cliente esta roto No intente optimizar esto, solo implemente una copia confiable.
El cliente es sospechoso. En este caso, debe comparar el cliente con el servidor para determinar si el cliente está actualizado y necesita deltas.

Debe seguir el patrón de diseño de la base de datos (y SVN) de numeración secuencial de cada cambio. De esa manera, un cliente puede hacer una solicitud trivial ("¿Qué revisión debería tener?") Antes de intentar sincronizar. Y aún así, la consulta ("Todos los deltas desde 2149") es deliciosamente simple para que el cliente y el servidor la procesen.

La pregunta no es muy clara, pero buscaría un bloqueo optimista si fuera usted. Se puede implementar con un número de secuencia que el servidor devuelve para cada registro. Cuando un cliente intenta volver a guardar el registro, incluirá el número de secuencia que recibió del servidor. Si el número de secuencia coincide con lo que hay en la base de datos en el momento en que se recibe la actualización, se permite la actualización y se incrementa el número de secuencia. Si los números de secuencia no coinciden, la actualización no está permitida.

Lo que realmente necesitas es Transformación operacional (OT). Esto puede incluso atender los conflictos en muchos casos.

Esto sigue siendo un área activa de investigación, pero hay implementaciones de varios algoritmos OT alrededor. He estado involucrado en dicha investigación durante varios años, así que avíseme si esta ruta le interesa y estaré encantado de ponerle recursos relevantes.

Para la sincronización delta (cambio), puede usar el patrón pubsub para publicar cambios de nuevo en todos los clientes suscritos, servicios como empujer pueden hacer esto.

Para la creación de reflejo de la base de datos, algunos marcos web utilizan una mini base de datos local para sincronizar la base de datos del lado del servidor con la local en la base de datos del navegador; se admite la sincronización parcial. Compruebe meteror .