Kuidas ja miks me kirjutasime suure koormuse talumisega skaleeritava teenuse 1C: Ettevõtted jaoks: Java, PostgreSQL, Hazelcast

Selles artiklis räägime, kuidas ja miks me arendasime Koostöö süsteemi – mehhanism, mis edastab teavet kliendirakenduste ja 1C:Enterprise serverite vahel – ülesande seadmisest arhitektuuri ja rakenduse üksikasjade väljatöötamiseni.

Koostöö süsteem (edaspidi – KS) on hajutatud tõrketaluv sõnumite vahetamise süsteem tagatud kohaletoimetamisega. KS on loodud kõrgendatud koormuse teenusena, millel on kõrge mastaapsus ning on saadaval nii veebiteenusena (mida pakub 1C) kui ka seeriatootena, mida saab juurutada oma serveriressurssidesse.

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

Ülesande seadmine

Et oleks selge, miks me Koostöö süsteemi tegime, räägin veidi sellest, kuidas 1C-s ärirakenduste arendamine toimub.

Alustuseks – natuke meie kohta neile, kes veel ei tea, millega me tegeleme:) Me arendame tehnoloogiaplatvormi "1C:Ettevõte". Platvorm sisaldab ärirakenduste arendustööriistu ja runtime'i, mis võimaldab ärirakendustel töötada ristplatvormil.

Kliendiserveri arenduspõhimõte

Ärirakendused, mis on loodud "1C:Ettevõtte" peal, töötavad kolmekihilise kliendiserveri arhitektuuri "DBMS – rakendusserver – klient". Rakenduslik kood, mis on kirjutatud 1C sisseehitatud keeles, võib käivituda kas rakendusserveris või kliendis. Kõik rakendusobjektidega (näiteks registrite, dokumentide jne) seotud tehingud, samuti andmebaasi lugemine ja kirjutamine toimub ainult serveris. Vormide ja käsurea funktsionaalsus on samuti rakendatud serveris. Kliendis toimub vormide saamine, avamine ja kuvamine, kasutajaga "suhtlemine" (hoiatuste, küsimuste jne kaudu), väiksed arvutused vormides, mis vajavad kiiret reageerimist (näiteks hinna korrutamine kogusega), kohalike failidega töötamine, seadmetega töötamine.

Rakenduskoodis peavad protseduuride ja funktsioonide pealkirjades olema selgelt märgitud, kus kood täidetakse - kasutades direktiive &НаКлиенте / &НаСервере (&AtClient / &AtServer ingliskeelses keeleversioonis). 1C arendajad parandavad mind nüüd, öeldes, et direktiive tegelikult suurem, kuid meile pole see praegu oluline.

Kliendikoodist saab kutsuda serverikoodi, kuid serverikoodist kliendikoodi kutsuda ei saa. See on meie kehtestatud fundamentaalne piirang mitmel põhjusel. Esiteks, serverikood peab olema kirjutatud nii, et see täitub ühtemoodi, sõltumata sellest, kust seda kutsutakse - kliendilt või serverilt. Ja juhul, kui serverikoodi kutsutakse teise serverikoodi seest, puudub klient täielikult. Ja samuti seetõttu, et serverikoodi täitmise käigus võis klient, kes selle kutsus, sulgeda, rakendusest välja minna, ja serveril ei ole enam kedagi, keda kutsuda.

Nupu vajutamise töötav kood: kliendi serveriprotseduuri kutsumine töötab, serverilt kliendiprotseduuri kutsumine - ei.

See tähendab, et kui me serverist tahame edastada mingit sõnumit kliendirakendusse, näiteks et "pikaajalise" raporti genereerimine on lõppenud ja raportit on võimalik vaadata – sellist võimalust meil ei ole. Peame kasutama trikke, näiteks kliendikoodist perioodiliselt serverit küsima. Kuid selline lähenemine koormab süsteemi liigsete väljakutsetega ja ei tundu eriti élégantsena.

Ja on ka vajadus, näiteks, kui telefonikõne SIP-teavitada sellest klienditeavet, et see leidu jätkuvalt helistaja numbri järgi personaalsetest andmetest ja näitaks kasutajale teavet helistava kliendi kohta. Või näiteks, kui laos on tellimus, teavitada sellest kliendi rakendust tellijale. Ühesõnaga, olukordi, kus selline mehhanism võiks kasuks tulla, on palju.

Tegelikult ülesanne

Loo sõnumite vahetamise mehhanism. Kiire, usaldusväärne, garantii kohaletoimetamine, võimalus sõnumite paindlikuks otsimiseks. Mehhanismi põhjal rakenda sõnumi rakendus (sõnumid, videokõned), mis töötab 1C rakendustes.

Kujundada horisontaalselt skaleeritav süsteem. Suurenev koormus peab olema katnud sõlmede arvu suurendamisega.

Rakendus

Otsustasime, et SV serveriosa ei integreerita otse 1C:Enterprise platvormi, vaid rakendatakse eraldi tootena, mille API-d saab kutsuda 1C rakenduste lahenduste koodist. Seda tehti mitmel põhjusel, millest kõige olulisem on võimaldada sõnumite vahetust erinevate 1C rakenduste vahel (näiteks kaubanduse juhtimise ja raamatupidamise vahel). Erinevad 1C rakendused võivad töötada erinevate 1C:Enterprise platvormi versioonide peal, asuda erinevates serverites jne. Sellistes tingimustes on SV teostamine eraldi tootena, mis asub 1C installatsioonidest „külg“ - optimaalne lahendus.

Nii et, otsustasime, et teeme SV-st eraldi toote. Väikestele ettevõtetele soovitame kasutada SV-serverit, mille oleme oma pilves üles seadnud (wss://1cdialog.com), et vältida kohaliku installatsiooni ja seadistamisega seotud kulusid. Suuremad kliendid võivad aga leida, et nende võimsustele oma SV-serveri seadmine on õigustatud. Sarnast lähenemist kasutasime ka oma pilvepõhises SaaS-toote puhul. 1cFresh – see on välja antud kui versioonitoode klientide installimiseks ning samuti on see meie pilves üles seatud. https://1cfresh.com/.

Rakendus

Koormuse ja tõrke talumise saavutamiseks seame üles mitte ühe, vaid mitu Java-rakendust ja nende ette paneme koormuse tasakaalustaja. Kui sõnumit peab node'ilt node'ile edastama, kasutame Hazelcastis publish/subscribe süsteemi.

Kliendi suhtlemine serveriga toimub websocket'i kaudu. See sobib hästi reaalajas süsteemide jaoks.

Jaotatud vahemälu

Otsisite Redis, Hazelcasti ja Ehcache'i vahel. Aasta on 2015. Redis just lahkus uuest klastri versioonist (liialt uus, hirmutav), Sentineli kuulub hulk piiranguid. Ehcache ei oska kokku koguneda (see funktsionaalsus tuli hiljem). Otsustasime proovida Hazelcast 3.4.
Hazelcast koguneb klastri «kastist välja». Ühe sõlme režiimis pole see eriti kasulik ja sobib ainult vahemäluna – ei oska andmeid kettale salvestada; kaotasime ainulaadse sõlme – kaotasime andmed. Me paigutame mitu Hazelcasti ja varundame kriitilisi andmeid nende vahel. Vahemälu ei varunda – seda ei ole kahju.

Meie jaoks on Hazelcast:

• Kasutaja sessioonide salvestus. Iga kord, kui minema baasi sessiooni järele minna – võtab kaua aega, seetõttu paneme kõik sessioonid Hazelcasti.
• Vahemälu. Otsid kasutaja profiili – kontrolli vahemälus. Kirjutasid uue sõnumi – pane vahemällu.
• Rakenduse instantside suhtlemise teemad. Sõlm genereerib sündmuse ja asetab selle Hazelcasti teemasse. Teised rakenduse sõlmed, mis sellele teemale on tellinud, saavad ja töötlevad sündmust.
• Klastri lukustused. Näiteks loome arutelu unikaalse võtme alusel (süntesaator arutelu 1C andmebaasi raames):

conversationKeyChecker.check("BENSOKOLONKA");

      doInClusterLock("BENSOKOLONKA", () -> {

          conversationKeyChecker.check("BENSOKOLONKA");

          createChannel("BENSOKOLONKA");
      });

Kontrollisime, et kanal puudub. Võtsime lukustuse, kontrollisime uuesti, lõime. Kui lukustust ei kontrollita, on võimalus, et mõni teine teema, mis sel ajal samuti kontrollis, proovib luua sama arutelu – ja see juba eksisteerib. Lukustust ei saa teha synchronized või tavalise java Lock abil. Andmebaasi kaudu – aeglane, ja andmebaasi ka kahju, Hazelcast läbi – see on just see, mida vajame.

Valime DBMS-i

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

PostgreSQL-i klustereerimine on keeruline – on XL, XC, Citus, kuid see ei ole iseenesest noSQL, mis on välja pakutud mastiks. Me ei pidanud noSQL-i peamise salvestuslahendusena, piisab sellest, et kasutame Hazelcasti, millega me varem pole töötanud.

Kui tuleb skaleerida relatsiooni DB – siis tähendab see sharding. Nagu te teate, jagame shardinguga andmebaasi eraldi osadeks, nii et igaüht neist saab viia eraldi serverisse.

Meie esimene sharding'i variant eeldas, et saame jagada meie rakenduse iga tabeli erinevatesse serveritesse erinevates proportsioonides. Kui serveris A on palju sõnumeid – palun, viige osa sellest tabelist serverisse B. See lahendus oli selgelt enneaegne optimeerimine, seetõttu otsustasime piirduda multi-tenant lähenemisega.

Multi-tenant'i kohta saate lugeda näiteks veebisaidilt Citus Data.

SV-s on määratlused rakenduse ja tellija kohta. 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 rakendus registreeritakse SV serveris. Tellijal võib olla registreeritud mitu rakendust, ning need rakendused saavad omavahel sõnumeid vahetada. Tellija on meie süsteemis muutunud elanikuks (tenant). Mitme tellija sõnumid 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 andmebaasi serverisse).

Meil on peamine andmebaas, kus hoitakse suunamise tabelit kõigi tellijate andmebaaside asukoha teabega.

Kuna peamine andmebaas ei tohi olla kitsaskoht, hoiame suunamise tabelit (ja muid sageli kasutatavaid andmeid) vahemälus.

Kui tellija andmebaas hakkab aeglustuma, lõikame selle sees osadeks. Teistes projektides kasutame suurte tabelite partitsioneerimiseks pg_pathman.

Kuna kasutajate sõnumite kadumine on halb, toetame meie andmebaase koopiatega. Sünkroonsete ja asünkroonsete koopiate kombinatsioon võimaldab meil kindlustada end peamise andmebaasi kadumise korral. Sõnumi kadu 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, et SV on lisaks muule ka sõnumiteenus, on hädavajalik kiire, mugav ja paindlik otsing, mis arvestab morfoloogiat ja ebakorrektseid vasteid. Otsustasime, et ei hakka ratast leiutama ja kasutame avatud otsingusüsteemi Elasticsearch, mis on loodud Lucene'i raamatukogu põhjal. Lucene. Elasticsearchi deployime ka klastris (master – data – data), et vähendada rakenduse sõlmede rikkeprobleemide riski.

Githubis leidsime vene morfoloogia plugin Elasticsearchile ja kasutame seda. Elasticsearchi indeksis hoiame sõnade juured (mida määrab plugin) ja N-grammid. Kui kasutaja sisestab otsinguteksti, otsime sisestatud teksti N-grammide hulgast. Indeksi salvestamisel sõna „tekstid“ jaguneb järgmistesse N-grammidesse:

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

Ning ka salvestatakse sõna „tekst“ juur. Selline lähenemine võimaldab otsida nii sõna algust, keskel kui ka lõpust.

Üldine pilt

Kuvab sama pilti artikli algusest, kuid juba seletustega:

• Tasakaalustaja, mis on Interneti-suunas; meil on nginx, võib olla ükskõik milline.
• Java rakenduste instantsid suhtlevad omavahel läbi Hazelcasti.
• Veebisoketiga töötamiseks kasutame Netty.
• Java rakendus on kirjutatud Java 8 keeles, koosneb bundeledest OSGi. Plaanides on üleminek Java 10-le ja modulaarsele arhitektuurile.

Arendus ja testimine

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

Koormustestimine ja mälu leketud

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

• Test kestis mitu päeva ja teenusekatkestusi ei esinenud
• Peamiste toimingute vastuse aeg ei ületanud mugavat piiri
• Tootlikuse halvenemine võrreldes eelmise versiooniga ei ole üle 10%

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

Koormustestimist süsteemi interaktsiooni teeme kolmes konfiguratsioonis:

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

Stressitestil käivitame mitu sada voogu, mis pidevalt koormavad süsteemi: kirjutavad sõnumeid, loovad arutelusid, saadavad sõnumite nimekirja. Imitseerime tavaliste kasutajate tegevusi (saada oma lugemata sõnumite nimekiri, kellelegi kirjutada) ja programmilisi lahendusi (üle anda pakett erineva konfiguratsiooniga, töödelda teadet).

Näiteks, nii näeb välja osa stressitestist:

• Süsteemi siseneb kasutaja
  • Küsimus oma lugemata arutelude kohta
  • 50% tõenäosusega loeb sõnumeid
  • 50% tõenäosusega kirjutab sõnumeid
  • Edasi jätkab kasutaja:
    • 20% tõenäosusega loob uue arutelu
    • Valib juhuslikult mõne oma arutelu
    • Siseneb sisse
    • Küsimus sõnumeid, kasutajate profiile
    • Loob viis sõnumit, mis on suunatud juhuslikele kasutajatele sellest arutelust
    • Lahkub arutelust
    • Kordab 20 korda
    • Lahkub süsteemist, naaseb stsenaariumi algusesse

  • Süsteemi siseneb chatbot (imiteerib sõnumivahetust rakenduste koodist)
    • 50% tõenäosusega loob uue kanali andmevahetuseks (eriline arutelu)
    • 50% tõenäosusega saadab sõnumi mõnes olemasolevas kanalisse

Skeem «Ainult ühendused» ei ilmnenud juhuslikult. On olukordi: kasutajad on süsteemi lülitanud, kuid pole veel sisse harjunud. Iga kasutaja lülitab hommikul kell 09:00 arvuti sisse, loob serveriga ühenduse ja vaikib. Need tüübid on ohtlikud, neid on palju – nende paketid sisaldavad ainult PING/PONG, kuid nad hoiavad serveriga ühendust (nad ei saa seda mitte hoida – äkki tuleb uus sõnum). Test simuleerib olukorda, kus süsteemi püüab poole tunni jooksul sisse logida suur hulk selliseid kasutajaid. See on sarnane stressitestiga, kuid see keskendub just sellele esimeses sisenemises – et ei toimuks tõrkeid (inimene ei kasuta süsteemi, kuid see juba ebaõnnestub – raske on midagi hullemat välja mõelda).

Kasutajate registreerimise skeem algab esimesest käivitamisest. Me tegime stressitesti ja olime kindlad, et kirjavahetuse käigus süsteem ei aeglustu. Kuid kasutajad hakkasid sisse logima ja registreerimine hakkas ajapiirangute tõttu ebaõnnestuma. Registreerimisel kasutasime /dev/random, mis on seotud süsteemi entropiaga. Server ei jõudnud piisavalt entropiat koguda ning uue SecureRandom'i nõudmisel seiskus see kümneid sekundeid. Sellest olukorrast on palju väljapääse, näiteks: minna üle vähem turvalisele /dev/urandom'ile, paigutada spetsiaalne kaart, mis genereerib entropiat, genereerida juhuslikke numbreid ette ja hoida neid teas. Me lahendasime probleemi ajutiselt puuga, kuid alates sellest ajast juhime eraldi testi uute tellijate registreerimise osas.

Koormuse generaatorina kasutame JMeter. See ei oska töötada veebipõhiste soketitega, vajalik on plugin. Esimesed otsingutulemustes otsingus "jmeter websocket" on artiklid BlazeMeter'ilt, milles soovitatakse pluginat Maciej Zaleskilt.

. Sellest me ka alustasime.

Peaaegu kohe pärast tõsiste testide alustamist avastasime, et JMeter'is algasid mäluleked.

Plugin – see on eraldi suur lugu, 176 tähega on tal 132 fork'i github'is. Autor ei ole sinna 2015. aastast kommenteerinud (me kasutasime seda 2015. aastal, siis see ei tekitanud kahtlusi), mitmeid github'i probleeme seoses mäluleketega, 7 lahendamata pull request'i.
Kui otsustate testida koormust selle pluginaga, pöörake tähelepanu järgmistele aruteludele:

1. Mitme haru süsteemis kasutati tavalist LinkedList'i, mille tulemusena saadi NPE käitamisel. Selle saab lahendada, kas liikudes ConcurrentLinkedDeque'i juurde või kasutades synchronized-blokke. Otsustasime esimese variandi kasuks (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/43).
2. Mälu leke, teabe kustutamine ühenduse katkestamise korral ei toimi (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/44).
3. Streaming-režiimis (kui veebisoket ei suleta proovi lõpus, vaid kasutatakse edasi) ei tööta Response pattern'id (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/19).

See on üks neist, mis on github'is. Mida tegime:

1. Võtsime Elyran Kogani forki (@elyrank) – seal on lahendatud probleemid 1 ja 3
2. Lahendasime probleemi 2
3. Uuendasime jetty versioonilt 9.2.14 9.3.12-le
4. Kapseldasime SimpleDateFormat'i ThreadLocal'i; SimpleDateFormat ei ole lõimeohutu, mis tõi kaasa NPE käitamisel
5. Korrigeerisime veel ühe mälu leke (ühendus ei suletud õigesti katkestamise korral)

Kuid siiski voolab!

Mälu hakkas otsa saama mitte ühe päeva, vaid kahe päevaga. Aega ei jäänud, otsustasime käivitada vähem lõime, kuid neljal agentil. Seda pidi piisama vähemalt nädalaks.

On möödunud kaks päeva…

Nüüd hakkas Hazelcast-il mälu otsa saama. Logides oli näha, et pärast paaripäevast testimist hakkab Hazelcast kurtma mälupuuduse üle ja pärast mõnda aega laguneb klaster ning sõlmed jätkavad üksikult hukkumist. Me ühendasime JVisualVM hazelcast-iga ja nägime "tõusvat saagi" – see kutsus regulaarselt esile GC, kuid ei suutnud kuidagi mälu puhastada.

Selgus, et hazelcast 3.4 versioonis ei vabastata mälu täielikult, kui kustutatakse map / multiMap (map.destroy()):

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

Praegu on viga 3.5 versioonis parandatud, kuid siis oli see probleem. Me loome uusi multiMap-e dünaamiliste nimedega ja kustutame vastavalt oma loogikale. Kood nägi välja umbes nii:

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

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

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

Kutse:

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

multiMap loodi iga tellimuse jaoks ja eemaldati, kui seda ei olnud enam vaja. Otsustasime, et kasutame Map<String,Set>, kus võtmena on tellimuse nimi ja väärtustena seansi identifikaatorid (mille alusel saab vajadusel kasutaja identifikaatoreid saada).

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

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

Graafikud on paranenud.

Mida veel oleme õppinud koormustestimise kohta

1. JSR223 tuleb kirjutada groovy keeles ja aktiveerida kompilatsiooni vahemälu – see on oluliselt kiirem. Ling.
2. Jmeter-Plugins graafikud on lihtsamad mõista kui standardsed. Ling.

Meie kogemus Hazelcastiga

Hazelcast oli meie jaoks uus toode, alustasime selle kasutamist versioonist 3.4.1, praegu on meie tootmisserveris versioon 3.9.2 (artikli kirjutamise hetkel oli viimane versioon Hazelcast – 3.10).

ID genereerimine

Alustasime täisarvuliste identifikaatoritega. Kujutlegem, et vajame uue üksuse jaoks Long tüüpi identifikaatorit. Andmebaasi järk ei sobi, tabelid osalevad shardingus – viib see selleni, et on sõnum ID=1 andmebaasis DB1 ja sõnum ID=1 andmebaasis DB2, Elasticsearchis sellise ID järgi ei talletata, Hazelcastis samuti, kuid kõige hullem on see, kui soovite kahte andmebaasi ühendada ühte (näiteks otsustades, et piisab ühest andmebaasist nende abonentide jaoks). Hazelcastis saab luua mitu AtomicLong ja hoida loendurit seal, siis on uue ID saamise tulemuslikkus – incrementAndGet pluss aeg Hazelcastisse päringu tegemiseks. Kuid Hazelcastis on midagi veel optimaalsemat – FlakeIdGenerator. Iga kliendi jaoks väljastatakse ID vahemik, näiteks esimesena – vahemik 1 kuni 10 000, teisele – vahemik 10 001 kuni 20 000 ja nii edasi. Nüüd saab klient uusi identifikaatoreid ise välja anda, kuni tema antud vahemik lõpeb. Töötab kiiresti, kuid rakenduse (ja Hazelcasti kliendi) taaskäivitamisel algab uus järjestus – sealt tulenevad ärajäänud ID-d jne. Samuti ei saa arendajad hästi aru, miks ID-d on täisarvud, kuid on nii palju segmenteeritud. Oleme kõik kaalunud ja läinud UUID-de peale.

Muide, neile, kes soovivad olla nagu Twitter, on olemas selline teek nimega Snowcast – see on Snowflake'i teostus Hazelcast'i peal. Vaadata saab siit:

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

Kuid me ei ole selle nii kaugele veel 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();
        }        
    });
}

Oodatav: newValue
Tegelik: oldValue

Pidin kirjutama oma replace, 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äärtuse a transactioneel kaardil");
        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äärtuse mitte transactioneel kaardil");
    IMap map = hazelcastInstance.getMap(mapName);
    return map.replace(key, oldValue, newValue);
}

Testige mitte ainult tavalisi andmestruktuure, vaid ka nende tehinguversioone. Juhtub, et IMap töötab, aga TransactionalMap mitte.

Uue JAR-i paigaldamine ilma seisakute tekitamiseta

Alguses otsustasime salvestada Hazelcasti oma klasside objekte. Näiteks, meil on klass Application, mida soovime salvestada ja lugeda. Salvestame:

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

Lugemine:

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

Kõik töötab. Seejärel otsustasime luua Hazelcastis indeksi, et selle kaudu otsida:

map.addIndex("subscriberId", false);

Ja kui me registreerisime uue üksuse, algas ClassNotFoundException. Hazelcast üritas indeksi täiendamist, kuid ei teadnud meie klassist midagi ja soovis, et me esitaksime JAR-i koos selle klassiga. Me tegime nii ja kõik töötas, kuid tekkis uus probleem: kuidas uuendada JAR-i ilma klastrit täielikult peatamata? Hazelcast ei paku uut JAR-i pärast podide värskendamist. Sel hetkel otsustasime, et saame ilma indeksiotsinguta ka hakkama. Kui kasutada Hazelcasti võtme-väärtuse salvestusena, kas siis kõik töötab? Mitte päris. Siin näeme jälle erinevat käitumist IMap ja TransactionalMap vahel. Seal, kus IMap ei hooli, viskab TransactionalMap vea.

IMap. Salvestame 5000 objekti, loeme välja. Kõik 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 tehingus see 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 lähenemise täielikult muutnud: me serialiseerime JSON-i ja salvestame selle Hazelcasti. Hazelcast ei pea teadma meie klasside struktuuri, mistõttu saame uuendada ilma seisakuteta. Domeeniobjektide versioneerimist juhib rakendus. Samal ajal võivad töötada erinevad rakenduste versioonid, ja võib juhtuda, et uus rakendus kirjutab objekte uute väljadega, mille kohta vana veel ei tea. Ja samal ajal loeb uus rakendus objekte, mille on salvestanud vana rakendus, kus uutest väljadest puuduvad. Sellised olukorrad käsitletakse rakenduse sees, kuid lihtsuse huvides me ei muuda ega eemalda välju, vaid ainult laiendame klasse uute väljade lisamisega.

Kuidas me tagame kõrge jõudluse

Neli külastust Hazelcasti – hea, kaks andmebaasi – halb

Andmete toomine vahemälust on alati parem kui andmebaasist, kuid me ei taha hoida kasutut teavet. Otsuse selle kohta, mida vahemällu salvestada, lükkame arenduse viimasele etapile. Kui uus funktsionaalsus on kodeeritud, aktiveerime PostgreSQLis kõikide päringute logimise (log_min_duration_statement seade 0) ja teeme koormustestimise umbes 20 minutiks. Kogutud logide põhjal oskavad tööriistad nagu pgFouine ja pgBadger koostada analüütilisi aruandeid. Aruannetes otsime eelkõige aeglaseid ja sagedasi päringuid. Aeglaste päringute jaoks koostame täitmisplaani (EXPLAIN) ja hindame, kas sellist päringut saaks kiirendada. Samade sisendandmete sagedased päringud paigutuvad hästi vahemällu. Päringud püüame hoida "tasapinnaliste" ehk ühes päringus ainult ühte tabelit.

Töötamine

SV online-teenus käivitati 2017. aasta kevadel, eraldi tootena ilmus SV 2017. aasta novembris (toona beetaversioonina).

Rohkem kui aasta kasutusea jooksul ei ole SV online-teenuses olnud tõsiseid probleeme. Zabbix, kogume ja juurutame läbi Bamboo.

SV serveri distributsioon tarnitakse natiivsete paketina: RPM, DEB, MSI. Lisaks pakume Windowsile ühte installijat, mis on üks EXE-fail, mis installib serveri, Hazelcasti ja Elasticsearchi ühele masinale. Esialgu nimetati seda installiversiooni „demonstreerivaks“, kuid nüüd on selge, et see on kõige populaarsem juurutamisviis.

Allikas: habr.com