{"id":73949,"date":"2020-03-13T02:42:07","date_gmt":"2020-03-12T23:42:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1"},"modified":"2020-03-13T02:42:07","modified_gmt":"2020-03-12T23:42:07","slug":"kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","title":{"rendered":"C\u00f3mo elegimos el sistema de cach\u00e9 en Sportmaster. Parte 1","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\u00a1Hola! Me llamo Alexey Pyankov, soy desarrollador en la empresa Sportmaster. En este el post<\/a><\/noindex> relato, cont\u00e9 c\u00f3mo comenz\u00f3 el trabajo en el sitio de Sportmaster en 2012, qu\u00e9 iniciativas logramos \"empujar\" y, por el contrario, qu\u00e9 obst\u00e1culos encontramos.<\/p>\n

Hoy quiero compartir mis pensamientos sobre otro tema: la elecci\u00f3n del sistema de cach\u00e9 para el backend de Java en el panel de administraci\u00f3n del sitio. Este tema tiene un significado especial para m\u00ed; aunque la historia se desarroll\u00f3 en solo 2 meses, durante esos 60 d\u00edas trabajamos entre 12 y 16 horas al d\u00eda sin un solo d\u00eda de descanso. Nunca antes hab\u00eda pensado ni imaginado que se pod\u00eda trabajar tanto.<\/p>\n

Por lo tanto, dividir\u00e9 el texto en 2 partes para no sobrecargarlo por completo. De hecho, la primera parte ser\u00e1 muy ligera: una preparaci\u00f3n, una introducci\u00f3n y algunas reflexiones sobre qu\u00e9 es la cach\u00e9. Si ya eres un desarrollador experimentado o has trabajado con cach\u00e9s, desde el punto de vista t\u00e9cnico, probablemente no encontrar\u00e1s nada nuevo en este art\u00edculo. Pero para un junior, una peque\u00f1a revisi\u00f3n puede indicar en qu\u00e9 direcci\u00f3n mirar si se encuentra en tal encrucijada.<\/p>\n

\"C\u00f3mo<\/a><\/noindex>
\n<\/a><\/noindex>
\nCuando se lanz\u00f3 la nueva versi\u00f3n del sitio de Sportmaster en producci\u00f3n, los datos llegaban de una manera, por decirlo suavemente, no muy conveniente. La base eran tablas preparadas para la versi\u00f3n anterior del sitio (Bitrix), que deb\u00edan ser extra\u00eddas en ETL, transformadas a una nueva forma y enriquecidas con diferentes detalles de otras diez sistemas. Para que una nueva imagen o descripci\u00f3n del producto apareciera en el sitio, hab\u00eda que esperar hasta el d\u00eda siguiente: la actualizaci\u00f3n solo se realizaba por la noche, una vez al d\u00eda.<\/p>\n

Al principio hab\u00eda tantas preocupaciones durante las primeras semanas de lanzamiento que estas incomodidades para los gestores de contenido eran una trivialidad. Pero, tan pronto como todo se estabiliz\u00f3, el desarrollo del proyecto continu\u00f3: unos meses despu\u00e9s, a comienzos de 2015, comenzamos a desarrollar activamente el panel de administraci\u00f3n. En 2015 y 2016 todo iba bien, publicamos con regularidad, el panel de administraci\u00f3n abarcaba una parte cada vez mayor de la preparaci\u00f3n de datos y nos est\u00e1bamos preparando para que pronto se confiara a nuestro equipo lo m\u00e1s importante y complicado: el contorno de productos (preparaci\u00f3n completa y manejo de datos de todos los productos). Pero en el verano de 2017, justo antes del lanzamiento del contorno de productos, el proyecto se encontrar\u00eda en una situaci\u00f3n muy complicada, precisamente debido a problemas con la cach\u00e9. Sobre este episodio quiero hablar en la segunda parte de esta publicaci\u00f3n de dos partes.<\/p>\n

Pero en este post empezar\u00e9 desde lejos, reunir\u00e9 algunas ideas \u2014 consideraciones sobre la cach\u00e9, revisar las cuales antes de un gran proyecto ser\u00eda un buen paso.<\/p>\n

Cuando surge la tarea de caching<\/h2>\n

\nLa tarea de caching no aparece sin motivo. Somos desarrolladores, escribimos un producto de software y queremos que sea demandado. Si el producto tiene demanda y es exitoso, los usuarios llegan. Y llegan m\u00e1s y m\u00e1s. Y as\u00ed, hay muchos usuarios, y el producto se vuelve muy cargado.<\/p>\n

En las primeras etapas no pensamos en la optimizaci\u00f3n y el rendimiento del c\u00f3digo. Lo principal es la funcionalidad, lanzar r\u00e1pidamente un piloto y verificar las hip\u00f3tesis. Y si la carga aumenta, mejoramos el hardware. Incrementamos entre dos y tres veces, cinco, incluso diez veces. En alg\u00fan momento, las finanzas no lo permitir\u00e1n. \u00bfY cu\u00e1ntos usuarios m\u00e1s habr\u00e1? No ser\u00e1n solo 2-5-10, sino que en caso de \u00e9xito, ser\u00e1 de 100-1000 hasta 100,000 veces m\u00e1s. Es decir, tarde o temprano, tendremos que abordar la optimizaci\u00f3n.<\/p>\n

Supongamos que una parte del c\u00f3digo (llamemos a esta parte una funci\u00f3n) funciona indebidamente lento y queremos reducir el tiempo de ejecuci\u00f3n. La funci\u00f3n puede ser el acceso a una base de datos o la ejecuci\u00f3n de alguna l\u00f3gica compleja; lo importante es que se tarda mucho. \u00bfCu\u00e1nto se puede reducir el tiempo de ejecuci\u00f3n? En teor\u00eda, se puede reducir hasta cero, no m\u00e1s all\u00e1. \u00bfY c\u00f3mo se puede reducir el tiempo de ejecuci\u00f3n a cero? Respuesta: simplemente evitar la ejecuci\u00f3n. En vez de eso, devolver el resultado de inmediato. \u00bfY c\u00f3mo se sabe el resultado? Respuesta: se puede calcular o mirarlo en alg\u00fan lado. Calcular lleva tiempo. Y mirar, por ejemplo, es recordar el resultado que la funci\u00f3n devolvi\u00f3 la \u00faltima vez que fue llamada con los mismos par\u00e1metros.<\/p>\n

Es decir, la implementaci\u00f3n de la funci\u00f3n no nos importa. Solo necesitamos saber de qu\u00e9 par\u00e1metros depende el resultado. Entonces, si representamos los valores de los par\u00e1metros como un objeto que se puede usar como clave en un cierto almac\u00e9n, podemos guardar el resultado del c\u00e1lculo y, en el pr\u00f3ximo acceso, recuperarlo. Si estas operaciones de guardar y recuperar el resultado son m\u00e1s r\u00e1pidas que la ejecuci\u00f3n de la funci\u00f3n, tendremos una mejora en la velocidad. La magnitud de la mejora puede alcanzar hasta 100, 1000 o incluso 100,000 veces (10^5 es m\u00e1s bien una excepci\u00f3n, pero en caso de una base de datos bastante lenta, es bastante posible).<\/p>\n

Requisitos b\u00e1sicos para el sistema de cach\u00e9<\/h2>\n

\nLo primero que puede ser un requisito para el sistema de cach\u00e9 es una r\u00e1pida velocidad de lectura y, en un grado ligeramente menor, velocidad de escritura. Esto es cierto, pero solo hasta que implementemos el sistema en producci\u00f3n.<\/p>\n

Presentemos un caso.<\/p>\n

Supongamos que hemos proporcionado el hardware para la carga actual y ahora estamos implementando gradualmente el cach\u00e9. El n\u00famero de usuarios aumenta un poco, la carga crece - a\u00f1adimos un poco de cach\u00e9, implementamos aqu\u00ed y all\u00e1. Esto contin\u00faa durante un tiempo, y ya las funciones pesadas casi no se llaman; toda la carga principal recae en el cach\u00e9. El n\u00famero de usuarios ha crecido en N veces durante este tiempo.<\/p>\n

Y si la reserva inicial de hardware pod\u00eda ser de 2 a 5 veces, con la ayuda del cach\u00e9 podr\u00edamos aumentar el rendimiento hasta 10 veces o, en el mejor de los casos, 100 veces, y, en ocasiones, incluso 1000 veces. Es decir, en el mismo hardware tratamos 100 veces m\u00e1s solicitudes. Genial, \u00a1merecemos un premio!<\/p>\n

Pero ahora, en un buen momento, accidentalmente, el sistema fall\u00f3 y el cach\u00e9 colaps\u00f3. Nada especial, ya que el cach\u00e9 fue elegido bajo la exigencia de 'alta velocidad de lectura y escritura, lo dem\u00e1s no importa'.<\/p>\n

En relaci\u00f3n con la carga inicial, la reserva de hardware que ten\u00edamos era de 2 a 5 veces, mientras que la carga ha aumentado entre 10 y 100 veces. Con la ayuda del cach\u00e9, hab\u00edamos evitado las llamadas a funciones pesadas y, por lo tanto, todo funcionaba sin problemas. Ahora, sin el cach\u00e9, \u00bfcu\u00e1ntas veces caer\u00e1 nuestro sistema? \u00bfQu\u00e9 nos suceder\u00e1? El sistema colapsar\u00e1.<\/p>\n

Incluso si nuestro cach\u00e9 no colaps\u00f3, sino que solo se limpi\u00f3 por un tiempo, necesitar\u00e1 ser calentado, y esto tomar\u00e1 un tiempo. Y durante ese tiempo, la carga principal recaer\u00e1 en la funcionalidad.<\/p>\n

Conclusi\u00f3n: los proyectos de alta carga en producci\u00f3n requieren del sistema de cach\u00e9 no solo alta velocidad de lectura y escritura, sino tambi\u00e9n integridad de datos y resistencia a fallos.<\/p>\n

Los tormentos de la elecci\u00f3n<\/h2>\n

\nEn el proyecto con panel de administraci\u00f3n, la elecci\u00f3n fue la siguiente: primero instalamos Hazelcast, ya que ten\u00edamos experiencia con este producto del sitio principal. Sin embargo, esta elecci\u00f3n result\u00f3 ser inadecuada: bajo nuestro perfil de carga, Hazelcast no solo funciona lentamente, sino incre\u00edblemente lento. Y en cuanto a los plazos de producci\u00f3n, ya est\u00e1bamos comprometidos en ese momento.<\/p>\n

Spoiler: c\u00f3mo se desarrollaron las circunstancias que nos hicieron pasar por esta dificultad y c\u00f3mo nos encontramos en una situaci\u00f3n tensa y complicada - lo contar\u00e9 en la segunda parte, y c\u00f3mo llegamos a ello y c\u00f3mo salimos. Pero por ahora, solo dir\u00e9 que fue un gran estr\u00e9s, y 'pensar - de alguna manera no se puede pensar, agitamos la botella'. 'Agitamos la botella' - esto es tambi\u00e9n un spoiler, sobre esto un poco m\u00e1s adelante.<\/p>\n

Lo que hicimos:<\/p>\n

    \n
  1. Hicimos una lista de todos los sistemas que sugiere Google y StackOverflow. Un poco m\u00e1s de 30.<\/li>\n
  2. Escribimos pruebas con la carga caracter\u00edstica de producci\u00f3n. Para ello, registramos los datos que pasan a trav\u00e9s del sistema en el entorno de producci\u00f3n, una especie de sniffer para datos no en red, pero dentro del sistema. En las pruebas, usamos exactamente esos datos.<\/li>\n
  3. Todo el equipo, cada uno elige el siguiente sistema de la lista, lo configura y ejecuta las pruebas. Si la prueba no pasa, no soporta la carga, lo descartamos y pasamos al siguiente en la lista.<\/li>\n
  4. En el sistema 17, qued\u00f3 claro que todo estaba m\u00e1s que perdido. Ya basta de 'agitar la botella', es hora de pensar seriamente.<\/li>\n<\/ol>\n

    \nPero esta es una opci\u00f3n cuando se necesita elegir un sistema que 'pase por velocidad' en pruebas previamente realizadas. \u00bfY si no hay tales pruebas y queremos elegir m\u00e1s r\u00e1pido?<\/p>\n

    Simulemos tal opci\u00f3n (es dif\u00edcil imaginar que un desarrollador medio o avanzado vive en el vac\u00edo, y en el momento de la elecci\u00f3n a\u00fan no ha definido su preferencia sobre qu\u00e9 producto probar primero - por lo tanto, las reflexiones posteriores son m\u00e1s bien te\u00f3ricas\/filos\u00f3ficas\/sobre juniors).<\/p>\n

    Una vez definidos los requisitos, comenzaremos a elegir una soluci\u00f3n lista para usar. \u00bfPara qu\u00e9 inventar la rueda? Iremos y tomaremos un sistema de cach\u00e9 existente.<\/p>\n

    Si reci\u00e9n est\u00e1s comenzando y vas a buscar en Google, la secuencia m\u00e1s o menos es la siguiente, pero en general, los puntos de referencia ser\u00e1n as\u00ed. Primero te encontrar\u00e1s con Redis, que est\u00e1 muy en boga. Luego descubrir\u00e1s que existe EhCache, el sistema m\u00e1s antiguo y probado. Despu\u00e9s, se mencionar\u00e1 Tarantool, un desarrollo nacional que tiene un aspecto \u00fanico en su soluci\u00f3n. Y tambi\u00e9n Ignite, que est\u00e1 en auge y cuenta con el apoyo de SberTech. Al final, tambi\u00e9n se mencionar\u00e1 Hazelcast, pues a menudo aparece en el mundo empresarial en grandes compa\u00f1\u00edas.<\/p>\n

    Este listado no es exhaustivo, existen decenas de sistemas. Pero solo analizaremos uno. Tomaremos cinco sistemas seleccionados para un 'concurso de belleza' y realizaremos una selecci\u00f3n. \u00bfQui\u00e9n ser\u00e1 el ganador?<\/p>\n

    Redis<\/h3>\n

    \nLeemos lo que dicen en el sitio oficial.
    \n    Redis<\/a><\/noindex> \u2014 proyecto de c\u00f3digo abierto. Ofrece almacenamiento de datos en memoria, la posibilidad de guardado en disco, particionado autom\u00e1tico, alta disponibilidad y recuperaci\u00f3n tras cortes de red.<\/p>\n

    Parece que todo est\u00e1 excelente, se puede usar y conectar; hace todo lo necesario. Pero veamos, solo por curiosidad, a los dem\u00e1s candidatos.<\/p>\n

    EhCache<\/h3>\n

    \nEhCache<\/a><\/noindex> \u2014 'el cach\u00e9 m\u00e1s utilizado para Java' (traducci\u00f3n del eslogan del sitio oficial). Tambi\u00e9n es de c\u00f3digo abierto. Y aqu\u00ed entendemos que Redis no es para Java, es universal, y para interactuar con \u00e9l se necesita un wrapper. EhCache resulta ser m\u00e1s conveniente. \u00bfQu\u00e9 m\u00e1s promete el sistema? Fiabilidad, validaci\u00f3n, funcionalidad completa. Y adem\u00e1s, es el m\u00e1s difundido. Y cachea teras de datos.<\/p>\n

    Olvid\u00e9 Redis, estoy listo para elegir EhCache.<\/p>\n

    Pero un sentimiento de patriotismo me empuja a ver qu\u00e9 tiene de bueno Tarantool.<\/p>\n

    Tarantool<\/h3>\n

    \nTarantool<\/a><\/noindex> \u2014 se presenta como 'Plataforma de integraci\u00f3n de datos en tiempo real'. Suena muy complicado, por lo que leemos la p\u00e1gina detenidamente y encontramos una declaraci\u00f3n llamativa: 'Cachea el 100% de los datos en memoria'. Esto deber\u00eda generar preguntas, ya que los datos pueden ser significativamente m\u00e1s que la memoria. La aclaraci\u00f3n es que aqu\u00ed se entiende que, para escribir datos en disco desde la memoria, Tarantool no utiliza serializaci\u00f3n. En su lugar, hace uso de caracter\u00edsticas de bajo nivel del sistema, donde la memoria se mapea simplemente en el sistema de archivos con muy buenos \u00edndices de I\/O. En general, lo han hecho de manera bastante notable y genial.<\/p>\n

    Veamos las implementaciones: Mail.ru, la autor\u00eda corporativa, Avito, Beeline, Megafon, Alfa-Banco, Gazprom\u2026<\/p>\n

    Si a\u00fan quedaban dudas sobre Tarantool, el caso de implementaci\u00f3n en Mastercard me convence. Elijo Tarantool.<\/p>\n

    Pero a\u00fan as\u00ed...<\/p>\n

    Ignite<\/h3>\n

    \n... hay m\u00e1s Ignite<\/a><\/noindex>, declarado como \"plataforma de computaci\u00f3n in-memory... velocidades in-memory en petabytes de datos\". Aqu\u00ed tambi\u00e9n hay muchas ventajas: cach\u00e9 in-memory distribuido, el almacenamiento y cach\u00e9 key-value m\u00e1s r\u00e1pido, escalabilidad horizontal, alta disponibilidad, estricta integridad. En resumen, resulta que el m\u00e1s r\u00e1pido es Ignite.<\/p>\n

    Implementaciones: Sberbank, American Airlines, Yahoo! Japan. Y luego descubro que Ignite no solo est\u00e1 implementado en Sberbank, sino que el equipo de SberTech env\u00eda a sus personas al equipo de Ignite para mejorar el producto. Esto me convence completamente y estoy listo para elegir Ignite.<\/p>\n

    Es completamente incomprensible por qu\u00e9, miro el quinto punto.<\/p>\n

    Hazelcast<\/h3>\n

    \nEntro en el sitio web Hazelcast<\/a><\/noindex>, lo leo. Y resulta que la soluci\u00f3n m\u00e1s r\u00e1pida para el almacenamiento en cach\u00e9 distribuido es Hazelcast. Es \u00f3rdenes de magnitud m\u00e1s r\u00e1pido que cualquier otra soluci\u00f3n y, en general, es el l\u00edder en el campo de grids de datos in-memory. En comparaci\u00f3n con esto, elegir otra cosa ser\u00eda no respetarse a uno mismo. Adem\u00e1s, utiliza almacenamiento redundante para mantener el funcionamiento continuo del cl\u00faster sin p\u00e9rdida de datos.<\/p>\n

    Eso es, estoy listo para elegir Hazelcast.<\/p>\n

    Comparaci\u00f3n<\/h2>\n

    \nPero si miramos, los cinco candidatos est\u00e1n descritos de tal manera que cada uno de ellos es el mejor. \u00bfC\u00f3mo elegir? Podemos ver cu\u00e1l es el m\u00e1s popular, buscar comparativas, y el dolor de cabeza se desvanecer\u00e1.<\/p>\n

    Encontramos uno as\u00ed resumen<\/a><\/noindex>, elegimos nuestros 5 sistemas.<\/p>\n

    \"C\u00f3mo
    \n
    \nAqu\u00ed est\u00e1n ordenados: en la parte superior Redis, en segundo lugar \u2014 Hazelcast, Tarantool e Ignite ganan popularidad, EhCache se mantiene igual. <\/p>\n

    Pero echemos un vistazo a el m\u00e9todo de c\u00e1lculo<\/a><\/noindex>: enlaces a sitios web, inter\u00e9s general en el sistema, ofertas de trabajo \u2014 \u00a1genial! Es decir, cuando mi sistema se caiga, dir\u00e9: \"No, \u00a1es confiable! \u00a1Mira cu\u00e1ntas ofertas de trabajo hay...\". Esa comparaci\u00f3n tan sencilla no servir\u00e1.<\/p>\n

    Todos estos sistemas no son solo sistemas para almacenamiento en cach\u00e9. Tambi\u00e9n tienen muchas m\u00e1s funcionalidades, incluyendo \u2013 cuando no son los datos los que se transfieren al cliente para su procesamiento, sino al contrario: el c\u00f3digo que necesita ejecutarse sobre los datos se traslada al servidor, se ejecuta all\u00ed, y se devuelve el resultado. Y como un sistema separado para almacenamiento en cach\u00e9, no se consideran tan a menudo.<\/p>\n

    Est\u00e1 bien, no nos rendimos, buscaremos una comparaci\u00f3n directa entre sistemas. Tomemos las dos mejores opciones \u2014 Redis y Hazelcast. Nos interesa la velocidad, y compararemos seg\u00fan ese par\u00e1metro.<\/p>\n

    Hz vs Redis<\/h3>\n

    \nEncontramos uno as\u00ed comparaci\u00f3n<\/a><\/noindex>:
    \n\"C\u00f3mo
    \n
    \nEl azul es Redis, el rojo es Hazelcast. Hazelcast gana en todas partes, y esto se justifica: es multihilo, altamente optimizado, cada hilo trabaja con su propia partici\u00f3n, por lo que no hay bloqueos. En cambio, Redis es de un solo hilo y no aprovecha la ventaja de las CPU modernas multin\u00facleo. Hazelcast utiliza E\/S as\u00edncrona, mientras que Redis-Jedis utiliza sockets bloqueantes. Al final, Hazelcast usa un protocolo binario, mientras que Redis est\u00e1 orientado a texto, lo que significa que es ineficiente.<\/p>\n

    Por si acaso, consultemos otra fuente de comparaci\u00f3n. \u00bfQu\u00e9 nos mostrar\u00e1?<\/p>\n

    Redis vs Hz<\/h3>\n

    \nOtra cosa m\u00e1s comparaci\u00f3n<\/a><\/noindex>:
    \n\"C\u00f3mo
    \n
    \nAqu\u00ed es al rev\u00e9s, el rojo es Redis. Es decir, Redis gana en rendimiento a Hazelcast. En la primera comparaci\u00f3n, gan\u00f3 Hazelcast, en la segunda, Redis.     Aqu\u00ed tambi\u00e9n<\/a><\/noindex> se explic\u00f3 muy claramente por qu\u00e9 gan\u00f3 Hazelcast en la comparaci\u00f3n anterior.<\/p>\n

    Resulta que el resultado del primero estaba, de hecho, manipulado: tomaron Redis en su caja b\u00e1sica, mientras que ajustaron Hazelcast para el caso de prueba. Entonces, resulta que: en primer lugar, no se puede confiar en nadie, y en segundo lugar, cuando finalmente elijamos un sistema, tambi\u00e9n necesitamos configurarlo correctamente. Estas configuraciones incluyen decenas, casi cientos de par\u00e1metros.<\/p>\n

    Agitamos la botella<\/h2>\n

    \nY todo el proceso que acabamos de realizar, puedo explicarlo con la met\u00e1fora \"Agitamos la botella\". Es decir, ahora no se puede programar, lo principal es saber leer stackoverflow. Y tengo en mi equipo a un profesional que trabaja exactamente as\u00ed en momentos cr\u00edticos.<\/p>\n

    \u00bfQu\u00e9 hace? Ve un dispositivo que no funciona, observa el stack trace, toma algunas palabras (cu\u00e1les exactamente es su experiencia en el programa), busca en Google, encuentra stackoverflow entre las respuestas. Sin leer ni pensar, entre las respuestas a la pregunta, elige algo que se parezca a la sugerencia \"hacer esto y aquello\" (elegir esa respuesta es su talento, ya que no siempre es la que ha recibido m\u00e1s 'me gusta'), aplica, observa: si algo ha cambiado, genial. Si no ha cambiado, retrocedemos. Y repetimos inicio-verificaci\u00f3n-b\u00fasqueda. Y de esta manera intuitiva, logra que despu\u00e9s de un tiempo el c\u00f3digo funcione. No sabe por qu\u00e9, no sabe qu\u00e9 hizo, no puede explicarlo. \u00a1Pero! Esa cosa funciona. Y \"el incendio est\u00e1 apagado\". Ahora revisemos qu\u00e9 hicimos. Cuando el programa funciona, es un orden de magnitud m\u00e1s f\u00e1cil. Y ahorra significativamente tiempo.<\/p>\n

    Este m\u00e9todo se explica muy bien con este ejemplo.<\/p>\n

    Hace tiempo era muy popular construir un velero dentro de una botella. El velero es grande y fr\u00e1gil, mientras que el cuello de la botella es muy estrecho, no se puede meter por dentro. \u00bfC\u00f3mo se arma?<\/p>\n

    \"C\u00f3mo
    \n
    \nHay un m\u00e9todo que es muy r\u00e1pido y muy efectivo.<\/p>\n

    El barco consta de un mont\u00f3n de peque\u00f1as cosas: palitos, cuerdas, velas, pegamento. Todo esto lo metemos en la botella.
    \nTomamos la botella con ambas manos y comenzamos a sacudir. La agitamos, la agitamos. Y normalmente, el resultado es un desastre, claro. Pero a veces, a veces sale un barco. M\u00e1s bien, algo que se parece a un barco.<\/p>\n

    Le mostramos eso a alguien: \"\u00a1Serge, \u00bfves!?\". Y realmente, desde lejos, parece un barco. Pero no se puede dejar as\u00ed.<\/p>\n

    Tambi\u00e9n hay otra forma. La utilizan chicos m\u00e1s avanzados, como hackers.<\/p>\n

    Le di una tarea a un chico as\u00ed, lo hizo todo y se fue. Y miras, parece que est\u00e1 hecho. Pero despu\u00e9s de un tiempo, cuando hay que modificar el c\u00f3digo, comienza a haber problemas por su culpa... Menos mal que ya se hab\u00eda alejado. Estos chicos, que aplican el ejemplo de la botella, hacen lo siguiente: ven que donde est\u00e1 el fondo, el vidrio se curva. Y no est\u00e1 del todo claro si es transparente o no. Entonces, los \"hackers\" cortan ese fondo, insertan el barco, vuelven a pegar el fondo y parece que as\u00ed debe ser.<\/p>\n

    Desde el punto de vista de la formulaci\u00f3n del problema, parece que todo est\u00e1 bien. Pero, en el caso de los barcos: \u00bfpara qu\u00e9 se hace este barco, a qui\u00e9n realmente le sirve? No tiene ninguna funcionalidad. Normalmente, tales barcos son regalos para personas de alto rango, que lo ponen en una estanter\u00eda como un s\u00edmbolo, como un signo. Y si para una persona as\u00ed, un l\u00edder de un gran negocio o un funcionario de alto rango, como bandera, est\u00e1 esta chapuza con el cuello cortado, \u00bfno es mejor que nunca se entere de eso? Entonces, \u00bfc\u00f3mo se hacen al final estos barcos que se pueden regalar a una persona importante?<\/p>\n

    El \u00fanico lugar, crucial, con el que realmente no se puede hacer nada es el casco. Y el casco del barco pasa justo por el cuello de la botella. Mientras que el barco se ensambla fuera de la botella. Pero no es solo armar el barco, es un verdadero arte joyero. Se agregan a las piezas elementos especiales que permiten levantarlos despu\u00e9s. Por ejemplo, las velas se pliegan, se introducen cuidadosamente en el interior, y luego, con unas pinzas, se levantan y ajustan con gran precisi\u00f3n. Como resultado, se obtiene una obra de arte que se puede regalar con la conciencia tranquila y con orgullo.<\/p>\n

    Y si queremos que el proyecto sea exitoso, debe haber al menos una persona joyera en el equipo. Aquella que se preocupa por la calidad del producto y considera todos los aspectos, sin sacrificar ninguno, incluso en momentos de estr\u00e9s, cuando las circunstancias requieren hacer algo urgente en detrimento de lo importante. Todos los proyectos exitosos que son sostenibles y han soportado la prueba del tiempo se basan en este principio. En ellos hay algo muy preciso y \u00fanico, algo que utiliza todas las posibilidades disponibles. En el ejemplo del barco en la botella, se juega con el hecho de que el casco del barco pasa por el cuello.<\/p>\n

    Volviendo a la tarea de elegir nuestro servidor de cach\u00e9, \u00bfc\u00f3mo se podr\u00eda aplicar este m\u00e9todo? Propongo una manera de elegir entre todos los sistemas que hay: no mover la botella, no elegir, sino ver qu\u00e9 hay en ellos que deber\u00edamos tener en cuenta al elegir un sistema.<\/p>\n

    D\u00f3nde buscar el cuello de botella<\/h2>\n

    \nIntentemos no mover la botella, no revisar todo lo que hay por turnos, sino ver qu\u00e9 tareas surgir\u00e1n si, de repente, tuvi\u00e9ramos que dise\u00f1ar un sistema similar a medida. Por supuesto, no vamos a inventar la rueda, pero utilizaremos este esquema para orientarnos sobre qu\u00e9 aspectos prestar atenci\u00f3n en las descripciones de productos. Haremos un borrador de este esquema.<\/p>\n

    \"C\u00f3mo
    \n
    \nSi el sistema es distribuido, entonces tendremos varios servidores (6). Supongamos que cuatro (es conveniente colocarlos en la imagen, pero, por supuesto, pueden ser tantos como se desee). Si los servidores est\u00e1n en diferentes nodos, significa que en todos ellos hay alg\u00fan c\u00f3digo ejecut\u00e1ndose que se encarga de hacer que estos nodos formen un cl\u00faster y, en caso de desconexi\u00f3n, se reconozcan entre s\u00ed.<\/p>\n

    Tambi\u00e9n se necesita un c\u00f3digo l\u00f3gico (2), que hable sobre la cach\u00e9. Con este c\u00f3digo, los clientes interact\u00faan a trav\u00e9s de alguna API. El c\u00f3digo del cliente (1) puede estar tanto dentro de la misma JVM como comunicarse con \u00e9l por la red. La l\u00f3gica implementada internamente consiste en las decisiones sobre qu\u00e9 objetos mantener en la cach\u00e9 y cu\u00e1les desechar. Para almacenar la cach\u00e9 usamos la memoria (3), pero si es necesario, podemos guardar parte de los datos en el disco (4).<\/p>\n

    Veamos en qu\u00e9 partes se generar\u00e1 carga. En realidad, cada flecha y cada nodo se ver\u00e1n afectados. Primero, entre el c\u00f3digo del cliente y la API, si se trata de una interacci\u00f3n en red, la ca\u00edda puede ser bastante notable. En segundo lugar, dentro de la propia API: si complicamos demasiado la l\u00f3gica, podr\u00edamos toparnos con el CPU. Y ser\u00eda bueno que la l\u00f3gica no utilizara la memoria innecesariamente. Y queda la interacci\u00f3n con el sistema de archivos: en una variante normal, esto implica serializar \/ restaurar y escribir \/ leer.<\/p>\n

    A continuaci\u00f3n, la interacci\u00f3n con el cl\u00faster. Lo m\u00e1s probable es que est\u00e9 en este mismo sistema, pero tambi\u00e9n puede estar separado. Aqu\u00ed tambi\u00e9n es necesario tener en cuenta la transmisi\u00f3n de datos hacia \u00e9l, la velocidad de serializaci\u00f3n de datos y la interacci\u00f3n entre cl\u00fasteres.<\/p>\n

    Ahora, por un lado, podemos imaginar 'qu\u00e9 engranajes girar\u00e1n' en el sistema de cach\u00e9 al procesar solicitudes de nuestro c\u00f3digo, y por otro lado, podemos estimar cu\u00e1ntas y qu\u00e9 solicitudes generar\u00e1 nuestro c\u00f3digo hacia este sistema. Esto es suficiente para hacer una elecci\u00f3n m\u00e1s o menos sensata: seleccionar un sistema que se ajuste a nuestro caso de uso.<\/p>\n

    Hazelcast<\/b><\/p>\n

    Veamos c\u00f3mo aplicar esta descomposici\u00f3n a nuestra lista. Por ejemplo, Hazelcast.<\/p>\n

    Para a\u00f1adir\/quitar datos de Hazelcast, el c\u00f3digo del cliente se dirige (1) a la API. Hz permite iniciar un servidor como embebido, y en este caso, llamar a la API es una invocaci\u00f3n de un m\u00e9todo dentro de la JVM, se puede considerar gratuito.<\/p>\n

    Para que la l\u00f3gica funcione en (2), Hz se basa en el hash de un arreglo de bytes de la clave serializada, es decir, la serializaci\u00f3n de la clave se llevar\u00e1 a cabo de todos modos. Este es un overhead inevitable para Hz.
    \nLas estrategias de desalojo est\u00e1n bien implementadas, pero para casos especiales, se pueden conectar las propias. No hay que preocuparse por esta parte.<\/p>\n

    El almacenamiento (4) se puede conectar. Excelente. La interacci\u00f3n (5) para embedded puede considerarse instant\u00e1nea. El intercambio de datos entre nodos en el cl\u00faster (6) \u2013 s\u00ed, existe. Esto contribuye a la resistencia a fallos a costa de la velocidad. La caracter\u00edstica de Hz Near-cache permite reducir el precio: los datos obtenidos de otros nodos del cl\u00faster ser\u00e1n almacenados en cach\u00e9.<\/p>\n

    \u00bfQu\u00e9 se puede hacer en tales condiciones para aumentar la velocidad?<\/p>\n

    Por ejemplo, para evitar la serializaci\u00f3n de la clave en (2) \u2013 a\u00f1adir otra cach\u00e9 sobre Hazelcast, para los datos m\u00e1s calientes. En Sportmaster, para este prop\u00f3sito, eligieron Caffeine.<\/p>\n

    Para ajustar al nivel (6), en Hz se propusieron dos tipos de almacenamiento: IMap y ReplicatedMap.
    \n\"C\u00f3mo
    \n
    \nVale la pena mencionar c\u00f3mo Hazelcast lleg\u00f3 al stack tecnol\u00f3gico de Sportmaster.<\/p>\n

    En 2012, cuando trabaj\u00e1bamos en el primer piloto del futuro sitio web, Hazelcast result\u00f3 ser el primer enlace que arroj\u00f3 el motor de b\u00fasqueda. La conexi\u00f3n se estableci\u00f3 \"desde el primer momento\" \u2014 nos convenci\u00f3 que solo dos horas despu\u00e9s de integrar Hz en el sistema, ya estaba funcionando. Y funcionaba bien. Hasta el final del d\u00eda escribimos algunas pruebas, nos alegramos. Y esa reserva de energ\u00eda fue suficiente para superar las sorpresas que Hz iba presentando con el tiempo. Actualmente, el equipo de Sportmaster no tiene razones para renunciar a Hazelcast.<\/p>\n

    Pero argumentos como \"el primer enlace en el motor de b\u00fasqueda\" y \"armamos r\u00e1pidamente HelloWorld\" son, por supuesto, una excepci\u00f3n y una particularidad del momento en que se realiz\u00f3 la elecci\u00f3n. Las verdaderas pruebas para el sistema elegido comienzan con el despliegue en producci\u00f3n, y es precisamente en esta etapa donde se debe prestar atenci\u00f3n al elegir cualquier sistema, incluso la cach\u00e9. De hecho, en nuestro caso se puede decir que elegimos Hazelcast por casualidad, pero luego result\u00f3 que elegimos correctamente.<\/p>\n

    Para producci\u00f3n, es mucho m\u00e1s importante: monitoreo, manejo de fallos en nodos individuales, replicaci\u00f3n de datos, costo de escalado. Es decir, se debe prestar atenci\u00f3n a las tareas que surgir\u00e1n precisamente en el mantenimiento del sistema \u2013 cuando la carga supere por decenas de veces lo planificado, cuando accidentalmente subamos algo incorrecto y en el lugar equivocado, cuando se requiera desplegar una nueva versi\u00f3n del c\u00f3digo, cambiar datos y hacerlo sin que los clientes lo noten.<\/p>\n

    Para todos estos requisitos, Hazelcast, sin duda, es adecuado.<\/p>\n

    Continuar\u00e1<\/h2>\n

    \nPero Hazelcast no es una panacea. En 2017, elegimos Hazelcast para el cach\u00e9 en el panel de administraci\u00f3n, simplemente bas\u00e1ndonos en la buena impresi\u00f3n de experiencias pasadas. Esto jug\u00f3 un papel clave en una muy amarga broma, lo que nos llev\u00f3 a una situaci\u00f3n complicada de la que \u00abheroicamente\u00bb salimos despu\u00e9s de 60 d\u00edas. Pero sobre esto, en la pr\u00f3xima parte.<\/p>\n

    Y mientras tanto\u2026 \u00a1Feliz nuevo c\u00f3digo!
    \n
    Fuente:     habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

    \u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440. \u0412 \u044d\u0442\u043e\u043c \u043f\u043e\u0441\u0442\u0435 \u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u0430\u043b, \u043a\u0430\u043a \u043d\u0430\u0447\u0438\u043d\u0430\u043b\u0430\u0441\u044c \u0440\u0430\u0431\u043e\u0442\u0430 \u043d\u0430\u0434 \u0441\u0430\u0439\u0442\u043e\u043c \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440 \u0432 2012 \u0433\u043e\u0434\u0443, \u043a\u0430\u043a\u0438\u0435 \u0438\u043d\u0438\u0446\u0438\u0430\u0442\u0438\u0432\u044b \u0443\u0434\u0430\u043b\u043e\u0441\u044c \u00ab\u043f\u0440\u043e\u0442\u043e\u043b\u043a\u043d\u0443\u0442\u044c\u00bb \u0438 \u043d\u0430\u043e\u0431\u043e\u0440\u043e\u0442, \u043a\u0430\u043a\u0438\u0435 \u0433\u0440\u0430\u0431\u043b\u0438 \u043c\u044b \u0441\u043e\u0431\u0440\u0430\u043b\u0438. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u044f \u0445\u043e\u0447\u0443 \u043f\u043e\u0434\u0435\u043b\u0438\u0442\u044c\u0441\u044f \u043c\u044b\u0441\u043b\u044f\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043b\u0435\u0434\u0443\u044e\u0442 \u0437\u0430 \u0434\u0440\u0443\u0433\u0438\u043c \u0441\u044e\u0436\u0435\u0442\u043e\u043c \u2013 \u0432\u044b\u0431\u043e\u0440 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0434\u043b\u044f java-\u0431\u044d\u043a\u0435\u043d\u0434\u0430 \u0432 \u0430\u0434\u043c\u0438\u043d\u043a\u0435 \u0441\u0430\u0439\u0442\u0430. \u042d\u0442\u043e\u0442 \u0441\u044e\u0436\u0435\u0442 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":73950,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-73949","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47C\u00f3mo elegimos en Sportmaster un sistema de cach\u00e9. Parte 1 | ProHoster","description":"\u00a1Hola! Me llamo Alexey Pyankov, soy desarrollador en la compa\u00f1\u00eda Sportmaster.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041a\u0430\u043a \u043c\u044b \u0432 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440\u0435 \u0432\u044b\u0431\u0438\u0440\u0430\u043b\u0438 \u0441\u0438\u0441\u0442\u0435\u043c\u0443 \u043a\u0435\u0448\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f. \u0427\u0430\u0441\u0442\u044c 1 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u0410\u043b\u0435\u043a\u0441\u0435\u0439 \u041f\u044c\u044f\u043d\u043a\u043e\u0432, \u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 \u0421\u043f\u043e\u0440\u0442\u043c\u0430\u0441\u0442\u0435\u0440.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/kak-my-v-sportmastere-vybirali-sistemu-keshirovaniya-chast-1","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-03-12T23:42:07+00:00","article:modified_time":"2020-03-12T23:42:07+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"73949","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 18:23:51","updated":"2022-09-28 05:05:57","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/73949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=73949"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/73949\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/73950"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=73949"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=73949"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=73949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}