Utilizzo di Redis come cache intermedia per l'API REST

Question

Abbiamo un'app iOS che comunica con un server django tramite l'API REST. La maggior parte dei dati consiste in oggetti Item piuttosto grandi che coinvolgono alcuni modelli correlati che vengono renderizzati in un unico dizionario piatto e questi dati cambiano raramente.

Abbiamo trovato che l'interrogazione di questo non è un problema per Postgres, ma la generazione di risposte JSON richiede una notevole quantità di tempo. D'altra parte, le raccolte di articoli variano per utente.

Ho pensato a un sistema di rendering, dove abbiamo creato un dizionario per oggetto Item e lo abbiamo salvato in redis come stringa JSON, in questo modo possiamo servire l'API direttamente da redis (ad es. HMGET (id degli elementi nella libreria utente), che è veloce, e rende relativamente facile rigenerare "istanze renderizzate", in pratica solo un paio di segnali post_save.

Mi chiedo quanto è buono questo disegno, ci sono grossi difetti in esso? Forse c'è un modo migliore per l'attività?

Answer 1

Certo, facciamo lo stesso nella nostra azienda, utilizzando Redis per archiviare non JSON ma stringhe XML di grandi dimensioni che vengono generate dai database di backend per richieste RESTful e consente di risparmiare un sacco di hop di rete e overhead.

Un paio di cose da tenere a mente se questa è la prima volta che si sta utilizzando Redis ...

Dedicated Server Redis
Redis è single-threaded e dovrebbe essere distribuito su un server dedicato con potenza della CPU sufficiente. Non commettere l'errore di distribuirlo sull'app o sul server del database.

High Availability
Impostare Redis con master/slave replica per alta disponibilità. So che ci sono stati molti progressi con Redis cluster, quindi potresti voler controllare anche quello per HA.

Cache Hit/Miss
Quando si controlla Redis per una cache "hit", se la connessione è morto o si verifica alcuna eccezione, non mancano la richiesta, appena predefinito al database; il caching dovrebbe sempre essere il "miglior sforzo" dal momento che il database può sempre essere utilizzato come ultima risorsa.