{"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-fragmentacion-alojamiento-distribucion-de-carga","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/redis-cluster-sharding-hosting-lastverteilung\/","title":{"rendered":"Sharding en Redis Cluster: distribuci\u00f3n de la carga para grandes plataformas de alojamiento web"},"content":{"rendered":"<p>Redis Cluster distribuye las claves en 16 384 ranuras de hash, con lo que consigue <strong>Fragmentaci\u00f3n<\/strong> con una distribuci\u00f3n de carga planificable para grandes plataformas de alojamiento web. Mostrar\u00e9 concretamente c\u00f3mo los servicios de alojamiento distribuyen sesiones, cach\u00e9s, colas y l\u00edmites de tasa entre varios nodos y, de este modo, <strong>Cuellos de botella<\/strong> Evitarlo en la RAM, la CPU y la red.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<p>En este apartado se resumen las ideas m\u00e1s importantes sobre <strong>Redis<\/strong> Re\u00fane los conceptos de cluster y sharding para el alojamiento web y los clasifica de forma pr\u00e1ctica. Mantengo la lista concisa para que las decisiones sobre arquitectura, funcionamiento y crecimiento se tomen m\u00e1s r\u00e1pidamente. Estos puntos sirven de gu\u00eda para la planificaci\u00f3n, la implementaci\u00f3n y el ajuste en entornos de producci\u00f3n <strong>Alrededores<\/strong>.<\/p>\n<ul>\n  <li><strong>Ranuras de hash<\/strong>: 16 384 ranuras distribuyen las claves de forma autom\u00e1tica y determinista.<\/li>\n  <li><strong>Escala<\/strong>: Un mayor n\u00famero de nodos aumenta la capacidad mediante la redistribuci\u00f3n de las ranuras.<\/li>\n  <li><strong>Alta disponibilidad<\/strong>: Las r\u00e9plicas garantizan la conmutaci\u00f3n por error y mejoran el rendimiento de lectura.<\/li>\n  <li><strong>Cargas de trabajo<\/strong>: Las sesiones, las cach\u00e9s, las colas y los l\u00edmites de frecuencia mejoran de forma apreciable.<\/li>\n  <li><strong>Dise\u00f1o de teclas<\/strong>: Los hashtags reducen los accesos entre ranuras en el d\u00eda a d\u00eda.<\/li>\n<\/ul>\n<p>Recomiendo que estos puntos clave se utilicen como elementos recurrentes <strong>Lista de control<\/strong> utilizarlas y revisarlas cuidadosamente cuando se produzcan cambios en el perfil de carga, la estructura de datos o la automatizaci\u00f3n de la implementaci\u00f3n.<\/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>C\u00f3mo funciona el sharding en Redis Cluster<\/h2>\n<p>Un cl\u00faster de Redis divide todo el espacio de claves en exactamente 16 384 <strong>Ranuras de hash<\/strong> . La asignaci\u00f3n de ranuras se realiza de forma determinista mediante CRC16, m\u00e1s concretamente mediante <code>CRC16(clave) % 16384<\/code>, lo que hace que cada clave se asigne de forma repetible a la misma ranura. Este c\u00e1lculo permite la distribuci\u00f3n autom\u00e1tica sin que las aplicaciones tengan que gestionar su propia l\u00f3gica de partici\u00f3n, lo que facilita claramente la implementaci\u00f3n y el mantenimiento <strong>Simplificado<\/strong>. Si muevo ranuras entre nodos, la parte de datos correspondiente tambi\u00e9n se desplaza, de modo que el escalado horizontal se lleva a cabo de forma gradual. Para las operaciones con varias claves, tengo previsto utilizar etiquetas hash como <code>usuario:{42}:sesi\u00f3n<\/code>, para que las claves relacionadas se asignen a la misma ranura y las solicitudes no traspasen los l\u00edmites del cl\u00faster <strong>superar<\/strong>.<\/p>\n\n<h2>Importancia para las grandes plataformas de alojamiento web<\/h2>\n<p>Las grandes infraestructuras de alojamiento agrupan muchas cargas de trabajo independientes y generan numerosas <strong>Consejos<\/strong> en las capas de cach\u00e9 y de sesi\u00f3n. La escalabilidad de un \u00fanico servidor es limitada, ya que la memoria, la red y la CPU se convierten r\u00e1pidamente en factores limitantes. Con el sharding en cl\u00faster, distribuyo los puntos de mayor carga entre varios servidores primarios y, de este modo, consigo procesar m\u00e1s solicitudes en paralelo por segundo. Los accesos con gran volumen de lectura se benefician de las r\u00e9plicas, mientras que la carga de escritura se distribuye entre varios nodos <strong>divide<\/strong>. De este modo, mantengo unos tiempos de respuesta m\u00e1s constantes y mitigo el impacto de los picos de tr\u00e1fico puntuales en toda la pila.<\/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>Escalabilidad y alta disponibilidad en combinaci\u00f3n<\/h2>\n<p>Combino el escalado horizontal con la alta disponibilidad haciendo que cada partici\u00f3n tenga un servidor principal y al menos un <strong>R\u00e9plica<\/strong> recibe. Si un servidor primario falla, la r\u00e9plica toma el relevo, lo que garantiza que los datos sigan estando accesibles y que las solicitudes de lectura contin\u00faen fluyendo. A medida que aumenta la carga, a\u00f1ado nodos adicionales y redistribuyo las ranuras, lo que incrementa paso a paso la capacidad y el rendimiento. Para aplicaciones con gran volumen de lecturas, dirijo a los consumidores de forma selectiva a las r\u00e9plicas, mientras que las rutas de escritura utilizan los nodos primarios. Esta clara separaci\u00f3n de funciones garantiza una previsibilidad en cargas de trabajo mixtas <strong>Tiempos de respuesta<\/strong> y reduce los puntos conflictivos.<\/p>\n\n<h2>Buenas pr\u00e1cticas para el funcionamiento y la arquitectura<\/h2>\n<p>Establezco desde el principio las reglas para los nombres de las claves, utilizo hashtags de forma sistem\u00e1tica y separo de forma l\u00f3gica las sesiones, las cach\u00e9s, las colas y los l\u00edmites de frecuencia mediante nombres y TTL, para que el cl\u00faster <strong>equilibrado<\/strong> . Mantengo los grupos de conexiones a un tama\u00f1o reducido y controlado, y mido cuidadosamente la latencia, el tiempo de espera, los reintentos y el comportamiento de la canalizaci\u00f3n. Para los cambios en el tama\u00f1o del cl\u00faster, preveo b\u00faferes de memoria para que las redistribuciones de ranuras se realicen sin que se produzca escasez de memoria. Quien quiera comparar conceptos de alta disponibilidad, puede consultar adem\u00e1s <a href=\"https:\/\/webhosting.de\/es\/redis-sentinel-alta-disponibilidad-configuracion-del-servidor-redis-estabilidad\/\">Redis Sentinel<\/a> , pero entiendo que un cl\u00faster ofrece de forma nativa el sharding y la escalabilidad horizontal. Documento las asignaciones de ranuras, nombro los nodos de forma coherente y automatizo las copias de seguridad para que las recuperaciones y <strong>Conmutaci\u00f3n por error<\/strong> sigan siendo reproducibles.<\/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>Gesti\u00f3n de ranuras y reequilibrio en la pr\u00e1ctica<\/h2>\n<p>Durante el reequilibrio, transfiero los hash-slots en peque\u00f1os lotes entre nodos, superviso las latencias y compruebo los contadores de errores durante el <strong>Migraci\u00f3n<\/strong>. A nivel de aplicaci\u00f3n, me encargo de garantizar la idempotencia y la repetibilidad de las operaciones de escritura, para que las redirecciones temporales no causen da\u00f1os. Eventos de monitorizaci\u00f3n para cambios de ranura y redirecciones (<code>MOVED<\/code>, <code>ASK<\/code>) ayudan a que los clientes respondan correctamente. Doy prioridad a los slots con teclas r\u00e1pidas para aliviar r\u00e1pidamente los cuellos de botella m\u00e1s graves. Una vez finalizado el proceso, compruebo la distribuci\u00f3n de los slots y las cuotas de memoria por nodo, y ajusto los l\u00edmites para <strong>Tr\u00e1fico<\/strong>, archivos y conexiones.<\/p>\n\n<h2>Planificaci\u00f3n: almacenamiento, red y nodos<\/h2>\n<p>Para planificar la capacidad, empiezo por la RAM por nodo, el n\u00famero previsto de claves, el tama\u00f1o medio de los objetos y una reserva para la sobrecarga y las r\u00e9plicas, de modo que los picos no provoquen desalojos. <strong>desembocar<\/strong>. En cuanto a la red, tengo en cuenta el ancho de banda, la latencia entre las zonas de disponibilidad y la p\u00e9rdida de paquetes, ya que influyen en el comportamiento de la replicaci\u00f3n y la conmutaci\u00f3n por error. En cuanto a la CPU, calculo la combinaci\u00f3n de comandos, el uso de Lua\/funciones y los procesos en segundo plano, como las reescrituras AOF. Para el crecimiento, planifico la incorporaci\u00f3n gradual de nodos y el reequilibrio de ranuras durante las ventanas de mantenimiento. La siguiente tabla resume los par\u00e1metros clave para la pr\u00e1ctica diaria y facilita <strong>Decisiones<\/strong>:<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Aspecto<\/th>\n      <th>valor indicativo<\/th>\n      <th>Efecto<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Reserva de RAM por nodo<\/td>\n      <td>20-30: mantener libre %<\/td>\n      <td>Margen para el reequilibrio, sobrecarga de objetos, fragmentaci\u00f3n<\/td>\n    <\/tr>\n    <tr>\n      <td>Factor de r\u00e9plica<\/td>\n      <td>1-2 r\u00e9plicas<\/td>\n      <td>Protecci\u00f3n contra fallos y mayor rendimiento de lectura<\/td>\n    <\/tr>\n    <tr>\n      <td>Distribuci\u00f3n de ranuras<\/td>\n      <td>de manera uniforme por cada Primary<\/td>\n      <td>Equilibra la carga y el almacenamiento<\/td>\n    <\/tr>\n    <tr>\n      <td>N\u00famero m\u00e1ximo de conexiones<\/td>\n      <td>adaptado al sistema de agrupaci\u00f3n<\/td>\n      <td>Evita los picos de colas y de tiempo de espera<\/td>\n    <\/tr>\n    <tr>\n      <td>Pol\u00edtica de desalojo<\/td>\n      <td>asignar a una carga de trabajo<\/td>\n      <td>Reducci\u00f3n controlada de la capacidad de almacenamiento bajo presi\u00f3n<\/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 uso en el d\u00eda a d\u00eda del alojamiento web<\/h2>\n<p>Utilizo Redis Cluster con frecuencia para <strong>Sesiones<\/strong> para que los inicios de sesi\u00f3n se puedan escalar a trav\u00e9s de m\u00faltiples nodos y los sistemas individuales no se bloqueen. El almacenamiento en cach\u00e9 de objetos para PHP, Node.js o Go se beneficia de menores fluctuaciones de latencia, ya que las claves activas no permanecen vinculadas a un \u00fanico servidor. Distribuyo las colas y los l\u00edmites de tasa en fragmentos espec\u00edficos para separar claramente los accesos de escritura y de lectura. Quien se plantee cu\u00e1ndo tiene m\u00e1s sentido utilizar un cl\u00faster en lugar de un servidor \u00fanico, encontrar\u00e1 aqu\u00ed una introducci\u00f3n pr\u00e1ctica: <a href=\"https:\/\/webhosting.de\/es\/redis-en-cluster-frente-a-redis-independiente-en-el-alojamiento-web-con-redis\/\">Sistema independiente frente a cl\u00faster<\/a>. Las instalaciones especialmente grandes de WordPress, tiendas online y SaaS mantienen constantes los tiempos de carga de las p\u00e1ginas gracias a esta arquitectura y alivian la carga <strong>Backends<\/strong>.<\/p>\n\n<h2>S\u00edntomas de aver\u00eda y puesta a punto<\/h2>\n<p>Reconozco las \u00abteclas r\u00e1pidas\u00bb por una carga asim\u00e9trica en las ranuras, un aumento de las latencias y picos de uso de la CPU; las distribuyo, utilizo los hashtags de forma adecuada y aplico medidas diferenciadas <strong>TTLs<\/strong>. En caso de tiempos de espera, compruebo primero las rutas de red, los grupos de conexiones y el pipelining antes de aumentar los par\u00e1metros del servidor. Interpreto las expulsiones como un indicio de falta de reserva o de objetos demasiado grandes, tras lo cual aumento los b\u00faferes de memoria o ajusto la serializaci\u00f3n y la compresi\u00f3n. Para las \u00f3rdenes con varias claves, planifico las claves de modo que se encuentren en la misma ranura, para que el cl\u00faster no reaccione ante errores entre ranuras. Cuando resulta conveniente, utilizo el almacenamiento en cach\u00e9 del lado del cliente para las lecturas frecuentes, con el fin de reducir la carga <strong>bajar<\/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>Seguridad y aislamiento multitenant<\/h2>\n<p>Activo la autenticaci\u00f3n, protejo los comandos de administrador y a\u00edslo <strong>Redes<\/strong> De forma estricta, para que los proyectos de los clientes se ejecuten de forma independiente y segura. Configuro las claves con prefijos de espacio de nombres para cada cliente, con el fin de controlar por separado la visibilidad y las cuotas de cada uno. No limito el uso de TLS a los puntos finales expuestos, sino que tambi\u00e9n lo utilizo internamente entre nodos cuando as\u00ed lo exige el cumplimiento normativo. Las auditor\u00edas, la pol\u00edtica de registro estructurada y los l\u00edmites de tasa por cliente evitan el uso indebido y los costes excesivos. Para las copias de seguridad y las restauraciones, dispongo de gu\u00edas de procedimientos, pruebo la restauraci\u00f3n peri\u00f3dicamente y documento <strong>OPR\/OTR<\/strong>.<\/p>\n\n<h2>Ruta de migraci\u00f3n: de un nodo \u00fanico a un cl\u00faster<\/h2>\n<p>Empiezo realizando mediciones de carga y an\u00e1lisis clave en el servidor individual para obtener datos \u00fatiles <strong>Fragmentos<\/strong> deducir. A continuaci\u00f3n, configuro un cl\u00faster de prueba, activo los hashtags, ajusto la configuraci\u00f3n de los controladores y planifico paso a paso las ventanas de reequilibrio. Para las rutas de datos paralelas, preveo escrituras dobles de corta duraci\u00f3n hasta que la consistencia y las latencias en el cl\u00faster de destino sean las adecuadas. Quien desee abordar el tema de forma integral, puede leer m\u00e1s en profundidad sobre <a href=\"https:\/\/webhosting.de\/es\/base-de-datos-fragmentacion-replicacion-alojamiento-web-infraestructura-escalable\/\">Fragmentaci\u00f3n y replicaci\u00f3n<\/a> en el contexto del alojamiento web. Concluyo este repaso con la supervisi\u00f3n, las alertas, los guiones de actuaci\u00f3n y la planificaci\u00f3n de la capacidad para la <strong>Fase de crecimiento<\/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>Cu\u00e1ndo es recomendable optar por los cl\u00fasteres<\/h2>\n<p>Activo Redis Cluster cuando la carga de lectura y escritura satura regularmente el servidor \u00fanico <strong>L\u00edmites<\/strong> o cuando los clientes exigen capacidades claramente aisladas. Tambi\u00e9n se benefician los proyectos en fuerte crecimiento con picos de tr\u00e1fico poco definidos, ya que los slots y los nodos se pueden ampliar por etapas. Cuanto m\u00e1s heterog\u00e9neas sean las cargas de trabajo, m\u00e1s sentido tiene la separaci\u00f3n en fragmentos dedicados para sesiones, cach\u00e9s, colas y tasas. Quien solo tenga peque\u00f1os vol\u00famenes de datos y una carga constante, en determinadas circunstancias le resultar\u00e1 m\u00e1s sencillo quedarse con la configuraci\u00f3n de un \u00fanico nodo y ahorrarse la sobrecarga. Para escenarios mixtos, tomo la decisi\u00f3n bas\u00e1ndome en claves, presupuestos de latencia, requisitos de conmutaci\u00f3n por error y costes en <strong>Euro<\/strong>.<\/p>\n\n<h2>Consistencia, persistencia y recuperaci\u00f3n en el cl\u00faster<\/h2>\n<p>Yo elijo la opci\u00f3n deseada <strong>Coherencia<\/strong> y la durabilidad por carga de trabajo: las sesiones y las cach\u00e9s suelen bastarse con una consistencia eventual, mientras que las colas cr\u00edticas o los almacenes de tokens exigen garant\u00edas m\u00e1s estrictas. A nivel de nodo, elijo entre instant\u00e1neas de bases de datos relacionales (RDB) y AOF. Con AOF y <code>appendfsync cada segundo<\/code> En la pr\u00e1ctica, consigo un buen equilibrio entre el rendimiento y la ventana de p\u00e9rdida de datos (\u22481 segundo). Quien necesite valores de RPO m\u00e1s estrictos, debe calcular los costes de <code>siempre<\/code> de forma consciente. Activo <code>rdb-save-incremental-fsync<\/code> y planifico las reescrituras de AOF de manera que no coincidan con los picos de carga.<\/p>\n<p>Para escribir con seguridad, yo apuesto por <code>m\u00ednimo de r\u00e9plicas para escribir<\/code> y <code>min-replicas-max-lag<\/code> por Primary, para evitar que se guarden cambios sin confirmar en caso de problemas de red. En cuanto a las r\u00e9plicas, considero que <strong>solo lectura<\/strong>, a menos que los clientes lean deliberadamente desde r\u00e9plicas (READONLY). En cuanto a las copias de seguridad, considero que <em>local del nodo<\/em>: Cada nodo primario almacena de forma permanente \u00fanicamente sus ranuras; por lo tanto, el playbook de copia de seguridad y restauraci\u00f3n abarca todos los nodos. Para <strong>DR<\/strong> Tengo previsto crear un segundo cl\u00faster (fr\u00edo\/caliente), replicar instant\u00e1neas y archivos AOF fuera del sitio y documentar los valores de RTO y RPO de forma realista. No voy a extender los cl\u00fasteres a trav\u00e9s de regiones con alta latencia; en su lugar, prefiero la conmutaci\u00f3n activa\/pasiva entre cl\u00fasteres.<\/p>\n\n<h2>Par\u00e1metros del cl\u00faster que defino desde el principio<\/h2>\n<p>Unos cuantos par\u00e1metros determinan la estabilidad y el comportamiento en caso de fallo. Los configuro deliberadamente y los documento:<\/p>\n<ul>\n  <li><code>tiempo de espera del nodo del cl\u00faster<\/code>: controla cu\u00e1ndo se consideran inactivos los nodos y cu\u00e1ndo se inicia la conmutaci\u00f3n por error; elijo valores que se adapten a las latencias de la red y a la carga de trabajo.<\/li>\n  <li><code>factor de validez de la r\u00e9plica del cl\u00faster<\/code>: evita que se apliquen r\u00e9plicas obsoletas; realizo un ajuste conservador para garantizar una <strong>Conmutaci\u00f3n por error<\/strong>.<\/li>\n  <li><code>barrera-de-migraci\u00f3n-de-cl\u00fasteres<\/code>: define cu\u00e1ndo se migran las r\u00e9plicas a otro primario; evito la oscilaci\u00f3n en configuraciones con recursos limitados.<\/li>\n  <li><code>cluster-require-full-coverage<\/code>: si faltan ranuras, bloqueo deliberadamente las operaciones de escritura, en lugar de arriesgarme a que se produzcan estados incoherentes.<\/li>\n  <li><code>tama\u00f1o-de-la-cola-de-respuestas<\/code>: dimensionarlo lo suficientemente grande como para que las perturbaciones de la red a corto plazo no obliguen a una sincronizaci\u00f3n completa.<\/li>\n  <li><code>l\u00edmite del b\u00fafer de salida del cliente<\/code> Para pubsub\/normal: protege contra valores at\u00edpicos y estabiliza la memoria.<\/li>\n  <li><code>active-defrag s\u00ed<\/code>: reduce la fragmentaci\u00f3n bajo cargas que consumen mucha memoria.<\/li>\n<\/ul>\n\n<h2>Comportamiento del cliente, redireccionamientos y enrutamiento<\/h2>\n<p>Conf\u00edo en <strong>Compatible con cl\u00fasteres<\/strong> Los clientes que <code>MOVED<\/code> y <code>ASK<\/code> entenderlo autom\u00e1ticamente. Durante el reequilibrio, acepto breves fases con <code>ASK<\/code>-Redireccionamientos; por eso, mis clientes admiten <code>PREGUNTAR<\/code> y repito las solicitudes de forma idempotente. Utilizo el pipelining con moderaci\u00f3n: agrupo los lotes por slot sin arriesgarme a que se produzca latencia debido a pipelines demasiado grandes. Aplico un retroceso exponencial y fluctuaci\u00f3n a los tiempos de espera y los reintentos, para que los picos no se vean agravados por la recuperaci\u00f3n sincr\u00f3nica. Para las rutas con gran carga de lectura, activo <code>READONLY<\/code>, para que las r\u00e9plicas puedan responder de forma segura; las rutas de escritura siguen siendo estrictamente <strong>READWRITE<\/strong>.<\/p>\n<p>Tengo previsto crear grupos de conexiones <em>por nodo de destino<\/em>, no solo a nivel global. Un grupo que concentra todas las conexiones en unos pocos nodos genera puntos de congesti\u00f3n. Mido la latencia, la carga y las tasas de error por nodo, y calibro peri\u00f3dicamente el tama\u00f1o de los grupos.<\/p>\n\n<h2>L\u00edmites y patrones en el conjunto de comandos<\/h2>\n<p>Las operaciones con varias claves solo funcionan si todas las claves se encuentran en la misma ranura. Lo resumo con hashtags (<code>{\u2026}<\/code>) y utilizo un identificador de ranura \u00fanico por grupo de objetos. <strong>Transacciones<\/strong> (<code>MULTI\/EXEC<\/code>) y <strong>Lua<\/strong>\/<code>FUNCI\u00d3N<\/code>-Limito las llamadas a las claves de una ranura; en caso contrario, tengo previsto aplicar un enfoque en dos fases (primero recopilar, luego conmutar por ranura). <strong>SCAN<\/strong> y <code>CLAVES<\/code> No lo utilizo en todo el cl\u00faster, sino por nodo y con muestreo, para no interferir en el funcionamiento. Para Pub\/Sub, en las cargas de trabajo del cl\u00faster utilizo <strong>Pub\/Sub fragmentado<\/strong>, para que los mensajes se escalen de forma local por slot. Implemento los l\u00edmites de tasa de forma estable por slot mediante un hash-tag basado en el ID de usuario o de tenant, para que las operaciones INCR\/EXPIRE no se dividan.<\/p>\n\n<h2>Mantenimiento y actualizaciones continuas sin tiempo de inactividad<\/h2>\n<p>Para las actualizaciones, voy rotando los nodos uno tras otro: actualizar la r\u00e9plica, comprobar el estado de sincronizaci\u00f3n, actualizaci\u00f3n selectiva <strong>Conmutaci\u00f3n por error<\/strong> a la nueva r\u00e9plica, actualizar el antiguo primario y volver a conectarlo como r\u00e9plica. De esta forma se mantiene la capacidad y cumplo con los SLO. Antes de los saltos de versi\u00f3n, pruebo el conjunto de comandos, la compatibilidad con AOF\/RDB y los m\u00f3dulos (si se utilizan) en el entorno de prueba. Para la sustituci\u00f3n de nodos utilizo la t\u00e9cnica de ranuras<strong>Resharding<\/strong> en peque\u00f1os lotes; los TTL y los metadatos de las claves se conservan durante la migraci\u00f3n, pero, aun as\u00ed, superviso las latencias y el tama\u00f1o de los lotes.<\/p>\n\n<h2>Supervisi\u00f3n, m\u00e9tricas y alertas<\/h2>\n<p>Defino los SLI como la latencia P99, la tasa de errores, la cobertura de ranuras y el retraso de replicaci\u00f3n. De <code>INFORMACI\u00d3N<\/code> yo tiro <strong>aciertos\/fallos en el espacio de claves<\/strong>, <strong>operaciones instant\u00e1neas por segundo<\/strong>, <strong>clientes_conectados<\/strong>, <strong>memoria_utilizada \/ rss<\/strong> y <strong>relaci\u00f3n_fragmentaci\u00f3n_mem<\/strong>. El <strong>Slowlog<\/strong> ayuda a identificar los valores at\u00edpicos; <code>LATENCY DOCTOR<\/code> Detecta picos en el sistema (disco, CPU). Me activa una alerta cuando:<\/p>\n<ul>\n  <li>Si la latencia P95\/P99 aumenta o el porcentaje de tiempos de espera supera los umbrales,<\/li>\n  <li>el retraso en la replicaci\u00f3n sigue siendo elevado,<\/li>\n  <li>Utilizaci\u00f3n de memoria por nodo &gt;80 % y fragmentaci\u00f3n RSS &gt;1,5,<\/li>\n  <li>frecuente <code>MOVED<\/code>\/<code>ASK<\/code>-Se produzcan incidentes (reequilibrio inesperado),<\/li>\n  <li>\u00bfAumentan los desahucios o... <code>clientes_bloqueados<\/code> crece.<\/li>\n<\/ul>\n<p>Para la capacidad, tengo previsto utilizar los siguientes umbrales: a partir de X % de RAM y Y % de CPU durante Z minutos, pondr\u00e9 en marcha un plan de reequilibrio o de ampliaci\u00f3n horizontal. Mantengo los paneles de control organizados por ranuras y nodos, para detectar los puntos cr\u00edticos <strong>principios de<\/strong> se hacen visibles.<\/p>\n\n<h2>Eficiencia en el uso del almacenamiento y modelo de datos<\/h2>\n<p>Optimizo los objetos antes de a\u00f1adir nodos: serializaci\u00f3n m\u00e1s peque\u00f1a (JSON compactos, formatos binarios),... <strong>TTLs<\/strong> Y evitar valores demasiado grandes ahorra RAM. Para muchas claves peque\u00f1as, utilizo tipos estructurados (por ejemplo, hash) de forma eficiente, pero presto atenci\u00f3n a la sobrecarga por objeto. <strong>Desfragmentaci\u00f3n activa<\/strong> y adaptada a las necesidades <code>pol\u00edtica de memoria m\u00e1xima<\/code> (por ejemplo <code>allkeys-lru<\/code> o <code>volatile-ttl<\/code>) mantienen estables las latencias cuando la memoria escasea. Mido la dispersi\u00f3n del tama\u00f1o de los objetos y tengo en cuenta la fragmentaci\u00f3n; as\u00ed puedo tomar mejores decisiones en cuanto al hardware.<\/p>\n\n<h2>Topolog\u00eda de red y ubicaci\u00f3n de las zonas<\/h2>\n<p>Distribuyo los \u00abprimaries\u00bb y los \u00abreplicates\u00bb en diferentes <strong>Zonas de disponibilidad<\/strong> y vigilo la latencia y la p\u00e9rdida de paquetes. La interconexi\u00f3n de cl\u00fasteres (Gossip\/Bus) requiere latencias estables; evito las rutas L2 de gran alcance. Para los nombres DNS de los nodos, establezco nombres fijos y asignaci\u00f3n fija de direcciones IP durante las ventanas de mantenimiento, para que los clientes no se encuentren con sorpresas. <strong>MTU<\/strong>, Compruebo la configuraci\u00f3n de ECN y de colas bajo carga, ya que unas tasas de p\u00e9rdida de paquetes incluso peque\u00f1as, con un QPS elevado, provocan r\u00e1pidamente tiempos de espera apreciables.<\/p>\n\n<h2>Manuales operativos y gu\u00edas de procedimientos<\/h2>\n<p>Tengo preparados unos \u00abplaybooks\u00bb concisos y probados: arranque de cl\u00fasteres, a\u00f1adir\/eliminar nodos, redistribuci\u00f3n selectiva de datos, copias de seguridad y restauraci\u00f3n, simulacros de conmutaci\u00f3n por error y despliegues de actualizaciones. Cada gu\u00eda de procedimientos incluye requisitos previos (qu\u00f3rum, memoria libre), acciones paso a paso y <strong>Rollback<\/strong>-Rutas. Documento la denominaci\u00f3n, la asignaci\u00f3n de ranuras, la cadena de r\u00e9plicas y las listas de control de acceso (ACL); de este modo, el funcionamiento se mantiene estable incluso cuando hay cambios en el equipo.<\/p>\n\n<h2>Brevemente resumido<\/h2>\n<p>Redis Cluster distribuye los datos a trav\u00e9s de ranuras de hash, se escala horizontalmente a trav\u00e9s de varios nodos y, gracias a las r\u00e9plicas, ofrece una <strong>Actuaci\u00f3n<\/strong>. Las plataformas de alojamiento se benefician porque las sesiones, las cach\u00e9s, las colas y los l\u00edmites de tasa crecen de forma independiente, y los puntos de congesti\u00f3n se producen con menos frecuencia. Consigo buenos resultados con un dise\u00f1o claro de claves, grupos de conexiones controlados, b\u00faferes de memoria y un reequilibrio adecuado. La monitorizaci\u00f3n, las alertas y los guiones de actuaci\u00f3n documentados reducen notablemente el riesgo durante la migraci\u00f3n, la ampliaci\u00f3n y la conmutaci\u00f3n por error. Quien planifica de forma consciente obtiene tiempos de respuesta constantes, mayor capacidad de reserva para los picos y una configuraci\u00f3n que se adapta al tr\u00e1fico <strong>crece contigo<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>El sharding de Redis Cluster mejora la distribuci\u00f3n de la carga, la escalabilidad y la disponibilidad en las grandes plataformas de alojamiento. Te lo explicamos de forma concisa.<\/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\/es\/wp-json\/wp\/v2\/posts\/20508","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=20508"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20508\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20501"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20508"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20508"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20508"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}