Discourse utilizza ampiamente il lock Redis come meccanismo di sincronizzazione. L’implementazione del lock Redis di Discourse (come mostrato di seguito) può essere ottimizzata per ridurre il numero di comandi Redis, diminuendo così il tempo di round-trip e i costi di esecuzione su Redis.
Come possiamo migliorarlo
Sia lock che unlock utilizzano le Transazioni Redis. Il processo di lock potrebbe essere semplificato nel codice riportato qui sotto:
WATCH key
GET key # determina se la chiave è scaduta
MULTI
SET key
EXPIRE key, expire_time + 1
Il motivo per cui si utilizza la transazione Redis (come ipotizzo) sembra essere la necessità di verificare se la chiave è scaduta prima di impostarla effettivamente.
Tuttavia, penso che potremmo semplicemente utilizzare il comando SETEX fornito da Redis, che imposta una chiave con un tempo di scadenza. Infatti, la documentazione Redis SETEX lo utilizza come esempio per sostituire SET & EXPIRE con SETEX.
Ecco gli argomenti a favore della sostituzione:
- Impostare il valore come tempo di scadenza e verificarlo prima di impostare la chiave è superfluo. Il meccanismo TTL è sufficiente a garantire che la chiave scada correttamente.
- Anche se decidessimo di utilizzare il tempo di scadenza come valore, non avremmo bisogno di alcuna transazione. Poiché garantire l’atomicità tra
GET(riga 2 nel codice sopra) eMULTI & EXECnon aggiunge alcun valore. Questo perché, se il lock non viene acquisito, verrà riprovato.
Nota storica
Ho approfondito la cronologia dei commit Git per raccogliere maggiori informazioni. Sembra che quando il lock Redis è stato introdotto, non venisse utilizzato il TTL fornito da Redis. La funzionalità TTL è stata introdotta molto più tardi.
Quindi, ipotizzo che potremmo fare un passo in più ed eliminare completamente le transazioni Redis.