¿RabbitMQ, ZeroMQ, Service Broker o algo similar es una solución adecuada para crear un servicio web de base de datos de alta disponibilidad?

Question

Tengo un servicio web CRUD, y se me ha encomendado la tarea de tratar de encontrar una manera de garantizar que no perdamos datos cuando la base de datos no funcione. Todos sabemos que si la base de datos deja de funcionar, no podremos obtener "lecturas", pero para un subconjunto específico de las operaciones queremos asegurarnos de no perder datos.

Me ha dado la impresión de que esto es algo que está cubierto por servicios como 0MQ, RabbitMQ o uno de los servicios de Microsoft MQ. Aunque después de unos días de lectura e investigación, ni siquiera estoy seguro de que los mensajes de los que estamos hablando en los servicios de MQ incluyan operaciones de bases de datos. Sin embargo, estoy 100% seguro de que puedo hacer cola en todos los hello worlds que pueda esperar.

Si puedo usar una cola de mensajes para agregar una capa de protección a la base de datos, me inclino hacia Rabbit (porque parece persistir por fallas) pero dado que el objetivo es un databse del servidor Microsoft SQL, quizás uno sus soluciones (como SQL Service Broker o MSMQ) son más apropiadas.

La verdadera pregunta fundamental de la que todavía no estoy seguro es si estoy jugando con la baraja adecuada (por así decirlo).

Con el deseo de un servicio web de alta disponibilidad, que continúa funcionando si la base de datos falla, ¿tiene sentido poner una instancia de Rabbit MQ "entre" el servicio web y la base de datos? ¿Quizás el enlace correcto en la cadena es que RabbitMQ envíe mensajes al servidor web?

¿O hay alguna otra solución para lograr esto? Hay una serie de ideas perdidas en este momento sobre cómo encontrar una manera de reiniciar los weblogs en caso de corte de la base de datos o algo así ... pero todavía estamos en las primeras etapas que (al menos yo) no tengo ni idea de lo que ' voy a hacer

¿La cola de mensajes es la solución correcta?

Answer 1

Introducir colas de mensajes entre un servicio y una base de datos es ciertamente una forma de mejorar la disponibilidad del servicio. Escribir en una cola local siempre será más barato y más disponible que escribir en una base de datos.

Además, al utilizar las colas de espera, usted obtiene control sobre el volumen de tráfico de la base de datos que su base de datos debe manejar al máximo.

Sin embargo, para hacer esto, debe tener en cuenta que cuando se realiza una escritura en la base de datos, la solicitud se pone en cola y se entregará y procesará fuera de línea.

Incluso en condiciones en las que esto sucede de forma casi instantánea, está perdiendo el beneficio que la naturaleza sincrónica de su servicio actual le permite. Y ese beneficio es que sus consumidores de servicios (o clientes web) siempre pueden saber si la operación fue exitosa o no.

He escrito sobre este tema antes del here. El usuario que publicó la pregunta tenía preocupaciones similares a usted. Si haces esto o no es una decisión que debes tomar.

En cuanto a las pilas de tecnología en las que está pensando, 0MQ no es realmente un sistema de cola de mensajes, es más como enchufes con esteroides.

De las otras plataformas MQ que menciona, todas admiten durabilidad a través de bloqueos del sistema. MSMQ es una solución mucho más liviana que rabbitMQ (que implementa el protocolo AMQP y, por lo tanto, admite patrones de mensajes listos para usar).

Service Broker es una tecnología de base de datos y no se integra bien con el código, excepto a través de SqlDependency, o algo llamado Notificaciones que está habilitado en la plataforma StreamInsight.

Me gustaría ir a MSMQ (que admite mensajes duraderos a través de colas transaccionales) ya que es liviano, parte de Windows y tiene soporte para la biblioteca .net.