RabbitMQ, ZeroMQ, Service Broker o qualcosa di simile sono una soluzione appropriata per la creazione di un servizio web di database ad alta disponibilità?

Question

Ho un servizio web CRUD, e ho il compito di cercare di capire un modo per garantire che non perdiamo dati quando il database va giù. Tutti sanno che se il database non funziona, non saremo in grado di ottenere "letture", ma per un sottoinsieme specifico delle operazioni vogliamo assicurarci di non perdere i dati.

Mi è stata data l'impressione che si tratti di servizi come 0MQ, RabbitMQ o uno dei servizi Microsoft MQ. Sebbene dopo alcuni giorni di lettura e ricerca, non sono nemmeno sicuro che i messaggi di cui stiamo parlando nei servizi MQ includano le operazioni di database. Sono comunque sicuro al 100% di poter accodare quanti più mondi ciao come potrei mai sperare.

Se riesco a utilizzare una coda di messaggi per aggiungere un livello di protezione al database, mi rivolgo a Rabbit (perché sembra persistere attraverso arresti anomali) ma poiché l'obiettivo è un database Microsoft SQL server, forse uno di le loro soluzioni (come SQL Service Broker o MSMQ) sono più appropriate.

La vera domanda fondamentale di cui non sono ancora sicuro è se sto addirittura giocando con il mazzo di carte giusto (per così dire).

Con il desiderio di un servizio web ad alta disponibilità, che continua a funzionare se il database va giù, ha senso mettere un'istanza di Rabbit MQ "tra" il webservice e il database? Forse il link giusto nella catena è avere RabbitMQ per inviare messaggi al server web?

Oppure c'è qualche altra soluzione per raggiungere questo? Ci sono un certo numero di idee perdute al momento di trovare un modo per fare il rollup dei blog in caso di interruzione del database o qualcosa del genere ... ma siamo ancora agli stadi precoci che (almeno io) non ho idea di cosa sia sto andando a fare.

Il messaggio è la coda della soluzione giusta?

Answer 1

Introdurre l'accodamento dei messaggi tra un servizio e un database è sicuramente un modo per migliorare la disponibilità del servizio. Scrivere su una coda locale sarà sempre più economico e più disponibile rispetto alla scrittura su un database.

Inoltre, utilizzando l'accodamento si ottiene il controllo del volume del traffico del database che il database deve gestire al massimo.

Tuttavia, per fare questo è necessario essere consapevoli del fatto che quando viene eseguita una scrittura del database la richiesta viene messa in coda e verrà consegnata ed elaborata offline.

Anche in condizioni in cui ciò accade quasi istantaneamente, si sta perdendo il vantaggio che la natura sincrona del servizio corrente consente. E questo vantaggio è che i consumatori del servizio (o i client Web) possono sempre sapere se l'operazione è andata a buon fine o meno.

Ho già parlato di questo argomento prima dello here. L'utente che ha postato la domanda ha avuto preoccupazioni simili a te. Che tu lo faccia o no è una decisione che devi prendere.

Per quanto riguarda gli stack tecnologici a cui stai pensando, 0MQ non è realmente un sistema di code di messaggi, è più simile a socket su steroidi.

Delle altre piattaforme MQ citate, tutte supportano la durata attraverso arresti anomali del sistema. MSMQ è molto più leggero di una soluzione di rabbitMQ (che implementa il protocollo AMQP e supporta quindi schemi di messaggistica immediatamente disponibili).

Il broker di servizi è una tecnologia di database e non si integra bene con il codice tranne tramite SqlDependency o qualcosa chiamato Notifiche abilitato sulla piattaforma StreamInsight.

Vorrei andare per MSMQ (che supporta la messaggistica durevole tramite code transazionali) poiché è leggero, parte di Windows e ha il supporto della libreria .net core.