¡Hola! Mi nombre es Alexey Pyankov, soy desarrollador de la empresa Sportmaster. En eso Le conté cómo comenzó el trabajo en el sitio web de Sportmaster en 2012, qué iniciativas logramos “impulsar” y viceversa, qué comisión recaudamos.
Hoy quiero compartir ideas relacionadas con otro tema: elegir un sistema de almacenamiento en caché para el backend de Java en el área de administración del sitio. Esta trama tiene un significado especial para mí: aunque la historia se desarrolló durante solo 2 meses, durante estos 60 días trabajamos de 12 a 16 horas y sin un solo día libre. Nunca había pensado ni imaginado que fuera posible trabajar tan duro.
Por eso, dividí el texto en 2 partes para no cargarlo por completo. Por el contrario, la primera parte será muy ligera: 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, lo más probable es que no haya nada nuevo en este artículo. Pero para un joven, una reseña tan pequeña puede indicarle en qué dirección mirar si se encuentra en una encrucijada así.
Cuando se puso en producción la nueva versión del sitio web de Sportmaster, los datos se recibieron de una manera que, por decirlo suavemente, no era muy conveniente. La base fueron las tablas preparadas para la versión anterior del sitio (Bitrix), que tuvieron que introducirse en ETL, llevarse a un nuevo formato y enriquecerse con varios detalles de una docena de sistemas más. Para que apareciera una nueva imagen o descripción de producto en el sitio, había que esperar hasta el día siguiente; las actualizaciones solo se realizaban por la noche, una vez al día.
Al principio, hubo tantas preocupaciones durante las primeras semanas de inicio de la producción que tales inconvenientes para los administradores de contenido fueron insignificantes. Pero tan pronto como todo se calmó, el desarrollo del proyecto continuó; después de unos meses, a principios de 2015, comenzamos a desarrollar activamente el panel de administración. En 2015 y 2016, todo va bien, publicamos regularmente, el panel de administración cubre cada vez más la preparación de datos y nos estamos preparando para el hecho de que pronto a nuestro equipo se le confiará lo más importante y complejo: el producto. circuito (preparación completa y mantenimiento de datos de todos los productos). Pero en el verano de 2017, justo antes del lanzamiento del circuito de productos básicos, el proyecto se encontrará en una situación muy difícil, precisamente por problemas con el almacenamiento en caché. Quiero hablar de este episodio en la segunda parte de esta publicación de dos partes.
Pero en esta publicación comenzaré desde lejos, presentaré algunas ideas, ideas sobre el almacenamiento en caché, que serían un buen paso para revisar antes de un proyecto grande.
Cuando ocurre una tarea de almacenamiento en caché
La tarea de almacenamiento en caché no aparece simplemente. Somos desarrolladores, escribimos un producto de software y queremos que tenga demanda. Si el producto tiene demanda y tiene éxito, los usuarios vendrán. Y cada vez vienen más. Y luego hay muchos usuarios y 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, implementar rápidamente un piloto y probar hipótesis. Y si la carga aumenta, bombeamos el hierro. Lo aumentamos dos o tres veces, cinco veces, tal vez 10 veces. En algún lugar de aquí, las finanzas ya no lo permitirán. ¿Cuántas veces aumentará el número de usuarios? No será como 2-5-10, pero si tiene éxito, será de 100-1000 a 100 mil veces. Es decir, tarde o temprano tendrás que hacer una optimización.
Digamos que una parte del código (llamemos función a esta parte) lleva un tiempo indecentemente largo y queremos reducir el tiempo de ejecución. Una función puede ser el acceso a una base de datos o puede ser la ejecución de alguna lógica compleja; lo principal es que lleva mucho tiempo ejecutarla. ¿Cuánto se puede reducir el tiempo de ejecución? En el límite, puedes reducirlo a cero, nada más. ¿Cómo se puede reducir el tiempo de ejecución a cero? Respuesta: eliminar la ejecución por completo. En su lugar, devuelva el resultado inmediatamente. ¿Cómo puedes saber el resultado? Respuesta: o calculalo o busca en alguna parte. Lleva mucho tiempo calcularlo. Y espiar es, por ejemplo, recordar el resultado que produjo la función la última vez cuando se llamó con los mismos parámetros.
Es decir, la implementación de la función no es importante para nosotros. Basta con saber de qué parámetros depende el resultado. Luego, si los valores de los parámetros se representan en forma de un objeto que puede usarse como clave en algún almacenamiento, entonces el resultado del cálculo se puede guardar y leer la próxima vez que se acceda a él. Si esta escritura y lectura del resultado es más rápida que ejecutar la función, tenemos una ganancia en términos de velocidad. La cantidad de beneficio puede llegar a 100, 1000 y 100 mil veces (10^5 es más bien una excepción, pero en el caso de una base bastante rezagada, es bastante posible).
Requisitos básicos para un sistema 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 cierto, pero sólo hasta que implementemos el sistema en producción.
Juguemos este caso.
Digamos que hemos proporcionado hardware a la carga actual y ahora estamos introduciendo gradualmente el almacenamiento en caché. El número de usuarios crece un poco, la carga crece: agregamos algunos cachés, lo atornillamos aquí y allá. Esto continúa durante algún tiempo, y ahora prácticamente ya no se llaman funciones pesadas: toda la carga principal recae en el caché. El número de usuarios durante este tiempo ha aumentado N veces.
Y si el suministro inicial de hardware pudiera ser de 2 a 5 veces mayor, entonces con la ayuda del caché podríamos mejorar el rendimiento en un factor de 10 o, en un buen caso, en un factor de 100, en algunos lugares quizás en un factor de 1000. Es decir, en el mismo hardware, procesamos 100 veces más solicitudes. ¡Genial, te mereces el pan de jengibre!
Pero ahora, en un buen momento, por casualidad, el sistema falló y el caché colapsó. Nada especial: después de todo, el caché se eligió basándose en el requisito de "alta velocidad de lectura y escritura, el resto no importa".
En relación con la carga inicial, nuestra reserva de hierro era de 2 a 5 veces, y la carga durante este tiempo aumentó de 10 a 100 veces. Usando el caché, eliminamos las llamadas a funciones pesadas y, por lo tanto, todo funcionó. Y ahora, sin caché, ¿cuántas veces se ralentizará nuestro sistema? ¿Qué nos pasará? El sistema caerá.
Incluso si nuestro caché no falló, sino que solo se borró por un tiempo, será necesario calentarlo, y esto llevará algún tiempo. Y durante este tiempo, la carga principal recaerá en la funcionalidad.
Conclusión: los proyectos de producción altamente cargados requieren un sistema de almacenamiento en caché no solo para tener altas velocidades de lectura y escritura, sino también para garantizar la seguridad de los datos y la resistencia a fallas.
La agonía de la elección
En un proyecto con un panel de administración, la elección fue la siguiente: primero instalamos Hazelcast, porque Ya estábamos familiarizados con este producto por la experiencia del sitio principal. Pero aquí esta elección resultó infructuosa: según nuestro perfil de carga, Hazelcast no sólo es lento, sino terriblemente lento. Y en ese momento ya nos habíamos apuntado a la fecha de estreno.
Spoiler: cómo se desarrollaron exactamente las circunstancias para que nos perdimos algo tan importante y terminamos en una situación aguda y tensa - les contaré en la segunda parte - y cómo terminamos y cómo salimos. Pero ahora solo diré que fue mucho estrés y "pensar, de alguna manera no puedo pensar, estamos sacudiendo la botella". "Agitar la botella" también es un spoiler, hablaremos de eso más adelante.
Lo que hicimos:
- Hacemos una lista de todos los sistemas que sugieren Google y StackOverflow. un poco mas de 30
- Escribimos pruebas con una carga típica de producción. Para hacer esto, registramos los datos que pasan a través del sistema en un entorno de producción, una especie de rastreador de datos que no está en la red, sino dentro del sistema. Exactamente estos datos se utilizaron en las pruebas.
- Con todo el equipo, todos seleccionan el siguiente sistema de la lista, lo configuran y ejecutan pruebas. No pasa la prueba, no soporta la carga: lo tiramos y pasamos al siguiente de la fila.
- En el sistema 17 quedó claro que todo era inútil. Deja de agitar la botella, es hora de pensar seriamente.
Pero esta es una opción cuando necesita elegir un sistema que "supere la velocidad" en pruebas preparadas previamente. ¿Qué pasa si todavía no existen pruebas de este tipo y desea elegir rápidamente?
Modelemos esta opción (es difícil imaginar que un desarrollador intermedio+ viva en el vacío y en el momento de la selección aún no haya formalizado su preferencia sobre qué producto probar primero; por lo tanto, el razonamiento adicional es más teórico/filosófico/ sobre un junior).
Una vez que hayamos decidido los requisitos, comencemos a elegir una solución lista para usar. Por qué reinventar la rueda: tomaremos un sistema de almacenamiento en caché ya preparado.
Si recién estás comenzando y lo buscas en Google, entonces toma o da la orden, pero en general, las pautas serán así. En primer lugar, te encontrarás con Redis, se escucha en todas partes. Entonces descubrirá que EhCache es el sistema más antiguo y probado. A continuación escribiremos sobre Tarantool, un desarrollo nacional que tiene un aspecto único de solución. Y también Ignite, porque ahora está ganando popularidad y cuenta con el apoyo de SberTech. Al final también está Hazelcast, porque en el mundo empresarial suele aparecer entre las grandes empresas.
La lista no es exhaustiva; hay docenas de sistemas. Y sólo joderemos una cosa. Tomemos los 5 sistemas seleccionados para el “concurso de belleza” y hagamos una selección. Quién será el ganador.
Redis
Leemos lo que escriben en el sitio web oficial.
- proyecto de código abierto. Ofrece almacenamiento de datos en memoria, la capacidad de guardar en disco, partición automática, alta disponibilidad y recuperación ante interrupciones de la red.
Parece que todo está bien, puedes cogerlo y atornillarlo: todo lo que necesitas, lo hace. Pero sólo por diversión, veamos a los otros candidatos.
Ehcaché
- “el caché más utilizado para Java” (traducción del eslogan del sitio web oficial). También de código abierto. Y luego entendemos que Redis no es para Java, sino en general, y para interactuar con él se necesita un contenedor. Y EhCache será más conveniente. ¿Qué más promete el sistema? Fiabilidad, funcionalidad probada y completa. Pues también es el más común. Y almacena en caché terabytes de datos.
Se olvidó Redis, estoy listo para elegir EhCache.
Pero un sentimiento de patriotismo me empuja a ver qué tiene de bueno Tarantool.
tarantool
- cumple con la designación “Plataforma de integración de datos en tiempo real”. Suena muy complicado, así que leemos la página en detalle y encontramos una declaración fuerte: "Almacena en caché el 100% de los datos en la RAM". Esto debería plantear dudas; después de todo, puede haber muchos más datos que memoria. La explicación es que significa que Tarantool no ejecuta la serialización para escribir datos en el disco desde la memoria. En cambio, utiliza 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, hicieron algo maravilloso y genial.
Veamos las implementaciones: Mail.ru Corporate Highway, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Si aún quedaban dudas sobre Tarantool, entonces el caso de implementación en Mastercard me remata. Tomo Tarantool.
Pero de todos modos…
Encender
... ¿hay algo más? , se anuncia como una “plataforma informática en memoria... velocidades en memoria en petabytes de datos”. Aquí también hay muchas ventajas: caché en memoria distribuida, el almacenamiento y caché de valores clave más rápidos, escalamiento horizontal, alta disponibilidad e integridad estricta. En general, resulta que el más rápido es Ignite.
Implementaciones: Sberbank, American Airlines, Yahoo! Japón. Y luego descubrí que Ignite no solo se implementa en Sberbank, sino que el equipo de SberTech envía a su gente al propio equipo de Ignite para perfeccionar el producto. Esto es completamente cautivador y estoy listo para tomar Ignite.
No está del todo claro por qué, estoy mirando el quinto punto.
Hazelcast
voy al sitio , lectura. Y resulta que la solución más rápida para el almacenamiento en caché distribuido es Hazelcast. Es mucho 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, tomar otra cosa es no respetarse a uno mismo. También utiliza almacenamiento de datos redundante para el funcionamiento continuo del clúster sin pérdida de datos.
Eso es todo, estoy listo para tomar Hazelcast.
Comparación
Pero si nos fijamos, los cinco candidatos están descritos de tal manera 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 desaparecerá.
encontramos uno como este , elige nuestros 5 sistemas.
Aquí están ordenados: Redis está en la cima, Hazelcast está en segundo lugar, Tarantool e Ignite están ganando popularidad, EhCache ha sido y sigue siendo el mismo.
Pero miremos : enlaces a sitios web, interés general en el sistema, ofertas de trabajo - ¡genial! Es decir, cuando mi sistema falla, diré: “¡No, es confiable! Hay muchas ofertas de trabajo..." Una comparación tan simple no sirve.
Todos estos sistemas no son sólo sistemas de almacenamiento en caché. También tienen muchas funciones, incluso cuando los datos no se envían al cliente para su procesamiento, sino viceversa: el código que debe ejecutarse en los datos se mueve al servidor, se ejecuta allí y se devuelve el resultado. Y no se los suele considerar como un sistema de almacenamiento en caché independiente.
Bien, no nos rindamos, busquemos una comparación directa de los sistemas. Tomemos las dos opciones principales: Redis y Hazelcast. Nos interesa la velocidad y los compararemos en función de este parámetro.
Hz frente a Redis
Encontramos esto :
El azul es Redis, el rojo es Hazelcast. Hazelcast gana en todas partes y hay una razón para ello: es multiproceso, está 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 modernas CPU multinúcleo. Hazelcast tiene E/S asíncronas, Redis-Jedis tiene sockets de bloqueo. Después de todo, Hazelcast usa un protocolo binario y Redis se centra en texto, lo que significa que es ineficiente.
Por si acaso, recurramos a otra fuente de comparación. ¿Qué nos mostrará?
Redis frente a Hz
otro :
Aquí, por el contrario, el rojo es Redis. Es decir, Redis supera a Hazelcast en términos de rendimiento. Hazelcast ganó la primera comparación y Redis ganó la segunda. explicó con mucha precisión por qué Hazelcast ganó la comparación anterior.
Resulta que el resultado del primero en realidad estaba manipulado: Redis se tomó en la caja base y Hazelcast se diseñó para un caso de prueba. Luego resulta: en primer lugar, no podemos confiar en nadie y, en segundo lugar, cuando finalmente elegimos un sistema, todavía tenemos que configurarlo correctamente. Estas configuraciones incluyen docenas, casi cientos de parámetros.
agitando la botella
Y puedo explicar todo el proceso que hemos hecho ahora con la siguiente metáfora: “Agitando la botella”. Es decir, ahora no hace falta programar, ahora lo principal es poder leer stackoverflow. Y en mi equipo tengo una persona, un profesional, que trabaja exactamente así en los momentos críticos.
¿Qué está haciendo? Ve algo roto, ve un rastro de pila, extrae algunas palabras (cuáles son su experiencia en el programa), busca en Google y encuentra stackoverflow entre las respuestas. Sin leer, sin pensar, entre las respuestas a la pregunta, elige algo muy parecido a la frase "haz esto y aquello" (elegir esa respuesta es su talento, porque no siempre es la respuesta que recibió más me gusta), aplica, mira: si algo ha cambiado, entonces genial. Si no ha cambiado, retroceda. Y repita iniciar-comprobar-búsqueda. Y de esta manera intuitiva, se asegura de que el código funcione después de un tiempo. No sabe por qué, no sabe qué hizo, no puede explicarlo. ¡Pero! Esta infección funciona. Y “el fuego se apaga”. Ahora averigüemos qué hicimos. Cuando el programa funciona, es mucho más fácil. Y ahorra mucho tiempo.
Este método está muy bien explicado con este ejemplo.
Alguna vez fue muy popular coleccionar un velero en una botella. Al mismo tiempo, el velero es grande y frágil, y el cuello de la botella es muy estrecho, es imposible empujarlo hacia adentro. ¿Cómo montarlo?
Existe un método así, muy rápido y muy eficaz.
El barco se compone de un montón de cositas: palos, cuerdas, velas, pegamento. Ponemos todo esto en una botella.
Cogemos la botella con ambas manos y empezamos a agitar. La sacudimos y la sacudimos. Y normalmente resulta ser una completa basura, por supuesto. Pero a veces. ¡A veces resulta ser un barco! Más precisamente, algo parecido a un barco.
Le mostramos algo a alguien: "Seryoga, ¿¡ves!?" Y efectivamente, desde lejos parece un barco. Pero no se puede permitir que esto continúe.
Hay otra manera. Los utilizan personas más avanzadas, como los piratas informáticos.
Le di una tarea a este tipo, hizo todo y se fue. Y miras, parece que está hecho. Y después de un tiempo, cuando es necesario finalizar el código, esto comienza gracias a él... Es bueno que ya haya logrado huir muy lejos. Estos son los chicos que, usando el ejemplo de una botella, harán esto: ves, donde está el fondo, el vaso se dobla. Y no está del todo claro si es transparente o no. Luego los "hackers" cortan este fondo, insertan un barco allí, luego vuelven a pegar el fondo, y es como si así fuera.
Desde el punto de vista del planteamiento del problema, todo parece correcto. Pero usando los barcos como ejemplo: ¿por qué construir este barco? ¿Quién lo necesita? No proporciona ninguna funcionalidad. Por lo general, estos barcos son regalos para personas de muy alto rango, quienes los colocan en un estante encima de ellos, como una especie de símbolo, como una señal. Y si se trata de una persona así, el jefe de una gran empresa o un funcionario de alto rango, ¿cómo representará la bandera un pirata al que le han cortado el cuello? Sería mejor si nunca se enterara. Entonces, ¿cómo terminan fabricando estos barcos que se pueden regalar a una persona importante?
El único lugar clave sobre el que realmente no puedes hacer nada es el cuerpo. Y el casco del barco encaja perfectamente en el cuello. Mientras que el barco se ensambla fuera de la botella. Pero no se trata sólo de montar un barco, es un auténtico arte de joyería. Se añaden palancas especiales a los componentes, que luego permiten levantarlos. Por ejemplo, las velas se pliegan, se introducen con cuidado en el interior y luego, con la ayuda de unas pinzas, se tiran y se levantan con mucha precisión. El resultado es una obra de arte que se puede regalar con la conciencia tranquila y con orgullo.
Y si queremos que el proyecto tenga éxito, debe haber al menos un joyero en el equipo. Alguien que se preocupa por la calidad del producto y tiene en cuenta todos los aspectos, sin sacrificar nada, incluso en momentos de estrés, cuando las circunstancias exigen hacer lo urgente en detrimento de lo importante. Todos los proyectos exitosos que sean sostenibles y que hayan resistido la prueba del tiempo se basan en este principio. Hay algo muy preciso y único en ellos, algo que aprovecha todas las posibilidades disponibles. En el ejemplo del barco en una botella, se juega con el hecho de que el casco del barco pasa por el cuello.
Volviendo a la tarea de elegir nuestro servidor de caché, ¿cómo se podría aplicar este método? Ofrezco esta opción de elegir entre todos los sistemas que existen: no agite la botella, no elija, pero mire lo que tienen en principio, qué buscar al elegir un sistema.
Dónde buscar cuellos de botella
Intentemos no agitar la botella, no repasar todo lo que hay allí uno por uno, pero veamos qué problemas surgirán si de repente, para nuestra tarea, diseñamos nosotros mismos un sistema de este tipo. Por supuesto, no ensamblaremos la bicicleta, pero usaremos este diagrama para ayudarnos a determinar a qué puntos prestar atención en las descripciones de los productos. Esbocemos dicho diagrama.
Si el sistema es distribuido, entonces tendremos varios servidores (6). Digamos que son cuatro (es conveniente colocarlos en la imagen, pero, por supuesto, puede haber tantos como quieras). Si los servidores están en nodos diferentes, significa que todos ejecutan algún código que se encarga de garantizar que estos nodos formen un clúster y, en caso de interrupción, se conecten y se reconozcan entre sí.
También necesitamos la lógica del código (2), que en realidad trata sobre el 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 o acceder a él a través de la red. La lógica implementada internamente es la decisión de qué objetos dejar en el caché y cuáles descartar. Usamos la memoria (3) para almacenar el caché, pero si es necesario, podemos guardar algunos de los datos en el disco (4).
Veamos en qué partes se producirá la carga. En realidad, se cargarán cada flecha y cada nodo. En primer lugar, entre el código del cliente y la API, si se trata de comunicación de red, el hundimiento puede ser bastante notable. En segundo lugar, dentro del marco de la propia API: si nos excedemos con una lógica compleja, podemos tener problemas con la CPU. Y sería bueno si la lógica no perdiera el tiempo con la memoria. Y queda la interacción con el sistema de archivos; en la versión habitual, esto es serializar/restaurar y escribir/leer.
Lo siguiente es la interacción con el clúster. Lo más probable es que esté en el mismo sistema, pero podría estar por separado. Aquí también es necesario tener en cuenta la transferencia de datos, la velocidad de serialización de datos y las interacciones 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 tomar una decisión más o menos sensata: elegir un sistema para nuestro caso de uso.
Hazelcast
Veamos cómo aplicar esta descomposición a nuestra lista. Por ejemplo, Hazelcast.
Para poner/tomar datos de Hazelcast, el código del cliente accede a (1) la api. Hz le permite ejecutar el servidor integrado y, en este caso, acceder a la API es una llamada a un método dentro de la JVM, que puede considerarse gratuita.
Para que funcione la lógica en (2), Hz se basa en el hash de la matriz de bytes de la clave serializada; es decir, la clave se serializará en cualquier caso. Esto es una sobrecarga inevitable para Hz.
Las estrategias de desalojo se implementan bien, pero para casos especiales puedes agregar las tuyas propias. No tienes que preocuparte por esta parte.
Se puede conectar el almacenamiento (4). Excelente. La interacción (5) para incrustados puede considerarse instantánea. Intercambio de datos entre nodos del clúster (6): sí, existe. Se trata de una inversión en tolerancia a fallos a expensas de la velocidad. La función Hz Near-cache le 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 la serialización de la clave en (2), adjunte otro caché encima de Hazelcast para obtener los datos más recientes. Sportmaster eligió Caffeine para este fin.
Para girar en el nivel (6), Hz ofrece dos tipos de almacenamiento: IMap y ReplicatedMap.
Vale la pena mencionar cómo Hazelcast entró en la pila de tecnología de Sportmaster.
En 2012, cuando estábamos trabajando en el primer piloto del futuro sitio, fue Hazelcast el que resultó ser el primer enlace que arrojó el motor de búsqueda. La relación comenzó "por primera vez": nos cautivó el hecho de que apenas dos horas después, cuando atornillamos Hz al sistema, funcionó. Y funcionó bien. Al final del día habíamos completado una serie de pruebas y estábamos contentos. Y esta reserva de vigor fue suficiente para superar las sorpresas que Hz deparó con el tiempo. Ahora el equipo Sportmaster no tiene motivos para abandonar Hazelcast.
Pero argumentos como “el primer enlace en el motor de búsqueda” y “HelloWorld se creó rápidamente” son, por supuesto, una excepción y una característica del momento en que se realizó la elección. Las pruebas reales del sistema elegido comienzan con el lanzamiento a producción, y es en esta etapa donde se debe prestar atención a la hora de elegir cualquier sistema, incluido el caché. En realidad, en nuestro caso podemos decir que elegimos Hazelcast por accidente, pero luego resultó que elegimos correctamente.
Para la producción, es mucho más importante: monitoreo, manejo de fallas en nodos individuales, replicación de datos, costo de escalado. Es decir, vale la pena prestar atención a las tareas que surgirán durante el mantenimiento del sistema: cuando la carga es diez veces mayor de lo planeado, cuando accidentalmente cargamos algo en el lugar equivocado, cuando necesitamos implementar una nueva versión. del código, reemplazar datos y hacerlo desapercibido para los clientes.
Para todos estos requisitos, Hazelcast ciertamente cumple con los requisitos.
Continuará
Pero Hazelcast no es una panacea. En 2017, elegimos Hazelcast para el caché de administración, simplemente por las buenas impresiones de experiencias pasadas. Esto jugó un papel clave en una broma muy cruel, por lo que nos encontramos en una situación difícil y salimos de ella "heroicamente" durante 60 días. Pero hablaremos más de eso en la siguiente parte.
Mientras tanto... ¡Feliz Código Nuevo!
Fuente: habr.com