Како и зошто напишавме скалабилна услуга со големо оптоварување за 1C: Enterprise: Java, PostgreSQL, Hazelcast

Во оваа статија ќе зборуваме за тоа како и зошто се развивме Систем за интеракција – механизам кој пренесува информации помеѓу клиентските апликации и серверите 1C:Enterprise - од поставување задача до размислување низ архитектурата и деталите за имплементација.

Системот за интеракција (во натамошниот текст како SV) е дистрибуиран, толерантен систем за пораки со загарантирана испорака. SV е дизајниран како услуга со големо оптоварување со голема приспособливост, достапна и како онлајн услуга (обезбедена од 1C) и како масовно произведен производ што може да се распореди на вашите сопствени серверски капацитети.

SV користи дистрибуирано складирање Лескина и пребарувач Еластична пребарување. Ќе зборуваме и за Java и за тоа како хоризонтално го скалираме PostgreSQL.

Проблем изјава

За да стане јасно зошто го создадовме Системот за интеракција, ќе ви кажам малку за тоа како функционира развојот на деловни апликации во 1C.

За почеток, малку за нас за оние кои сè уште не знаат што правиме :) Ја правиме технолошката платформа 1C:Enterprise. Платформата вклучува алатка за развој на деловни апликации, како и време на работа што им овозможува на деловните апликации да работат во меѓуплатформско опкружување.

Парадигма за развој на клиент-сервер

Деловните апликации создадени на 1C: Enterprise работат на три нивоа клиент-сервер архитектура „DBMS – сервер за апликации – клиент“. Кодот на апликацијата напишан во вграден јазик 1C, може да се изврши на серверот за апликација или на клиентот. Целата работа со објектите на апликацијата (директориуми, документи, итн.), како и читањето и пишувањето на базата на податоци, се врши само на серверот. Функционалноста на формите и командниот интерфејс е исто така имплементирана на серверот. Клиентот врши примање, отворање и прикажување форми, „комуницира“ со корисникот (предупредувања, прашања...), мали пресметки во обрасци кои бараат брз одговор (на пример, множење на цената по количина), работа со локални датотеки, работа со опрема.

Во кодот на апликацијата, заглавјата на процедурите и функциите мора експлицитно да наведат каде ќе се изврши кодот - користејќи ги директивите &AtClient / &AtServer (&AtClient / &AtServer во англиската верзија на јазикот). Програмерите на 1C сега ќе ме поправат велејќи дека директивите се всушност подобро, но за нас сега ова не е важно.

Може да го повикате кодот на серверот од кодот на клиентот, но не можете да го повикате кодот на клиентот од кодот на серверот. Ова е фундаментално ограничување што го направивме од повеќе причини. Особено, затоа што кодот на серверот мора да биде напишан на таков начин што ќе се извршува на ист начин без разлика каде се повикува - од клиентот или од серверот. И во случај на повикување серверски код од друг код на серверот, нема клиент како таков. И бидејќи за време на извршувањето на кодот на серверот, клиентот што го повикал може да се затвори, да излезе од апликацијата и серверот повеќе нема да има кого да повика.

Код што се справува со кликнување на копче: повикувањето серверска процедура од клиентот ќе работи, повикувањето клиентска процедура од серверот нема

Ова значи дека ако сакаме да испратиме некоја порака од серверот до клиентската апликација, на пример, дека генерирањето на „долготрајниот“ извештај е завршено и извештајот може да се гледа, немаме таков метод. Треба да користите трикови, на пример, периодично да го анкетирате серверот од кодот на клиентот. Но, овој пристап го оптоварува системот со непотребни повици и генерално не изгледа многу елегантно.

И, исто така, има потреба, на пример, кога ќе пристигне телефонски повик SIP- кога упатувате повик, известете ја клиентската апликација за ова за да може да го користи бројот на повикувачот за да го најде во базата на податоци на другата договорна страна и да му покаже на корисникот информации за договорната страна што повикува. Или, на пример, кога ќе пристигне нарачка во магацинот, известете ја клиентската апликација на клиентот за ова. Општо земено, има многу случаи кога таков механизам би бил корисен.

Самото производство

Направете механизам за пораки. Брз, сигурен, со гарантирана испорака, со можност за флексибилно пребарување на пораки. Врз основа на механизмот, имплементирајте гласник (пораки, видео повици) што работи во апликациите 1C.

Дизајнирајте го системот да биде хоризонтално скалабилен. Зголеменото оптоварување мора да се покрие со зголемување на бројот на јазли.

Реализация

Решивме да не го интегрираме серверскиот дел на SV директно во платформата 1C: Enterprise, туку да го имплементираме како посебен производ, чиј API може да се повика од кодот на апликативните решенија 1C. Ова беше направено од повеќе причини, од кои главната беше тоа што сакав да овозможам размена на пораки помеѓу различни апликации 1C (на пример, помеѓу управување со трговија и сметководство). Различни апликации 1C можат да работат на различни верзии на платформата 1C:Enterprise, да се наоѓаат на различни сервери итн. Во такви услови, имплементацијата на SV како посебен производ лоциран „на страна“ на инсталациите 1C е оптимално решение.

Така, решивме да го направиме SV како посебен производ. Препорачуваме малите компании да го користат серверот CB што го инсталиравме во нашиот облак (wss://1cdialog.com) за да ги избегнат режиските трошоци поврзани со локалната инсталација и конфигурација на серверот. Големите клиенти можеби сметаат дека е препорачливо да инсталираат сопствен CB сервер во нивните капацитети. Ние користевме сличен пристап во нашиот облак SaaS производ 1cСвежо - се произведува како масовно произведен производ за инсталација на локациите на клиентите, а исто така е распореден во нашиот облак https://1cfresh.com/.

Апликација

За да ја дистрибуираме толеранцијата на оптоварување и дефекти, ќе распоредиме не една Java апликација, туку неколку, со балансер на оптоварување пред нив. Ако треба да префрлите порака од јазол на јазол, користете објавување/претплати на Hazelcast.

Комуникацијата помеѓу клиентот и серверот е преку веб-сокет. Добро е прилагоден за системи во реално време.

Дистрибуиран кеш

Избравме помеѓу Redis, Hazelcast и Ehcache. 2015 е. Редис само што објави нов кластер (премногу нов, страшен), има Сентинел со многу ограничувања. Ehcache не знае како да се состави во кластер (оваа функционалност се појави подоцна). Решивме да го пробаме со Hazelcast 3.4.
Hazelcast е составен во кластер надвор од кутијата. Во режимот на еден јазол, тој не е многу корисен и може да се користи само како кеш - не знае како да ги исфрли податоците на дискот, ако го изгубите единствениот јазол, ги губите податоците. Распоредуваме неколку Hazelcasts, меѓу кои правиме резервна копија на критичните податоци. Не правиме резервна копија на кешот - не ни пречи тоа.

За нас, Hazelcast е:

• Складирање на кориснички сесии. Потребно е долго време да се оди во базата на податоци за сесија секој пат, па затоа ги ставаме сите сесии во Hazelcast.
• Кеш. Ако барате кориснички профил, проверете го кешот. Напиша нова порака - ставете ја во кешот.
• Теми за комуникација помеѓу инстанци на апликации. Јазолот генерира настан и го става во темата Hazelcast. Другите апликациски јазли претплатени на оваа тема го примаат и обработуваат настанот.
• Кластер брави. На пример, создаваме дискусија користејќи единствен клуч (единечна дискусија во базата на податоци 1C):

conversationKeyChecker.check("БЕНЗОКОЛОНКА");

      doInClusterLock("БЕНЗОКОЛОНКА", () -> {

          conversationKeyChecker.check("БЕНЗОКОЛОНКА");

          createChannel("БЕНЗОКОЛОНКА");
      });

Проверивме дека нема канал. Ја зедовме бравата, ја проверивме повторно и ја создадовме. Ако не ја проверите бравата по преземањето на бравата, тогаш постои можност во тој момент да се провери и друга нишка и сега ќе се обиде да ја создаде истата дискусија - но таа веќе постои. Не можете да заклучите користејќи синхронизирано или редовно java Lock. Преку базата на податоци - бавно е, и штета е за базата на податоци; преку Hazelcast - тоа е она што ви треба.

Избор на DBMS

Имаме големо и успешно искуство со работа со PostgreSQL и соработка со развивачите на овој DBMS.

Не е лесно со кластерот PostgreSQL - постои XL, XC, Цитус, но генерално, ова не се NoSQL-и кои се скалираат надвор од кутијата. Не го сметавме NoSQL за главно складирање; доволно беше што го зедовме Hazelcast, со кој претходно не работевме.

Ако треба да скалирате релациона база на податоци, тоа значи сечењето. Како што знаете, со Sharding ја делиме базата на податоци на посебни делови за да може секој од нив да биде поставен на посебен сервер.

Првата верзија на нашето споделување претпоставуваше можност да ја дистрибуира секоја од табелите на нашата апликација низ различни сервери во различни пропорции. Има многу пораки на серверот А - ве молам, ајде да преместиме дел од оваа табела на серверот Б. Оваа одлука едноставно врескаше за прерана оптимизација, па решивме да се ограничиме на пристап со повеќе станари.

Можете да прочитате за мулти-закупец, на пример, на веб-страницата Цитус податоци.

SV ги има концептите на апликација и претплатник. Апликација е специфична инсталација на деловна апликација, како што е ERP или сметководство, со нејзините корисници и деловни податоци. Претплатник е организација или поединец во чие име апликацијата е регистрирана во серверот SV. Претплатникот може да има регистрирани неколку апликации и овие апликации можат да разменуваат пораки меѓу себе. Претплатникот стана закупец во нашиот систем. Пораките од неколку претплатници може да се лоцираат во една физичка база на податоци; ако видиме дека претплатникот почнал да генерира многу сообраќај, го преместуваме во посебна физичка база на податоци (или дури и посебен сервер за база на податоци).

Имаме главна база на податоци каде што се чува рутирачка табела со информации за локацијата на сите бази на податоци на претплатници.

За да спречиме главната база на податоци да биде тесно грло, ја чуваме рутирачката табела (и другите често потребни податоци) во кеш.

Ако базата на податоци на претплатникот почне да забавува, ќе ја пресечеме на партиции внатре. На други проекти што ги користиме pg_pathman.

Бидејќи губењето на корисничките пораки е лошо, ние ги одржуваме нашите бази на податоци со реплики. Комбинацијата на синхрони и асинхрони реплики ви овозможува да се осигурате во случај на губење на главната база на податоци. Загубата на пораката ќе се случи само ако примарната база на податоци и нејзината синхрона реплика не успеат истовремено.

Ако се изгуби синхроната реплика, асинхроната реплика станува синхрона.
Ако главната база на податоци се изгуби, синхроната реплика станува главна база на податоци, а асинхроната реплика станува синхрона реплика.

Elasticsпребарување за пребарување

Бидејќи, меѓу другото, SV е и гласник, потребно е брзо, практично и флексибилно пребарување, земајќи ја предвид морфологијата, користејќи непрецизни совпаѓања. Решивме да не го измислиме повторно тркалото и да го користиме бесплатниот пребарувач Elasticsearch, создаден врз основа на библиотеката Луцен. Ние, исто така, распоредуваме Elasticsearch во кластер (master – data – data) за да ги елиминираме проблемите во случај на неуспех на јазлите на апликацијата.

На github најдовме Руски приклучок за морфологија за Elasticsearch и искористете го. Во индексот Elasticsearch складираме корени на зборови (што ги одредува додатокот) и N-грами. Како што корисникот внесува текст за пребарување, го бараме внесениот текст меѓу N-грами. Кога ќе се зачува во индексот, зборот „текстови“ ќе се подели на следните N-грами:

[тие, тек, текст, текст, текстови, ек, екс, екс, текстови, кс, кс, ксти, ст, сти, ти],

И коренот на зборот „текст“ исто така ќе биде зачуван. Овој пристап ви овозможува да пребарувате на почетокот, на средината и на крајот на зборот.

Големата слика

Повторете ја сликата од почетокот на статијата, но со објаснувања:

• Балансерот изложен на Интернет; имаме nginx, може да биде било кој.
• Примерите на Java апликациите комуницираат едни со други преку Hazelcast.
• За работа со веб-сокет што го користиме Netty.
• Јава апликацијата е напишана во Java 8 и се состои од пакети OSGi. Плановите вклучуваат миграција на Java 10 и транзиција кон модули.

Развој и тестирање

Во процесот на развивање и тестирање на SV, наидовме на голем број интересни карактеристики на производите што ги користиме.

Тестирање на вчитување и протекување на меморија

Ослободувањето на секое издание на SV вклучува тестирање на оптоварување. Успешно е кога:

• Тестот работеше неколку дена и немаше дефекти во сервисот
• Времето на одговор за клучните операции не го надмина удобниот праг
• Влошувањето на перформансите во споредба со претходната верзија не е повеќе од 10%

Ние ја пополнуваме базата на податоци за тестирање со податоци - за да го направите ова, добиваме информации за најактивниот претплатник од производствениот сервер, ги множиме неговите броеви со 5 (бројот на пораки, дискусии, корисници) и го тестираме на тој начин.

Ние спроведуваме тестирање на оптоварување на системот за интеракција во три конфигурации:

1. стрес тест
2. Само врски
3. Регистрација на претплатници

За време на стрес-тестот, стартуваме неколку стотици нишки и тие го вчитуваат системот без запирање: пишување пораки, креирање дискусии, примање листа на пораки. Симулираме дејства на обичните корисници (добијте список со мои непрочитани пораки, пишувајте некому) и софтверски решенија (пренесувате пакет со различна конфигурација, обработувате предупредување).

На пример, вака изгледа дел од стрес тестот:

• Корисникот се најавува
  • Ги бара вашите непрочитани дискусии
  • 50% веројатност да читаат пораки
  • 50% веројатност да пишуваат пораки
  • Следен корисник:
    • Има 20% шанса да создаде нова дискусија
    • Случајно избира која било од неговите дискусии
    • Влегува внатре
    • Бара пораки, кориснички профили
    • Создава пет пораки упатени до случајни корисници од оваа дискусија
    • Ја напушта дискусијата
    • Се повторува 20 пати
    • Се одјавува, се враќа на почетокот на сценариото

  • Во системот влегува четбот (емулира пораки од кодот на апликацијата)
    • Има 50% шанса да создаде нов канал за размена на податоци (специјална дискусија)
    • 50% веројатност да напишат порака до некој од постоечките канали

Сценариото „Само врски“ се појави со причина. Постои ситуација: корисниците го поврзаа системот, но сè уште не се вклучија. Секој корисник го вклучува компјутерот во 09:00 часот наутро, воспоставува врска со серверот и молчи. Овие момци се опасни, ги има многу - единствените пакети што ги имаат се ПИНГ/ПОНГ, но ја задржуваат врската со серверот (не можат да ја задржат - што ако има нова порака). Тестот репродуцира ситуација кога голем број такви корисници се обидуваат да се логираат на системот за половина час. Слично е на стрес тест, но неговиот фокус е токму на овој прв влез - за да нема неуспеси (лицето не го користи системот, а тој веќе паѓа - тешко е да се замисли нешто полошо).

Скриптата за регистрација на претплатници започнува од првото лансирање. Спроведовме стрес-тест и бевме сигурни дека системот не успорува за време на кореспонденцијата. Но, дојдоа корисници и регистрацијата почна да пропаѓа поради тајмаут. При регистрација користевме / dev / случајно, што е поврзано со ентропијата на системот. Серверот немаше време да акумулира доволно ентропија и кога беше побаран нов SecureRandom, тој замрзна десетици секунди. Има многу начини за излез од оваа ситуација, на пример: префрлете се на помалку безбедниот /dev/urandom, инсталирајте специјална табла што генерира ентропија, генерирате случајни броеви однапред и складирајте ги во базен. Привремено го затворивме проблемот со базенот, но оттогаш спроведуваме посебен тест за регистрирање нови претплатници.

Ние користиме како генератор на оптоварување Mеметр. Не знае како да работи со websocket; му треба приклучок. Првите во резултатите од пребарувањето за барањето „jmeter websocket“ се: написи од BlazeMeter, кои препорачуваат приклучок од Мациеј Залески.

Оттука решивме да почнеме.

Речиси веднаш откако започнавме сериозно тестирање, откривме дека JMeter почна да протекува меморија.

Приклучокот е посебна голема приказна; со 176 ѕвезди, има 132 вилушки на github. Самиот автор не се обврзал на тоа од 2015 година (го зедовме во 2015 година, тогаш не предизвика сомнежи), неколку проблеми со github во врска со протекување на меморијата, 7 незатворени барања за повлекување.
Ако одлучите да извршите тестирање за оптоварување користејќи го овој приклучок, ве молиме обрнете внимание на следните дискусии:

1. Во опкружување со повеќе нишки, се користеше обична LinkedList, и резултатот беше НПЕ во траење. Ова може да се реши или со префрлување на ConcurrentLinkedDeque или со синхронизирани блокови. Ја избравме првата опција за себе (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/43).
2. Протекување меморија; при исклучување, информациите за врската не се бришат (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/44).
3. Во режимот на стриминг (кога веб-сокетот не е затворен на крајот од примерокот, но се користи подоцна во планот), шемите на одговор не работат (https://github.com/maciejzaleski/JMeter-WebSocketSampler/issues/19).

Ова е едно од оние на github. Што направивме:

1. Презеле вилушка Елиран Коган (@elyrank) – ги поправа проблемите 1 и 3
2. Решен проблем 2
3. Ажурирана дига од 9.2.14 до 9.3.12
4. Завиткан SimpleDateFormat во ThreadLocal; SimpleDateFormat не е безбеден за нишки, што доведе до NPE при извршување
5. Поправено е друго истекување на меморијата (врската беше погрешно затворена кога беше исклучена)

А сепак тече!

Меморијата почна да истекува не за еден ден, туку за два. Апсолутно немаше време, па решивме да лансираме помалку теми, но на четири агенти. Ова требаше да биде доволно барем една недела.

Поминаа два дена...

Сега Hazelcast е без меморија. Дневниците покажаа дека по неколку дена тестирање, Hazelcast почна да се жали на недостаток на меморија, а по некое време кластерот се распадна, а јазлите продолжија да умираат еден по еден. Го поврзавме JVisualVM со лешник и видовме „пила што се крева“ - редовно го повикуваше GC, но не можеше да ја исчисти меморијата.

Се испостави дека во hazelcast 3.4, при бришење на мапа / multiMap (map.destroy()), меморијата не е целосно ослободена:

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

Грешката сега е поправена во 3.5, но тогаш беше проблем. Создадовме нови мултимапи со динамични имиња и ги избришавме според нашата логика. Кодот изгледаше отприлика вака:

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();
    }
}

Визов:

service.join(auth1, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");
service.join(auth2, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");

multiMap беше креиран за секоја претплата и се брише кога не беше потребно. Решивме да започнеме со Мапа , клучот ќе биде името на претплатата, а вредностите ќе бидат идентификатори на сесии (од кои потоа можете да добиете идентификатори на корисници, доколку е потребно).

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

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

Табелите се подобрија.

Што друго научивме за тестирањето на оптоварување?

1. JSR223 треба да биде напишан во жлеб и да вклучува кеш за компилација - тоа е многу побрзо. Линк.
2. Графиконите на Jmeter-Plugins се полесни за разбирање од стандардните. Линк.

За нашето искуство со Hazelcast

Hazelcast беше нов производ за нас, почнавме да работиме со него од верзијата 3.4.1, сега нашиот производствен сервер работи со верзијата 3.9.2 (во моментот на пишување, најновата верзија на Hazelcast е 3.10).

Генерирање ИД

Почнавме со идентификатори на цели броеви. Да замислиме дека ни треба уште еден Долг за нов ентитет. Редоследот во базата не е погодна, табелите се вклучени во поделбата - излегува дека има порака ID=1 во DB1 и порака ID=1 во DB2, не можете да ја ставите оваа ID во Elasticsearch, ниту во Hazelcast , но најлошото е ако сакате да ги комбинирате податоците од две бази на податоци во една (на пример, да одлучите дека една база е доволна за овие претплатници). Можете да додадете неколку AtomicLongs на Hazelcast и да го задржите бројачот таму, а потоа перформансите за добивање на нов ID се зголемуваат и добивате плус времето за барање до Hazelcast. Но, Hazelcast има нешто пооптимално - FlakeIdGenerator. При контактирање на секој клиент, им се дава опсег на ID, на пример, првиот – од 1 до 10, вториот – од 000 до 10 итн. Сега клиентот може сам да издава нови идентификатори додека не заврши опсегот што му е издаден. Работи брзо, но кога ќе ја рестартирате апликацијата (и клиентот Hazelcast), започнува нова низа - оттука и прескокнувањата итн. Покрај тоа, програмерите навистина не разбираат зошто ИД се цели броеви, но се толку неконзистентни. Измеривме сè и се префрливме на UUID.

Патем, за оние кои сакаат да бидат како Твитер, постои таква библиотека Snowcast - ова е имплементација на Snowflake на врвот на Hazelcast. Можете да го погледнете овде:

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

Но, ние веќе не се приближивме до тоа.

TransactionMap.замени

Уште едно изненадување: TransactionalMap.replace не работи. Еве еден тест:

@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();
        }        
    });
}

Expected : newValue
Actual : oldValue

Морав да напишам своја замена користејќи getForUpdate:

protected <K,V> boolean replaceInMap(String mapName, K key, V oldValue, V newValue) {
    TransactionalTaskContext context = HazelcastTransactionContextHolder.getContext();
    if (context != null) {
        log.trace("[CACHE] Replacing value in a transactional map");
        TransactionalMap<K, V> map = context.getMap(mapName);
        V value = map.getForUpdate(key);
        if (oldValue.equals(value)) {
            map.put(key, newValue);
            return true;
        }

        return false;
    }
    log.trace("[CACHE] Replacing value in a not transactional map");
    IMap<K, V> map = hazelcastInstance.getMap(mapName);
    return map.replace(key, oldValue, newValue);
}

Тестирајте не само редовни структури на податоци, туку и нивните трансакциски верзии. Се случува IMap да работи, но TransactionalMap повеќе да не постои.

Вметнете нов JAR без прекини

Прво, решивме да снимаме предмети од нашите часови во Hazelcast. На пример, имаме класа Application, сакаме да ја зачуваме и прочитаме. Зачувај:

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);

Читаме:

IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);

Сè работи. Потоа решивме да изградиме индекс во Hazelcast за да пребаруваме по:

map.addIndex("subscriberId", false);

И кога пишуваа нов ентитет, тие почнаа да добиваат ClassNotFoundException. Hazelcast се обиде да додаде на индексот, но не знаеше ништо за нашиот клас и сакаше да му биде доставен JAR со оваа класа. Го направивме токму тоа, сè работеше, но се појави нов проблем: како да се ажурира JAR без целосно да се запре кластерот? Hazelcast не го зема новиот JAR за време на ажурирање од јазол до јазол. Во овој момент решивме дека можеме да живееме без пребарување на индекси. На крајот на краиштата, ако користите Hazelcast како продавница со клучна вредност, тогаш сè ќе функционира? Не навистина. Овде повторно однесувањето на IMap и TransactionalMap е различно. Онаму каде што на IMap не му е грижа, TransactionalMap исфрла грешка.

IMap. Пишуваме 5000 предмети, ги читаме. Се е очекувано.

@Test
void get5000() {
    IMap<UUID, Application> 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());
    }
}

Но, тоа не работи во трансакција, добиваме ClassNotFoundException:

@Test
void get_transaction() {
    IMap<UUID, Application> 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<UUID, Application> transactionalMap = context.getMap("application_t");
            Application retrievedInside = transactionalMap.get(id);

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

Во 3.8, се појави механизмот за распоредување на класа на корисници. Можете да назначите еден главен јазол и да ја ажурирате датотеката JAR на неа.

Сега целосно го сменивме нашиот пристап: самите го серијализираме во JSON и го зачувуваме во Hazelcast. Hazelcast не треба да ја знае структурата на нашите часови и можеме да се ажурираме без прекини. Верзијата на објектите на доменот е контролирана од апликацијата. Различни верзии на апликацијата можат да работат во исто време, а можна е ситуација кога новата апликација пишува објекти со нови полиња, но старата сè уште не знае за овие полиња. И во исто време, новата апликација чита објекти напишани од старата апликација кои немаат нови полиња. Ние се справуваме со такви ситуации во рамките на апликацијата, но заради едноставност не менуваме или бришеме полиња, туку само ги прошируваме класите со додавање нови полиња.

Како обезбедуваме високи перформанси

Четири патувања до Hazelcast - добро, две до базата на податоци - лоши

Одењето во кешот за податоци е секогаш подобро отколку да одите во базата на податоци, но не сакате ниту да складирате неискористени записи. Одлуката за тоа што да се кешира ја оставаме до последната фаза на развој. Кога новата функционалност е кодирана, го вклучуваме евидентирањето на сите барања во PostgreSQL (log_min_duration_statement до 0) и го извршуваме тестирањето за оптоварување 20 минути. Користејќи ги собраните дневници, алатките како pgFouine и pgBadger можат да градат аналитички извештаи. Во извештаите, првенствено бараме бавни и чести прашања. За бавни прашања, градиме план за извршување (ОБјаснете) и проценуваме дали таквото барање може да се забрза. Честите барања за исти влезни податоци добро се вклопуваат во кешот. Ние се обидуваме да ги задржиме прашањата „рамни“, една табела по барање.

Експлоатација

SV како онлајн услуга беше пуштена во употреба во пролетта 2017 година, а како посебен производ, SV беше објавен во ноември 2017 година (тогаш во статус на бета верзија).

За повеќе од една година од работењето, нема сериозни проблеми во работењето на онлајн услугата CB. Ја следиме онлајн услугата преку Zabbix, собирајте и распоредете од Бамбус.

Дистрибуцијата на серверот SV се обезбедува во форма на домашни пакети: RPM, DEB, MSI. Плус за Windows обезбедуваме единствен инсталатер во форма на единствен EXE кој ги инсталира серверот, Hazelcast и Elasticsearch на една машина. Првично ја нарекувавме оваа верзија на инсталацијата како „демо“ верзија, но сега стана јасно дека ова е најпопуларната опција за распоредување.

Извор: www.habr.com