Hola! Em dic Alexey Pyankov, sóc desenvolupador de l'empresa Sportmaster. En aquest Vaig explicar com va començar el treball al lloc web de Sportmaster l'any 2012, quines iniciatives vam aconseguir "impulsar" i viceversa, quin rastell vam recollir.
Avui vull compartir idees que segueixen un altre tema: escollir un sistema de memòria cau per al backend de Java a l'àrea d'administració del lloc. Aquesta trama té un significat especial per a mi: tot i que la història es va desenvolupar només durant 2 mesos, durant aquests 60 dies vam treballar 12-16 hores i sense un sol dia de descans. Mai havia pensat ni imaginat que fos possible treballar tant.
Per tant, he dividit el text en 2 parts per no carregar-lo completament. Al contrari, la primera part serà molt lleugera: preparació, introducció, algunes consideracions sobre què és la memòria cau. Si ja sou un desenvolupador experimentat o heu treballat amb memòria cau, des del punt de vista tècnic probablement no hi haurà res de nou en aquest article. Però per a un jove, una revisió tan petita li pot dir en quina direcció mirar si es troba en una cruïlla de camins.
Quan es va posar en producció la nova versió del lloc web de Sportmaster, les dades es van rebre d'una manera que, per dir-ho suaument, no era gaire convenient. La base eren taules preparades per a la versió anterior del lloc (Bitrix), que s'havien d'incorporar a ETL, portar-les a una nova forma i enriquir-les amb diverses petites coses d'una dotzena de sistemes més. Per tal que aparegués una imatge nova o una descripció del producte al lloc, calia esperar fins l'endemà, actualitzacions només a la nit, un cop al dia.
Al principi, hi havia tantes preocupacions des de les primeres setmanes d'entrada en producció que aquests inconvenients per als gestors de continguts eren una mica. Però, tan bon punt tot es va assentar, el desenvolupament del projecte va continuar: uns mesos més tard, a principis de 2015, vam començar a desenvolupar activament el tauler d'administració. El 2015 i el 2016, tot va bé, publiquem regularment, el tauler d'administració cobreix cada cop més la preparació de dades i ens estem preparant per al fet que aviat al nostre equip es confiarà el més important i complex: el producte. circuit (preparació completa i manteniment de les dades de tots els productes). Però a l'estiu del 2017, just abans de la posada en marxa del circuit de productes bàsics, el projecte es trobarà en una situació molt difícil, precisament per problemes amb la memòria cau. Vull parlar d'aquest episodi a la segona part d'aquesta publicació en dues parts.
Però en aquesta entrada començaré des de lluny, presentaré algunes reflexions: idees sobre la memòria cau, que seria un bon pas per desplaçar-se abans d'un gran projecte.
Quan es produeix una tasca de memòria cau
La tasca de memòria cau no només apareix. Som desenvolupadors, escrivim un producte de programari i volem que sigui demanat. Si el producte té una demanda i té èxit, els usuaris vindran. I cada cop en vénen més. I després hi ha molts usuaris i després el producte es carrega molt.
En les primeres etapes, no pensem en l'optimització i el rendiment del codi. El més important és la funcionalitat, llançar ràpidament un pilot i provar hipòtesis. I si la càrrega augmenta, bombem la planxa. Ho augmentem dues o tres vegades, cinc vegades, potser 10 vegades. En algun lloc aquí: les finances ja no ho permetran. Quantes vegades augmentarà el nombre d'usuaris? No serà com 2-5-10, però si té èxit, serà de 100-1000 a 100 mil vegades. És a dir, tard o d'hora, hauràs de fer una optimització.
Suposem que alguna part del codi (anomenem aquesta part una funció) triga un temps indecent i volem reduir el temps d'execució. Una funció pot ser l'accés a una base de dades o l'execució d'alguna lògica complexa; el més important és que es triga molt de temps a completar-se. Fins a quin punt es pot reduir el temps d'execució? En el límit, podeu reduir-lo a zero, no més. Com es pot reduir el temps d'execució a zero? Resposta: elimineu l'execució per complet. En canvi, retorneu el resultat immediatament. Com es pot saber el resultat? Resposta: calcula'l o mira en algun lloc. Es necessita molt de temps per calcular. I espiar és, per exemple, recordar el resultat que la funció va produir l'última vegada quan es va cridar amb els mateixos paràmetres.
És a dir, la implementació de la funció no és important per a nosaltres. N'hi ha prou amb saber de quins paràmetres depèn el resultat. Aleshores, si els valors dels paràmetres es representen en forma d'objecte que es pot utilitzar com a clau en algun emmagatzematge, el resultat del càlcul es pot desar i llegir la propera vegada que s'hi accedeixi. Si aquesta escriptura i lectura del resultat és més ràpida que executar la funció, tenim un benefici en termes de velocitat. La quantitat de beneficis pot arribar a 100, 1000 i 100 mil vegades (10 ^ 5 és més aviat una excepció, però en el cas d'una base força retardada, és molt possible).
Requisits bàsics per a un sistema de memòria cau
El primer que es pot convertir en un requisit per a un sistema de memòria cau és la velocitat de lectura ràpida i, en una mesura una mica menor, la velocitat d'escriptura. Això és cert, però només fins que posem el sistema a producció.
Juguem a aquest cas.
Suposem que hem proporcionat la càrrega actual amb maquinari i ara estem introduint la memòria cau gradualment. El nombre d'usuaris creix una mica, la càrrega creix: afegim una mica de memòria cau, ho fem aquí i allà. Això continua durant un temps, i ara les funcions pesades pràcticament ja no es diuen: tota la càrrega principal cau a la memòria cau. El nombre d'usuaris durant aquest temps ha augmentat N vegades.
I si el subministrament inicial de maquinari podria ser de 2 a 5 vegades, amb l'ajuda de la memòria cau podríem millorar el rendiment per un factor de 10 o, en un bon cas, per un factor de 100, en alguns llocs potser per un factor. de 1000. És a dir, en el mateix maquinari: processem 100 vegades més peticions. Genial, et mereixes el pa de pessic!
Però ara, en un bon moment, per casualitat, el sistema es va estavellar i la memòria cau es va col·lapsar. Res especial: després de tot, la memòria cau es va triar en funció del requisit "alta velocitat de lectura i escriptura, la resta no importa".
En relació amb la càrrega inicial, la nostra reserva de ferro va ser de 2 a 5 vegades i la càrrega durant aquest temps va augmentar de 10 a 100 vegades. Amb la memòria cau, vam eliminar les trucades per a funcions pesades i, per tant, tot va funcionar. I ara, sense una memòria cau, quantes vegades s'alentirà el nostre sistema? Què ens passarà? El sistema caurà.
Fins i tot si la nostra memòria cau no s'ha bloquejat, sinó que només s'ha esborrat durant un temps, caldrà escalfar-la i això trigarà una mica. I durant aquest temps, la càrrega principal recaurà en la funcionalitat.
Conclusió: els projectes de producció amb molta càrrega requereixen un sistema de memòria cau no només per tenir altes velocitats de lectura i escriptura, sinó també per garantir la seguretat de les dades i la resistència als errors.
Farina d’elecció
En un projecte amb un panell d'administració, l'elecció va ser així: primer vam instal·lar Hazelcast, perquè Ja estàvem familiaritzats amb aquest producte per l'experiència del lloc principal. Però aquí aquesta elecció va resultar infructuosa: sota el nostre perfil de càrrega, Hazelcast no només és lenta, sinó terriblement lenta. I en aquell moment ja ens havíem inscrit per a la data de llançament.
Spoiler: com es van desenvolupar exactament les circumstàncies que ens vam perdre una cosa tan gran i vam acabar amb una situació aguda i tensa -ja us explicaré a la segona part- i com vam acabar i com vam sortir. Però ara, només diré que va ser molt d'estrès, i "pensar, d'alguna manera no puc pensar, estem sacsejant l'ampolla". "Shaking the bottle" també és un spoiler, sobre això més endavant.
Què vam fer:
- Fem una llista de tots els sistemes que suggereixen Google i StackOverflow. Una mica més de 30
- Escrivim proves amb una càrrega típica de producció. Per fer-ho, hem gravat les dades que passen pel sistema en un entorn de producció: una mena de rastreig de dades no a la xarxa, sinó a l'interior del sistema. Exactament aquestes dades es van utilitzar en les proves.
- Amb tot l'equip, tothom selecciona el següent sistema de la llista, el configura i realitza proves. No passa la prova, no porta la càrrega: la llencem i passem a la següent de la fila.
- El sistema del 17 va quedar clar que tot estava desesperat. Deixa de sacsejar l'ampolla, és hora de pensar seriosament.
Però aquesta és una opció quan necessiteu triar un sistema que "superi la velocitat" en proves preparades prèviament. Què passa si encara no hi ha aquestes proves i voleu triar ràpidament?
Modelem aquesta opció (és difícil imaginar que un desenvolupador mitjà+ viu al buit, i en el moment de la selecció encara no ha formalitzat la seva preferència pel que fa a quin producte provar primer; per tant, un raonament addicional és més aviat un teòric/filosofia/). sobre un júnior).
Un cop decidits els requisits, començarem a seleccionar una solució fora de la caixa. Per què reinventar la roda: anem a agafar un sistema de memòria cau ja fet.
Si tot just esteu començant i busqueu-lo a Google, doneu o preneu la comanda, però en general, les directrius seran així. En primer lloc et trobaràs amb Redis, s'escolta per tot arreu. Aleshores descobrireu que EhCache és el sistema més antic i provat. A continuació, escriurem sobre Tarantool, un desenvolupament domèstic que té un aspecte únic de la solució. I també Ignite, perquè ara està augmentant en popularitat i gaudeix del suport de SberTech. Al final també hi ha Hazelcast, perquè en el món empresarial sovint apareix entre les grans empreses.
La llista no és exhaustiva; hi ha desenes de sistemes. I només posarem una cosa. Agafem els 5 sistemes seleccionats per al "concurs de bellesa" i fem una selecció. Qui serà el guanyador?
Redis
Llegim el que escriuen al lloc web oficial.
- projecte de codi obert. Ofereix emmagatzematge de dades a la memòria, la capacitat d'estalviar al disc, particionament automàtic, alta disponibilitat i recuperació de les interrupcions de la xarxa.
Sembla que tot està bé, pots agafar-lo i cargolar-ho, tot el que necessites, ho fa. Però només per diversió, mirem els altres candidats.
EhCache
- "la memòria cau més utilitzada per a Java" (traducció de l'eslògan del lloc web oficial). També de codi obert. I llavors entenem que Redis no és per a java, sinó general, i per interactuar amb ell necessites un embolcall. I EhCache serà més convenient. Què més promet el sistema? Fiabilitat, provada, funcionalitat completa. Bé, també és el més habitual. I guarda terabytes de dades a la memòria cau.
Redis està oblidat, estic preparat per triar EhCache.
Però un sentit de patriotisme m'empeny a veure què té de bo Tarantool.
Tarantool
- compleix la denominació "Plataforma d'integració de dades en temps real". Sembla molt complicat, així que llegim la pàgina amb detall i trobem una declaració forta: "Escriu a la memòria cau el 100% de les dades a la memòria RAM". Això hauria de plantejar preguntes: després de tot, hi pot haver moltes més dades que memòria. L'explicació és que vol dir que Tarantool no executa la serialització per escriure dades al disc des de la memòria. En canvi, utilitza característiques de baix nivell del sistema, quan la memòria simplement s'assigna a un sistema de fitxers amb molt bon rendiment d'E/S. En general, van fer alguna cosa meravellosa i genial.
Vegem les implementacions: carretera corporativa Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
Si encara hi havia dubtes sobre Tarantool, el cas d'implementació de Mastercard m'acaba. Prenc Tarantool.
De totes formes…
Ignite
... hi ha alguna cosa més , es presenta com una "plataforma informàtica en memòria... velocitats en memòria en petabytes de dades". També hi ha molts avantatges aquí: memòria cau distribuïda a la memòria, emmagatzematge i memòria cau més ràpids de valor-clau, escalat horitzontal, alta disponibilitat, integritat estricta. En general, resulta que el més ràpid és Ignite.
Implementacions: Sberbank, American Airlines, Yahoo! Japó. I llavors descobreixo que Ignite no només s'implementa a Sberbank, sinó que l'equip de SberTech envia la seva gent al propi equip d'Ignite per perfeccionar el producte. Això és completament captivador i estic preparat per prendre Ignite.
No està del tot clar per què, estic mirant el cinquè punt.
avellana
Vaig al lloc , lectura. I resulta que la solució més ràpida per a la memòria cau distribuïda és Hazelcast. És ordres de magnitud més ràpid que totes les altres solucions i, en general, és líder en el camp de la xarxa de dades en memòria. En aquest context, prendre una altra cosa és no respectar-se. També utilitza l'emmagatzematge de dades redundant per al funcionament continu del clúster sense pèrdua de dades.
Això és tot, estic preparat per prendre Hazelcast.
Comparació
Però si us fixeu, els cinc candidats es descriuen de tal manera que cadascun d'ells és el millor. Com triar? Podem veure quin és el més popular, buscar comparacions i el mal de cap desapareixerà.
En trobem un com aquest , tria els nostres 5 sistemes.
Aquí estan ordenats: Redis està al capdavant, Hazelcast ocupa el segon lloc, Tarantool i Ignite estan guanyant popularitat, EhCache ha estat i segueix sent el mateix.
Però mirem-ho : enllaços a llocs web, interès general pel sistema, ofertes de feina, genial! És a dir, quan el meu sistema falli, diré: “No, és fiable! Hi ha moltes ofertes de feina..." Una comparació tan senzilla no servirà.
Tots aquests sistemes no són només sistemes de memòria cau. També tenen moltes funcionalitats, inclòs quan les dades no es bombegen al client per processar-les, però viceversa: el codi que cal executar a les dades es mou al servidor, s'executa allà i es retorna el resultat. I no es consideren tan sovint com un sistema separat per a la memòria cau.
D'acord, no ens rendem, busquem una comparació directa dels sistemes. Prenem les dues opcions principals: Redis i Hazelcast. Ens interessa la velocitat i les compararem en funció d'aquest paràmetre.
Hz vs Redis
Trobem això :
El blau és Redis, el vermell és Hazelcast. Hazelcast guanya a tot arreu, i hi ha una raó per a això: és multifils, altament optimitzat, cada fil funciona amb la seva pròpia partició, de manera que no hi ha cap bloqueig. I Redis és d'un sol fil; no es beneficia de les CPU modernes de diversos nuclis. Hazelcast té E/S asíncrona, Redis-Jedis té connectors de bloqueig. Després de tot, Hazelcast utilitza un protocol binari i Redis està centrat en el text, és a dir, és ineficient.
Per si de cas, anem a una altra font de comparació. Què ens mostrarà?
Redis vs Hz
un altre :
Aquí, al contrari, el vermell és Redis. És a dir, Redis supera a Hazelcast pel que fa a rendiment. Hazelcast va guanyar la primera comparació, Redis va guanyar la segona. va explicar molt precisament per què Hazelcast va guanyar la comparació anterior.
Resulta que el resultat del primer va ser realment manipulat: Redis es va agafar a la caixa base i Hazelcast es va adaptar per a un cas de prova. Aleshores resulta: en primer lloc, no podem confiar en ningú i, en segon lloc, quan finalment triem un sistema, encara hem de configurar-lo correctament. Aquests paràmetres inclouen desenes, gairebé centenars de paràmetres.
Sacsejant l'ampolla
I puc explicar tot el procés que hem fet ara amb la metàfora següent: "Agitar l'ampolla". És a dir, ara no cal programar, ara el més important és poder llegir stackoverflow. I tinc una persona al meu equip, un professional, que treballa exactament així en els moments crítics.
Què està fent? Veu una cosa trencada, veu un rastre de pila, n'hi treu algunes paraules (quines són la seva experiència en el programa), cerca a Google, troba un desbordament de pila entre les respostes. Sense llegir, sense pensar, entre les respostes a la pregunta, tria alguna cosa més semblant a l'oració "fes això i allò" (escollir aquesta resposta és el seu talent, perquè no sempre és la resposta que va rebre més likes), s'aplica, sembla: si alguna cosa ha canviat, és genial. Si no ha canviat, torneu-lo enrere. I repetiu llançament-verificació-cerca. I d'aquesta manera intuïtiva, s'assegura que el codi funcioni després d'un temps. No sap per què, no sap què va fer, no sap explicar-ho. Però! Aquesta infecció funciona. I "el foc està apagat". Ara anem a esbrinar què hem fet. Quan el programa funciona, és un ordre de magnitud més fàcil. I estalvia molt de temps.
Aquest mètode està molt ben explicat amb aquest exemple.
Abans era molt popular recollir un veler en una ampolla. Al mateix temps, el veler és gran i fràgil, i el coll de l'ampolla és molt estret, és impossible empènyer-lo dins. Com muntar-lo?
Hi ha un mètode així, molt ràpid i molt eficaç.
El vaixell consta d'un munt de petites coses: pals, cordes, veles, cola. Tot això ho posem en una ampolla.
Agafem l'ampolla amb les dues mans i comencem a sacsejar. La sacsegem i la sacsegem. I normalment resulta ser una escombraria completa, és clar. Però a vegades. De vegades resulta ser un vaixell! Més precisament, quelcom semblant a un vaixell.
Mostrem això a algú: "Seryoga, ho veus!?" I, efectivament, de lluny sembla un vaixell. Però això no es pot permetre que continuï.
Hi ha una altra manera. Són utilitzats per nois més avançats, com els pirates informàtics.
Vaig donar una tasca a aquest noi, ho va fer tot i va marxar. I mireu, sembla que està fet. I al cap d'una estona, quan s'ha de concretar el codi, això comença per ell... És bo que ja hagi aconseguit fugir lluny. Aquests són els nois que, fent servir l'exemple d'una ampolla, faran això: ja veus, on està el fons, el vidre es doblega. I no està del tot clar si és transparent o no. Aleshores, els "pirates informàtics" tallen aquest fons, hi introdueixen un vaixell i, a continuació, tornen a enganxar el fons, i és com si se suposa que ha de ser així.
Des del punt de vista de la configuració del problema, tot sembla correcte. Però fent servir els vaixells com a exemple: per què fer aquest vaixell, qui el necessita de totes maneres? No ofereix cap funcionalitat. En general, aquests vaixells són regals per a persones de molt alt rang, que el posen en un prestatge a sobre d'ells, com una mena de símbol, com a senyal. I si una persona així, el cap d'una gran empresa o un alt funcionari, com representarà la bandera per a tal pirateig, el coll del qual ha estat tallat? Seria millor que no se n'adonés mai. Aleshores, com acaben fent aquests vaixells que es poden donar a una persona important?
L'únic lloc clau sobre el qual realment no pots fer res és el cos. I el casc del vaixell encaixa directament al coll. Mentre que el vaixell està muntat fora de l'ampolla. Però no només es tracta de muntar un vaixell, és una autèntica joieria. S'afegeixen palanques especials als components, que després permeten aixecar-los. Per exemple, les veles es pleguen, es posen amb cura a dins, i després, amb l'ajuda d'unes pinces, s'estiren i s'aixequen amb molta precisió, amb precisió. El resultat és una obra d'art que es pot regalar amb la consciència tranquil·la i l'orgull.
I si volem que el projecte tingui èxit, ha d'haver almenys un joier a l'equip. Algú que es preocupa per la qualitat del producte i té en compte tots els aspectes, sense renunciar a res, fins i tot en moments d'estrès, quan les circumstàncies exigeixen fer l'urgència a costa de l'important. Tots els projectes d'èxit que són sostenibles, que han resistit la prova del temps, es construeixen sobre aquest principi. Hi ha quelcom de molt precís i únic en ells, quelcom que aprofita totes les possibilitats disponibles. En l'exemple amb el vaixell a l'ampolla, es juga el fet que el casc del vaixell passa pel coll.
Tornant a la tasca d'escollir el nostre servidor de memòria cau, com es podria aplicar aquest mètode? Ofereixo aquesta opció d'escollir entre tots els sistemes existents: no sacsegeu l'ampolla, no trieu, però mireu què tenen en principi, què cal buscar a l'hora d'escollir un sistema.
On buscar el coll d'ampolla
Intentem no sacsejar l'ampolla, no passar per tot el que hi ha un a un, però vegem quins problemes sorgiran si de sobte, per a la nostra tasca, dissenyem nosaltres mateixos un sistema així. Per descomptat, no muntarem la bicicleta, però utilitzarem aquest diagrama per ajudar-nos a esbrinar quins punts hem de prestar atenció a les descripcions dels productes. Esbossem un diagrama així.
Si el sistema està distribuït, tindrem diversos servidors (6). Diguem que n'hi ha quatre (és convenient col·locar-los a la imatge, però, és clar, n'hi pot haver tants com vulgueu). Si els servidors estan en nodes diferents, vol dir que tots executen algun codi que s'encarrega de garantir que aquests nodes formen un clúster i, en cas d'interrupció, es connecten i es reconeixen.
També necessitem la lògica del codi (2), que en realitat tracta sobre la memòria cau. Els clients interactuen amb aquest codi mitjançant alguna API. El codi de client (1) pot estar dins de la mateixa JVM o accedir-hi a través de la xarxa. La lògica implementada a l'interior és la decisió de quins objectes deixar a la memòria cau i quins llençar. Utilitzem la memòria (3) per emmagatzemar la memòria cau, però si cal, podem desar algunes de les dades al disc (4).
Vegem en quines parts es produirà la càrrega. De fet, es carregarà cada fletxa i cada node. En primer lloc, entre el codi del client i l'API, si es tracta de comunicació de xarxa, la subsidència pot ser força notable. En segon lloc, dins del marc de la pròpia API, si ens excedim amb una lògica complexa, podem trobar problemes amb la CPU. I estaria bé que la lògica no perdés el temps en la memòria. I queda la interacció amb el sistema de fitxers: a la versió habitual, es tracta de serialitzar / restaurar i escriure / llegir.
El següent és la interacció amb el clúster. El més probable és que estigui en el mateix sistema, però podria ser per separat. Aquí també heu de tenir en compte la transferència de dades, la velocitat de serialització de dades i les interaccions entre el clúster.
Ara, d'una banda, podem imaginar "quins engranatges giraran" al sistema de memòria cau en processar les peticions del nostre codi, i d'altra banda, podem estimar quines i quantes peticions generarà el nostre codi a aquest sistema. Això és suficient per fer una elecció més o menys sòbria: triar un sistema per al nostre cas d'ús.
avellana
Vegem com aplicar aquesta descomposició a la nostra llista. Per exemple, Hazelcast.
Per posar/treure dades d'Hazelcast, el codi de client accedeix (1) a l'API. Hz us permet executar el servidor com a incrustat i, en aquest cas, accedir a l'API és una trucada de mètode dins de la JVM, que es pot considerar gratuïta.
Perquè la lògica de (2) funcioni, Hz es basa en el hash de la matriu de bytes de la clau serialitzada, és a dir, la clau es serialitzarà en qualsevol cas. Això és una sobrecàrrega inevitable per a Hz.
Les estratègies de desnonament estan ben implementades, però per a casos especials podeu afegir-ne les vostres. No us haureu de preocupar per aquesta part.
Es pot connectar l'emmagatzematge (4). Genial. La interacció (5) per incrustat es pot considerar instantània. Intercanvi de dades entre nodes del clúster (6): sí, existeix. Aquesta és una inversió en tolerància a errors a costa de la velocitat. La funció Hz Near-cache us permet reduir el preu: les dades rebudes d'altres nodes del clúster s'emmagatzemaran a la memòria cau.
Què es pot fer en aquestes condicions per augmentar la velocitat?
Per exemple, per evitar la serialització de la clau a (2), adjunteu una altra memòria cau a sobre de Hazelcast, per obtenir les dades més actuals. Sportmaster va triar la cafeïna per a aquest propòsit.
Per girar al nivell (6), Hz ofereix dos tipus d'emmagatzematge: IMap i ReplicatedMap.
Val la pena esmentar com Hazelcast va entrar a la pila de tecnologia Sportmaster.
L'any 2012, quan estàvem treballant en el primer pilot del futur lloc, va ser Hazelcast el que va resultar ser el primer enllaç que va tornar el motor de cerca. El conegut va començar "la primera vegada": ens va captivar el fet que només dues hores més tard, quan vam connectar Hz al sistema, va funcionar. I va funcionar bé. Al final del dia havíem completat una sèrie de proves i estàvem contents. I aquesta reserva de vigor va ser suficient per superar les sorpreses que Hz va llançar al llarg del temps. Ara l'equip Sportmaster no té cap motiu per abandonar Hazelcast.
Però arguments com "el primer enllaç del motor de cerca" i "HelloWorld es va muntar ràpidament" són, per descomptat, una excepció i una característica del moment en què va tenir lloc l'elecció. Les proves reals per al sistema escollit comencen amb el llançament en producció, i és en aquesta etapa que hauríeu de prestar atenció a l'hora de triar qualsevol sistema, inclosa la memòria cau. De fet, en el nostre cas podem dir que vam triar Hazelcast per casualitat, però després va resultar que vam triar correctament.
Per a la producció, molt més important: monitorització, gestió de fallades en nodes individuals, replicació de dades, cost d'escalat. És a dir, val la pena parar atenció a les tasques que sorgiran durant el manteniment del sistema: quan la càrrega és desenes de vegades més gran del previst, quan pengem alguna cosa per accident al lloc equivocat, quan necessitem llançar una nova versió. del codi, substituir les dades i fer-ho desapercebut per als clients.
Per a tots aquests requisits, Hazelcast s'adapta sens dubte.
Continuarà
Però Hazelcast no és una panacea. El 2017, vam triar Hazelcast per a la memòria cau d'administració, simplement basant-nos en bones impressions de l'experiència passada. Això va tenir un paper clau en una broma molt cruel, per la qual ens vam trobar en una situació difícil i "heroicament" en vam sortir durant 60 dies. Però més sobre això a la part següent.
Mentrestant... Feliç nou codi!
Font: www.habr.com