Hola, soy Valerio, fundador y CTO de Inspector.
Dado que el sistema de caché del Inspector se ejecuta en Redis, recientemente decidimos pasar de un solo servidor de Redis a un clúster de Redis administrado por AWS.
Amazon ElastiCache es un servicio de almacenamiento en caché completamente administrado que se puede configurar en modo de clúster con un simple clic para que se pueda escalar hacia adentro y hacia afuera fácilmente.
Ejecutar un clúster de Redis no es una tarea fácil. Orquestar múltiples nodos de Redis con la misma eficiencia que un servicio administrado requiere muchas habilidades verticales. Un servicio administrado nos ayuda a mantenernos enfocados en el desarrollo de aplicaciones en lugar de lidiar con problemas de administración de infraestructura.
Pero pasar de una instancia de un solo servidor a una configuración habilitada para clúster provocó que apareciera un nuevo error:
CROSSSLOT Keys in request don't hash to the same slot
Cuando Redis opera en modo de clúster, maneja el almacenamiento de datos de manera diferente que cuando opera como una sola instancia.
Esto se debe a que debería estar listo para distribuir datos entre varios nodos, lo que permite la escalabilidad horizontal.
Un clúster de Redis, si lo está comparando con Redis independiente, que es la configuración no distribuida, use el concepto " HASH SLOT " para la administración de claves, lo que implica algunas restricciones en las operaciones clave, necesarias para garantizar la coherencia de los datos en un entorno distribuido. .
Si echa un vistazo a la descripción del error, dice: " Las claves en la solicitud no generan hash en la misma ranura ", significa que estamos ejecutando algunos comandos que no son compatibles con las restricciones "HASH SLOT" mencionadas anteriormente.
Redis Cluster determina a qué instancia se asignará la clave particular mediante un algoritmo específico.
Para hacerlo simple, cuando crea una nueva clave, Redis le asignará un número entero, llamado hash-slot. Las claves con la misma ranura hash residirán en el mismo nodo de Redis dentro del clúster.
Puede verificarlo usted mismo con un ejemplo rápido.
Conéctese a su clúster de Redis:
redis-cli -h [CLUSTER_ADDRESS] -p 6379
Cree dos claves nuevas y verifique su ranura hash asignada:
redis> SET mykey1 "Hello" "OK" redis> SET mykey2 "Hello 2" "OK" redis> CLUSTER KEYSLOT mykey1 (integer) 650 redis> CLUSTER KEYSLOT mykey2 (integer) 8734
Como puede ver, el clúster ha asignado dos ranuras hash diferentes a las claves, por lo que probablemente estén almacenadas en diferentes nodos dentro del clúster.
Esto es exactamente lo que sucede cuando su aplicación crea o cambia claves en Redis.
Este error ocurre porque la aplicación intenta ejecutar un comando en varias claves, pero las claves involucradas en la operación no están en la misma ranura hash.
Esto da como resultado una operación de "RANURA CRUZADA" que no está permitida en un clúster.
Las ranuras hash controlan cómo se distribuyen los datos dentro del clúster, por lo que esta restricción es necesaria para evitar la corrupción de la información en un entorno distribuido.
En el ejemplo anterior, hemos verificado que las dos claves (mykey1, mykey2) han obtenido dos ranuras de hash diferentes.
Al intentar ejecutar un comando que involucre ambas teclas, obtendremos el error:
redis> SUNION mykey1 mykey2 (error) CROSSSLOT Keys in request don't hash to the same slot
Al crear claves que podrían usarse en operaciones de múltiples claves, use hashtags ({…}) para forzar las claves en la misma ranura hash.
Cuando la clave contiene un patrón "{...}", solo se considera la subcadena entre las llaves, "{" y "}", para calcular la ranura hash.
Por ejemplo, las claves {usuario1}:miclave1 y {usuario1}:miclave2 tienen el mismo hash-slot porque solo la cadena entre llaves "{" y "}", es decir, "usuario1", se usa para calcular la ranura hash:
redis> CLUSTER KEYSLOT {user1}:mykey1 (integer) 8006 redis> CLUSTER KEYSLOT {user1}:mykey2 (integer) 8006 redis> SUNION {user1}:mykey1 {user1}:mykey2 1) "Hello" 2) "Hello 2"
Ahora se pueden realizar operaciones de múltiples claves ya que ambas claves se colocan en la misma ranura hash.
Casi todos los clientes de Redis admiten la función de "etiqueta", por lo que debe explorar la documentación de su marco/biblioteca para comprender cómo usarlo.
¿Está buscando una herramienta de monitoreo "basada en código" en lugar de tener que instalar cosas a nivel de servidor?
Obtenga un entorno de monitoreo diseñado específicamente para desarrolladores de software evitando cualquier configuración de servidor o infraestructura.
Gracias a Inspector, nunca instalará cosas a nivel de servidor ni realizará configuraciones complejas en su infraestructura en la nube.
Inspector funciona con una biblioteca de software ligera que puede instalar en su aplicación como cualquier otra dependencia. Consulte la tecnología admitida en nuestro GitHub .
Visite nuestro sitio web para obtener más detalles: https://inspector.dev
También publicado aquí