Um artigo completa compreensão Redis persistência: RDB e AOF

Por que persistem?

operações Redis sobre os dados são baseados em memória, quando confrontados com um processo sai, o tempo de inatividade do servidor e outras circunstâncias imprevistas, se não houver nenhum mecanismo de persistência, os dados Redis serão perdidos não podem ser recuperados. Com mecanismo de persistência, persistência antes que você pode usar Redis reinício quando o próximo arquivo para recuperação de dados. mecanismo de persistência Redis para entender e compreender, para a operação diária e manutenção e desenvolvimento de Redis é muito útil, também em entrevista fabricantes mais frequentes do conhecimento. Redis suporta dois mecanismos de persistência:

1. RDB: um instantâneo dos dados atuais armazenados no disco rígido.
2. AOF: cada operação de gravação dos dados para o disco rígido.

Em seguida, vamos saber mais sobre estes dois mecanismos de persistência.

RDB resistência de

RDB (Redis DataBase) é a persistência atual Redis em todos os snapshots de dados gerado armazenados no disco rígido. RDB persistência pode ser acionado manualmente ou automaticamente acionado.

trigger manual

saveE bgsavecomandos podem ser acionados manualmente RDB persistência.

comando save

Executar savecomando acionados manualmente persistência RDB, mas saveo comando irá bloquear serviço Redis até RDB persistência para ser concluído. Quando o serviço Redis para armazenar grandes quantidades de dados, ele irá causar obstrução muito tempo, não é recomendado.

> save
OK

Após a execução, Redis registrado no log:

 * DB saved on disk

comando bgsave

Executar bgsavecomando também manualmente gatilho RDB persistência e savecomandos são diferentes: serviços Redis em geral, não irá bloquear. processo Redis irá executar a operação fork para criar um processo filho, RDB persistente responsável pela criança, não bloqueia o processo de serviço Redis. Redis bloqueio de serviços ocorre apenas na bifurcação fase, em geral, um tempo muito curto.

> bgsave
Background saving started

Após a execução, Redis registrado no log:

 * Background saving started by pid 2645
 * DB saved on disk
 * RDB: 0 MB of memory used by copy-on-write
 * Background saving terminated with success

bgsavecomandos FIG processo específico é a seguinte:

1. Executar bgsavecomandos, processo Redis para determinar se existe actualmente RDB ou AOF sub-segmento de execução, se houver uma extremidade directa.
2. Redis processo de operação fork execução para criar um segmento de criança, processo Redis será bloqueado durante a operação de garfo.
3. Depois Redis garfo processo estiver concluído, bgsaveo comando é longo, desde processo Redis não está bloqueado, você pode responder a outros comandos.
4. De acordo com o processo filho gera uma memória de fotos processo Redis arquivo e substitua o RDB arquivo original.
5. Redis processo de processo de notificação criança foi preenchido pelo semáforo.

trigger automaticamente

Além de realizar o comando acima desencadeada manualmente fora, dentro Redis pode ser desencadeada automaticamente RDB persistência. acionado automaticamente RDB persistente são baseados bgsaveabordagem, reduzir o processo de Redis congestionamento. Assim, sob o cenário irá acionar automaticamente?

1. Guardar as definições de configuração no arquivo de configuração, tais como sava m n, quando ele foi modificado indica n vezes estou segundos dados, automaticamente gatilho bgsaveoperação.
2. Quando a quantidade total de replicação do nó fazendo, o nó mestre irá executar automaticamente bgsavea operação, e transmite o arquivo gerado para o RDB nó.
3. Executar debug reloadcomando, ele irá acionar automaticamente bgsavea operação.
4. Executar shutdowncomando, se não abrir persistência AOF irá acionar automaticamente bgsavea operação.

vantagem RDB

RDB é um arquivo de arquivo compactado binário compacto, Redis é um instantâneo de todos os dados em algum ponto no tempo. Portanto, use RDB para recuperar dados muito mais rápido do que AOF rápido, ideal para backup, cópia completa do volume, cenário de recuperação de desastre.

deficiências RDB

Toda vez que bgsavea operação deve executar a operação regular garfo para criar uma criança pertencente a operações pesado, freqüentemente realizada alto custo, então eu não posso fazer persistência em tempo real, a persistência ou o segundo grau.

Além disso, por causa da iteração versão contínua Redis, existem diferentes formatos de versão RDB, é possível baixar a versão de formato RDB não é versões compatíveis de problemas de arquivo de alto RDB.

AOF persistência

AOF (Anexar arquivo somente) persistência é adicionado a cada comando de escrita escrito para o registo, quando você precisar de recuperar dados re-executar o comando arquivo AOF nele. AOF resolver a persistência de dados em tempo real, é atualmente o mainstream do modo de persistência Redis.

AOF fluxo persistente

processo FIG AOF é como se segue:

1. comando de acréscimo (acréscimo): todos os comandos de escrita são adicionados ao tampão de AOF (aof_buf) em.
2. sincronização de arquivos (sync): Dependendo do cache de política é sincronizado para o arquivo AOF AOF.
3. Arquivo Rewrite (reescrita): arquivos AOF reescrito regularmente para atingir o objectivo de compressão.
4. Os dados são carregados (carga): Quando você precisar restaurar os dados, re-executar os comandos no AOF arquivo.

estratégia de sincronização de arquivos

AOF processo de sincronização de arquivo persistente tem as seguintes estratégias:

1. Sempre : Cada buffer de gravação deve ser sincronizado com o arquivo AOF, operação de disco rígido é relativamente lento, limitando a alta concorrência Redis, a configuração não é recomendada.
2. NO : não realizado depois de cada memória intermédia de escrita, o ficheiro de sincronização para o funcionamento AOF pelo sistema operacional é responsável para cada ciclo do processo de sincronização AOF incontrolável, e aumenta a quantidade de dados por sincronização disco.
3. eversec : depois de cada buffer de gravação, sincronização uma vez por segundo pelo segmento dedicado, de modo que tanto a segurança desempenho e dados. É estratégia de sincronização recomendada é a estratégia padrão.

arquivos de gatilho substituição

AOF processo de reescrita arquivo persistente pode ser acionado manualmente ou automaticamente acionado.

1. gatilho Manual: Use o bgrewriteaofcomando.
2. Auto: determinar a época disparado automaticamente dispostas de acordo com a auto-aof-reescrita-min-tamanho e auto-aof-reescrita-percentual. auto-AOF-rewrite-min-size representa um valor mínimo quando reescrevendo operação tamanho do arquivo AOF, o padrão é 64 MB; auto-AOF-rewrite-porcentagem representa a proporção de AOF após uma reescrita do tamanho do arquivo atual eo tamanho do menor AOF arquivo valor, o padrão é 100. Enquanto apenas os dois primeiros serão acionados arquivos substituindo automaticamente excedido.

AOF persistência configuração

Depois AOF persistência de processos específicos tem que entender, nós olhamos como configurar o AOF. AOF persistência não é ativado por padrão, você precisa modificar o arquivo de configuração, tais como:

# appendonly改为yes，开启AOF
appendonly yes
# AOF文件的名字
appendfilename "appendonly.aof"
# AOF文件的写入方式
# everysec 每个一秒将缓存区内容写入文件 默认开启的写入方式
appendfsync everysec
# 运行AOF重写时AOF文件大小的增长率的最小值
auto-aof-rewrite-percentage 100
# 运行AOF重写时文件大小的最小值
auto-aof-rewrite-min-size 64mb