{"id":20508,"date":"2026-08-10T11:49:43","date_gmt":"2026-08-10T09:49:43","guid":{"rendered":"https:\/\/webhosting.de\/redis-cluster-sharding-hosting-lastverteilung\/"},"modified":"2026-08-10T11:49:43","modified_gmt":"2026-08-10T09:49:43","slug":"redis-cluster-sharding-alojamento-distribuicao-de-carga","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/redis-cluster-sharding-hosting-lastverteilung\/","title":{"rendered":"Sharding do Redis Cluster: distribui\u00e7\u00e3o de carga para grandes plataformas de alojamento"},"content":{"rendered":"<p>O Redis Cluster distribui as chaves por 16 384 slots de hash, criando assim <strong>Fragmenta\u00e7\u00e3o<\/strong> com distribui\u00e7\u00e3o de carga program\u00e1vel para grandes plataformas de alojamento. Vou mostrar, concretamente, como os servi\u00e7os de alojamento distribuem sess\u00f5es, caches, filas e limites de taxa por v\u00e1rios n\u00f3s e, assim, <strong>Estrangulamentos<\/strong> evitar no que diz respeito \u00e0 RAM, \u00e0 CPU e \u00e0 rede.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<p>Esta sec\u00e7\u00e3o resume as principais conclus\u00f5es sobre <strong>Redis<\/strong> O Sharding em cluster para alojamento re\u00fane estes aspetos e classifica-os de forma pr\u00e1tica. Procuro manter a lista concisa, para que as decis\u00f5es relativas \u00e0 arquitetura, ao funcionamento e ao crescimento sejam tomadas mais rapidamente. Os pontos servem de orienta\u00e7\u00e3o para o planeamento, a implementa\u00e7\u00e3o e o ajuste em ambientes de produ\u00e7\u00e3o <strong>Arredores<\/strong>.<\/p>\n<ul>\n  <li><strong>Slot de hash<\/strong>: 16 384 slots distribuem as chaves de forma autom\u00e1tica e determin\u00edstica.<\/li>\n  <li><strong>Escalonamento<\/strong>: Um maior n\u00famero de n\u00f3s aumenta a capacidade atrav\u00e9s da redistribui\u00e7\u00e3o dos slots.<\/li>\n  <li><strong>Alta disponibilidade<\/strong>: As r\u00e9plicas garantem a transi\u00e7\u00e3o em caso de falha e melhoram o desempenho de leitura.<\/li>\n  <li><strong>Cargas de trabalho<\/strong>: As sess\u00f5es, as caches, as filas e os limites de taxa beneficiam de forma mensur\u00e1vel.<\/li>\n  <li><strong>Key-Design<\/strong>: As hashtags reduzem os acessos entre slots no dia-a-dia.<\/li>\n<\/ul>\n<p>Recomendo que estes pontos-chave sejam utilizados como <strong>Lista de controlo<\/strong> utiliz\u00e1-las e verific\u00e1-las cuidadosamente sempre que forem feitas altera\u00e7\u00f5es no perfil de carga, na estrutura de dados ou na automatiza\u00e7\u00e3o da implementa\u00e7\u00e3o.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis-cluster-serverraum-4862.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Como funciona o sharding no Redis Cluster<\/h2>\n<p>Um cluster Redis divide todo o espa\u00e7o de chaves em exatamente 16 384 <strong>Slot de hash<\/strong> . A atribui\u00e7\u00e3o de slots \u00e9 feita de forma determin\u00edstica atrav\u00e9s do CRC16, mais precisamente atrav\u00e9s de <code>CRC16(chave) % 16384<\/code>, o que faz com que cada chave seja atribu\u00edda de forma repet\u00edvel ao mesmo slot. Este c\u00e1lculo permite a distribui\u00e7\u00e3o autom\u00e1tica, sem que as aplica\u00e7\u00f5es tenham de gerir a sua pr\u00f3pria l\u00f3gica de parti\u00e7\u00e3o, o que simplifica claramente a implementa\u00e7\u00e3o e a manuten\u00e7\u00e3o <strong>Simplificado<\/strong>. Se eu deslocar slots entre n\u00f3s, a parte de dados correspondente tamb\u00e9m se desloca, o que permite que o escalonamento horizontal ocorra de forma gradual. Para opera\u00e7\u00f5es com v\u00e1rias chaves, pretendo utilizar hash-tags como <code>utilizador:{42}:sess\u00e3o<\/code>, para que as chaves relacionadas fiquem no mesmo slot e os pedidos n\u00e3o ultrapassem os limites do cluster <strong>exceder<\/strong>.<\/p>\n\n<h2>Import\u00e2ncia para as grandes plataformas de alojamento<\/h2>\n<p>As grandes infraestruturas de alojamento agrupam muitas cargas de trabalho independentes e geram in\u00fameras <strong>Dicas<\/strong> na camada de cache e de sess\u00e3o. Um \u00fanico servidor tem uma escalabilidade limitada, porque a mem\u00f3ria, a rede e a CPU tornam-se rapidamente o fator limitante. Com o sharding em cluster, distribuo os pontos de maior carga por v\u00e1rios servidores prim\u00e1rios e, assim, consigo processar mais pedidos em paralelo por segundo. Os acessos com grande volume de leitura beneficiam das r\u00e9plicas, enquanto a carga de grava\u00e7\u00e3o \u00e9 distribu\u00edda por v\u00e1rios n\u00f3s <strong>divide<\/strong>. Desta forma, consigo manter os tempos de resposta mais constantes e atenuar o impacto de picos de tr\u00e1fego pontuais em toda a pilha.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis_cluster_meeting_7852.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Escalabilidade e alta disponibilidade em conjunto<\/h2>\n<p>Combino o escalonamento horizontal com a alta disponibilidade, fazendo com que cada parti\u00e7\u00e3o tenha um servidor prim\u00e1rio e, pelo menos, um <strong>R\u00e9plica<\/strong> recebe. Se um Primary falhar, a r\u00e9plica assume o controlo, garantindo que os dados permanecem acess\u00edveis e que as solicita\u00e7\u00f5es de leitura continuam a ser processadas. \u00c0 medida que a carga aumenta, adiciono n\u00f3s adicionais e redistribuo os slots, o que aumenta gradualmente a capacidade e o d\u00e9bito. Para aplica\u00e7\u00f5es com elevada carga de leitura, redireciono os consumidores de forma seletiva para as r\u00e9plicas, enquanto os percursos de grava\u00e7\u00e3o utilizam os n\u00f3s prim\u00e1rios. Esta separa\u00e7\u00e3o clara de fun\u00e7\u00f5es garante, em cargas de trabalho mistas, uma <strong>Tempos de resposta<\/strong> e reduz os pontos cr\u00edticos.<\/p>\n\n<h2>Melhores pr\u00e1ticas para opera\u00e7\u00e3o e arquitetura<\/h2>\n<p>Defino desde o in\u00edcio regras para os nomes das chaves, utilizo hashtags de forma consistente e separo sess\u00f5es, caches, filas e limites de taxa de forma l\u00f3gica atrav\u00e9s de nomes e TTLs, para que o cluster <strong>equilibrado<\/strong> permanece. Mantenho os conjuntos de liga\u00e7\u00f5es num tamanho reduzido e controlado e avalio cuidadosamente a lat\u00eancia, o tempo de espera, as tentativas de liga\u00e7\u00e3o e o comportamento do pipeline. Para altera\u00e7\u00f5es no tamanho do cluster, prevejo buffers de mem\u00f3ria, para que as redistribui\u00e7\u00f5es de slots ocorram sem escassez de mem\u00f3ria. Quem quiser comparar conceitos de alta disponibilidade (HA) pode consultar adicionalmente <a href=\"https:\/\/webhosting.de\/pt\/redis-sentinel-alta-disponibilidade-configuracao-do-servidor-redis-estabilidade\/\">Redis Sentinel<\/a> mas compreende que um cluster oferece sharding e escalabilidade horizontal de forma nativa. Documento as atribui\u00e7\u00f5es de slots, atribuo nomes aos n\u00f3s de forma consistente e automatizo as c\u00f3pias de seguran\u00e7a, para que as reinicializa\u00e7\u00f5es e <strong>Transfer\u00eancia em caso de falha<\/strong> continuem a ser reproduz\u00edveis.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis-cluster-sharding-load-balance-4456.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Gest\u00e3o de slots e reequil\u00edbrio na pr\u00e1tica<\/h2>\n<p>Durante o reequil\u00edbrio, transfiro os slots de hash em pequenos lotes entre os n\u00f3s, monitorizo as lat\u00eancias e verifico os contadores de erros durante o <strong>Migra\u00e7\u00e3o<\/strong>. Ao n\u00edvel da aplica\u00e7\u00e3o, garanto a idempot\u00eancia e a repetibilidade das opera\u00e7\u00f5es de grava\u00e7\u00e3o, para que os redirecionamentos tempor\u00e1rios n\u00e3o causem danos. Eventos de monitoriza\u00e7\u00e3o para mudan\u00e7as de slot e redirecionamentos (<code>MOVED<\/code>, <code>ASK<\/code>) ajudam a garantir que os clientes respondam corretamente. Dou prioridade aos slots com teclas de atalho, para resolver rapidamente os estrangulamentos mais graves. Ap\u00f3s a conclus\u00e3o, verifico a distribui\u00e7\u00e3o dos slots e as quotas de mem\u00f3ria por n\u00f3 e ajusto os limites para <strong>Tr\u00e1fego<\/strong>, ficheiros e liga\u00e7\u00f5es.<\/p>\n\n<h2>Planeamento: armazenamento, rede e n\u00f3s<\/h2>\n<p>Come\u00e7o o planeamento da capacidade com a RAM por n\u00f3, o n\u00famero previsto de chaves, o tamanho m\u00e9dio dos objetos e uma reserva para sobrecarga e r\u00e9plicas, para que os picos n\u00e3o provoquem evic\u00e7\u00f5es <strong>desembocar<\/strong>. No que diz respeito \u00e0 rede, tenho em conta a largura de banda, a lat\u00eancia entre as zonas de disponibilidade e as perdas de pacotes, uma vez que estas influenciam o comportamento da replica\u00e7\u00e3o e do failover. No que diz respeito \u00e0 CPU, calculo o conjunto de comandos, a utiliza\u00e7\u00e3o de Lua\/fun\u00e7\u00f5es e os processos em segundo plano, como as reescritas AOF. Para o crescimento, planeio a adi\u00e7\u00e3o gradual de n\u00f3s e o reequil\u00edbrio de slots durante as janelas de manuten\u00e7\u00e3o. A tabela seguinte re\u00fane os par\u00e2metros essenciais para a pr\u00e1tica di\u00e1ria e facilita <strong>Decis\u00f5es<\/strong>:<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Aspeto<\/th>\n      <th>valor de refer\u00eancia<\/th>\n      <th>Efeito<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Reserva de RAM por n\u00f3<\/td>\n      <td>20\u201330 % manter livre<\/td>\n      <td>Margem para reequil\u00edbrio, sobrecarga de objetos, fragmenta\u00e7\u00e3o<\/td>\n    <\/tr>\n    <tr>\n      <td>Fator de r\u00e9plica<\/td>\n      <td>1\u20132 r\u00e9plicas<\/td>\n      <td>Prote\u00e7\u00e3o contra falhas e desempenho de leitura adicional<\/td>\n    <\/tr>\n    <tr>\n      <td>Distribui\u00e7\u00e3o dos slots<\/td>\n      <td>de forma uniforme por cada Primary<\/td>\n      <td>Equilibra a carga e o armazenamento<\/td>\n    <\/tr>\n    <tr>\n      <td>N.\u00ba m\u00e1ximo de liga\u00e7\u00f5es<\/td>\n      <td>adaptado ao pooling<\/td>\n      <td>Evita picos de enfileiramento e de tempo limite<\/td>\n    <\/tr>\n    <tr>\n      <td>Pol\u00edtica de despejo<\/td>\n      <td>associar a uma carga de trabalho<\/td>\n      <td>Diminui\u00e7\u00e3o controlada da capacidade de armazenamento sob press\u00e3o<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/RedisClusterShardingOffice4567.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Casos de utiliza\u00e7\u00e3o no dia-a-dia da hospedagem<\/h2>\n<p>Utilizo frequentemente o Redis Cluster para <strong>Sess\u00f5es<\/strong> para que os in\u00edcios de sess\u00e3o possam ser escalados atrav\u00e9s de v\u00e1rios n\u00f3s e os sistemas individuais n\u00e3o fiquem bloqueados. O armazenamento em cache de objetos para PHP, Node.js ou Go beneficia de menores oscila\u00e7\u00f5es de lat\u00eancia, uma vez que as \u00abhot keys\u00bb n\u00e3o ficam vinculadas a um \u00fanico servidor. Distribuo as filas e os limites de taxa por shards espec\u00edficos, para separar claramente os acessos de escrita e de leitura. Quem estiver a ponderar quando \u00e9 que um cluster faz mais sentido do que um servidor \u00fanico, encontrar\u00e1 aqui uma introdu\u00e7\u00e3o pragm\u00e1tica: <a href=\"https:\/\/webhosting.de\/pt\/redis-em-cluster-vs-redis-autonomo-na-hospedagem-web-com-redis\/\">Aut\u00f3nomo vs. Cluster<\/a>. As instala\u00e7\u00f5es de grande dimens\u00e3o do WordPress, de lojas online e de SaaS mant\u00eam os tempos de carregamento das p\u00e1ginas constantes gra\u00e7as a esta arquitetura e aliviam a carga <strong>Backends<\/strong>.<\/p>\n\n<h2>Mensagens de erro e afina\u00e7\u00e3o<\/h2>\n<p>Reconhe\u00e7o as \u00abHot Keys\u00bb pela carga assim\u00e9trica nos slots, pelo aumento das lat\u00eancias e pelos picos de utiliza\u00e7\u00e3o da CPU; distribuo-as, utilizo hashtags de forma sensata e aplico uma abordagem diferenciada <strong>TTLs<\/strong>. Em caso de timeouts, verifico primeiro os caminhos de rede, os conjuntos de liga\u00e7\u00f5es e o pipelining, antes de aumentar os par\u00e2metros do servidor. Interpreto as evictions como um sinal de falta de reserva ou de objetos demasiado grandes, pelo que aumentei os buffers de mem\u00f3ria ou ajustei a serializa\u00e7\u00e3o e a compress\u00e3o. Para comandos com v\u00e1rias chaves, planeio as chaves de forma a que fiquem no mesmo slot, para que o cluster n\u00e3o reaja a erros entre slots. Sempre que faz sentido, utilizo o cache do lado do cliente para leituras frequentes, a fim de reduzir a carga <strong>baixar<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/redis_cluster_sharding_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Seguran\u00e7a e isolamento multi-tenant<\/h2>\n<p>Ativo a autentica\u00e7\u00e3o, protejo os comandos de administrador e isolo <strong>Redes<\/strong> De forma rigorosa, para que os projetos dos clientes funcionem de forma separada e segura. Configurei as chaves com prefixos de namespace por cliente, para controlar separadamente a visibilidade e as quotas por cliente. N\u00e3o limito o TLS aos pontos finais expostos, mas tamb\u00e9m o utilizo internamente entre n\u00f3s, quando a conformidade assim o exige. As auditorias, a pol\u00edtica de registo estruturada e os limites de taxa por cliente impedem abusos e custos excessivos. Para as c\u00f3pias de seguran\u00e7a e a recupera\u00e7\u00e3o, mantenho manuais de procedimentos dispon\u00edveis, testo regularmente a recupera\u00e7\u00e3o e documento <strong>RPO\/RTO<\/strong>.<\/p>\n\n<h2>Percurso de migra\u00e7\u00e3o: de um \u00fanico n\u00f3 para um cluster<\/h2>\n<p>Come\u00e7o por realizar medi\u00e7\u00f5es de carga e an\u00e1lises de chaves no servidor individual, a fim de obter resultados significativos <strong>Fragmentos<\/strong> deduzir. Em seguida, configuro um cluster de teste, ativo as hashtags, ajusto a configura\u00e7\u00e3o dos controladores e planeio, passo a passo, as janelas de reequil\u00edbrio. Para vias de dados paralelas, prevejo duplas grava\u00e7\u00f5es de curta dura\u00e7\u00e3o, at\u00e9 que a consist\u00eancia e as lat\u00eancias no cluster de destino estejam adequadas. Quem quiser abordar o tema de forma abrangente, pode aprofundar o assunto em <a href=\"https:\/\/webhosting.de\/pt\/banco-de-dados-fragmentacao-replicacao-hospedagem-web-infraestrutura-escalavel\/\">Sharding e replica\u00e7\u00e3o<\/a> no contexto do alojamento web. Concluo esta abordagem com monitoriza\u00e7\u00e3o, alertas, manuais de procedimentos e planeamento de capacidade para a <strong>Fase de crescimento<\/strong> de.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/serverraum-redis-8934.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Quando \u00e9 que os clusters s\u00e3o a escolha certa<\/h2>\n<p>Mudo para o Redis Cluster quando a carga de leitura e escrita sobrecarrega regularmente o servidor \u00fanico <strong>Limites<\/strong> ou quando os clientes exigem capacidades bem isoladas. Tamb\u00e9m os projetos em forte crescimento, com picos de tr\u00e1fego imprevis\u00edveis, beneficiam desta abordagem, uma vez que os slots e os n\u00f3s podem ser ampliados gradualmente. Quanto mais heterog\u00e9neas forem as cargas de trabalho, mais sensata se torna a separa\u00e7\u00e3o em shards dedicados para sess\u00f5es, caches, filas e taxas. Quem tem apenas pequenas quantidades de dados e uma carga constante, poder\u00e1, em determinadas circunst\u00e2ncias, optar mais facilmente pela configura\u00e7\u00e3o de um \u00fanico n\u00f3 e poupar em sobrecarga. Para cen\u00e1rios mistos, decido com base em chaves, or\u00e7amentos de lat\u00eancia, requisitos de failover e custos em <strong>Euro<\/strong>.<\/p>\n\n<h2>Consist\u00eancia, persist\u00eancia e recupera\u00e7\u00e3o no cluster<\/h2>\n<p>Eu defino a <strong>Consist\u00eancia<\/strong> e durabilidade por carga de trabalho: as sess\u00f5es e as caches costumam contentar-se com a consist\u00eancia eventual, enquanto as filas cr\u00edticas ou os armazenamentos de tokens exigem garantias mais rigorosas. Ao n\u00edvel do n\u00f3, opto entre instant\u00e2neos RDB e AOF. Com AOF e <code>appendfsync a cada segundo<\/code> Na pr\u00e1tica, consigo um bom equil\u00edbrio entre o d\u00e9bito e a janela de perda de dados (\u22481 segundo). Quem precisar de valores de RPO mais rigorosos deve calcular os custos de <code>sempre<\/code> de forma consciente. Eu ativo <code>rdb-save-incremental-fsync<\/code> e planeio as reescritas AOF de forma a que n\u00e3o coincidam com os picos de carga.<\/p>\n<p>Para escrever com seguran\u00e7a, eu uso <code>m\u00ednimo de r\u00e9plicas a escrever<\/code> e <code>min-replicas-max-lag<\/code> por Primary, para n\u00e3o permitir grava\u00e7\u00f5es n\u00e3o seguras em caso de problemas de rede. Considero que as r\u00e9plicas <strong>somente leitura<\/strong>, a menos que os clientes leiam deliberadamente a partir de r\u00e9plicas (READONLY). Considero os backups <em>local do n\u00f3<\/em>: Cada n\u00f3 prim\u00e1rio armazena apenas os seus slots; por isso, o manual de procedimentos de c\u00f3pia de seguran\u00e7a e restaura\u00e7\u00e3o abrange todos os n\u00f3s. Para <strong>DR<\/strong> Tenho previsto criar um segundo cluster (frio\/quente), replicar instant\u00e2neos\/AOF para fora do local e documentar os valores de RTO\/RPO de forma realista. N\u00e3o vou estender os clusters por regi\u00f5es com elevada lat\u00eancia \u2013 em vez disso, prefiro a comuta\u00e7\u00e3o ativa\/passiva entre clusters.<\/p>\n\n<h2>Par\u00e2metros do cluster que defino logo no in\u00edcio<\/h2>\n<p>Alguns par\u00e2metros determinam a estabilidade e o comportamento em caso de falha. Defino-os deliberadamente e documento-os:<\/p>\n<ul>\n  <li><code>tempo-de-espera-do-n\u00f3-do-cluster<\/code>: controla quando os n\u00f3s s\u00e3o considerados inativos e quando se inicia a transi\u00e7\u00e3o de falha; escolho valores que se adequem \u00e0s lat\u00eancias da rede e \u00e0 carga de trabalho.<\/li>\n  <li><code>fator-de-validade-da-r\u00e9plica-do-cluster<\/code>: impede que r\u00e9plicas desatualizadas sejam aplicadas; fa\u00e7o um ajuste conservador para garantir resultados limpos <strong>Transfer\u00eancia em caso de falha<\/strong>.<\/li>\n  <li><code>barreira-\u00e0-migra\u00e7\u00e3o-de-clusters<\/code>: define quando as r\u00e9plicas migram para outro prim\u00e1rio; evito oscila\u00e7\u00f5es em configura\u00e7\u00f5es com recursos limitados.<\/li>\n  <li><code>cluster-require-full-coverage<\/code>: se faltarem slots, bloqueio deliberadamente as grava\u00e7\u00f5es, em vez de arriscar situa\u00e7\u00f5es de inconsist\u00eancia.<\/li>\n  <li><code>tamanho-da-filha-de-respostas<\/code>: dimensionar com capacidade suficiente para que as perturba\u00e7\u00f5es de curta dura\u00e7\u00e3o na rede n\u00e3o obriguem a uma sincroniza\u00e7\u00e3o total.<\/li>\n  <li><code>limite do buffer de sa\u00edda do cliente<\/code> para pubsub\/normal: protege contra valores at\u00edpicos e estabiliza a mem\u00f3ria.<\/li>\n  <li><code>active-defrag sim<\/code>: reduz a fragmenta\u00e7\u00e3o sob cargas que exigem muito espa\u00e7o de mem\u00f3ria.<\/li>\n<\/ul>\n\n<h2>Comportamento do cliente, redirecionamentos e encaminhamento<\/h2>\n<p>Confio em <strong>Compat\u00edvel com cluster<\/strong> Clientes que <code>MOVED<\/code> e <code>ASK<\/code> compreender automaticamente. Durante o reequil\u00edbrio, aceito fases curtas com <code>ASK<\/code>-Redirecionamentos; por isso, os meus clientes suportam <code>PERGUNTAR<\/code> e repito as solicita\u00e7\u00f5es de forma idempotente. Utilizo o pipelining com modera\u00e7\u00e3o: agrupo os lotes por slot, sem correr o risco de lat\u00eancia devido a pipelines excessivamente grandes. Aplico tempo de espera e novas tentativas com recuo exponencial e jitter, para que os picos n\u00e3o sejam amplificados pela recupera\u00e7\u00e3o s\u00edncrona. Para percursos com grande carga de leitura, ativo <code>READONLY<\/code>, para que as r\u00e9plicas possam responder com seguran\u00e7a; os caminhos de grava\u00e7\u00e3o permanecem estritamente <strong>READWRITE<\/strong>.<\/p>\n<p>Estou a planear os conjuntos de liga\u00e7\u00f5es <em>por n\u00f3 de destino<\/em>, e n\u00e3o apenas a n\u00edvel global. Um pool que concentra todas as liga\u00e7\u00f5es em poucos n\u00f3s gera pontos de congest\u00e3o. Medei a lat\u00eancia, a carga e as taxas de erro por n\u00f3 e calibro regularmente os tamanhos dos pools.<\/p>\n\n<h2>Limites e padr\u00f5es no conjunto de comandos<\/h2>\n<p>As opera\u00e7\u00f5es com v\u00e1rias chaves s\u00f3 funcionam se todas as chaves estiverem na mesma ranhura. Vou destacar isto com hashtags (<code>{\u2026}<\/code>) e utilizo um ID de slot \u00fanico por grupo de objetos. <strong>Transac\u00e7\u00f5es<\/strong> (<code>MULTI\/EXEC<\/code>) e <strong>Lua<\/strong>\/<code>FUN\u00c7\u00c3O<\/code>-Limito as chamadas \u00e0s chaves de um slot; caso contr\u00e1rio, pretendo adotar uma abordagem em duas etapas (primeiro recolher, depois alternar por slot). <strong>SCAN<\/strong> e <code>CHAVES<\/code> N\u00e3o o utilizo a n\u00edvel do cluster, mas sim por n\u00f3 e com amostragem, para n\u00e3o perturbar o funcionamento. Para o Pub\/Sub, nas cargas de trabalho do cluster, recorro a <strong>Pub\/Sub fragmentado<\/strong>, para que as mensagens sejam dimensionadas localmente por slot. Implemento os limites de taxa de forma est\u00e1vel por slot, utilizando um hash-tag com base no ID do utilizador ou do inquilino, para que as opera\u00e7\u00f5es INCR\/EXPIRE n\u00e3o se fragmentem.<\/p>\n\n<h2>Manuten\u00e7\u00e3o cont\u00ednua e atualiza\u00e7\u00f5es sem tempo de inatividade<\/h2>\n<p>Para as atualiza\u00e7\u00f5es, vou alternando os n\u00f3s um a um: atualizar a r\u00e9plica, verificar o estado de sincroniza\u00e7\u00e3o, atualiza\u00e7\u00e3o seletiva <strong>Transfer\u00eancia em caso de falha<\/strong> para a nova r\u00e9plica, atualizar o antigo prim\u00e1rio e voltar a lig\u00e1-lo como r\u00e9plica. Desta forma, a capacidade \u00e9 mantida e consigo cumprir os SLOs. Antes de atualiza\u00e7\u00f5es de vers\u00e3o, testo o conjunto de comandos, a compatibilidade com AOF\/RDB e os m\u00f3dulos (caso estejam em uso) no ambiente de teste. Para a substitui\u00e7\u00e3o de n\u00f3s, utilizo o slot-<strong>Resharding<\/strong> em pequenos lotes; os TTLs e os metadados das chaves s\u00e3o mantidos durante o MIGRATE, mas, mesmo assim, estou a monitorizar as lat\u00eancias e os tamanhos dos conjuntos.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o, m\u00e9tricas e alertas<\/h2>\n<p>Defino os SLIs como a lat\u00eancia P99, a taxa de erros, a cobertura de slots e o atraso de replica\u00e7\u00e3o. De <code>INFORMA\u00c7\u00c3O<\/code> eu puxo <strong>acertos\/erros no espa\u00e7o de chaves<\/strong>, <strong>opera\u00e7\u00f5es instant\u00e2neas por segundo<\/strong>, <strong>clientes_conectados<\/strong>, <strong>mem\u00f3ria utilizada \/ RSS<\/strong> e <strong>r\u00e1cio_de_fragmenta\u00e7\u00e3o_de_mem\u00f3ria<\/strong>. O <strong>Slowlog<\/strong> ajuda a identificar valores at\u00edpicos; <code>LATENCY DOCTOR<\/code> deteta picos no sistema (disco, CPU). Emite um alarme quando:<\/p>\n<ul>\n  <li>Se a lat\u00eancia P95\/P99 aumentar ou a percentagem de timeouts ultrapassar os limiares,<\/li>\n  <li>o atraso na replica\u00e7\u00e3o continua a ser elevado,<\/li>\n  <li>Utiliza\u00e7\u00e3o da mem\u00f3ria por n\u00f3 &gt;80 % e fragmenta\u00e7\u00e3o RSS &gt;1,5,<\/li>\n  <li>frequentes <code>MOVED<\/code>\/<code>ASK<\/code>-ocorrerem eventos (reequil\u00edbrio inesperado),<\/li>\n  <li>Os despejos est\u00e3o a aumentar ou <code>clientes bloqueados<\/code> cresce.<\/li>\n<\/ul>\n<p>No que diz respeito \u00e0 capacidade, defino os seguintes gatilhos: a partir de X % de RAM e Y % de CPU durante Z minutos, inicio um plano de reequil\u00edbrio ou de expans\u00e3o horizontal. Organizo os pain\u00e9is de controlo por slots e n\u00f3s, para que os pontos de congest\u00e3o <strong>precoce<\/strong> tornam-se vis\u00edveis.<\/p>\n\n<h2>Efici\u00eancia de armazenamento e modelo de dados<\/h2>\n<p>Otimizo os objetos antes de adicionar n\u00f3s: serializa\u00e7\u00e3o mais pequena (JSONs compactos, formatos bin\u00e1rios), significativa <strong>TTLs<\/strong> e evitar valores excessivamente grandes poupa RAM. Para muitas chaves pequenas, utilizo tipos estruturados (por exemplo, hashes) de forma eficiente, mas tenho em aten\u00e7\u00e3o a sobrecarga por objeto. <strong>Desfragmenta\u00e7\u00e3o Ativa<\/strong> e orientada para as necessidades <code>pol\u00edtica de mem\u00f3ria m\u00e1xima<\/code> (por exemplo. <code>allkeys-lru<\/code> ou <code>vol\u00e1til-ttl<\/code>) mant\u00eam as lat\u00eancias est\u00e1veis quando a mem\u00f3ria escasseia. Medei a dispers\u00e3o do tamanho dos objetos e tenho em conta a fragmenta\u00e7\u00e3o \u2013 assim, consigo tomar melhores decis\u00f5es em termos de hardware.<\/p>\n\n<h2>Topologia da rede e localiza\u00e7\u00e3o das zonas<\/h2>\n<p>Distribuo os \u00abprimaries\u00bb e os \u00abreplicates\u00bb por diferentes <strong>Zonas de disponibilidade<\/strong> e mantenho a lat\u00eancia e as perdas de pacotes sob controlo. A interliga\u00e7\u00e3o de clusters (Gossip\/Bus) requer lat\u00eancias est\u00e1veis; evito percursos L2 de longo alcance. Para os nomes DNS dos n\u00f3s, defino nomes fixos e utilizo o IP-pinning durante as janelas de manuten\u00e7\u00e3o, para que os clientes n\u00e3o tenham surpresas. <strong>MTU<\/strong>, Verifico as defini\u00e7\u00f5es do ECN e da fila em condi\u00e7\u00f5es de carga, porque pequenas taxas de perda de pacotes, quando o QPS \u00e9 elevado, conduzem rapidamente a tempos de espera percet\u00edveis.<\/p>\n\n<h2>Manuais operacionais e manuais de procedimentos<\/h2>\n<p>Tenho \u00e0 disposi\u00e7\u00e3o manuais de procedimentos concisos e testados: inicializa\u00e7\u00e3o de clusters, adi\u00e7\u00e3o\/remo\u00e7\u00e3o de n\u00f3s, redistribui\u00e7\u00e3o seletiva, c\u00f3pia de seguran\u00e7a\/restaura\u00e7\u00e3o, exerc\u00edcios de failover e implementa\u00e7\u00e3o de atualiza\u00e7\u00f5es. Cada guia de procedimentos inclui pr\u00e9-requisitos (qu\u00f3rum, mem\u00f3ria livre), a\u00e7\u00f5es passo a passo e <strong>Revers\u00e3o<\/strong>-Caminhos. Documento a nomenclatura, a atribui\u00e7\u00e3o de slots, a cadeia de r\u00e9plicas e as ACLs de acesso \u2013 assim, o funcionamento mant\u00e9m-se est\u00e1vel mesmo em caso de mudan\u00e7as na equipa.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n<p>O Redis Cluster distribui os dados por meio de slots de hash, escala horizontalmente atrav\u00e9s de v\u00e1rios n\u00f3s e, com r\u00e9plicas, proporciona uma disponibilidade previs\u00edvel <strong>Desempenho<\/strong>. As plataformas de alojamento beneficiam porque as sess\u00f5es, as caches, as filas e os limites de taxa crescem separadamente, o que faz com que os pontos de congest\u00e3o surjam com menos frequ\u00eancia. Consigo bons resultados com um design de chaves claro, conjuntos de liga\u00e7\u00f5es controlados, buffers de mem\u00f3ria e um reequil\u00edbrio bem organizado. A monitoriza\u00e7\u00e3o, os alertas e os manuais de procedimentos documentados reduzem sensivelmente o risco durante a migra\u00e7\u00e3o, a expans\u00e3o e o failover. Quem planeia de forma consciente obt\u00e9m tempos de resposta constantes, maior capacidade de reserva para picos de tr\u00e1fego e uma configura\u00e7\u00e3o que acompanha o tr\u00e1fego <strong>cresce consigo<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>O sharding do Redis Cluster melhora a distribui\u00e7\u00e3o de carga, a escalabilidade e a disponibilidade para grandes plataformas de alojamento. Uma explica\u00e7\u00e3o sucinta.<\/p>","protected":false},"author":1,"featured_media":20501,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-20508","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"134","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Redis Cluster","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20501","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20508","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=20508"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20508\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20501"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20508"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20508"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20508"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}