2010-11-21 7 views
9

Cuando las instantáneas de los agregados no están sincronizadas con el registro de eventos, simplemente puedo reproducir mis eventos a partir de instantáneas anteriores (que se supone que están sincronizadas). Lo mismo puedo hacer cuando agrego/elimino nuevos campos o cuando modifico la lógica de los manejadores existentes.¿Cómo manejar situaciones, cuando el modelo de lectura no se sincronizó con los registros de eventos?

En caso de que necesite agregar un nuevo modelo de lectura (es decir, una nueva vista de informe), puedo hacer lo mismo otra vez: volveré a reproducir mis eventos.

Pero, ¿cómo debo manejar la situación, cuando el modelo de lectura no se sincronizó con el registro de eventos? El almacenamiento de eventos y la publicación están en una transacción, pero la actualización del modelo de lectura ocurrió en otra transacción, que puede fallar. La repetición de eventos desde el principio puede ayudar, pero puede llevar toda la eternidad. ¿Necesito un concepto de instantáneas para todo el modelo de lectura?

¿Cómo resuelves este problema? Gracias.

Respuesta

7

¿Cuál sería el motivo de la falla en el controlador de eventos? ¿Cuánto dura la "eternidad"?

Las actualizaciones del modelo de lectura rara vez fallan (a diferencia de los controladores de comandos), ya que la lógica interna es extremadamente simple. Es probable que las fallas sean causadas por problemas transitorios (IO/interrupción de la red) y el bus de mensajes las manejará automáticamente.

Sin embargo, si el modelo de lectura se corrompió por alguna razón, entonces la forma más fácil de restablecerlo y transmitir los eventos a través de. Incluso millones de eventos tomarían una cantidad de tiempo razonablemente pequeña. Además, siempre puedes usar el enfoque Map-Reduce.

Recomendaría no introducir instantáneas para leer modelos. Creo que esto solo complica la arquitectura sin ningún beneficio significativo.

+1

Gracias Rinat! En caso de repetición de eventos desde el principio, ¿utiliza un hilo de controladores de eventos? Porque en caso de usar varios subprocesos de trabajo, puedo recibir resultados incorrectos (aunque funcionará en producción debido a la naturaleza del dominio: la condición de carrera de varios eventos no es posible cuando se publican usuarios reales, pero es posible cuando se publica uno por uno para varios hilos de trabajo). ¿Reconoce globalmente que debemos usar solo un hilo de trabajo para procesar eventos desde el principio? Gracias por tus valiosas respuestas. –

+0

Buena llamada. Prefiero evitar tales problemas de concurrencia ejecutando siempre no más de 1 hilo por instancia de entidad (ya sean comandos o eventos). De modo que podemos tener múltiples hilos para los manejadores de eventos, sin embargo, cada vista * instancia * (identificada por alguna identidad) siempre será manejada solo por un solo hilo. Por supuesto, un hilo puede manejar más de una instancia de vista o escribir a la vez. ¿Esto ayuda? –

+0

¡Gracias! Después de algunos días de analizar tu respuesta, creo que entiendo la mecánica del manejo de eventos con múltiples hilos de trabajo. Aprecio tus respuestas. –

Cuestiones relacionadas