Le transazioni all'interno di un cluster Redis sono una storia diversa rispetto alle transazioni con Redis Standalone.
TL;DR;
Questo è più un problema concettuale relativo a garanzie e compromessi che a un problema con il cliente.
Spiegazione
In Redis Cluster, un particolare nodo è un master per uno o più hash-slot, ovvero lo schema di partizionamento per partizionare i dati tra più nodi. Uno slot hash, calcolato dalle chiavi utilizzate nel comando, risiede su un nodo. I comandi con più chiavi sono limitati a produrre lo stesso hash-slot. In caso contrario, vengono rifiutati. Tali costellazioni sono chiamate cross-slot.
Le transazioni sembrano essere la soluzione per eseguire comandi su chiavi di slot incrociati, ma a un certo punto si lascerebbe l'ambito di un nodo e sarebbe necessario un altro nodo per continuare la transazione. Questo può accadere se una chiave risiede su un nodo e l'altra chiave risiede su un altro nodo. Non c'è ancora alcun coordinamento delle transazioni e questo a volte può essere un problema per i problemi di Redis Cluster.
Un'API di alto livello che fornisce supporto transazionale per Redis Cluster deve affrontare molteplici problemi e finora esistono due strategie, come gestire le transazioni in Redis Cluster:
Supporta le transazioni se tutte le chiavi si trovano su un nodo
Questa opzione consente transazioni complete. La libreria client è necessaria per tenere traccia del nodo in cui viene eseguita la transazione e vietare le chiavi al di fuori dell'intervallo di slot per il tempo in cui la transazione è in corso. Poiché lo slot può essere determinato solo utilizzando un comando contenente una chiave, il client deve impostare un flag transazionale e al primo comando contenente una chiave deve essere emesso il comando MULTI, subito prima del primo comando all'interno della transazione. La limitazione qui è chiaramente il requisito di avere tutte le chiavi posizionate su un nodo.
Transazioni distribuite
In questo caso, vengono avviate più transazioni su tutti i nodi che si uniscono alla transazione distribuita. Questa transazione distribuita può includere chiavi da tutti i nodi master. Una volta eseguita la transazione, la libreria client avvia l'esecuzione della transazione, la libreria raccoglie tutti i risultati (per mantenere l'ordine dei risultati dei comandi) e li restituisce al chiamante.
Questo stile di transazione è trasparente per il cliente. Non appena viene richiesta una chiave su un particolare nodo e il nodo non fa ancora parte della transazione, aMULTI viene emesso il comando per unire il nodo alla transazione. Lo svantaggio qui è che le transazioni non possono più essere condizionate (WATCH ). Le singole transazioni non sanno se una chiave è stata modificata su un nodo diverso, quindi è possibile eseguire il rollback di una transazione mentre le altre transazioni andrebbero a buon fine. Suona un po' come un commit a due fasi.
Conclusione
Redis Transactions sembra un batch di comandi atomici che può essere reso condizionale. È importante ricordare che l'esecuzione del comando è posticipata perché i risultati letti vengono restituiti al momento dell'esecuzione della transazione e non al momento dell'emissione del comando.
Per Redis Cluster, i clienti non hanno deciso una strategia globale. È sicuro eseguire transazioni su un particolare nodo Redis Cluster, ma sei limitato alle chiavi servite da quel nodo. Entrambe le possibili strategie hanno proprietà che potrebbero essere utili per determinati casi d'uso, ma presentano anche delle limitazioni.
