¿Cuándo usar un caché más rápido que Redis? ¿cómo utilizar?

Me inscribí en el primer desafío del Proyecto Golden Stone: comparta el pozo de premios de 100,000, este es mi tercer artículo, haga clic para ver los detalles del evento

Hola a todos, estoy entre el sol y las estrellas. No es fácil de crear. Si les resulta útil, sigan, den me gusta, comenten, marquen como favorito y reenvíen, gracias.

prefacio

Imagine tal escenario, un usuario quiere retirar el saldo acumulado al ver la versión de súper velocidad del video durante mucho tiempo, por lo que hace clic en el botón de retiro y, con un golpe, su dinero irá a la tarjeta bancaria. Una acción tan simple para el usuario a menudo implica más de una docena de servicios en segundo plano (cuanto mayor sea la escala de la empresa y mayores sean los requisitos normativos, más servicios en toda la cadena de llamadas), y usted es responsable de un servicio de validación cruzada. , que es principalmente responsable de verificar si el ID de facturación, el ID de flujo de fondos, el número de cuenta del pagador y el número de cuenta del beneficiario que le pasó el upstream son los mismos que los configurados originalmente en la aplicación.

Para una buena experiencia del producto, el gran jefe requiere que la solicitud demore como máximo 1s para permitir que el usuario vea el resultado, por lo que la persona a cargo de cada servicio se peleó y reservó solo 50ms para su servicio. Cuando lo piensas, esto no es fácil, solo ve directamente al caché de Redis. El conjunto de Redis de salida crepitante, no hay ningún problema en el entorno de prueba, pero me quedé estupefacto después de conectarme. Debido a las fluctuaciones de la red y otras razones, su servicio a menudo se agota. El líder del equipo le ordenó que lo resolviera lo antes posible. , y luego porque su servicio se agotó le causó Si el gran jefe lo regaña, no piense en su desempeño. En este momento, ¿cómo lo optimizas?

teoría

Si desea ser más rápido que Redis, primero debe saber por qué Redis es más rápido. La razón más directa es que todos los datos en Redis están en la memoria, y obtener la base de datos de la memoria es varios órdenes de magnitud más rápido que obtener datos del disco duro. .

Entonces, si quiere ser más rápido que Redis, solo puede trabajar duro en la transmisión de datos, omitir la transmisión de datos entre diferentes servidores e incluso entre diferentes procesos, colocar los datos directamente en la JVM y escribir un ConcurrentMap para guardar los datos. dado que es un caché, debe haber un conjunto completo de estrategias de eliminación, restricciones de espacio máximo, estrategias de actualización, etc. Es demasiado costoso hacerlo a mano. Debe haber una gran empresa que haya hecho un trabajo así en un escenario similar, y quiere ganarse una buena reputación. Realice una búsqueda en github y debe haber una solución preparada. Así que hoy salió nuestro protagonista, Guava Cache.

práctica

Primero, se utiliza un fragmento de código para presentar el uso de Guava Cache como un todo. El Cache se divide en dos partes: CacheBuilder y CacheLoader. CacheBuilder es responsable de crear objetos de caché y luego configura la capacidad máxima, el método de caducidad y elimina los oyentes al crearlos. CacheLoader se encarga de cargar el valor según la clave.

LoadingCache<Key, Config> configs = CacheBuilder.newBuilder()
       .maximumSize(5000)
       .expireAfterWrite(30, TimeUnit.MINUTES)
       .removalListener(MY_LISTENER)
       .build(
           new CacheLoader<Key, Config>() {
             @Override
             public Graph load(Key key) throws AnyException {
               return loadFromRedis(key);
             }
           });
复制代码

escena aplicable

Todo tiene un precio, estás dispuesto a aceptar el costo del espacio de memoria para aumentar la velocidad
La cantidad de datos ocupados por el almacenamiento no será demasiado grande, demasiado grande causará Out of Memoryexcepciones
Se accederá a la misma clave muchas veces.

cargador de caché

No es necesario especificar CacheLoader en la compilación. Si sus datos tienen varios métodos de carga, puede usar el método invocable.

  cache.get(key, new Callable<Value>() {
    @Override
    public Value call() throws AnyException {
      return doThingsTheHardWay(key);
    }
  });
复制代码

Política de vencimiento

Las estrategias de caducidad se dividen en puntos de referencia de tamaño y puntos de referencia de tiempo. Los puntos de referencia de tamaño se pueden especificar mediante CacheBuilder.maximumSize(long)sum CacheBuilder.maximumWeight(long). Se maximumSize(long)aplica al hecho de que el espacio ocupado por cada valor es básicamente igual o la diferencia es insignificante. Solo depende de la cantidad de claves, y maximumWeight(long)se calculará el espacio ocupado de cada valor y asegúrese de que el peso total no sea mayor que el valor establecido, donde el método de cálculo de cada valor se weigher(Weigher)puede establecer mediante .

La base de tiempo es fácil de entender. Se divide en expireAfterAccess(long, TimeUnit)y expireAfterWrite(long, TimeUnit), respectivamente, cuánto tiempo tarda en fallar después de leer y cuánto tarda en fallar después de escribir en el caché. Cada vez que se lee el caché, el valor del error de lectura será renovado.

política de actualización

CacheBuilder.refreshAfterWrite(long, TimeUnit)El método proporciona la capacidad de actualizar automáticamente. Cabe señalar que si el método de recarga no se reescribe, la operación de actualización solo se realizará cuando se encuentre la clave nuevamente.

Resumir

Si lanza una pregunta, debe dar la respuesta, de lo contrario será un eunuco. Entonces, ¿cómo hago la pregunta en la introducción? Configuré un caché de segundo nivel a través de guayaba caché y redis, y escaneo la tabla cuando el servicio comienza la operación, coloque todo el contenido de configuración en el caché de guayaba por adelantado. El tiempo de actualización de guayaba se establece en cinco minutos, y la operación de actualización se reescribe para forzar la actualización. El tiempo de vencimiento de redis se establece en un día, y el valor en el caché de Redis correspondiente se elimina después de actualizar el contenido de la base de datos. De esta manera, se puede garantizar que el caché de guayaba local se puede ver afectado en la mayoría de los casos, y los datos son inconsistentes por hasta 5 minutos (el negocio es aceptable). Todo tiene un precio Como desarrollador back-end, debe elegir entre varias opciones y elegir una solución con un costo aceptable y un negocio aceptable.