Abbiamo un sistema occasionalmente connesso, basato su eventi: un'applicazione di budgeting in cui ogni cliente può prelevare l'archivio eventi di un altro cliente da un archivio separato (condivisione di rete, casella personale, ...).
È nostra idea assegnare ad ogni evento l'orologio vettoriale (incrementato) del client corrente in modo da poter determinare un ordine globale di eventi quando estraiamo gli eventi da altri client.
Tuttavia, l'ordine tramite gli orologi vettoriali è garantito solo se non ci sono aggiornamenti simultanei.
Abbiamo pensato di aggiungere un timestamp locale al clock vettoriale che deve essere utilizzato per risolvere tali conflitti. L'ordine risultante sarebbe lo stesso su ciascun client perché i timestamp sono generati al momento dell'evento stesso.
Se due timestamp sono identici, ricorreremo all'ordine tramite l'id del cliente.
Questo approccio è sano e sicuro?
Informazioni aggiuntive
Supportiamo più client (cioè dispositivi). Ogni cliente gestisce un negozio di eventi locale. I clienti possono pubblicare il loro negozio di eventi, a quel punto diventa disponibile per gli altri clienti. Esempio: il client A salva la sua ultima versione in una cartella in Dropbox - altri client possono quindi leggere le informazioni persistenti.
Quando estraiamo gli store degli eventi da altri client, dobbiamo unirli nel nostro negozio e ricostruire l'ordine globale degli eventi (la concorrenza è l'ultima vittorie). Ciò significa che ogni cliente, nel tempo, condividerà la stessa lista di eventi (consistenza finale).
Per ottenere un ordine globale, vogliamo utilizzare gli orologi vettoriali. Ogni evento ha un orologio vettoriale unico di quel punto nel tempo associato ad esso. Gli eventi vengono creati da qualsiasi client e inizialmente vengono memorizzati solo nell'archivio eventi locale del client. L'aggiunta di nuovi eventi all'archivio eventi incrementa l'orologio vettoriale del client.
Avremo eventi come Transazione aggiunta all'account , Transaction description modificata , Importo preventivato aggiustato ecc. Ogni nuovo cliente sarà un fork dell'archivio eventi di qualche altro client, eventualmente integrato con altri store di eventi del cliente. Successivamente, può aggiungere i propri eventi contemporaneamente mentre altri client sono attivi.
Uno di questi casi d'uso è: Sono fuori a fare acquisti e inserisco una transazione nel mio telefono mentre qualcun altro a casa sta adeguando il budget pianificato e le transazioni di compensazione in base al nostro estratto conto bancario. Le mie transazioni potrebbero essere visualizzate una volta che il cliente a casa ha ritirato i miei ultimi aggiornamenti, ma entrambi i client continuano a funzionare in modo un po 'disconnessi con aggiornamenti simultanei su entrambi i client.
Gli aggiornamenti simultanei non dovrebbero essere un problema con un'architettura basata su eventi, dal momento che possiamo determinare lo stato completo dell'applicazione ripetendo tutti gli eventi nell'ordine . Vedremo solo alcuni conflitti se più client modificano gli stessi aggregati o i modelli di lettura risultanti - nel qual caso: le ultime vincite e prova a parlare tra loro prima di lavorare sulle stesse cose.