Redis è un database chiave-valore avanzato. È simile a memcached, ma i dati possono essere conservati e i tipi di dati sono ricchi. Ci sono stringhe, liste collegate, set e collezioni ordinate. Supporta il calcolo della somma, dell'intersezione e della differenza di complemento delle collezioni lato server, e supporta anche una varietà di funzioni di ordinamento. Quindi Redis può essere visto anche come un server di strutture dati.
Tutti i dati Redis vengono memorizzati in memoria e poi memorizzati su disco asincronamente di tanto in tanto (questo è chiamato "semi-persistente mode"); Puoi anche scrivere ogni modifica dei dati in un Append Only File (AOF) (questo si chiama "modalità di persistenza completa").
Il primo metodo è filesnapshotting: il redis predefinito persisterà i dati sul disco sotto forma di snapshot (un file binario, dump.rdb, questo nome di file può essere specificato), e il formato nel file di configurazione è: save N M significa che entro N secondi, redis prenderà una snapshot su disco se almeno M modifiche avvengono in redis. Ovviamente, possiamo anche eseguire manualmente il save o il bgsave (asincrono) per scattare snapshot.
Ecco una breve introduzione su come funziona: quando Redis deve persistere, Redis fa un fork di un processo figlio; Il processo figlio scrive i dati in un file RDB temporaneo su disco; Quando il sottoprocesso termina di scrivere il file temporaneo, sostituisce l'RDB originale, che ha il vantaggio del copy-on-write
Esiste anche un metodo di persistenza: append-only:filesnapshotting metodo. Quando redis è anomalamente morto, i dati recenti si perdono (la quantità di dati persi dipende dalla configurazione della tua policy di salvataggio), quindi questo è il suo più grande svantaggio: quando il volume di business è grande, i dati persi sono molti. Il metodo append-only può ottenere tutte le perdite di dati, ma le prestazioni di Redis sono peggiori. AOF può essere mantenuto durante tutto il processo, basta attivarlo nel file di configurazione (predefinito è no), appendone solo sì. Dopo che AOF è abilitato, ogni volta che redis esegue un comando per modificare i dati, questi verranno aggiunti al file AOF, e quando redis viene riavviato, il file AOF verrà letto per "replay" per ripristinarlo all'ultimo momento prima che redis venga chiuso.
Riscrittura LOG Man mano che il file AOF diventa sempre più grande con la modifica dei dati, molti dei quali registrano modifiche in una chiave. Pertanto, redis ha una caratteristica interessante: ricostruire il file AOF in background senza influenzare l'operazione lato client. Eseguire il comando BGREWRITEAOF in qualsiasi momento scrive la sequenza più breve di comandi nella memoria corrente sul disco, e questi comandi possono costruire completamente la situazione attuale dei dati senza cambiamenti inutili (come cambiamenti di stato, cambi di contatore, ecc.), riducendo la dimensione del file AOF. Quindi, quando si usa OF, redis consiglia anche BGREWRITEAOF.
Ci sono tre modi per aggiornare il file AOF, si riferisce al parametro di configurazione appendfsync: appendfsync chiama sempre fsync per scaricare nel file AOF ogni volta che viene inviato un comando di modifica, che è molto, molto lento ma anche molto sicuro; appendfsync ogni secondo chiama fsync per scaricare rapidamente nel file AOF, ma può perdere dati entro un secondo; appendfsync no si affida al sistema operativo per aggiornare, redis non aggiorna attivamente l'OV, che è il più veloce, ma la sicurezza è scarsa. Di default si consiglia un refresh al secondo, così da considerare sia la velocità che la sicurezza.
Potrebbe essere dovuto a ragioni di sistema che l'AOF sia corrotto, Redis non può più caricare questo OF dell'OV, puoi seguire i passaggi seguenti per risolverlo: Prima, fai un backup del file AOF e copialo in un altro posto; Correggi il file OF originale, esegui: $redis-check-aof –fix; Puoi usare il comando diff –u per vedere dove i file sono incoerenti prima e dopo la riparazione. Riavvia il servizio Redis.
Come funziona LOG Rewrite: Lo stesso usa copy-on-write: il primo redis forkerà un processo figlio; Il processo figlio scrive l'ultimo AOF in un file temporaneo; Il processo genitore scrive incrementalmente le ultime modifiche eseguite in memoria (al momento, il vecchio AOF è ancora scritto, ed è sicuro riscriverlo se fallisce); Quando il processo figlio termina di riscrivere il file temporaneo, il processo genitore riceve un segnale e scrive le precedenti modifiche incrementali in memoria fino alla fine del file temporaneo. Redis rinomina il vecchio file OF, rinomina il file temporaneo e inizia a scrivere nel nuovo OF.
Infine, nel caso (crash o crash del disco), ricorda di fare regolarmente il backup del file *rdb *.aof generato tramite filesnapshotting o Append-only sulla macchina remota. Uso un crontab per SCP ogni mezz'ora. Non ho usato la funzione master-slave di Redis, perché un backup di mezz'ora dovrebbe andare bene, e penso che sia un po' uno spreco della macchina se hai un master-slave. Questo dipende in definitiva dall'applicazione.
|
Pubblicato su 24/08/2017 16:37:45
|
|
|
