A, Redis dois tipos de maneira persistente (RDB & AOF)
Redis persistência do processo não exige muito de nossos desenvolvedores para participar, o que temos a fazer é isso? Além de compreensão em profundidade dos princípios do papel do RDB e do AOF, o resto é desenvolver estratégias apropriadas com base na situação real, e, em seguida, mais complexo, que é um personalizado de alta disponibilidade, a estratégia de segurança de dados.
Dois, RDB maneira persistente:
Em RDB forma, você tem duas opções:
- Um deles é para executar manualmente comandos de dados persistentes para fazer Redis realizar um instantâneo dos dados; e executar manualmente o comando persistente, você ainda tem duas opções, ou seja, economia de comando e bgsave comando.
(1) Salvar trabalho operação Redis no segmento principal, de modo que a operação irá bloquear outros pedidos devem ser evitados.
(Por padrão, a persistência de arquivo dump.rdb, e após os redis de reinício, que ler automaticamente o arquivo, é aprendido, geralmente o próximo dez milhões tipo string chave, arquivos de 1GB instantâneo, a memória de sincronização de tempo 20-30 segundos)
(2) bgsave chama garfo, produzir a criança, o processo pai continuará a processar o pedido. O processo filho para gravar dados em um arquivo temporário, e depois de escrita, .rdb substituir o arquivo original. Fork ocorre quando o pai e processo de memória filho compartilhado, de modo a não afectar o processo filho para instantâneos de dados, durante o qual os dados modificados será uma cópia, mas não para a memória compartilhada. Então, RDB os dados persistentes é ocorrer dados de Fork. dados persistentes sob tais condições, se para alguns casos de inatividade, os dados serão perdidos por algum tempo. Se a sua situação não é tão sensível à perda de dados, perda também pode ser obtida a partir de bancos de dados tradicionais ou faltando parte não importa, então você pode escolher RDB maneira persistente.
- O outro é baseado em arquivos de configuração política configuradas para persistir dados automaticamente quando certas condições forem satisfeitas estratégia. Na verdade, ele bgsave comando e princípio de persistência é o mesmo.
Este é o arquivo de configuração de política padrão, ou a relação entre eles é, a cada 900 segundos, durante os quais pelo menos uma mudança fundamental, fazer snapshots. Ou a cada trezentos segundos mudanças fundamentais dez fazer snapshots. Ou a cada sessenta segundos, a mudança de pelo menos dez mil chaves, fazer snapshots.
3.AOF instantâneos:
AOF, acrescentar apenas arquivos. 
AppendOnly modificar o arquivo de configuração para sim. Depois de persistência abertura AOF, cada instrução executada por você, será gravado no arquivo appendonly.aof. Mas, na verdade, não imediatamente comando é gravada no arquivo de disco rígido, mas é escrito para o cache de disco rígido, a próxima estratégia, configure o tempo para gravar o arquivo em seu disco rígido a partir do cache de disco rígido. Assim, sob certas condições, até certo ponto, ainda haverá perda de dados, mas você pode reduzir significativamente a perda de dados.
Aqui está a configuração política persistente AOF. Redis usar everysec padrão, cada segundo que é persistente, e sempre será escrito para cada operação é imediatamente AOF arquivo. E não, não é ativamente sincronização, 30s padrão uma vez. Claro, sempre deve ser o menos eficiente, pense everysec o suficiente para uso, segurança de dados e alto desempenho.
Redis também nos permite usar os dois lados, e depois de os redis reinício irá recuperar dados de AOF porque coisa pequena AOF do que a perda de dados RDB.
E em profundidade compreensão da diferença entre:
RDB instantâneos cada vez vai voltar a gravar todas as informações para todo o conjunto de dados. RDB ao restaurar dados mais rápida, o desempenho maximizar Redis, o processo filho sem qualquer impacto no desempenho do pai.
operações de comando AOF registros ordenados Redis. situações inesperadas pouco de perda de dados. Ele constantemente adicionando registro de log operação AOF arquivo, você pode dizer, quão grande era esse arquivo. Sim, ele vai certamente tornar-se enorme, mas haverá Redis estratégias de otimização, como suas operações em uma chave key1, conjunto key1 001, set key1 002 , set key1 003. Isso é otimizar os resultados dos dois primeiros ligeiramente removidos, e que a configuração específica otimizado correspondente ao arquivo de configuração é
antiga refere-se a mais do que a última vez AOF AOF reescrita qual a percentagem de tamanho de arquivo, a otimização será, novamente, se não reescrito também, coloca o arranque principal. Este último está autorizado a reescrever o limite mínimo AOF tamanho do arquivo. bgrewriteaof comando é comando de substituição manualmente, processo filho garfo, em um arquivo temporário para reconstruir o estado de banco de dados, sem qualquer impacto sobre o AOF original, quando a reconstrução do velho Estado, vai colocar os dados durante um período de tempo após a ocorrência do garfo juntamente com adicional para um arquivo temporário e, finalmente, substituir o original AOF arquivo, o novo comando continua a acrescentar a um novo arquivo AOF.
