Kuidas ja miks me kirjutasime kõrge koormusega skaleeritava teenuse 1C: Ettevõtte jaoks: Java, PostgreSQL, Hazelcast

Selles artiklis räägime, kuidas ja miks me selle välja töötasime Koostöö süsteemist – mehhanism, mis edastab teavet kliendirakenduste ja 1C:Ettevõtte serverite vahel – ülesande määratlemisest arhitektuuri ja rakendamise üksikasjade mõtlemiseni.

Koostöö süsteem (edaspidi – KS) on hajutatud tõrke- ja koormustaluv süsteem sõnumite vahetamiseks, millele on tagatud kohaletoimetamine. KS on kujundatud kui suure koormusega teenus, millel on kõrge skaleeritavus, ja see on saadaval nii veebiteenusena (mida pakub ettevõte 1C) kui ka seeriatootena, mida saab rakendada oma serverivõimsusel.

KS kasutab hajutatud salvestusruumi Hazelcast ja otsingusüsteemi Elasticsearch. Samuti räägime Java'st ja sellest, kuidas me PostgreSQL-i horisontaalselt skaleerime.

Ülesande seadmine

Et aru saada, miks me Koostöö süsteemi lõime, räägin natuke sellest, kuidas 1C-s ärrakenduste arendamine toimub.

Alustuseks – natuke meie kohta neile, kes veel ei tea, millega me tegeleme :) Me arendame tehnoloogilist platvormi „1C:Ettevõte“. Platvorm sisaldab ärrakenduste arendamise vahendit ning runtime'i, mis võimaldab ärrakendustel töötada mitmesugustes keskkondades.

Kliendiserveri arendusparadigma

Ärrakendused, mis on loodud „1C:Ettevõttes“, töötavad kolmetasandilises kliendiserveri arhitektuuris „DBMS – rakenduste server – klient“. Rakenduslik kood, mis on kirjutatud 1C sisekeeles, võib töötada rakenduste serveris või kliendil. Kõik töö, mis on seotud rakendusobjektide (näiteks registrid, dokumendid jne), samuti andmebaasi lugemise ja kirjutamisega, toimub ainult serveris. Vormide ja käsuliidese funktsionaalsus on samuti rakendatud serveris. Klient tegeleb vormide saamise, avamise ja kuvamisega, „suhtlemisega“ kasutajaga (hoiatused, küsimused...), väikeste arvutustega vormides, mis vajavad kiiret reageerimist (näiteks hinnaliste koguste korrutamine), kohalike failide töötlemise ja seadme töötlusega.

Rakendusliku koodi protseduuride ja funktsioonide päistes tuleb selgelt näidata, kus kood töötab – kasutada direktiive &НаКлиенте / &НаСервере (&AtClient / &AtServer ingliskeelses versioonis). 1C arendajad parandavad mind, öeldes, et direktiivid on tegelikult ei nõuta enam, kuid see pole meile praegu oluline.

Kliendikoodist saab kutsuda serverikoodi, kuid serverikoodist kliendikoodi kutsuda ei saa. See on meie poolt kehtestatud põhi piirang mitmetel põhjustel. Eelkõige seetõttu, et serverikood peab olema kirjutatud nii, et see toimib ühtviisi, sõltumata sellest, kust seda kutsutakse - kliendist või serverist. Ja juhul, kui serverikoodi kutsutakse teise serverikoodi kaudu, siis klient enam ei eksisteeri. Samuti seetõttu, et serverikoodi täitmise ajal võib klient, kes selle kutsus, sulgeda, rakendusest välja minna ja serveril ei ole enam kedagi, kellele kutsuda.

Kood, mis töötleb nupu vajutamist: serveripäring kliendist töötab, kuid kliendipäring serverist — ei.

See tähendab, et kui me serverist soovime edastada mõne sõnumi kliendirakendusele, näiteks et "pikaks ajaks" kestnud aruande koostamine on lõppenud ja aruanne on saadaval — meil pole sellist võimalust. Peame leidma muid lahendusi, näiteks küsima serverilt regulaarselt. Kuid selline lähenemine koormab süsteemi liigsete päringutega ja kokkuvõttes ei näe see väga elegantne välja.

Ja on veel vajadus, näiteks, kui saabub telefonikõne, SIPteavitada sellest kliendirakendust, et see leidlikult otsiks helistaja numbrit partnerite andmebaasist ja kuvaks kasutajale teavet helistava partneri kohta. Või näiteks teavitada kliendirakendust tellijast, kui laost saabub tellimus. Ühesõnaga, selliseid juhtumeid, kus selline mehhanism oleks abiks, on palju.

Asjaolu sõnastamine.

Luua sõnumite vahetamise mehhanism. Kiire, usaldusväärne, tagatud kohaletoimetamisega, võimalusega paindlikult sõnumeid otsida. Mehhanismi baasil ellu viia sõnumitooja (sõnumid, videokõned), mis töötab 1C rakenduste sees.

Kavandada horisontaalselt skaleeritav süsteem. Kasvav koormus peab olema kaetud sõlmede arvu suurendamisega.

Rakendamine

Otsustasime, et SV serveri osa ei integreerita otse 1C:Enterprise platvormi, vaid rakendatakse eraldi tootena, mille API-d saab kutsuda 1C rakenduste kodeerimisest. See otsus tehti mitmel põhjusel, millest peamine oli soov võimaldada sõnumite vahetamist erinevate 1C rakenduste vahel (näiteks Kaupade Halduse ja Raamatupidamise vahel). Erinevad 1C rakendused võivad töötada erinevate 1C:Enterprise platvormi versioonidega, asuda erinevatel serveritel jne. Sellistes tingimustes on SV rakendamine eraldiseisva tootena, mis asub 1C installatsioonidest

Nii otsustasime, et teeme SV eraldi tootena. Väikestele ettevõtetele soovitame kasutada SV serverit, mille oleme paigaldanud oma pilve (wss://1cdialog.com), et vältida kohapealse paigalduse ja seadistamisega seotud kulusid. Suuremad kliendid võivad aga kaaluda enda SV serveri paigaldamist oma ressurssidele. Sarnast lähenemist oleme kasutanud oma pilve põhises SaaS tootes. 1cFresh – see väljastatakse kui seeriatoode klientide paigalduseks ja samuti on see rakendatud meie pilve https://1cfresh.com/.

Rakendus

Koormuse ja tõrketaluvuse jaotamiseks ei paigalda me mitte ühte, vaid mitut Java-rakendust ning nende ette paigaldame koormuse tasakaalustaja. Kui on vajalik sõnumi edastamine node'ilt node'ile – kasutame publish/subscribe funktsiooni Hazelcastis.

Klientide ja serveri vaheline suhtlemine toimub websocketi kaudu. See sobib hästi reaalajas süsteemidele.

Jaotatud vahemälu

Valisime Redis, Hazelcasti ja Ehcache'i vahel. Aasta on 2015. Redis just käivitas uue klastriversiooni (liialt uus, liiga hirmus), Sentinelil on palju piiranguid. Ehcache ei suuda klastrisse kokku minna (see funktsionaalsus ilmus hiljem). Otsustasime proovida Hazelcasti 3.4.
Hazelcast koguneb klastriks "kastist välja". Ühe node'i režiimis ei ole see kuigi kasulik ja võib sobida ainult vahemäluks - see ei oska andmeid kettale salvestada, kui kaotame ainus node'i - kaotame andmed. Me käsitleme mitut Hazelcast'i, mille vahel varundame kriitilisi andmeid. Vahemälu ei varunda – seda ei ole kahju kaotada.

Meie jaoks on Hazelcast:

• Kasutajasektsioonide salvestamine. Igal korral andmebaasist seanssile minek on aeglane, seetõttu paneme kõik seansid Hazelcasti.
• Vahemälu. Otsid kasutaja profiili – kontrolli vahemälus. Kirjutasid uue sõnumi – salvesta vahemällu.
• Rakenduste instantside suhtlemise teemad. Sõlm genereerib sündmuse ja lisab selle Hazelcasti teema. Teised rakenduse sõlmed, mis on sellel teemal tellitud, saavad ja töötlevad sündmust.
• Klastri lukustused. Näiteks loome arutelu unikaalse võtme järgi (arutelu-süntetar, mis on 1C andmebaasis):

conversationKeyChecker.check("BENSIINIAJA");

      doInClusterLock("BENSIINIAJA", () -> {

          conversationKeyChecker.check("BENSIINIAJA");

          createChannel("BENSIINIAJA");
      });

Kontrollisime, et kanali ei ole. Võtsime lukustuse, kontrollisime uuesti, lõime kanali. Kui lukustuse võtmisel ei kontrolli, on võimalus, et teine thread kontrollis samuti ja proovib luua sama arutelu – aga see juba eksisteerib. Lukustamine synchronized või tavalise java Lockiga ei ole võimalik. Andmebaasi kaudu – aeglane, ja andmebaasi on kahju, Hazelcasti kaudu – see on just see, mida vajame.

Valime andmebaasi

Meil on suur ja edukas kogemus PostgreSQL-i ja selle andmebaasi arendajatega koostöös.

PostgreSQL-i klastri haldamine on keeruline – there are XL, XC, Citus, kuid see ei ole põhimõtteliselt noSQL, mis skaleeruvad kohe välja. NoSQL-i peamise salvestusena ei kaalutud, sest piisavalt on, et võtame Hazelcasti, millega pole varem töötatud.

Kui on vaja mõõta relatiivset andmebaasi – see tähendab, sharding. Nagu teate, jagame andmebaasi eraldi osadeks, et igaüks neist saaks viia eraldi serverisse.

Meie sharding’i esimene variant võimaldas iga meie rakenduse tabeli eraldamise erinevatesse serveritesse erinevates proportsioonides. Palju sõnumeid serveris A – tulge, viime osa sellest tabelist serverisse B. Selline lahendus karjus varajase optimeerimise järele, seega otsustasime piirduda multi-tenant lähenemisega.

Multi-tenant’i kohta saab lugeda näiteks veebisaidilt Citus Data.

SV-s on rakenduse ja tellija mõisted. Rakendus on konkreetne ärirakenduse installatsioon, näiteks ERP või raamatupidamine, koos oma kasutajate ja äriandmetega. Tellija on organisatsioon või füüsiline isik, kelle nimel rakenduse registreerimine SV-serveris toimub. Tellijal võib olla registreeritud mitmeid rakendusi, ja need rakendused saavad omavahel teateid vahetada. Tellija on meie süsteemis nüüd elanik (tenant). Mitme tellija teated võivad asuda ühes füüsilises andmebaasis; kui me näeme, et mõni tellija genereerib palju liiklust, viime ta eraldi füüsilisse andmebaasi (või isegi eraldi DB-serverisse).

Meil on peamine andmebaas, kus hoitakse marsruutimistabelit, mis sisaldab teavet kõigi tellijate andmebaaside asukoha kohta.

Kuna peamine andmebaas ei tohiks olla kitsas koht, hoiame marsruutimistabelit (ja teisi sageli nõutavaid andmeid) mälus.

Kui tellija andmebaas hakkab pidurdama, jagame selle osadeks. Teistes projektides kasutame suurte tabelite partitsioneerimiseks pg_pathman.

Kuna kasutajate sõnumite kaotamine on halb, hoiame oma andmebaase koopiatega. Sünkroonsete ja asünkroonsete koopiate kombinatsioon võimaldab end kaitsta peamise andmebaasi kaotuse korral. Sõnumi kaotus toimub ainult siis, kui peamine andmebaas ja selle sünkroonne koopia ebaõnnestuvad samal ajal.

Kui sünkroonne koopia kaob, muutub asünkroonne koopia sünkroonseks.
Kui peamine andmebaas kaob, muutub sünkroonne koopia peamiseks andmebaasiks, asünkroonne koopia – sünkroonseks koopiaks.

Elasticsearch otsinguks

Kuna lisaks muule on SV ka sõnumivahetus, vajatakse siin kiiret, mugavat ja paindlikku otsingut, arvestades morfoloogiat ja ebatäpset vastavust. Otsustasime mitte ratast leiutada ja kasutame avatud allika otsingusüsteemi Elasticsearch, mis on loodud Lucene raamatukogul. Lucene. Elasticsearchi käitame samuti klustis (master – data – data), et vältida probleeme, kui rakenduse sõlmed ebaõnnestuvad.

Githubl leidsime vene morfoloogia plugina Elasticsearchi jaoks ja kasutame seda. Elasticsearchi indeksis hoiame sõnade juuri (mida määratleb plugin) ja N-gramme. Kui kasutaja sisestab otsinguteksti, otsime sisestatud teksti N-grammide hulgast. Indeksisse salvestamisel jaguneb sõna «tekstid» järgnevateks N-grammideks:

[te, tek, tekst, tekstid, ek, eks, ekst, ekstid, ks, kst, kstid, st, stid, id,],

Samuti salvestatakse sõna «tekst» juur. Selline lähenemine võimaldab otsida nii sõna alguses, keskel kui ka lõpus.

Ülevaade

Pilt, mille kordame artikli alguses, kuid nüüd koos selgitustega:

• Tasakaalustaja, mis on seatud internetti; meil on – nginx, see võib olla mis tahes.
• Java rakenduste instantsid suhtlevad omavahel läbi Hazelcasti.
• Veebivoodete haldamiseks kasutame Netty.
• Java rakendus on kirjutatud Java 8 keeles ja koosneb bändlitest OSGi. Plaanis on migreerida Java 10 peale ja liikuda moodulite juurde.

Arendamine ja testimine

Arendamise ja testimise protsessis kohtasime mitmeid huvitavaid tooteomadusi, mida kasutasime.

Koormustestimine ja mälu leke

Iga väljaande koormustestimine on koormustestimine. See on edukalt läbitud, kui:

• Test töötas mitmeid ööpäevi ja teeninduses ei olnud katkestusi
• Peamiste toimingute vastuse aeg ei ületanud mugavat piiri
• Tootlikuse halvenemine võrreldes eelmisel versiooniga ei ületanud 10%

Testimisandmebaasi täidame andmetega – selleks saame tootmisserverilt kõige aktiivsema abonendi andmed, korrutame tema numbrid 5-ga (sõnumite, arutelude, kasutajate arv) ja testime nii.

Teeme süsteemi koormustestimist kolmes konfiguratsioonis:

1. Stressitest
2. Ainult ühendused
3. Abonentide registreerimine

Stressitestis käivitame mitusada lõime, mis pidevalt koormavad süsteemi: saadavad sõnumeid, loovad arutelusid, saavad sõnumite nimekirja. Simuleerime tavaliste kasutajate (oma lugemata sõnumite nimekirja saamine, kellelegi kirjutamine) ja tarkvaralahenduste tegevust (paketi edastamine teise konfiguratsiooni, teate töötlemine).

Näiteks selline on osa stressitestist:

• Kasutaja siseneb süsteemi
  • Küsimus oma lugemata arutelude kohta
  • 50% tõenäosusega loeb sõnumeid
  • 50% tõenäosusega kirjutab sõnumeid
  • Siiski kasutaja:
    • Loob uue arutelu 20% tõenäosusega
    • Valib juhuslikult mõne oma arutelu
    • Siseneb sisse
    • Küsimus sõnumite, kasutajaprofiilide kohta
    • Loob viis sõnumit, mis on suunatud juhuslikele kasutajatele sellest arutelust
    • Väljub arutelust
    • Kordab 20 korda
    • Logib välja, naaseb tagasi stsenaariumi algusesse

  • Süsteemi siseneb vestlusrobot (emuleerib sõnumite vahetust rakenduste koodist)
    • Loob 50% tõenäosusega uue kanali andmevahetuseks (eriline arutelu)
    • Kirjutab 50% tõenäosusega sõnumi mis tahes olemasolevatesse kanalitesse

Stsenaarium „Ainult ühendused” ei ilmunud lihtsalt juhuslikult. On olukordi: kasutajad on süsteemi ühendatud, kuid pole veel sellesse sisse harjunud. Iga kasutaja käivitab hommikul kell 09:00 arvuti, loob ühenduse serveriga ja vaikib. Need mehed on ohtlikud, neid on palju – paketides on vaid PING/PONG, kuid nad hoidke ühendust serveriga (nad ei saa mitte hoida – äkki tuleb uus sõnum). Test korratakse olukorras, kus kahe tunni jooksul püüab suure arv kasutajaid süsteemi autoriseerida. See sarnaneb stressitestiga, kuid keskendub just sellele esimesele sisenemisele – et poleks tõrkeid (inimene ei kasuta süsteemi, kuid see juba kukub välja – raske on välja mõelda midagi hullemat).

Tellijate registreerimise stsenaarium algab esimese käivitamisega. Me tegime stressitesti ja olime kindlad, et kirjavahetuses süsteem ei tõrgu. Kuid kasutajad hakkasid tulema ja registreerimine hakkas aeganõudlikult välja kukkuma. Registreerimisel kasutasime /dev/random, mis on seotud süsteemi entropiaga. Server ei jõudnud koguda piisavalt entropiat ja uue SecureRandom'i päringu juures hangus see kümneteks sekunditeks. Sellest olukorrast on palju väljapääse, näiteks: minna vähem turvaliselt /dev/urandom'i, paigaldada eraldi plaat, mis genereerib entropiat, genereerida juhuslikke numbreid eelnevalt ja hoida neid basseinides. Me sulgesime probleemi ajutiselt basseiniga, kuid alates sellest ajast teeme eraldi testi uute tellijate registreerimiseks.

Koormuse generaatorina kasutame JMeter. Töötada veebisoketiga ei oska, vajame plugina. Esimeste seas otsingutulemustes otsides „jmeter websocket” tulevad artiklid BlazeMeter, milles soovitatakse plugina Maciej Zaleski.

Seda me otsustasime alustada.

Peaaegu kohe pärast tõsise testimise alustamist avastasime, et JMeteris on hakanud esinema mälulekkeid.

Plugin – see on eraldi suur lugu, 176 tähte on tal 132 fork’i githubis. Autor ei ole sellesse alates 2015. aastast kommenteerinud (me võtsime selle 2015. aastal, siis see ei tekitanud kahtlusi), mitmed githubi probleemid mälulekete osas, 7 lahendamata pull requesti.
Kui otsustate seda pluginit koormustestimiseks kasutada, siis pöörake tähelepanu järgmistele aruteludele:

1. Mitme lõime keskkonnas kasutati tavalist LinkedList’i, mille tulemusena saime NPE käitusaegsel. Probleem lahendatakse kas üleminekuga ConcurrentLinkedDeque’ile või sünkroniseeritud plokkidega. Valisime enda jaoks esimese variandi (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/43).
2. Mäluleke, ühenduse katkestamisel ei kustutata ühenduse teavet (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/44).
3. Streaming režiimis (kui websocket ei suletud lõpliku näitamises, vaid seda kasutatakse edasi plaanis) ei tööta Response pattern’id (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/19).

See on üks neist, mis on githubis. Mida me tegime:

1. Võtsime Elyran Kogani forki (@elyrank) – seal on lahendatud probleemid 1 ja 3
2. Lahendasime probleemi 2
3. Uuendasime jetty 9.2.14 versioonilt 9.3.12-le
4. Mähkime SimpleDateFormat’i ThreadLocal’isse; SimpleDateFormat ei ole lõime ohutu, mis põhjustas NPE käitusaegsel
5. Selle mälulekke kõrvaldasime (ühendus ei olnud katkestatud õigesti)

Ja siiski, see lekib!

Mälu hakkas otsa saama mitte päevaga, vaid kahega. Aega ei jäänud üldse, otsustasime käivitada vähem lõime, kuid neljal agendil. Seda peaks piisama vähemalt nädalaks.

Kaks päeva möödus…

Nüüd hakkas Hazelcast’il mälu otsa saama. Logides oli näha, et paar päeva testimist järel hakkab Hazelcast kurtma mälu puuduse üle, ja mõne aja pärast kaob klaster ja nodid jätkavad üksikute hukkumist. Ühendatud JVisualVM Hazelcast’iga ja nägime "üles jõudvat sae" – see kutsus regulaarselt välja GC, kuid ei suutnud kuidagi mälu puhastada.

Selgus, et hazelcast 3.4 versioonis ei vabastata mälumaalt täielikult: map / multiMap'i kustutamisel (map.destroy())

github.com/hazelcast/hazelcast/issues/6317
github.com/hazelcast/hazelcast/issues/4888

Nüüd on viga parandatud 3.5 versioonis, kuid tol hetkel oli see probleem. Loodime uusi multiMap’e dünaamiliste nimedega ja kustutasime vastavalt meie loogikale. Kood nägi välja umbes nii:

public void join(Authentication auth, String sub) {
    MultiMap sessions = instance.getMultiMap(sub);
    sessions.put(auth.getUserId(), auth);
}

public void leave(Authentication auth, String sub) {
    MultiMap sessions = instance.getMultiMap(sub);
    sessions.remove(auth.getUserId(), auth);

    if (sessions.size() == 0) {
        sessions.destroy();
    }
}

Kutsumine:

service.join(auth1, "UUED_SÕNUMID_ARUTEL_UUID1");
service.join(auth2, "UUED_SÕNUMID_ARUTEL_UUID1");

multiMap loodi iga tellimuse jaoks ja eemaldati, kui see ei olnud enam vajalik. Otsustasime, et loome Map ning võti on tellimuse nimi ja väärtused on seansi identifikaatorid (mille kaudu saab hiljem vajadusel kasutajate identifikaatoreid kätte).

public void join(Authentication auth, String sub) {
    addValueToMap(sub, auth.getSessionId());
}

public void leave(Authentication auth, String sub) { 
    removeValueFromMap(sub, auth.getSessionId());
}

Graafikud on korrigeeritud.

Mida me veel õppisime koormustestimise kohta

1. JSR223 tuleb kirjutada groovy's ning lisada koostamise vahemälu - see on oluliselt kiirem. Link.
2. Jmeter-Plugins graafikud on lihtsamad mõista kui standardsed. Link.

Meie kogemus Hazelcast'iga

Hazelcast oli meile uus toode, alustasime selle kasutamist versiooniga 3.4.1, praegu on meie tootmiserveris versioon 3.9.2 (artikli kirjutamise hetkel on viimane versioon Hazelcast 3.10).

ID genereerimine

Alustasime täisarvuliste identifikaatoritega. Kujutame ette, et me vajame uut Long uut tüüpi entiteedi jaoks. Järjekord andmebaasis ei sobi, tabelid osalevad jagamises - tuleb välja, et andmebaasis 1 on sõnum ID=1 ja andmebaasis 2 on sõnum ID=1, Elasticsearch'is sellise ID-ga sa ei saa, Hazelcast'is samuti, aga kõige hullem on, kui soovid andmed kahest andmebaasist üheks koos viia (nt kui otsustad, et üks andmebaas piisab nende tellijate jaoks). Hazelcast'is saab luua mitu AtomicLong'i ja hoida loenduri seal, siis on uue ID saamise efektiivsus - incrementAndGet pluss aeg Hazelcast'isse päringu tegemiseks. Kuid Hazelcast'is on midagi veel optimaalsemat - FlakeIdGenerator. Iga kliendi juurde, kui ta pärib, antakse ID-de vahemik, näiteks esimesena - 1 kuni 10 000, teise jaoks - 10 001 kuni 20 000 ja nii edasi. Nüüd võib klient ise uusi identifikaatoreid väljastada, kuni tema antud vahemik saab otsa. See töötab kiiresti, kuid rakenduse (ja Hazelcast'i kliendi) taaskäivitamisel algab uus järjestus - sealt tulenevad vaheajaks jäävad ja jne. Lisaks ei ole arendajatele kuigi selge, miks ID-d on täisarvud, kuid nad on nii korralikult valdavalt segaduses. Me kaalusime kõik üle ja läksime UUID-dele üle.

Üks asi, mis puudutab neid, kes tahavad olla nagu Twitter, on olemas selline teek, nagu Snowcast - see on Snowflake'i rakendus Hazelcast'i peal. Vaadata saab siit:

github.com/noctarius/snowcast
github.com/twitter/snowflake

Aga me pole veel sinna jõudnud.

TransactionalMap.replace

Veel üks üllatus: TransactionalMap.replace ei tööta. Siin on selline test:

@Test
public void replaceInMap_putsAndGetsInsideTransaction() {

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            context.getMap("map").put("key", "oldValue");
            context.getMap("map").replace("key", "oldValue", "newValue");
            
            String value = (String) context.getMap("map").get("key");
            assertEquals("newValue", value);

            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }
    });
}

Oodatud: newValue
Tegelik: oldValue

Pidime kirjutama oma replace'i, kasutades getForUpdate:

protected  boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
    TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
    if (context != null) {
        log.trace("[CACHE] Asendamine väärtusele tehingulises kaardis");
        TransactionalMap map = context.getMap(mapName);
        V value = map.getForUpdate(key);
        if (oldValue.equals(value)) {
            map.put(key, newValue);
            return true;
        }

        return false;
    }
    log.trace("[CACHE] Asendamine väärtusele mitte tehingulises kaardis");
    IMap map = hazelcastInstance.getMap(mapName);
    return map.replace(key, oldValue, newValue);
}

Testige mitte ainult tavalisi andmestruktuure, vaid ka nende tehingulisi versioone. Juhtub, et IMap töötab, aga TransactionalMap ei töötata.

Uue JAR'i allalaadimine ilma katkestuseta

Esialgu otsustasime salvestada Hazelcast'i oma klasside objekte. Näiteks, meil on klass Application, me tahame selle salvestada ja lugeda. Salvestame:

IMap map = hazelcastInstance.getMap("application");
map.set(id, application);

Loeme:

IMap map = hazelcastInstance.getMap("application");
return map.get(id);

Kõik töötab. Siis otsustasime luua Hazelcast'is indeksi, et selle kaudu otsida:

map.addIndex("subscriberId", false);

Ja kui salvestasime uue üksuse, hakkasime saama ClassNotFoundException'i. Hazelcast üritas indeksi täiendada, kuid ei teadnud meie klassist midagi ja tahtis, et me pakuksime selle klassi JAR'i. Me tegime seda ja kõik töötas, kuid tekkis uus probleem: kuidas uuendada JAR'i ilma klastrite täieliku peatamiseta? Hazelcast ei võta uut JAR'i vastu versioonivärskenduse ajal. Sel hetkel otsustasime, et saame elada ilma indeksi otsimiseta. Lõppude lõpuks, kui kasutada Hazelcast'i võtme-väärtuse salvestusena, kas kõik toimib? Mitte päris. Siin on jälle erinev käitumine IMap'i ja TransactionalMap'i vahel. Seal, kus IMap'il pole vahet, TransactionalMap viskab vea.

IMap. Salvestame 5000 objekti, loeme sisse. Kõik on ootuspärane.

@Test
void get5000() {
    IMap map = hazelcastInstance.getMap("application");
    UUID subscriberId = UUID.randomUUID();

    for (int i = 0; i < 5000; i++) {
        UUID id = UUID.randomUUID();
        String title = RandomStringUtils.random(5);
        Application application = new Application(id, title, subscriberId);
        
        map.set(id, application);
        Application retrieved = map.get(id);
        assertEquals(id, retrieved.getId());
    }
}

Aga tehingutes ei tööta, saame ClassNotFoundException:

@Test
void get_transaction() {
    IMap map = hazelcastInstance.getMap("application_t");
    UUID subscriberId = UUID.randomUUID();
    UUID id = UUID.randomUUID();

    Application application = new Application(id, "qwer", subscriberId);
    map.set(id, application);
    
    Application retrievedOutside = map.get(id);
    assertEquals(id, retrievedOutside.getId());

    hazelcastInstance.executeTransaction(context -> {
        HazelcastTransactionContextHolder.setContext(context);
        try {
            TransactionalMap transactionalMap = context.getMap("application_t");
            Application retrievedInside = transactionalMap.get(id);

            assertEquals(id, retrievedInside.getId());
            return null;
        } finally {
            HazelcastTransactionContextHolder.clearContext();
        }
    });
}

3.8 versioonis ilmus User Class Deployment mehhanism. Saate määrata ühe peamise sõlme ja värskendada JAR-faili sellel.

Nüüd oleme täielikult lähenemist muutnud: ise serializeerime JSON-iks ja salvestame Hazelcasti. Hazelcast ei pea teadma meie klasside struktuuri ning me saame värskendusi teha ilma seiskamiseta. Domeeniobjektide versioonimist haldab rakendus. Erinevad rakenduse versioonid võivad töötada samaaegselt, ja võib esineda olukord, kus uus rakendus kirjutab objekte uute väljadega, samas kui vana rakendus neid välju ei tunne. Ja samal ajal loeb uus rakendus objekte, mille on kirjutanud vana rakendus, millel ei ole uusi väljasid. Selliseid olukordi käsitleme rakenduse sees, kuid lihtsuse huvides ei muuda ega kustuta välju, vaid laiendame klasse, lisades uusi välju.

Kuidas me tagame kõrge jõudluse

Neli päringut Hazelcastis – hea, kaks andmebaasis – halb

Andmete hankimine vahemälust on alati parem kui andmebaasist, kuid ei soovi ka hoida kasutamata kirjeid. Otsuse selle kohta, mida vahemälus hoida, lükkame arenduse viimasesse etappi. Kui uus funktsionaalsus on kodeeritud, aktiveerime PostgreSQL-is kõigi päringute logimise (log_min_duration_statement 0-le) ja viime läbi koormustestimise umbes 20 minutiks. Kogutud logide põhjal suudavad sellised utiliidid nagu pgFouine ja pgBadger koostada analüütilisi raportite. Raportis otsime esmalt aeglaseid ja sagedasi päringuid. Aeglaste päringute puhul koostame teostusplaani (EXPLAIN) ja hindame, kas sellist päringut on võimalik kiirendada. Sageli esinevad päringud, mis tuginevad samadele sisenditele, sobivad hästi vahemälus hoidmiseks. Püüame hoida päringud "tasapinnalised", käsitledes ühte tabelit ühes päringus.

Käitus

SV kui veebiteenus käivitus 2017. aasta kevadel ja kui eraldi toode ilmus SV novembris 2017 (tol hetkel beetaversioonina).

Ühe aasta jooksul ei ole SV veebiteenuse töös tõsiseid probleeme olnud. Jälgime veebiteenust läbi Zabbix, kogume ja paigaldame läbi Bamboo.

SV serveri installatsioon pakutakse natiivsete paketina: RPM, DEB, MSI. Lisaks pakume Windowsile ühte installijat, mis on ühe EXE vormis, mis installeerib serveri, Hazelcasti ja Elasticsearchi ühele masinale. Alguses nimetasime seda installatsiooni "demonstreerivaks" versiooniks, kuid nüüd on selge, et see on kõige populaarsem juurutusvariant.

Allikas: habr.com