🧚🏿 📌 🤜🏻 Cómo en Sportmaster elegimos un sistema de almacenamiento en caché. Parte 1 ♠️ 🐰 🏴󠁧󠁢󠁥󠁮󠁧󠁿

¡Hola! Mi nombre es Alexey Pyankov, soy desarrollador en Sportmaster. En esta publicación , hablé sobre cómo comenzó el trabajo en el sitio web de Sportmaster en 2012, qué iniciativas logramos impulsar y viceversa, qué rastrillo recolectamos.

Hoy quiero compartir los pensamientos que siguen a otra historia: elegir un sistema de almacenamiento en caché para el backend de Java en el panel de administración del sitio. Este argumento es de particular importancia para mí, aunque la historia tuvo lugar solo 2 meses, pero estos 60 días trabajamos durante 12-16 horas y sin un día libre. Nunca había pensado e imaginado que puedes trabajar tanto.

Por lo tanto, divido el texto en 2 partes, para no descargarlo por completo. Por el contrario, la primera parte será muy fácil: preparación, introducción, algunas consideraciones sobre qué es el almacenamiento en caché. Si ya es un desarrollador experimentado o ha trabajado con cachés, desde el punto de vista técnico, probablemente no haya nada nuevo en este artículo. Pero para un joven, una pequeña revisión de este tipo puede indicar qué aspecto tomar, si se encuentra en una encrucijada.

Cuando se lanzó la nueva versión del sitio web Sportmaster en producción, los datos llegaron de una manera, por decirlo suavemente, no muy conveniente. La base fueron las tablas preparadas para la versión anterior del sitio (Bitrix), que tuvo que ser reforzada en ETL, traída a un nuevo aspecto y enriquecida con diferentes pequeñas cosas de una docena de sistemas más. Para que una nueva imagen o descripción del producto aparezca en el sitio, tuvo que esperar hasta el día siguiente: actualice solo por la noche, 1 vez por día.

Al principio, había tantas preocupaciones durante las primeras semanas de producción que tales inconvenientes para los administradores de contenido eran un poco triviales. Pero, tan pronto como todo se calmó, el desarrollo del proyecto continuó: unos meses más tarde, a principios de 2015, comenzamos a desarrollar activamente el panel de administración. En 2015 y 2016, todo va bien, lo lanzaremos regularmente, el área de administración cubre la mayor parte de la preparación de datos y nos estamos preparando para el hecho de que pronto lo más importante y difícil se confiará a nuestro equipo: la línea de productos (preparación completa y mantenimiento de datos para todos los productos). Pero en el verano de 2017, justo antes del lanzamiento de la línea de productos, el proyecto se encontrará en una situación muy difícil, precisamente por problemas de almacenamiento en caché. Quiero hablar sobre este episodio en la segunda parte de esta publicación de dos partes.

Pero en esta publicación comenzaré desde lejos, como algunas ideas: ideas sobre el almacenamiento en caché, que desplazar antes de un gran proyecto por adelantado sería un buen paso.

Cuando surge una tarea de caché

La tarea de almacenamiento en caché no solo aparece. Somos desarrolladores, escribimos un producto de software y queremos que tenga demanda. Si el producto tiene demanda y es exitoso, llegan los usuarios. Y vienen más y más. Y entonces hay muchos usuarios y luego el producto se vuelve muy cargado.

En las primeras etapas, no pensamos en la optimización y el rendimiento del código. Lo principal es la funcionalidad, despliegue rápidamente el piloto y pruebe las hipótesis. Y si la carga crece, bombeamos hierro. Lo incrementamos en un factor de dos, tres, cinco, que sea 10 veces. En algún lugar aquí, las finanzas ya no lo permitirán. ¿Y cuántas veces aumentará el número de usuarios? No solo será 2-5-10, sino que si tiene éxito, será de 100-1000 y hasta 100 mil veces. Es decir, tarde o temprano, pero tendrá que hacer la optimización.

Digamos que una parte del código (llamemos a esta parte una función) funciona de manera indecente durante mucho tiempo, y queremos reducir el tiempo de ejecución. Función: puede ser el acceso a la base de datos, puede ser la ejecución de una lógica compleja; lo principal es que lleva mucho tiempo. ¿Cuánto puede reducir el tiempo de entrega? En el límite, se puede reducir a cero, no más. ¿Y cómo puedes reducir el tiempo de ejecución a cero? Respuesta: generalmente excluye la ejecución. En cambio, devuelva inmediatamente el resultado. ¿Y cómo sabes el resultado? Respuesta: calcule o busque en alguna parte. Calcular es mucho tiempo. Y mirar es, por ejemplo, recordar el resultado que la función produjo la última vez cuando se llamó con los mismos parámetros.

Es decir, la implementación de la función no nos importa. Es suficiente saber de qué parámetros depende el resultado. Luego, si los valores de los parámetros se presentan en forma de un objeto que se puede usar como clave en algún almacenamiento, entonces podemos guardar el resultado del cálculo y leerlo la próxima vez. Si estos resultados de lectura-escritura son más rápidos que realizar la función, tenemos una ganancia en velocidad. El valor de la ganancia puede llegar a 100, 1000 y 100 mil veces (10 ^ 5 es más probable una excepción, pero en el caso de una base de retraso decente es bastante posible).

Requisitos clave de almacenamiento en caché

Lo primero que puede convertirse en un requisito para un sistema de almacenamiento en caché es una velocidad de lectura rápida y, en menor medida, una velocidad de escritura. Esto es así, pero solo hasta que implementemos el sistema en producción.

Juguemos un caso así.

Supongamos que proporcionamos hierro a la carga actual y ahora estamos introduciendo gradualmente el almacenamiento en caché. Los usuarios están creciendo un poco, la carga está creciendo: agregamos cachés un poco, lo sujetamos aquí y allá. Esto ha estado sucediendo durante algún tiempo, y ahora las funciones pesadas prácticamente no se invocan: toda la carga principal recae en el caché. El número de usuarios durante este tiempo ha crecido N veces.

Y si el suministro inicial de hierro puede ser de 2 a 5 veces, entonces con la ayuda del caché podríamos ajustar la productividad cada 10 o, en un buen caso, 100 veces, en algunos lugares, posiblemente 1000. Es decir, procesamos en el mismo hierro 100 veces más solicitudes. ¡Genial, merece un pan de jengibre!

Pero ahora, en un momento, por accidente, el sistema se bloqueó y el caché se bloqueó. Nada especial: después de todo, el caché se seleccionó a pedido "lectura y escritura de alta velocidad, el resto no importa".

Con respecto a la carga inicial, la reserva de hierro fue de 2 a 5 veces, y la carga durante este tiempo creció de 10 a 100 veces. Con la ayuda del caché, eliminamos las llamadas para funciones pesadas y, por lo tanto, todo voló. Y ahora, sin un caché, ¿cuántas veces se hunde nuestro sistema? ¿Qué nos pasará? El sistema caerá.

Incluso si nuestro caché no se bloqueó, sino que solo se borró por un tiempo, será necesario calentarlo, y esto llevará algún tiempo. Y en este momento, la carga principal recaerá en lo funcional.

Conclusión: los proyectos de alta carga en el producto requieren del sistema de almacenamiento en caché no solo una alta velocidad de lectura y escritura, sino también seguridad de datos y resistencia a fallas.

Harina de elección

En el proyecto con el panel de administración, la elección fue así: primero pusieron Hazelcast, porque Ya estábamos familiarizados con este producto por la experiencia del sitio principal. Pero, aquí, esta elección no tuvo éxito: para nuestro perfil de carga, Hazelcast funciona no solo lentamente, sino terriblemente lento. Y en ese momento, ya nos suscribimos a los términos de retiro del producto.

Spoiler: ¿cómo surgieron exactamente las circunstancias en que nos perdimos un golpe y tuvimos una situación aguda y tensa, lo diré en la segunda parte, y cómo salimos y cómo salimos? Pero ahora, solo diré que fue muy estresante, y "pensar, de alguna manera no lo creo, agitar la botella". "Sacudir la botella" también es un spoiler, sobre esto un poco más.

Qué hemos hecho:

Hacemos una lista de todos los sistemas solicitados por google y StackOverflow. Un poco más de 30
, . , - — , .
, , , . , – , .
17- , . « », .

Pero esta es una opción cuando necesita elegir un sistema que "se arrastre en velocidad" en las pruebas preparadas previamente. ¿Y si aún no hay tales pruebas y le gustaría elegir más rápido?

Simularemos tal opción (es difícil imaginar que el desarrollador medio + viva en el vacío, y en el momento de la selección aún no había decidido qué producto probar en primer lugar; por lo tanto, es más probable que una discusión posterior sea un teórico / filosofía / sobre un junior).

Una vez determinados los requisitos, comenzaremos a elegir una solución de la caja. Por qué reinventar la rueda: iremos y tomaremos un sistema de caché listo para usar.

Si recién está comenzando y buscará en Google, entonces más o menos el pedido, pero en general, las pautas serán así. En primer lugar, te topas con Redis, se escucha en todas partes. Entonces descubrirá que existe EhCache como el sistema más antiguo y probado. Luego se escribirá sobre Tarantool, un desarrollo interno en el que hay un aspecto único de la solución. Y también Ignite, porque ahora está en aumento en popularidad y goza del apoyo de SberTech. Al final, está Hazelcast, porque en el mundo empresarial a menudo parpadea en medio de grandes empresas.

Esta lista no termina allí; hay docenas de sistemas. Y jodimos solo uno. Tome los 5 sistemas seleccionados para el "concurso de belleza" y realice una selección. Quién será el ganador.

Redis

Leemos lo que escriben en el sitio web oficial.
Redis es un proyecto de código abierto. Ofrece almacenamiento de datos en memoria, la capacidad de guardar en disco, particionar automáticamente en particiones, alta disponibilidad y recuperación de interrupciones de red.

Parece que todo está bien, puedes tomarlo y atornillarlo; todo lo que necesita es lo que hace. Pero solo busquemos el interés en los otros candidatos.

Ehcache

EhCache : "el caché más utilizado para Java" (traducción del eslogan del sitio oficial). También de código abierto. Y aquí entendemos que Redis no está bajo Java, sino en general, y para interactuar con él, necesitas un contenedor. Y EhCache será más conveniente. ¿Qué más promete el sistema? Fiabilidad, eficacia, funcionalidad completa. Bueno, y ella es la más común. Y almacena en caché terabytes de datos.

Redis está olvidado, estoy listo para elegir EhCache.

Pero una sensación de patriotismo me empuja a ver qué hace que Tarantool sea bueno.

Tarantool

Tarantool : cumple con la designación "Plataforma de integración de datos en tiempo real". Parece muy difícil, así que leemos la página en detalle y encontramos una declaración ruidosa: "Almacena en caché el 100% de los datos en la RAM". Esto debería generar preguntas; después de todo, puede haber muchos más datos que memoria. El descifrado es que aquí está implícito que Tarantool no ejecuta la serialización para escribir datos en un disco desde la memoria. En cambio, utiliza las características de bajo nivel del sistema cuando la memoria simplemente se asigna a un sistema de archivos con muy buen rendimiento de E / S. En general, lo hicieron de alguna manera maravillosa y genial.

Veamos la implementación: la autopista corporativa Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom ...

Si todavía hubiera dudas sobre Tarantool, entonces la introducción de la implementación de Mastercard me mataría. Tomo Tarantool.

Pero de todos modos…

Encender

... hay Ignite , declarada como "una plataforma informática en memoria ... velocidades en memoria en petabytes de datos". También hay muchas ventajas: caché distribuido en memoria, el almacenamiento de valor-clave más rápido y caché, escala horizontal, alta disponibilidad, integridad estricta. En general, resulta que el más rápido es Ignite.

Implementaciones: Sberbank, American Airlines, Yahoo! Japón Y luego sigo descubriendo que Ignite no solo se implementa en Sberbank, sino que el equipo de SberTech envía a su gente al equipo de Ignite para finalizar el producto. Esto es completamente cautivador y estoy listo para tomar Ignite.

Es completamente incomprensible por qué, miro el quinto punto.

Hazelcast

Voy al sitio web de Hazelcast , lo leo. Y resulta que la solución más rápida para el almacenamiento en caché distribuido es Hazelcast. Es un orden de magnitud más rápido que todas las demás soluciones y, en general, es líder en el campo de la cuadrícula de datos en memoria. En este contexto, tome algo más: no se respete a sí mismo. También utiliza almacenamiento de datos redundante para el funcionamiento continuo del clúster sin pérdida de datos.

Todo, estoy listo para tomar Hazelcast.

Comparación

Pero si nos fijamos, los cinco candidatos están tan pintados que cada uno de ellos es el mejor. ¿Como escoger? Podemos ver cuál es el más popular, buscar comparaciones y el dolor de cabeza pasará.

Encontramos tal revisión , elija nuestros 5 sistemas.

Aquí están ordenados: en la cima de Redis, en segundo lugar está Hazelcast, Tarantool e Ignite están ganando popularidad, EhCache ha sido y sigue siendo.

Pero veamos el método de cálculo : enlaces a sitios web, interés general en el sistema, ofertas de trabajo, ¡genial! Es decir, cuando mi sistema se caiga, diré: “¡No, es confiable! Aquí hay muchas ofertas de trabajo ... ". Una comparación tan simple no funcionará.

Todos estos sistemas no son solo sistemas de almacenamiento en caché. Todavía tienen mucha funcionalidad, incluso cuando no se transfieren los datos al cliente para su procesamiento, sino más bien: el código que debe ejecutarse en los datos se mueve al servidor, se ejecuta allí y se devuelve el resultado. Y como un sistema separado para el almacenamiento en caché, no se consideran tan a menudo.

Bueno, no te rindas, encontramos una comparación directa de sistemas. Tome las dos opciones principales: Redis y Hazelcast. Estamos interesados en la velocidad, podemos compararlos con este parámetro.

Hz vs Redis

Encontramos tal comparación : el

azul es Redis, el rojo es Hazelcast. Hazelcast gana en todas partes, y se explica la razón: es multihilo, altamente optimizado, cada hilo funciona con su propia partición, por lo que no hay bloqueos. Y Redis es de un solo subproceso, no se beneficia de las CPU modernas de varios núcleos. Hazelcast tiene E / S asincrónicas, Redis-Jedis tiene enchufes de bloqueo. Al final, Hazelcast utiliza un protocolo binario, mientras que Redis está orientado al texto, lo que significa que es ineficiente.

Por si acaso, recurrimos a otra fuente de comparación. ¿Qué nos mostrará?

Redis vs Hz

Otra comparación :

Aquí, por el contrario, el rojo es Redis. Es decir, Redis supera a Hazelcast en rendimiento. En la primera comparación, Hazelcast ganó, en la segunda - Redis. Aquí, explicaron con mucha precisión por qué Hazelcast ganó en la comparación anterior.

Resulta que el resultado del primero fue manipulado: Redis fue llevada a la caja base, y Hazelcast fue encarcelado por un caso de prueba. Luego resulta: en primer lugar, no se puede confiar en nadie y, en segundo lugar, cuando elegimos un sistema, aún necesitamos configurarlo correctamente. Estas configuraciones incluyen docenas, casi cientos de parámetros.

Sacudiendo una botella

Y todo el proceso que acabamos de hacer, lo puedo explicar con una metáfora, "Agite la botella". Es decir, ahora no puede programar, ahora lo principal es poder leer stackoverflow. Y en mi equipo hay una persona, un profesional, que trabaja así en los momentos críticos.

¿Qué está haciendo? Ve algo roto, ve un rastro de la pila, toma algunas de sus palabras (cuáles son su experiencia en el programa), busca en Google, encuentra el desbordamiento de pila entre las respuestas. Sin leer, sin pensar, entre las respuestas a la pregunta: elige algo más similar a la oración "haz esto y aquello" (elegir esa respuesta es su talento, ya que no siempre es la respuesta que reunió más "me gusta"), usa , se ve: si algo ha cambiado, entonces está bien. Si no ha cambiado, estamos retrocediendo. Y repetimos start-check-search. Y de una manera tan intuitiva, logra que después de un tiempo el código funcione. No sabe por qué, no sabe lo que ha hecho, no puede explicarlo. ¡Pero! Esta infección funciona. Y el "fuego extinguido". Ahora entendemos lo que hemos hecho. Cuando el programa funciona, es mucho más fácil.Y significativamente ahorra tiempo.

Este método se explica muy bien con este ejemplo.

Alguna vez fue muy popular recoger un velero en una botella. Al mismo tiempo, el velero es grande y frágil, y el cuello de la botella es muy estrecho; no se puede empujar hacia adentro. ¿Cómo armarlo?

Existe tal método, muy rápido y muy efectivo.

El barco consta de un montón de pequeñas cosas: palos, cuerdas, velas, pegamento. Ponemos todo esto en una botella.
Tomamos la botella con ambas manos y comenzamos a temblar. Estamos temblando, temblando. Y por lo general, obtienes basura completa, por supuesto. Pero a veces. ¡A veces obtienes un barco! Más precisamente, algo similar a un barco.

Le estamos mostrando esto a alguien: "Serge, ¿ves?". Y de hecho, desde lejos, como si fuera un barco. Pero entonces no puedes dejarlo pasar.

Hay otra manera Los muchachos están usando otros más avanzados, como los hackers.

Le dio una tarea a ese tipo, hizo todo y se fue. Y te ves, parece que está hecho. Y después de un tiempo, cuando es necesario refinar el código, allí comienza por eso ... Es bueno que ya haya logrado escapar muy lejos. Estos son los tipos que, usando el ejemplo de una botella, harán esto: ya ves, donde está el fondo, el vidrio se dobla. Y no está del todo claro si es transparente o no. Luego, los "hackers" cortaron este fondo, insertaron el barco allí, luego pegaron el fondo nuevamente, y como si fuera necesario.

Desde el punto de vista de establecer el problema, todo parece ser correcto. Pero aquí hay un ejemplo de barcos: ¿por qué este barco en general, quién lo necesita en absoluto? No tiene ninguna funcionalidad. Por lo general, estos barcos son un regalo para personas de alto rango que lo colocan en un estante encima de sí mismos, como algún tipo de símbolo, como un signo. Y ahora, si esa persona, el jefe de una gran empresa o un funcionario de alto rango, ¿cómo se coloca la bandera en esa basura, en la cual se corta el cuello? Sería mejor si él nunca lo supiera. Entonces, ¿cómo se hacen estos barcos que se pueden presentar a una persona importante?

El único lugar, clave, con el que realmente no hay nada que hacer, es el edificio. Y el casco de la nave solo pasa por el cuello. Mientras que el barco sale de la botella. Pero no es solo ensamblar un barco, es una verdadera joyería. Se agregan palancas especiales a los componentes, lo que les permite levantarlos más tarde. Por ejemplo, las velas se doblan, se introducen suavemente y luego, con la ayuda de unas pinzas, son muy joyas, sin duda, se tiran y se levantan. El resultado es una obra de arte que puede presentarse con la conciencia tranquila y el orgullo.

Y si queremos que el proyecto tenga éxito, debe haber al menos un joyero en el equipo. Cualquiera que se preocupe por la calidad del producto y tenga en cuenta todos los aspectos, sin sacrificar uno solo, incluso en momentos de estrés, cuando las circunstancias requieren urgente en detrimento de lo importante. Todos los proyectos exitosos que son sostenibles, que han resistido la prueba del tiempo, se basan en este principio. Tienen algo muy preciso y único, algo que utiliza todas las funciones disponibles. En el ejemplo de un barco en una botella, se deduce que el casco del barco atraviesa el cuello.

Volviendo a la tarea de elegir nuestro servidor de almacenamiento en caché, ¿cómo podría aplicarse este método? Propongo tal opción de todos los sistemas que hay: no agite la botella, no elija, pero vea qué, en principio, tienen algo que buscar al elegir un sistema.

Dónde buscar cuello de botella

Intentemos no sacudir la botella, no clasificar todo lo que está a su vez, pero veamos qué tareas surgen, si de repente, para su tarea: diseñar ese sistema usted mismo. Por supuesto, no armaremos la bicicleta, pero utilizaremos este esquema para orientarnos sobre qué puntos prestar atención en las descripciones de los productos. Esbozamos tal esquema.

Si el sistema se distribuye, tendremos varios servidores (6). Digamos cuatro (es conveniente colocarlo en la imagen, pero, por supuesto, puede haber cualquier número de ellos). Si los servidores están en nodos diferentes, significa que algún código está girando sobre todos ellos, lo que es responsable de garantizar que estos nodos formen un clúster y, en caso de interrupción, se conecten y se reconozcan entre sí.

Todavía necesita una lógica de código (2), que en realidad se trata de almacenamiento en caché. Los clientes interactúan con este código a través de alguna API. El código de cliente (1) puede estar dentro de la misma JVM y acceder a él a través de la red. La lógica implementada en el interior es la decisión de qué objetos dejar en el caché, cuáles lanzar. Usamos la memoria (3) para almacenar el caché, pero si es necesario, también podemos guardar parte de los datos en el disco (4).

Veamos en qué partes se producirá la carga. En realidad, cada flecha y cada nodo se cargarán. En primer lugar, entre el código del cliente y la API, si se trata de una interacción de red, el hundimiento puede ser bastante notable. En segundo lugar, dentro del marco de la API, habiendo anulado la lógica compleja, podemos encontrarnos con la CPU. Y sería bueno si la lógica no impulsara la memoria una vez más. Y sigue habiendo interacción con el sistema de archivos: en la versión habitual, se serializa / restaura y se escribe / lee.

Mayor interacción con el clúster. Lo más probable es que esté en el mismo sistema, pero puede estar por separado. Aquí, también debe considerar la transferencia de datos, la velocidad de serialización de datos y la interacción entre el clúster.

Ahora, por un lado, podemos imaginar "qué engranajes girarán" en el sistema de caché al procesar solicitudes de nuestro código, y por otro lado, podemos estimar qué y cuántas solicitudes generará nuestro código a este sistema. Esto es suficiente para hacer una elección más o menos sobria: elegir un sistema para nuestro caso de uso.

Hazelcast

Veamos cómo se aplica esta descomposición a nuestra lista. Por ejemplo, Hazelcast.

Para poner / tomar datos de Hazelcast, el código del cliente accede (1) a la API. Hz le permite iniciar el servidor como incrustado, y en este caso, acceder a la API es una llamada de método dentro de la JVM, puede leerlo de forma gratuita.

Para resolver la lógica en (2), Hz se basa en un hash de la matriz de bytes de la clave serializada, es decir, la serialización de la clave ocurrirá en cualquier caso. Esta es una sobrecarga inevitable para Hz.
Las estrategias de desalojo se implementan bien, pero para casos especiales, puede conectar las suyas. No tiene que preocuparse por esta parte.

El almacenamiento (4) se puede conectar. Multa. La interacción (5) para embebido puede considerarse instantánea. El intercambio de datos entre nodos en el clúster (6): sí, lo es. Esto contribuye a la resiliencia a costa de la velocidad. La función Hz de Near-cache permite reducir el precio: los datos recibidos de otros nodos del clúster se almacenarán en caché.

¿Qué se puede hacer en tales condiciones para aumentar la velocidad?

Por ejemplo, para evitar serializar la clave en (2), encima de Hazelcast, atornille otra caché para obtener los datos más actuales. En Sportmaster, se eligió cafeína para este propósito.

Para girar en el nivel (6), Hz ofrece dos tipos de almacenamiento: IMap y ReplicatedMap.

Vale la pena decir cómo Hazelcast entró en la pila de tecnología Sportmaster.

En 2012, cuando trabajamos en el primer piloto del futuro sitio, fue Hazelcast el que resultó ser el primer enlace que emitió el motor de búsqueda. El conocido comenzó "la primera vez": nos impresionó el hecho de que solo dos horas después, cuando atornillamos los Hz en el sistema, funcionó. Y funcionó bien. Hasta el final del día agregamos algunas pruebas, nos alegramos. Y este suministro de vigor fue suficiente para superar esas sorpresas que Hz arrojó con el tiempo. Ahora el equipo Sportmaster no tiene motivos para negarse a Hazelcast.

Pero argumentos tales como "el primer enlace en el motor de búsqueda" y "rápidamente ensamblaron HelloWorld", esto, por supuesto, es una excepción y una característica del momento en que tuvo lugar la elección. Estas pruebas para el sistema seleccionado comienzan con el lanzamiento en el producto, y es en esta etapa que debe prestar atención al elegir cualquier sistema, incluido el caché. En realidad, en nuestro caso, podemos decir que elegimos Hazelcast por casualidad, pero luego resultó que elegimos el correcto.

Para la producción, es mucho más importante: monitoreo, fallas de procesamiento en nodos individuales, replicación de datos, costo de escalado. Es decir, vale la pena prestar atención a las tareas que surgirán justo cuando el sistema sea compatible: cuando la carga sea diez veces mayor de lo planeado, cuando accidentalmente llenemos algo en la dirección incorrecta, cuando necesite implementar una nueva versión del código, reemplazar los datos y hacerlo inadvertido para clientes

Para todos estos requisitos, Hazelcast es definitivamente adecuado.

Continuará

Pero Hazelcast no es una panacea. En 2017, elegimos Hazelcast para el caché en el panel de administración, simplemente confiando en la buena impresión de la experiencia pasada. Esto jugó un papel clave en una broma muy malvada, por eso nos encontramos en una situación difícil y "heroicamente" salimos de ella durante 60 días. Pero más sobre eso en la siguiente parte.

Mientras tanto ... ¡Feliz nuevo código!

Cómo en Sportmaster elegimos un sistema de almacenamiento en caché. Parte 1