Redis é um banco de dados avançado de chave-valor. É parecido com o memcached, mas os dados podem ser preservados e os tipos de dados são ricos. Existem strings, listas enlaçadas, conjuntos e coleções ordenadas. Ele suporta calcular a soma, interseção e complementaridade (diferença) de coleções no lado do servidor, além de suportar uma variedade de funções de ordenação. Assim, o Redis também pode ser visto como um servidor de estruturas de dados.
Todos os dados do Redis são armazenados na memória e depois armazenados no disco de forma assíncrona de tempos em tempos (isso é chamado de "modo semi-persistente"); Você também pode gravar todas as alterações de dados em um Arquivo Apenas Anexo (AOF) (isso é chamado de "modo de persistência completa").
O primeiro método é filesnapshotting: o redis padrão persiste dados para o disco na forma de um snapshot (um arquivo binário, dump.rdb, esse nome de arquivo pode ser especificado), e o formato no arquivo de configuração é: save N M significa que, em N segundos, o redis fará um snapshot para o disco se pelo menos M modificações ocorrerem no redis. Claro, também podemos executar manualmente save ou bgsave (assíncrono) para tirar snapshots.
Aqui está uma breve introdução de como funciona: Quando o Redis precisa persistir, o Redis faz um fork de um processo filho; O processo filho grava os dados em um arquivo RDB temporário no disco; Quando o subprocesso termina de escrever o arquivo temporário, ele substitui o RDB original, que tem a vantagem do copy-on-write
Também existe um método de persistência: Append-only:filesnapshotting método Quando o redis está anormalmente morto, os dados recentes serão perdidos (a quantidade de dados perdidos depende da configuração da sua política de salvamento), então essa é a maior desvantagem: quando o volume de negócios é grande, os dados perdidos são muitos. O método apenas append-only pode alcançar toda a perda de dados, mas o desempenho do redis é pior. O AOF pode ser mantido durante todo o processo, só precisa ser ativado no arquivo de configuração (o padrão é não), apenas apendido sim Depois que o AOF for ativado, toda vez que o Redis executar um comando para modificar dados, ele será adicionado ao arquivo AOF, e quando o Redis for reiniciado, o arquivo AOF será lido para "replay" e restaurado até o último momento antes do fechamento do Readis.
Regravação LOG À medida que o arquivo AOF se torna cada vez maior à medida que os dados são modificados, muitos dos quais registram mudanças em uma chave. Portanto, o redis tem uma característica interessante: reconstruir o arquivo AOF em segundo plano sem afetar a operação do lado do cliente. Executar o comando BGREWRITEAOF a qualquer momento gravará a sequência mais curta de comandos na memória atual no disco, e esses comandos podem construir completamente a situação atual dos dados sem mudanças desnecessárias (como mudanças de estado, mudanças de contador, etc.), reduzindo o tamanho do arquivo AOF. Então, ao usar OF, o Redis recomenda usar também o BGREWRITEAOF.
Existem três maneiras de atualizar o arquivo AAF, consulte o parâmetro de configuração appendfsync: appendfsync sempre chama o fsync para limpar o arquivo AOF toda vez que um comando de modificação é enviado, o que é muito, muito lento, mas também muito seguro; appendfsync everysec chama fsync a cada segundo para esvaziar rapidamente para o arquivo AOF, mas pode perder dados em um segundo; appendfsync não depende do sistema operacional para atualizar, o redis não atualiza ativamente o OV, que é o mais rápido, mas a segurança é ruim. A atualização por segundo é recomendada por padrão, para que tanto a velocidade quanto a segurança sejam consideradas.
Pode ser por razões do sistema que o AOF está corrompido, o Redis não pode mais carregar esse OF do OV, você pode seguir os passos abaixo para corrigir: Primeiro, faça um backup do arquivo AOF e copie para outro lugar; Corrigir o arquivo OF original, executar: $redis-check-aof –fix; Você pode usar o comando diff –u para ver onde os arquivos são inconsistentes antes e depois do reparo. Reinicie o serviço Redis.
Como funciona o LOG Rewrite: O mesmo usa copy-on-write: o primeiro redis faz fork de um processo filho; O processo filho grava o AOF mais recente em um arquivo temporário; O processo pai escreve incrementalmente as últimas mudanças executadas na memória (neste momento, o AOF antigo ainda está escrito, e é seguro reescrever caso falhe); Quando o processo filho termina de reescrever o arquivo temporário, o processo pai recebe um sinal e grava as alterações incrementais anteriores na memória até o final do arquivo temporário. O Redis renomeia o arquivo OF antigo, renomeia o arquivo temporário e começa a escrever no novo OF.
Por fim, caso (a máquina trave ou trave o disco), lembre-se de fazer backup regular do arquivo *rdb *.aof gerado usando filesnapshotting ou apenas Append-only na máquina remota. Eu uso um crontab para SCP a cada meia hora. Não usei a função mestre-escravo do Redis, porque um backup de meia hora deve ser suficiente, e sinto que é um desperdício da máquina se você tem um mestre-escravo. Isso depende, no fim das contas, da aplicação.
|
Publicado em 24/08/2017 16:37:45
|
|
|
