Transazioni distribuite con Kafka

2

Devo implementare una transazione che si estende su componenti non accoppiati (SOA + MOM).

Quando viene ricevuto un particolare evento, FOO e BAR devono eseguire un'operazione transazionale: cioè, entrambe le transazioni su FOO-DB e BAR-DB devono essere eseguite correttamente o nessuna di esse. La coerenza qui è molto importante.

Quando l'evento è ricevuto (1), FOO esegue un'operazione su un database (2).
Se l'operazione fallisce, non accade più nulla.
Se l'operazione ha esito positivo, un messaggio viene inviato a BAR tramite un MOM (Kafka) (3).
BAR esegue un'operazione su un altro database (4).
Se l'operazione fallisce, l'operazione precedentemente eseguita su FOO-DB deve essere ripristinata (5, 6).
Se l'operazione ha esito positivo, va tutto bene.

In questo momento sto usando Kafka. Mi piace la sua semplicità e velocità, ma sono aperto a considerare altre soluzioni se renderebbero questa situazione più facile da implementare / mantenere / estendere.

Sono abbastanza nuovo per architetture e pattern SOA e MAM, quindi mi chiedo:

  • questo è uno scenario / modello comune?
  • come viene comunemente implementato?
  • i mezzi semplici offerti da Kafka sono sufficienti per implementarlo in modo affidabile o sarebbe meglio prendere in considerazione altre soluzioni?
  • è il gestore delle transazioni distribuite solitamente fornito dal MOM o dal database? e se è il DB, come può essere fatto usando diversi DB?

Ci scusiamo per le molte domande, spero che non siano troppo per una singola domanda. Grazie!

    
posta Domenico De Felice 01.09.2015 - 17:37
fonte

2 risposte

1

Sto postando questo commento come risposta perché è troppo lungo per un commento, ma non fornisce una soluzione praticabile al problema degli OP, ma spiega solo perché ciò che vuole fare è che AFAIK non è in grado di implementare correttamente il 100%.

Si menziona FOO-DB due volte nel commento ma non in BAR-DB. Intendevi BAR-DB nella tua seconda istanza? Immagino che tu l'abbia fatto.

Ad ogni modo, ecco perché ciò che hai scritto non funzionerà: tu aggiorni il FOO-DB ma con un tag "non validato", succede, vai ad aggiornare BAR-DB, e una volta che confermi che l'aggiornamento ha avuto successo, tu rimuovere il tag "non validato" dal FOO-DB (che è solo un altro aggiornamento). In questo caso, tra il momento in cui si aggiorna il BAR-DB e si contrassegna il FOO-DB come convalidato, i database combinati si trovano in uno stato incoerente.

In sostanza, hai solo ritardato il problema di un round. Questo è simile al problema di due generali , ma non esattamente lo stesso. Anche se possiamo supporre che le comunicazioni tra questi due nodi siano garantite (perché stai usando Kafka), c'è sempre un ritardo non specificato e sconosciuto, rendendo impossibile un aggiornamento Atomico e Consistente ai database combinati.

Vorrei sottolineare che non sono un esperto di database. Ad esempio, questo era un problema in cui ho lavorato usando il cluster MongoDB che avevamo installato. Poiché disponevamo di più nodi per ogni database (replica), se si aggiornava un record nel database e si leggeva il record subito dopo, non si poteva garantire la lettura del record aggiornato. Le scritture richiedevano una quantità di tempo (solitamente piccola ma sconosciuta) da propagare a tutte le repliche.

In realtà non hai specificato quali database stai usando, quindi non conosco le esatte garanzie che forniscono, ma dal momento che sono due cluster completamente diversi da quello che sembra, quindi non importa quale MOM usi comunicare tra loro è, non possono coordinarsi perfettamente.

L'unica soluzione che posso pensare è bloccare entrambi i database, eseguire gli aggiornamenti e quindi sbloccare entrambi i database. Ovviamente questo non è fattibile, ma è un esperimento mentale per mostrare quale tipo di misure estreme ci vorrebbe per raggiungere questo obiettivo.

    
risposta data 26.01.2016 - 16:35
fonte
0

Non ho familiarità né con "Kafka" né con "MAMMA", ma se non lo faccio ancora, probabilmente inizierò assicurandoti che le idee dietro commit a due fasi sono compresi, al fine di guidare / informare la tua progettazione e il tuo sforzo di implementazione, a seconda del livello di coerenza che vuoi raggiungere.

'Spero che questo aiuti.

    
risposta data 11.09.2015 - 09:40
fonte

Leggi altre domande sui tag