Prácticas recomendadas de Memorystore para Redis

En esta página, se proporciona orientación sobre el uso óptimo de Memorystore para Redis. También se muestran posibles problemas que debes evitar.

Para obtener una lista de situaciones de solución de problemas, consulta Solución de problemas.

Prácticas recomendadas para la alta disponibilidad y la durabilidad de los datos

Recomendamos usar el nivel Estándar como el mecanismo principal para la alta disponibilidad (HA). El nivel Estándar proporciona una instancia de alta disponibilidad con varias réplicas y permite una recuperación rápida con la conmutación por error automática si la instancia principal falla. Además, habilitar las instantáneas de RDB en las instancias de nivel Estándar proporciona protección adicional contra las fallas de los nodos.

En algunos casos, es posible que también quieras asegurarte de poder recuperar datos de las copias de seguridad de instantáneas. En estas situaciones, las copias de seguridad y la capacidad de restablecer datos desde instantáneas de RDB pueden proporcionar protección adicional contra la pérdida de datos.

Si habilitas las instantáneas de RDB y necesitas recuperar tus datos, Memorystore para Redis puede hacerlo desde la instantánea más reciente. Estas instantáneas son solo para la recuperación interna del sistema y no puedes acceder a ellas.

Limitaciones de durabilidad y prácticas recomendadas

Aunque el nivel Estándar proporciona alta disponibilidad a través de la replicación y la conmutación por error automática, la alta disponibilidad no garantiza la durabilidad total de los datos. Memorystore para Redis no puede proporcionar una durabilidad de datos completa, incluso con la alta disponibilidad habilitada, durante ciertos eventos catastróficos, como fallas regionales temporales.

Para proteger tus datos y proporcionar un nivel de persistencia de referencia, las instantáneas de RDB están habilitadas de forma predeterminada cuando creas una instancia de Memorystore para Redis con la consola de Google Cloud .

Para las cargas de trabajo de producción, considera las siguientes prácticas recomendadas para mejorar aún más la resiliencia de tus datos:

  • Recuperación ante desastres: Memorystore para Redis no admite la replicación entre regiones. Si tu estrategia de recuperación ante desastres requiere replicación entre regiones para lograr una verdadera resiliencia regional, te recomendamos que uses una instancia de Memorystore para Valkey. Para obtener más información sobre cómo configurar y administrar instancias secundarias en varias regiones, consulta Trabaja con la replicación entre regiones en la documentación de Memorystore para Valkey.
  • Durabilidad máxima: Si tu aplicación requiere el nivel más alto posible de durabilidad de los datos, te recomendamos que uses una instancia de Memorystore para Valkey configurada con replicación entre regiones, copias de seguridad diarias automatizadas y persistencia de archivos de solo anexión (AOF). Esta combinación proporciona la protección más sólida contra la pérdida de datos. Para obtener más información, consulta Descripción general de la persistencia en la documentación de Memorystore para Valkey.

Prácticas recomendadas para la planificación de la capacidad

Para garantizar que puedas aprovisionar recursos y compilar arquitecturas resilientes de forma correcta, te recomendamos que sigas estas prácticas recomendadas para la planificación de la capacidad:

  • Implementa en varias ubicaciones: Si no puedes crear una instancia en tu zona preferida debido a restricciones de recursos temporales, intenta crear la instancia en otra zona dentro de la misma región o en otra región.
  • Usa el acceso entre regiones: Configura tus clientes para que accedan a tus instancias que se encuentran en diferentes regiones. Si necesitas aprovisionar una instancia que se encuentra en una región diferente debido a restricciones de recursos locales, tus clientes podrán conectarse a la instancia.
  • Elige un nivel de capacidad diferente: Si encuentras restricciones de recursos debido al tamaño de una instancia, selecciona un nivel de capacidad diferente o cambia el tamaño de la instancia. Para obtener más información, consulta Rendimiento del nivel de capacidad.

Exportación de RDB

Cuando exportes una copia de seguridad de RDB, usa la siguiente guía:

Operaciones que consumen muchos recursos

En las instancias de Redis de nivel Estándar, las siguientes operaciones usan memoria adicional durante la operación:

La actualización de versiones, el escalamiento y la conmutación por error manual utilizan memoria adicional (para instancias de nivel Estándar) debido a la replicación. Estas operaciones siguen el proceso de replicación descrito en Comportamiento de actualización de instancias de nivel Estándar.

Las operaciones de importación y exportación requieren memoria adicional debido al proceso bifurcado de Redis y la administración de datos copy-on-write (copiar al escribir) asociados con estas operaciones.

Para mitigar las desventajas de las operaciones que usan muchos recursos, debes cumplir con lo siguiente:

Operaciones y situaciones que requieren un reintento de conexión

Las siguientes operaciones y situaciones interrumpen la conexión de red entre tu red y la instancia de Redis:

Estas operaciones modifican tu instancia, lo que requiere una desconexión temporal. Debes tener una lógica de reintento con retirada exponencial antes de ejecutar estas operaciones para que la aplicación se vuelva a conectar de manera automática y siga funcionando normalmente.

Mantenimiento de rutina

Las instancias de Memorystore para Redis se someten a mantenimiento de forma periódica. Para obtener más detalles, consulta la política de mantenimiento de Memorystore para Redis.

Implementa las siguientes prácticas recomendadas para prepararte para el mantenimiento rutinario:

Administración de la memoria

La administración de la memoria puede ser un desafío debido a la conocida fragmentación de la memoria que se produce con Redis de código abierto. Recomendamos reducir la configuración maxmemory para que tu instancia te asigne una sobrecarga en caso de que haya una alta demanda de memoria.

La mejor manera de supervisar la presión sobre la memoria en tu instancia de Memorystore es con la métrica de proporción de uso de memoria del sistema. Si deseas obtener una guía más detallada para administrar la memoria de Memorystore para Redis, consulta las Prácticas recomendadas para la administración de la memoria.

Administra las conexiones inactivas

Con el tiempo, es posible que veas que aumenta la cantidad de conexiones a tu instancia de Memorystore si las conexiones no se cierran correctamente. Esto puede tener implicaciones negativas en el rendimiento, en especial si usas la encriptación en tránsito, que impone límites máximos de conexiones según tu nivel de capacidad. Para mitigar este problema, te recomendamos que uses el parámetro de configuración de Redis timeout, que te permite establecer la cantidad de segundos antes de que finalicen automáticamente las conexiones de clientes inactivas.

Nombres de recursos de Transparencia de acceso

Los datos sensibles no deben almacenarse en los nombres de recursos de Memorystore para Redis. Por nombres de recursos, nos referimos a los nombres de las instancias de Memorystore para Redis y a los metadatos de las instancias, como las etiquetas. No se garantiza que los datos almacenados en los nombres de los recursos estén protegidos por la Google Cloud Transparencia de acceso, y pueden entrar en conflicto con los requisitos de cumplimiento de la Transparencia de acceso de tu organización.

Se requiere un conector de Acceso a VPC sin servidores para algunos entornos sin servidores

Algunos entornos sin servidores requieren un conector de Acceso a VPC sin servidores para conectarse a Memorystore para Redis. Configura el conector de Acceso a VPC sin servidores para tu proyecto si deseas conectarte mediante uno de estos entornos.

Redes

Te recomendamos usar el modo de conexión de acceso a servicios privados. Memorystore para Redis usa dos modos de conexión: acceso a servicios privados e intercambio de tráfico directo. El modo de conexión de acceso a servicios privados hace que la administración del rango de IP sea más simple y te permite usar la VPC compartida si lo deseas.

Una vez que creas una instancia, no se puede cambiar el modo de conexión.

Para obtener más detalles, consulta Herramientas de redes.

Supervisión y alertas

Te recomendamos usar la supervisión y las alertas porque te ofrecen indicadores clave del uso de memoria de tu instancia de Redis. También te brindan estadísticas sobre la eficiencia con la que tu instancia de Redis responde a las solicitudes entrantes de caché.

Debes configurar las siguientes alertas predeterminadas:

Prácticas recomendadas para el uso de CPU

El uso inadecuado de comandos de Redis costosos genera latencia alta, falta de respuesta o problemas de conectividad. Las instancias de nivel Estándar proporcionan alta disponibilidad durante la recuperación ante desastres y dependen de la replicación asíncrona entre los nodos principal y de réplica. Si uno de los nodos tiene un procesamiento de comandos costoso que bloquea el subproceso principal de Redis, la replicación podría verse afectada. Si el problema persiste y se produce una interrupción de la ubicación, es posible que los datos más recientes escritos en la ubicación de la interrupción no estén disponibles en la otra ubicación.

Te recomendamos que uses Cloud Monitoring para configurar alertas para la métrica Segundos de CPU del subproceso principal (redis.googleapis.com/stats/cpu_utilization_main_thread) y asegurarte de que el uso de CPU no supere los 0.8 segundos para el nodo principal ni los 0.5 segundos para cada nodo de réplica, cuando la réplica se designa como una réplica de lectura.

Si tu instancia de Redis supera los valores recomendados, te recomendamos que escales la instancia a un nivel de capacidad más alto o que sigas las instrucciones para solucionar problemas para evitar operaciones que consuman mucha CPU.

Si tu instancia experimenta un uso elevado de CPU o si se agotan sus recursos (por ejemplo, por tener demasiadas conexiones), es posible que la instancia no se comporte de forma correcta y que falten métricas externas.

Comandos que consumen muchos recursos

Te recomendamos que evites usar comandos de Redis que consuman muchos recursos. El uso de estos comandos puede generar los siguientes problemas de rendimiento:

  • Latencia alta y tiempos de espera del cliente
  • Presión de memoria causada por comandos que aumentan el uso de memoria
  • Pérdida de datos durante la replicación y sincronización de nodos porque el subproceso principal de Redis está bloqueado
  • Verificaciones de estado, observabilidad y replicación con falta de recursos

En la siguiente tabla, se enumeran ejemplos de comandos de Redis que consumen muchos recursos y se proporcionan alternativas que usan los recursos de manera eficiente.

Categoría Comando que consume muchos recursos Alternativa con uso eficiente de recursos
Ejecutar para todo el espacio de claves KEYS SCAN
Ejecutar para un conjunto de claves de longitud variable LRANGE Limita el tamaño del rango que usas para una consulta.
ZRANGE Limita el tamaño del rango que usas para una consulta.
HGETALL HSCAN
SMEMBERS SSCAN
Bloquea la ejecución de una secuencia de comandos EVAL Asegúrate de que la secuencia de comandos no se ejecute de forma indefinida.
EVALSHA Asegúrate de que la secuencia de comandos no se ejecute de forma indefinida.
Cómo quitar archivos y vínculos DEL UNLINK
Publica y suscríbete PUBLISH SPUBLISH
SUBSCRIBE SSUBSCRIBE

Prácticas recomendadas para el cliente de Redis

En esta sección, se proporcionan instrucciones para usar de forma óptima tu cliente de Redis.

Detecta y controla las conexiones que no responden

Te recomendamos que configures tu aplicación cliente para detectar conexiones que no responden a Memorystore para Redis. Cuando se detecta una conexión que no responde, el cliente debe restablecerla. Para compilar una aplicación resiliente, te recomendamos las siguientes configuraciones de cliente:

  • Configura los parámetros de keep-alive de TCP: establece los parámetros TCP keepalive time, TCP keepalive interval y TCP keepalive probes para que los clientes detecten y descarten las conexiones que no responden de forma proactiva, incluso cuando las conexiones están inactivas. Por ejemplo, si configuras el parámetro TCP keepalive time en 30 segundos, TCP keepalive interval en 10 segundos y TCP keepalive probes en 3, los clientes restablecen las conexiones inactivas que no responden en un minuto.
  • Configura los tiempos de espera de usuario de TCP: Establece este tiempo de espera en tus clientes para restablecer las conexiones que tienen solicitudes pendientes y dejan de responder. Por ejemplo, si estableces el tiempo de espera en 15 segundos, los clientes restablecen las conexiones que no responden y que tienen solicitudes pendientes después de 15 segundos.

Prácticas recomendadas específicas para cada cliente

Si escalas horizontalmente tus aplicaciones, es posible que experimentes errores READONLY en los comandos de escritura. Memorystore para Redis usa una implementación que no es de Sentinel con extremos estáticos, y los clientes no reciben información de roles dinámicos por adelantado. Si usas una sola conexión de cliente para los extremos principal y de réplica, es posible que el cliente envíe por accidente comandos de escritura a la réplica de solo lectura. La réplica devuelve un error READONLY porque no puede procesar comandos de escritura.

Para evitar el enrutamiento incorrecto de las escrituras, no uses una sola conexión para las lecturas y las escrituras. En su lugar, divide tus operaciones creando las siguientes instancias de cliente independientes:

  • Cliente principal: Se conecta solo al extremo principal.
  • Cliente de réplica: Se conecta solo al extremo de réplica.

En las siguientes pestañas, se muestra cómo configurar las plantillas independientes en Go, Java, Node.js y Python.

Go

package main

import (
  "context"
  "fmt"

  "github.com/redis/go-redis/v9"
)

func main() {
ctx := context.Background()

  // Initialize the primary client connecting only to the primary endpoint
  primaryClient := redis.NewClient(&redis.Options{
      Addr:     "PRIMARY_HOST:6379",
      Password: "YOUR_PASSWORD",
      DB:       0,
  })
  defer primaryClient.Close()

  // Initialize the replica client connecting only to the replica endpoint
  replicaClient := redis.NewClient(&redis.Options{
      Addr:     "REPLICA_HOST:6379",
      Password: "YOUR_PASSWORD",
      DB:       0,
  })
  defer replicaClient.Close()

  // Use the primary client for all mutating commands
  err := primaryClient.Set(ctx, "example_key", "example_value", 0).Err()
  if err != nil {
      fmt.Printf("Failed to write to primary: %v\n", err)
  }

  // Use the replica client for all read-only commands
  val, err := replicaClient.Get(ctx, "example_key").Result()
  if err != nil {
      fmt.Printf("Failed to read from replica: %v\n", err)
  } else {
      fmt.Printf("Successfully read value: %s\n", val)
  }
}

Java

@Bean
public RedisConnectionFactory primaryConnectionFactory() {
  RedisStandaloneConfiguration config = new RedisStandaloneConfiguration("PRIMARY_HOST", 6379);
  config.setPassword(RedisPassword.of("YOUR_PASSWORD"));
  return new LettuceConnectionFactory(config);
}

@Bean
public RedisConnectionFactory replicaConnectionFactory() {
  RedisStaticMasterReplicaConfiguration config =
      new RedisStaticMasterReplicaConfiguration("PRIMARY_HOST", 6379);
  config.addNode("REPLICA_HOST", 6379);
  config.setPassword(RedisPassword.of("YOUR_PASSWORD"));

  LettuceClientConfiguration clientConfig = LettuceClientConfiguration.builder()
      .readFrom(ReadFrom.REPLICA_PREFERRED)
      .build();

  return new LettuceConnectionFactory(config, clientConfig);
}

@Bean
public RedisTemplate<String, Object> primaryRedisTemplate(
  @Qualifier("primaryConnectionFactory") RedisConnectionFactory factory) {

  RedisTemplate<String, Object> template = new RedisTemplate<>();
  template.setConnectionFactory(factory);
  return template;
}

@Bean
public RedisTemplate<String, Object> replicaRedisTemplate(
  @Qualifier("replicaConnectionFactory") RedisConnectionFactory factory) {

  RedisTemplate<String, Object> template = new RedisTemplate<>();
  template.setConnectionFactory(factory);
  return template;
}

Node.js

import { createClient } from 'redis';

async function main() {
// Initialize the primary client connecting only to the primary endpoint
const primaryClient = createClient({
  url: 'redis://PRIMARY_HOST:6379',
  password: 'YOUR_PASSWORD'
});

// Initialize the replica client connecting only to the replica endpoint
const replicaClient = createClient({
  url: 'redis://REPLICA_HOST:6379',
  password: 'YOUR_PASSWORD'
});

primaryClient.on('error', (err) => console.error('Primary Client Error', err));
replicaClient.on('error', (err) => console.error('Replica Client Error', err));

await primaryClient.connect();
await replicaClient.connect();

// Use the primary client for all mutating commands
try {
  await primaryClient.set('example_key', 'example_value');
  console.log('Successfully wrote to primary');
} catch (err) {
  console.error('Failed to write to primary:', err);
}

// Use the replica client for all read-only commands
try {
  const val = await replicaClient.get('example_key');
  console.log(`Successfully read value: ${val}`);
} catch (err) {
  console.error('Failed to read from replica:', err);
}

await primaryClient.disconnect();
await replicaClient.disconnect();
}

main();

Python

import redis

def main():
  # Initialize the primary client connecting only to the primary endpoint
  primary_client = redis.Redis(
      host='PRIMARY_HOST',
      port=6379,
      password='YOUR_PASSWORD',
      decode_responses=True
  )

  # Initialize the replica client connecting only to the replica endpoint
  replica_client = redis.Redis(
      host='REPLICA_HOST',
      port=6379,
      password='YOUR_PASSWORD',
      decode_responses=True
  )

  # Use the primary client for all mutating commands
  try:
      primary_client.set('example_key', 'example_value')
      print('Successfully wrote to primary')
  except redis.RedisError as e:
      print(f'Failed to write to primary: {e}')

  # Use the replica client for all read-only commands
  try:
      val = replica_client.get('example_key')
      print(f'Successfully read value: {val}')
  except redis.RedisError as e:
      print(f'Failed to read from replica: {e}')

if __name__ == '__main__':
  main()