Saltar para o conteúdo 
O Redis Sentinel protege os projetos web contra falhas, monitorizando o Redis Master ativo, assumindo automaticamente o controlo de uma réplica e redirecionando os clientes de forma transparente para o novo nó. Vou mostrar como o Alta disponibilidade como funciona na prática uma arquitetura Master-Replica e quais são as configurações essenciais para uma comutação fiável.
Pontos centrais
- Failover automático protege as sessões, as caches e as filas em caso de falha do servidor principal.
- Decisões por quórum evitar falsos alarmes através do voto por maioria.
- Descoberta de serviços mantém os clientes ligados sem necessidade de alternar manualmente.
- Configuração simplificada para topologias clássicas de réplica mestre.
- Prático para lojas online, APIs e WordPress.
Por que é que o Redis Sentinel é importante para projetos web
O Redis armazena sessões, entradas de cache, filas e sinalizadores de funcionalidades no Memória de trabalho, o que permite que as consultas sejam respondidas muito rapidamente. Se o único servidor principal falhar, os inícios de sessão, os carrinhos de compras e as tarefas em segundo plano deixam de funcionar. É precisamente aqui que o Redis Sentinel entra em ação e, se necessário, muda automaticamente para uma réplica. Desta forma, evito falhas relacionadas com os dados, reduzo os riscos de erros e mantenho as latências estáveis e baixas. A solução é adequada para lojas online, back-ends SaaS, CMS headless e instalações de WordPress com grande volume de Tráfego.
É assim que o Sentinel funciona internamente
Os processos Sentinel monitorizam o Master, as réplicas e outros Sentinels através de pings regulares e consultas de estado, o que constitui uma fiável Proporciona uma visão geral do cluster. Se um Sentinel detetar problemas, marca inicialmente o mestre como estando subjetivamente em falha. Se um número suficiente de outros Sentinels confirmar esse estado, o mestre é considerado objetivamente em falha e o failover é iniciado. Em seguida, o Sentinel seleciona uma réplica com um bom estado de replicação e baixa latência para servir de novo mestre. Simultaneamente, o Service Discovery informa todos os clientes sobre a atual Endereço do mestre.
Arquitetura básica para alta disponibilidade
Uma configuração típica inclui um servidor principal para operações de gravação, pelo menos duas réplicas para fins de segurança e três sentinelas para garantir a fiabilidade Quórum-Decisões. O número de Sentinels mantém-se ímpar, para que seja possível obter uma maioria simples. Costumo distribuir os servidores Redis e os Sentinels por vários hosts, para melhor fazer face a falhas nos hosts. Para o projeto, vale a pena dar uma vista de olhos nas opções adequadas Topologias de replicação, para que os percursos de dados sejam curtos. Assim, consigo manter latências baixas e um sinal limpo Inversão de papéis.
Detecção de erros e lógica de failover
Os parâmetros principais encontram-se no ficheiro sentinel.conf: Com monitor sentinela defino o objetivo e o quórum. Através de down-after-milissegundos Defino durante quanto tempo um mestre pode ficar sem responder antes de o marcar como inativo. Com o «failover-timeout», controlo a duração e o comportamento da troca de funções, o que define o intervalo de tempo para novas ligações. O valor «parallel-syncs» limita o número de réplicas que se sincronizam simultaneamente com o novo mestre. Testo estes limites no ambiente de teste, para que a transição seja rápida, mas não demasiado agressiva aciona.
Sentinel vs. Redis Cluster
O Redis Cluster distribui os dados por vários slots de mestre e permite o sharding, enquanto o Sentinel garante a disponibilidade de um grupo de réplicas mestre. A minha decisão baseia-se no volume de dados, na carga de gravação, no suporte a clientes e no esforço operacional. Para caches e sessões centrais, utilizo frequentemente o Sentinel, porque a configuração e a operação são simples. Se precisar de escalabilidade horizontal para grandes volumes de dados, analiso o Cluster mais detalhadamente e verifico as funcionalidades dos clientes. Para uma abordagem mais aprofundada, consulte Cluster vs. Autônomo, que orienta a escolha de acordo com os objetivos do projeto Simplificado.
| Solução | Foco | Despesas | Utilização típica |
|---|---|---|---|
| Redis Cluster | Sharding e escalabilidade | Mais alto | Conjuntos de dados muito grandes, ampla distribuição |
| Redis Sentinel | Alta disponibilidade (HA) | Inferior | Cache central, sessões, filas |
Configuração prática, desde o ambiente de desenvolvimento (DEV) até ao ambiente de produção (PROD)
Começo com um servidor principal claramente definido e protejo-o com duas réplicas, cuja configuração defino no ficheiro redis.conf com a opção `replicaof` e verifico com o comando `INFO replication`. Coloco os sentinels em três hosts, carrego o ficheiro sentinel.conf com as opções monitor, auth-pass, down-after-milliseconds e failover-timeout e ativo os serviços a nível do sistema. Em seguida, testo o processo, parando o mestre de forma seletiva e observando a comutação. Em ambientes de contentores, presto atenção à existência de volumes persistentes para ficheiros de persistência e a nomes de serviço únicos. Para o ambiente de produção, planeio janelas de manutenção e documento Rolos e disponibiliza uma autenticação consistente para servidores e Sentinels.
Integração de clientes e estratégias de ligação
Para que as transições sejam contínuas, os clientes têm de utilizar ativamente o Sentinel. Na prática, guardo os endereços vários Introduza os Sentinel, incluindo os nomes dos Master, para que o cliente, através de SENTINEL get-master-addr-by-name determina sempre o endereço principal válido. Se os clientes suportarem a subscrição de eventos Sentinel (+switch-master), tornam-se ainda mais estáveis. Controlo os intervalos de tempo importantes através de tempos limite de ligação e de socket, backoff exponencial e limites claros de novas tentativas. Direcionei sistematicamente os acessos de escrita para o mestre; para aliviar opcionalmente a carga de leitura, integro réplicas com somente leitura , mas tenha em atenção os requisitos de consistência. Em ambientes com DNS, utilizo nomes de anfitrião únicos e resolvíveis e defino no Sentinel anunciar-Configurações para que ele indique corretamente o seu endereço de contacto.
Segurança, autenticação e TLS
Em configurações produtivas, é Segurança por predefinição É imprescindível. Ativo as ACLs, atribuo utilizadores distintos para as aplicações, a replicação e a autenticação do Sentinel e limito rigorosamente os direitos aos comandos necessários. Protejo a comunicação entre o Redis, as réplicas e os Sentinels com TLS e, na configuração do firewall, permito exclusivamente as portas 6379 (Redis) e 26379 (Sentinel) a partir de redes definidas. Os endereços Bind isolam os serviços das interfaces públicas e verifico atempadamente o modo protegido, bem como a acessibilidade de host para host. Para a replicação, configuro masteruser/masterauth limpo, receber os Sentinels auth-user/auth-pass para consulta. Em ambientes de rede heterogéneos, reduzo as vulnerabilidades mantendo separados os acessos de gestão e, se necessário, tornando os comandos de administração sensíveis menos apelativos através da renomeação de comandos.
Persistência, consistência e profundidade de replicação
Embora o Redis funcione principalmente na RAM, planeio a persistência de forma consciente: o AOF e/ou o RDB garantem a segurança em caso de reinício e reduzem a janela de perda de dados. Com appendfsync (always/everysec) controlo a durabilidade em relação à latência de gravação; no caso das sessões e das caches, isso costuma ser suficiente everysec. Para ambientes replicados, dimensiono o Atrasos na replicação generoso, para que as réplicas possam, após perturbações na rede, um Resincronização parcial criar e não ter de sincronizar tudo de novo. Com mínimo de réplicas a escrever e min-replicas-max-lag Evito cenários de gravação de risco quando há poucas réplicas acessíveis ou quando estas apresentam atrasos significativos. A seleção dos candidatos em caso de failover é controlada através de prioridade-da-réplica e os deslocamentos de replicação, para que, na medida do possível, seja a réplica mais recente a assumir o controlo.
Obstáculos e soluções típicos
Valores demasiado ambiciosos para o «down-after-milliseconds» levam rapidamente a falsos alarmes; começo por valores conservadores e vou-os reduzindo à medida que obtenho informações do monitorização. Filtros de rede, endereços de ligação incorretos ou problemas de DNS prejudicam a comunicação do Sentinel, por isso verifico as portas, os nomes de anfitrião e Acessibilidade Desde cedo. Distribuo os Sentinels pelas zonas de disponibilidade, para que as falhas num local não bloqueiem as decisões por maioria. A falta de persistência (RDB/AOF) acarreta riscos de perda, por isso configuro o Redis para registar em configurações de alta disponibilidade (HA) e testo os reinícios. Analiso continuamente os registos e as métricas para detetar atempadamente latências anormais, pressão de memória ou desvio das réplicas Reconhecer.
Monitorização, registo e testes
Registo os logs do Sentinel e as métricas do Redis, tais como latência, utilização da memória, chaves removidas, atraso na replicação e estado do AOF, para poder reagir atempadamente. As regras de alarme notificam falhas, atrasos nas réplicas ou comutações repetidas. Os testes de failover devem fazer parte de cada sprint, para que as equipas dominem o processo com segurança. Documento a reação esperada dos clientes e mantenho listas de verificação prontas para reversões. Este ritmo reforça a Segurança operacional e reduz ao mínimo os tempos de inatividade.
Mais especificamente, analiso as funções de mestre/réplica, master_link_status, deslocamentos de replicação, operações instantâneas por segundo e indicadores de memória, como a fragmentação e as evacuações de chaves. Anomalias Taxas de reenvio Filenas, picos de latência repentinos ou flaps SDOWN/ODOWN recorrentes indicam problemas de rede ou de recursos. Configurei notificações para +switch-master e frequentes interrupções de failover, defino percursos de escalamento e registo as intervenções manuais. Sempre que for pertinente, utilizo o Sentinels script de notificação respectivamente script de reconfiguração do cliente, para acionar automaticamente sistemas externos e caches a jusante. Desta forma, as equipas mantêm-se informadas e as dependências permanecem consistentes.
O Redis Sentinel em ambientes de alojamento e com o WordPress
No WordPress, combino o Object Cache, as sessões persistentes e o Full-Page-Cache com o Sentinel, para que a disponibilidade do cache se mantenha estável mesmo sob carga. Separo os níveis web e de cache em instâncias diferentes e asseguro um elevado orçamento de E/S e de rede. Para uma transição sem problemas, vale a pena dar uma vista de olhos em comutação automática, para que as aplicações passem a utilizar imediatamente o novo servidor principal. Em configurações multi-tenant, imponho convenções de nomenclatura claras e ACLs consistentes. Desta forma, mantenho a administração organizada e aumento a Disponibilidade percetível.
Dois exemplos práticos de projetos web
Caso 1: Uma loja com promoções relâmpago armazena sessões e cestos de compras no Redis; em caso de falha do mestre, o Sentinel transfere o tráfego para uma réplica em segundos, enquanto o processo de checkout continua. Ajusto as sincronizações paralelas de forma a que estas não sobrecarreguem o novo mestre. Caso 2: Uma API utiliza o Redis como backend de limitação de taxa e de fila; com tempos de espera adequados e quórum, a API mantém-se operacional, mesmo que um nó falhe. Em ambos os casos, verifico se o cliente suporta o Sentinel, para poder atribuir dinamicamente o endereço do mestre a obter. Esta prática evita perdas de receita e mantém o fluxo de utilizadores mesmo em condições de elevada Carga.
Funcionamento em contentores e Kubernetes
Em ambientes orquestrados, garanto a identidade das instâncias do Redis através de nomes de anfitrião estáveis e volumes persistentes. Os StatefulSets, a anti-afinidade e os PodDisruptionBudgets impedem que várias funções sejam afetadas simultaneamente. As sondas de prontidão (Readiness) e de atividade (Liveness) têm em conta os estados de replicação, para que os nós não apareçam prematuramente no balanceador de carga. Para os Sentinels, também planeio pods/nós separados e mantenho os seus ficheiros de configuração persistentes, para que não percam os mestres/réplicas conhecidos. No que diz respeito à rede, opto por serviços «headless» para a resolução direta de nomes e reduzo as cadeias de saltos NAT, a fim de minimizar as latências e os falsos alarmes. Nas atualizações contínuas, protejo deliberadamente os quóruns: nunca alterei vários Sentinels ou o mestre ao mesmo tempo.
Manutenção, atualizações e regresso de um antigo «Master»
Para as atualizações, eu vou rolante Antes: Primeiro, atualizo as réplicas; depois, migro o mestre de forma controlada; por último, as sentinelas. Antes disso, faço uma cópia de segurança das configurações, planeio as cópias de segurança e verifico a integridade do AOF/RDB. Após um failover, o antigo mestre volta a funcionar como réplica; verifico o estado dos seus dados e a latência antes de o reintegrar no conjunto. Caso existam configurações divergentes ou entradas de autenticação incorretas, corrijo-as antes da reintegração. Mantenho os Sentinels consistentes e documento os comandos manuais (por exemplo, failover ou reiniciar), para que o estado se mantenha reproduzível. Utilizo as comutações planeadas para medições de carga e aprendo com elas para down-after e tempo de espera de failover.
Rede, quóruns e prevenção do «split-brain»
Distribuo os Sentinels pelos domínios de falha (AZs/Racks), para que as partições não bloqueiem as maiorias. Latências elevadas ou saltos de tempo assíncronos podem TILT-Ativar mecanismos de proteção; por isso, mantenho o NTP em bom estado e monitorizo os gargalos do agendador. Em cenários multirregionais, evito o failover automático entre regiões e, em vez disso, recorro à aprovação manual para evitar janelas de gravação inconsistentes. Controlo o cache do DNS com TTLs moderados, para que as alterações de endereço tenham efeito rapidamente, sem sobrecarregar o resolvedor. Para uma divulgação externa correta, utilizo de forma seletiva announce-ip/announce-port, caso os endereços internos e externos sejam diferentes.
Lista de verificação para a afinação na prática
- Sentinel: monitor, down-after-milissegundos, tempo de espera de failover, sincronizações paralelas validar em cada ambiente.
- Redis: Suficiente Atrasos na replicação, uma estratégia AOF/RDB sensata, mínimo de réplicas a escrever para uma escrita segura.
- Candidato a failover: prioridade-da-réplica, acompanhar os desfasamentos de replicação e a latência.
- Segurança: separar as ACLs (App/Replica/Sentinel), ativar o TLS, restringir rigorosamente as portas e as ligações.
- Clientes: Verificar se existem várias moradas Sentinel, o nome do mestre, os tempos de espera/backoff e a reconfiguração automática.
- Rede: nomes de host/DNS estáveis, TTLs moderados, autorizações de firewall, distribuição entre zonas de disponibilidade.
- Observabilidade: centralizar registos e métricas, +switch-master emitir alertas, atualizar os manuais de procedimentos.
- Processos: Simulações regulares de failover, janelas de manutenção, planos de contingência documentados.
Resumo: Alta disponibilidade sem rodeios
O Redis Sentinel oferece monitorização automática, failover e deteção de serviços numa configuração clássica de mestre-réplica, mantendo os caches críticos disponíveis. Eu configuro, no mínimo, três Sentinels, duas réplicas e tempos de espera bem definidos, para que as transições ocorram de forma rápida e fiável. Em comparação com o Redis Cluster, a operação mantém-se mais simples, o que facilita a análise de erros e a manutenção. Quem pretenda proteger sessões, caches ou filas beneficia diretamente desta Arquitetura. Com uma configuração correta, testes contínuos e uma monitorização atenta, o vosso backend Redis atinge um elevado Resiliência na vida quotidiana.
