San Airteagal seo beidh muid ag caint faoi conas agus cén fáth a d'fhorbair muid – meicníocht a aistríonn faisnéis idir feidhmchláir na gcliant agus 1C:Freastalaithe Fiontair - ó thasc a shocrú go dtí smaoineamh ar na sonraí ailtireachta agus cur chun feidhme.
Is córas teachtaireachtaí dáilte, fulangach le lochtanna é an Córas Idirghníomhaíochta (dá ngairtear SV anseo feasta) le seachadadh ráthaithe. Tá SV deartha mar sheirbhís ard-ualaigh le hinscálaitheacht ard, atá ar fáil mar sheirbhís ar líne (arna sholáthar ag 1C) agus mar tháirge olltáirgthe ar féidir a imscaradh ar do shaoráidí freastalaí féin.
Úsáideann SV stóras dáilte agus inneall cuardaigh . Labhróimid freisin faoi Java agus conas a dhéanaimid scála cothrománach ar PostgreSQL.
An fhadhb a fhoirmiú
Chun é a dhéanamh soiléir cén fáth ar chruthaigh muid an Córas Idirghníomhaíochta, inseoidh mé duit beagán faoi conas a oibríonn forbairt feidhmeanna gnó i 1C.
Chun tús a chur leis, beagán fúinn dóibh siúd nach bhfuil a fhios acu fós cad a dhéanaimid :) Táimid ag déanamh ardán teicneolaíochta 1C:Fiontar. Áirítear leis an ardán uirlis forbartha feidhmchlár gnó, chomh maith le ham rite a ligeann d’fheidhmchláir ghnó rith i dtimpeallacht tras-ardáin.
Paradigm forbartha cliant-freastalaí
Feidhmíonn feidhmchláir ghnó a chruthaítear ar 1C:Fiontar i dtrí leibhéal ailtireacht “DBMS - freastalaí feidhmchláir - cliant”. Cód iarratais scríofa i , is féidir é a fhorghníomhú ar fhreastalaí an iarratais nó ar an gcliant. Is ar an bhfreastalaí amháin a dhéantar an obair go léir le rudaí feidhmchláir (eolaire, doiciméid, etc.), chomh maith leis an mbunachar sonraí a léamh agus a scríobh. Cuirtear feidhmiúlacht foirmeacha agus comhéadan ordaithe i bhfeidhm ar an bhfreastalaí freisin. Déanann an cliant foirmeacha a fháil, a oscailt agus a thaispeáint, “cumarsáid” a dhéanamh leis an úsáideoir (rabhaidh, ceisteanna...), ríomhanna beaga i bhfoirmeacha a éilíonn freagra tapa (mar shampla, an praghas a iolrú de réir cainníochta), ag obair le comhaid áitiúla, ag obair le trealamh.
I gcód an fheidhmchláir, ní mór go léireodh ceannteidil na nósanna imeachta agus na bhfeidhmeanna go sainráite an áit a ndéanfar an cód a fhorghníomhú - ag baint úsáide as na treoracha &AtClient / &AtServer (&AtClient / &AtServer sa leagan Béarla den teanga). Ceartóidh forbróirí 1C anois mé ag rá go bhfuil treoracha iarbhír , ach níl sé seo tábhachtach dúinne anois.
Is féidir leat cód freastalaí a ghlaoch ó chód an chliaint, ach ní féidir leat cód cliaint a ghlaoch ó chód an fhreastalaí. Is teorannú bunúsach é seo a rinneamar ar roinnt cúiseanna. Go háirithe, toisc go gcaithfidh cód an fhreastalaí a bheith scríofa sa chaoi is go bhfeidhmíonn sé ar an mbealach céanna is cuma cén áit a dtugtar é - ón gcliant nó ón bhfreastalaí. Agus i gcás glaoch ar chód freastalaí ó chód freastalaí eile, níl aon chliant mar sin. Agus mar gheall le linn an cód freastalaí a fhorghníomhú, d'fhéadfadh an cliant a ghlaoigh é a dhúnadh, an t-iarratas a fhágáil, agus ní bheadh aon duine ag an bhfreastalaí le glaoch a thuilleadh.
Cód a láimhseálann cliceáil cnaipe: oibreoidh glaoch ar nós imeachta freastalaí ón gcliant, ní dhéanfaidh glaoch ar nós imeachta cliant ón bhfreastalaí
Ciallaíonn sé seo má theastaíonn uainn teachtaireacht éigin a sheoladh ón bhfreastalaí chuig an bhfeidhmchlár cliant, mar shampla, go bhfuil giniúint tuairisce “fadreatha” críochnaithe agus gur féidir féachaint ar an tuarascáil, níl a leithéid de mhodh againn. Caithfidh tú cleasanna a úsáid, mar shampla, an freastalaí a vótaíocht go tréimhsiúil ón gcód cliant. Ach luchtaíonn an cur chuige seo an córas le glaonna gan ghá, agus go ginearálta ní fhéachann sé an-galánta.
Agus tá gá freisin, mar shampla, nuair a thagann glao gutháin - agus glao á dhéanamh agat, cuir an t-iarratas cliant ar an eolas faoi seo ionas gur féidir leis uimhir an ghlaoiteora a úsáid chun í a aimsiú i mbunachar sonraí an chontrapháirtí agus faisnéis faoin gcontrapháirtí atá ag glaoch a thaispeáint don úsáideoir. Nó, mar shampla, nuair a thagann ordú chuig an stóras, cuir iarratas cliaint an chustaiméara ar an eolas faoi seo. Go ginearálta, tá go leor cásanna ann ina mbeadh meicníocht den sórt sin úsáideach.
An táirgeadh féin
Cruthaigh meicníocht teachtaireachtaí. Fast, iontaofa, le seachadadh ráthaithe, leis an gcumas cuardach a dhéanamh ar theachtaireachtaí go solúbtha. Bunaithe ar an meicníocht, a chur i bhfeidhm teachtaire (teachtaireachtaí, glaonna físe) ag rith taobh istigh iarratais 1C.
Dear an córas le bheith inscálaithe go cothrománach. Ní mór an t-ualach méadaithe a chlúdach trí líon na nóid a mhéadú.
Cur i bhFeidhm
Shocraigh muid gan an chuid freastalaí de SV a chomhtháthú go díreach isteach san ardán 1C:Fiontar, ach é a chur i bhfeidhm mar tháirge ar leith, ar féidir an API de a ghlaoch ó chód réitigh feidhmchláir 1C. Rinneadh é seo ar roinnt cúiseanna, agus ba é an príomhcheann acu ná go raibh mé ag iarraidh go bhféadfaí teachtaireachtaí a mhalartú idir iarratais éagsúla 1C (mar shampla, idir Bainistíocht Trádála agus Cuntasaíocht). Is féidir feidhmchláir éagsúla 1C a reáchtáil ar leaganacha éagsúla den ardán 1C:Fiontar, a bheith suite ar fhreastalaithe éagsúla, etc. I gcoinníollacha den sórt sin, is é an réiteach is fearr ná SV a chur i bhfeidhm mar tháirge ar leith atá suite “ar thaobh” suiteálacha 1C.
Mar sin, shocraigh muid SV a dhéanamh mar tháirge ar leithligh. Molaimid go n-úsáideann cuideachtaí beaga an freastalaí SL a chuireamar isteach inár scamall (wss://1cdialog.com) chun na forchostais a bhaineann le suiteáil áitiúil agus cumraíocht an fhreastalaí a sheachaint. B'fhéidir go mbeadh sé inmholta do chliaint mhóra a bhfreastalaí SL féin a shuiteáil ag a gcuid áiseanna. D’úsáideamar cur chuige comhchosúil inár dtáirge scamall SaaS – déantar é a tháirgeadh mar tháirge olltáirgthe lena shuiteáil ar shuíomhanna na gcliant, agus úsáidtear é inár néal freisin .
Iarratas
Chun an lamháltas ualaigh agus locht a dháileadh, ní úsáidfimid feidhmchlár Java amháin, ach roinnt eile, le cothromóir ualaigh os a gcomhair. Más gá duit teachtaireacht a aistriú ó nód go nód, bain úsáid as foilsigh/liostáil in Hazelcast.
Déantar cumarsáid idir an cliant agus an freastalaí trí websocket. Tá sé oiriúnach go maith do chórais fíor-ama.
Taisce dáilte
Roghnaigh muid idir Redis, Hazelcast agus Ehcache. 2015 atá ann. Tá Redis díreach tar éis braisle nua a scaoileadh (ró-nua, scanrúil), tá Sentinel ann le go leor srianta. Níl a fhios ag Ehcache conas teacht le chéile i mbraisle (bhí an fheidhmiúlacht seo le feiceáil níos déanaí). Shocraigh muid triail a bhaint as le Hazelcast 3.4.
Cuirtear Hazelcast le chéile i gcnuasach as an mbosca. I mód nód amháin, níl sé an-úsáideach agus ní féidir é a úsáid ach mar thaisce - níl a fhios aige conas sonraí a dhumpáil chuig diosca, má chailleann tú an t-aon nód amháin, caillfidh tú na sonraí. Imscaraimid roinnt Hazelcasts, a ndéanaimid cúltaca de shonraí ríthábhachtacha eatarthu. Ní dhéanaimid cúltaca den taisce - ní miste linn é.
Maidir linne, is é Hazelcast:
- Stóráil seisiúin úsáideora. Tógann sé go leor ama dul chuig an mbunachar le haghaidh seisiún gach uair, mar sin chuireamar na seisiúin ar fad i Hazelcast.
- Taisce. Má tá próifíl úsáideora á lorg agat, seiceáil an taisce. Scríobh teachtaireacht nua - cuir sa taisce é.
- Ábhair le haghaidh cumarsáide idir cásanna feidhmchláir. Gineann an nód imeacht agus cuireann sé san ábhar Hazelcast é. Faigheann nóid iarratais eile atá suibscríofa leis an ábhar seo an t-imeacht agus próiseálann é.
- Glais bhraisle. Mar shampla, cruthaímid plé ag baint úsáide as eochair uathúil (plé aonair laistigh de bhunachar sonraí 1C):
conversationKeyChecker.check("БЕНЗОКОЛОНКА");
doInClusterLock("БЕНЗОКОЛОНКА", () -> {
conversationKeyChecker.check("БЕНЗОКОЛОНКА");
createChannel("БЕНЗОКОЛОНКА");
});Sheiceáil muid nach bhfuil aon cainéal. Thógamar an glas, seiceáil arís é, agus chruthaigh sé é. Mura seiceálann tú an glas tar éis duit an glas a ghlacadh, tá seans ann go ndearna snáithe eile seiceáil freisin ag an nóiméad sin agus go ndéanfaidh tú iarracht anois an plé céanna a chruthú - ach tá sé ann cheana féin. Ní féidir leat glasáil a úsáid le Lock java sioncronaithe nó rialta. Tríd an mbunachar sonraí - tá sé mall, agus is mór an trua é don bhunachar sonraí; trí Hazelcast - sin a theastaíonn uait.
DBMS a roghnú
Tá taithí fhairsing rathúil againn ag obair le PostgreSQL agus ag comhoibriú le forbróirí an DBMS seo.
Níl sé éasca le braisle PostgreSQL - tá , , , ach go ginearálta ní NoSQLs iad seo a scála amach as an mbosca. Níor mheasamar NoSQL mar an príomhstóráil; ba leor gur thógamar Hazelcast, rud nár oibrigh muid leis roimhe seo.
Más gá duit bunachar sonraí coibhneasta a scála, ciallaíonn sé sin . Mar is eol daoibh, le roinnt a roinnt againn an bunachar sonraí i gcodanna ar leith ionas gur féidir gach ceann acu a chur ar fhreastalaí ar leith.
Ghlac an chéad leagan dár sharding leis an gcumas gach ceann de na táblaí dár bhfeidhmchlár a dháileadh ar fhreastalaithe éagsúla i gcomhréireanna éagsúla. Tá go leor teachtaireachtaí ar fhreastalaí A - le do thoil, déanaimis cuid den tábla seo a bhogadh chuig freastalaí B. Ní raibh an cinneadh seo ach ag screadaíl faoi bharrfheabhsú roimh am, agus mar sin shocraigh muid muid féin a theorannú do chur chuige ilthionóntaí.
Is féidir leat léamh faoi ilthionóntaí, mar shampla, ar an láithreán gréasáin .
Tá na coincheapa iarratais agus suibscríobhaí ag SV. Is éard is feidhmchlár ann ná suiteáil shonrach d’fheidhmchlár gnó, mar ERP nó Cuntasaíocht, lena úsáideoirí agus lena sonraí gnó. Is éard is síntiúsóir ann ná eagraíocht nó duine aonair a bhfuil an feidhmchlár cláraithe thar a cheann ar an bhfreastalaí SV. Is féidir roinnt feidhmchlár a bheith cláraithe ag suibscríobhaí, agus is féidir leis na feidhmchláir seo teachtaireachtaí a mhalartú lena chéile. Tháinig an suibscríobhaí ina thionónta inár gcóras. Is féidir teachtaireachtaí ó roinnt síntiúsóirí a aimsiú i mbunachar sonraí fisiceach amháin; má fheiceann muid go bhfuil síntiúsóir tosaithe ar a lán tráchta a ghiniúint, aistrímid é chuig bunachar sonraí fisiceach ar leith (nó fiú freastalaí bunachar sonraí ar leith).
Tá príomhbhunachar sonraí againn ina bhfuil tábla ródaithe stóráilte le faisnéis faoi shuíomh gach bunachar sonraí síntiúsóirí.
Chun an príomhbhunachar sonraí a chosc ó bheith ina scrogall, coinnímid an tábla ródaithe (agus sonraí eile a bhfuil gá leo go minic) i dtaisce.
Má thosaíonn bunachar sonraí an tsíntiúsóra ag moilliú, gearrfaimid é ina dheighiltí taobh istigh. Ar thionscadail eile a úsáidimid .
Ós rud é gur olc an rud é teachtaireachtaí úsáideora a chailliúint, coinnímid ár mbunachair shonraí le macasamhla. Ligeann an meascán de mhacasamhla sioncronacha agus asincrónacha duit tú féin a árachú i gcás go gcailltear an príomhbhunachar sonraí. Ní tharlóidh caillteanas teachtaireachtaí ach amháin má theipeann ar an mbunachar sonraí príomhúil agus a mhacasamhail sioncronach ag an am céanna.
Má chailltear macasamhail sioncrónach, éiríonn an macasamhail asincrónach sioncronach.
Má chailltear an príomhbhunachar sonraí, déantar an macasamhail sioncrónach mar phríomhbhunachar sonraí, agus déantar macasamhail sioncrónach den macasamhail asincrónach.
Cuardaigh leaisteacha le haghaidh cuardaigh
Ós rud é, i measc rudaí eile, gur teachtaire é SV freisin, éilíonn sé cuardach tapa, áisiúil agus solúbtha, ag cur san áireamh mhoirfeolaíocht, ag baint úsáide as cluichí neamhchruinn. Shocraigh muid gan an roth a athchruthú agus úsáid a bhaint as an inneall cuardaigh saor in aisce Elasticsearch, a cruthaíodh bunaithe ar an leabharlann . Déanaimid Elasticsearch a imscaradh freisin i mbraisle (máistir – sonraí – sonraí) chun deireadh a chur le fadhbanna i gcás teipe ar nóid feidhmchláir.
Ar github fuaireamar le haghaidh Elasticsearch agus é a úsáid. San innéacs Elasticsearch stórálaimid fréamhacha focal (a chinneann an breiseán) agus N-gram. De réir mar a chuireann an t-úsáideoir téacs isteach chun cuardach a dhéanamh, féachaimid don téacs clóscríofa i measc N-gram. Nuair a shábhálfar san innéacs é, roinnfear an focal “téacsanna” isteach sna N-ghram seo a leanas:
[iad siúd, tek, tex, téacs, téacsanna, ek, ex, ext, téacsanna, ks, kst, ksty, st, sty, tú],Agus caomhnófar fréamh an fhocail “téacs” freisin. Ligeann an cur chuige seo duit cuardach a dhéanamh ag tús, i lár, agus ag deireadh an fhocail.
An pictiúr mór
Déan an pictiúr arís ó thús an ailt, ach le mínithe:
- Cothromóir nochta ar an Idirlíon; ní mór dúinn nginx, is féidir é a bheith ar bith.
- Déanann cásanna feidhmchlár Java cumarsáid lena chéile trí Hazelcast.
- Chun oibriú le soicéad gréasáin a úsáidimid .
- Tá an feidhmchlár Java scríofa i Java 8 agus tá sé comhdhéanta de bheartáin . Áirítear leis na pleananna aistriú go Java 10 agus aistriú go modúil.
Forbairt agus tástáil
Agus an SV á fhorbairt agus á thástáil, tháinig muid trasna ar roinnt gnéithe suimiúla de na táirgí a úsáidimid.
Tástáil luchtaithe agus sceitheadh cuimhne
Baineann tástáil ualaigh le scaoileadh gach scaoileadh SV. Éiríonn leis nuair:
- D'oibrigh an tástáil ar feadh roinnt laethanta agus ní raibh aon teipeanna seirbhíse
- Níor sháraigh an t-am freagartha le haghaidh príomhoibríochtaí tairseach compordach
- Níl an meath feidhmíochta níos mó ná 10% i gcomparáid leis an leagan roimhe seo
Líonann muid an bunachar sonraí tástála le sonraí - chun é seo a dhéanamh, faigheann muid faisnéis faoin suibscríobhaí is gníomhaí ón bhfreastalaí táirgeachta, iolrú a líon faoi 5 (líon na dteachtaireachtaí, na bplé, na n-úsáideoirí) agus déanaimid tástáil ar an mbealach sin.
Déanaimid tástáil ualaigh ar an gcóras idirghníomhaíochta i dtrí chumraíocht:
- tástáil struis
- Naisc amháin
- Clárú síntiúsóir
Le linn na tástála struis, seolann muid na céadta snáitheanna, agus luchtaíonn siad an córas gan stad: teachtaireachtaí a scríobh, plé a chruthú, liosta teachtaireachtaí a fháil. Samhlaímid gníomhartha gnáthúsáideoirí (faigh liosta de mo chuid teachtaireachtaí neamhléite, scríobh chuig duine éigin) agus réitigh bogearraí (tarchuir pacáiste de chumraíocht dhifriúil, próiseálfaimid foláireamh).
Mar shampla, is é seo an chuma atá ar chuid den tástáil struis:
- Logálann an t-úsáideoir isteach
- Iarrann sé do phlé neamhléite
- Is dócha go léifidh 50% teachtaireachtaí
- 50% dócha go téacs
- An chéad úsáideoir eile:
- Tá seans 20% aige plé nua a chruthú
- Roghnaíonn sé go randamach aon cheann dá phlé
- Téann taobh istigh
- Teachtaireachtaí iarratais, próifílí úsáideora
- Cruthaítear cúig theachtaireacht a dhírítear chuig úsáideoirí randamacha ón bplé seo
- Fágann plé
- Athdhéantar seo 20 uair
- Logs amach, téann ar ais go dtí tús na scripte
- Téann chatbot isteach sa chóras (a aithrisíonn sé teachtaireachtaí ó chód feidhmchláir)
- Seans 50% go gcruthófar cainéal nua le haghaidh malartú sonraí (plé speisialta)
- Is dócha go scríobhfaidh 50% teachtaireacht chuig aon cheann de na bealaí atá ann cheana féin
Bhí an cás “Naisc Amháin” le feiceáil ar chúis. Tá cás ann: tá an córas nasctha ag úsáideoirí, ach níor ghlac siad páirt go fóill. Casann gach úsáideoir an ríomhaire ar 09:00 ar maidin, bunaíonn sé nasc leis an bhfreastalaí agus fanann sé ina thost. Tá na guys seo contúirteach, tá go leor acu - is iad na pacáistí amháin atá acu ná PING/PONG, ach coinníonn siad an nasc leis an bhfreastalaí (ní féidir leo é a choinneáil suas - cad má tá teachtaireacht nua ann). Atáirgeann an tástáil cás ina ndéanann líon mór úsáideoirí den sórt sin iarracht logáil isteach sa chóras i leath uair an chloig. Tá sé cosúil le tástáil struis, ach tá a fhócas go beacht ar an gcéad ionchur seo - ionas nach mbeidh aon teipeanna ann (ní úsáideann duine an córas, agus go dtiteann sé cheana féin - tá sé deacair smaoineamh ar rud éigin níos measa).
Tosaíonn an script clárúcháin suibscríobhaí ón gcéad seoladh. Rinneamar tástáil struis agus bhíomar cinnte nár mhoilligh an córas le linn comhfhreagrais. Ach tháinig úsáideoirí agus thosaigh an clárú ag teip mar gheall ar am istigh. Agus muid ag clárú úsáideamar , a bhaineann le eantrópacht an chórais. Ní raibh am ag an bhfreastalaí dóthain eantrópachta a charnadh agus nuair a iarradh SecureRandom nua, reo sé ar feadh na mílte soicind. Tá go leor bealaí amach anseo, mar shampla: aistrigh go dtí an /dev/urandom nach bhfuil chomh slán sin, suiteáil clár speisialta a ghineann eantrópacht, gineann uimhreacha randamacha roimh ré agus stóráil i linn iad. Dhúnamar an fhadhb leis an linn go sealadach, ach ó shin i leith tá tástáil ar leith á rith againn chun síntiúsóirí nua a chlárú.
Bainimid úsáid as mar ghineadóir ualach . Níl a fhios aige conas oibriú le websocket; tá breiseán ag teastáil uaidh. Seo an chéad cheann i dtorthaí cuardaigh don cheist “jmeter websocket”: , a mholann .
Sin an áit a shocraigh muid tosú.
Beagnach díreach tar éis tástáil thromchúiseach a thosú, fuaireamar amach gur thosaigh JMeter ag sceitheadh cuimhne.
Is scéal mór ar leith é an breiseán; le 176 réalta, tá 132 forc ar github. Níl an t-údar féin tiomanta dó ó 2015 (thóg muid é in 2015, níor ardaigh sé amhras), roinnt saincheisteanna github maidir le sceitheadh cuimhne, 7 n-iarratas ar tharraingt neamhdhúnta.
Má shocraíonn tú tástáil ualaigh a dhéanamh leis an mbreiseán seo, tabhair aird ar na díospóireachtaí seo a leanas:
- I dtimpeallacht il-snáithithe, baineadh úsáid as LinkedList rialta, agus ba é an toradh in am rite. Is féidir é seo a réiteach trí athrú go ConcurrentLinkedDeque nó trí bhlocanna sioncronaithe. Roghnaigh muid an chéad rogha dúinn féin ().
- Sceitheadh cuimhne; nuair a dhéantar dínascadh, ní scriostar an fhaisnéis nasctha ().
- Sa mhód sruthú (nuair nach bhfuil an soicéad gréasáin dúnta ag deireadh an tsampla, ach go n-úsáidtear é níos déanaí sa phlean), ní oibríonn patrúin freagartha ().
Tá sé seo ar cheann acu sin ar github. Cad a rinne muid:
- An bhfuil glactha (@elyrank) – réitíonn sé fadhbanna 1 agus 3
- Fadhb 2 le réiteach
- Lamairne nuashonraithe ó 9.2.14 go 9.3.12
- Fillte SimpleDateFormat in ThreadLocal; Níl SimpleDateFormat sábháilte ó thaobh snáitheanna de, rud a d'eascair NPE ag am rite
- Deisíodh sceitheadh cuimhne eile (dúnadh an ceangal go mícheart nuair a dínascadh é)
Agus fós sreabhann sé!
Thosaigh cuimhne ag rith amach ní in aghaidh an lae, ach in dhá cheann. Ní raibh aon am fágtha, agus mar sin shocraigh muid a sheoladh níos lú snáitheanna, ach ar cheithre gníomhairí. Ba chóir go mbeadh sé seo go leor ar feadh seachtaine ar a laghad.
Tá dhá lá caite...
Anois tá Hazelcast ag rith as cuimhne. Léirigh na logaí, tar éis cúpla lá de thástáil, gur thosaigh Hazelcast ag gearán faoi easpa cuimhne, agus tar éis roinnt ama thit an braisle as a chéile, agus lean na nóid ag bás ceann ar cheann. Cheangaileamar JVisualVM le hazelcast agus chonaic muid “sábh ag ardú” - thugamar an GC air go rialta, ach ní raibh sé in ann an chuimhne a ghlanadh.
Tharla sé, i gcrannchoill 3.4, agus léarscáil / multiMap (map.destroy()) á scriosadh, nach bhfuil an chuimhne saor go hiomlán:
Tá an fabht socraithe anois i 3.5, ach bhí sé ina fhadhb ar ais ansin. Chruthaíomar multiMaps nua le hainmneacha dinimiciúla agus scriosamar iad de réir ár loighic. Bhí cuma mar seo ar an gcód:
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();
}
}Focal:
service.join(auth1, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");
service.join(auth2, "НОВЫЕ_СООБЩЕНИЯ_В_ОБСУЖДЕНИИ_UUID1");Cruthaíodh multiMap do gach síntiús agus scriosadh é nuair nach raibh gá leis. Shocraigh muid go gcuirfinn tús le Map , is é an eochair ainm an tsíntiúis, agus aitheantóirí seisiúin a bheidh sna luachanna (as a bhféadfaidh tú aitheantóirí úsáideora a fháil ansin, más gá).
public void join(Authentication auth, String sub) {
addValueToMap(sub, auth.getSessionId());
}
public void leave(Authentication auth, String sub) {
removeValueFromMap(sub, auth.getSessionId());
}Tá feabhas tagtha ar na cairteacha.
Cad eile atá foghlamtha againn faoi thástáil ualaigh?
- Ní mór JSR223 a scríobh i groovy agus taisce tiomsaithe a áireamh - tá sé i bhfad níos tapúla. .
- Is fusa graif Jmeter-Breiseáin a thuiscint ná na cinn chaighdeánacha. .
Maidir lenár dtaithí le Hazelcast
Ba tháirge nua é Hazelcast dúinn, thosaigh muid ag obair leis ó leagan 3.4.1, anois tá ár bhfreastalaí táirgeachta ag rith leagan 3.9.2 (agus é seo á scríobh, is é 3.10 an leagan is déanaí de Hazelcast).
Giniúint ID
Thosaigh muid le haitheantóirí slánuimhir. Samhlóimid go dteastaíonn Fada eile uainn le haghaidh eintiteas nua. Níl seicheamh sa bhunachar sonraí oiriúnach, tá na táblaí i gceist le bearrtha - tarlaíonn sé go bhfuil teachtaireacht ID=1 in DB1 agus teachtaireacht ID=1 in DB2, ní féidir leat an t-aitheantas seo a chur in Elasticsearch, ná i Hazelcast , ach is é an rud is measa má theastaíonn uait na sonraí ó dhá bhunachar sonraí a chomhcheangal i gceann amháin (mar shampla, cinneadh a dhéanamh gur leor bunachar sonraí amháin do na síntiúsóirí seo). Is féidir leat roinnt AtomicLongs a chur le Hazelcast agus an cuntar a choinneáil ann, ansin tá an fheidhmíocht chun aitheantas nua a fháil incrimentAndGet móide an t-am le haghaidh iarratas chuig Hazelcast. Ach tá rud éigin níos fearr ag Hazelcast - FlakeIdGenerator. Nuair a théann siad i dteagmháil le gach cliant, tugtar raon aitheantais dóibh, mar shampla, an chéad cheann - ó 1 go 10, an dara ceann - ó 000 go 10, agus mar sin de. Anois is féidir leis an gcliant aitheantóirí nua a eisiúint leis féin go dtí go dtiocfaidh deireadh leis an raon a eisíodh dó. Oibríonn sé go tapa, ach nuair a atosóidh tú an t-iarratas (agus an cliant Hazelcast), tosaíonn seicheamh nua - mar sin na scipeanna, etc. Ina theannta sin, ní thuigeann forbróirí i ndáiríre cén fáth go bhfuil na IDanna slánuimhir, ach go bhfuil siad chomh neamhréireach. Mheáíomar gach rud agus aistrigh muid chuig UUIDanna.
Dála an scéil, dóibh siúd ar mian leo a bheith cosúil le Twitter, tá a leithéid de leabharlann Snowcast ann - is cur i bhfeidhm é seo de Snowflake ar bharr Hazelcast. Is féidir leat é a fheiceáil anseo:
Ach nílimid tar éis dul timpeall air a thuilleadh.
TransactionalMap.replace
Ionadh eile: ní oibríonn TransationalMap.replace. Seo tástáil:
@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 : oldValueBhí orm mo ionad féin a scríobh ag baint úsáide as 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);
}Déan tástáil ní hamháin ar struchtúir sonraí rialta, ach freisin ar a leaganacha idirbheartaíochta. Tarlaíonn sé go n-oibríonn IMap, ach níl TransactionalMap ann a thuilleadh.
Cuir isteach JAR nua gan am downt
Ar dtús, bheartaíomar rudaí dár ranganna a thaifeadadh i Hazelcast. Mar shampla, tá rang Feidhmchláir againn, ba mhaith linn é a shábháil agus a léamh. Sábháil:
IMap<UUID, Application> map = hazelcastInstance.getMap("application");
map.set(id, application);Léimid:
IMap<UUID, Application> map = hazelcastInstance.getMap("application");
return map.get(id);Tá gach rud ag obair. Ansin bheartaíomar innéacs a thógáil i Hazelcast chun cuardach a dhéanamh de réir:
map.addIndex("subscriberId", false);Agus aonán nua á scríobh acu, thosaigh siad ag fáil ClassNotFoundException. Rinne Hazelcast iarracht cur leis an innéacs, ach ní raibh a fhios aige rud ar bith faoinár rang agus theastaigh uaidh JAR leis an rang seo a sholáthar dó. Rinneamar é sin, d'oibrigh gach rud, ach bhí fadhb nua le feiceáil: conas an JAR a nuashonrú gan an braisle a stopadh go hiomlán? Ní phiocann Hazelcast an JAR nua le linn nuashonrú nód-by-nóid. Ag an bpointe seo shocraigh muid go bhféadfaimis maireachtáil gan cuardach innéacs. Tar éis an tsaoil, má úsáideann tú Hazelcast mar stór eochairluacha, ansin oibreoidh gach rud? Níl i ndáiríre. Anseo arís tá iompar IMap agus TransactionalMap difriúil. Nuair is cuma le IMap, caitheann TransactionalMap earráid.
IMap. Scríobhaimid 5000 réad, iad a léamh. Táthar ag súil le gach rud.
@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());
}
}Ach ní oibríonn sé in idirbheart, faighimid 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();
}
});
}I 3.8, bhí meicníocht Imlonnaithe Aicme Úsáideora le feiceáil. Is féidir leat máistir nód amháin a ainmniú agus an comhad JAR a nuashonrú air.
Anois tá ár gcur chuige athraithe go hiomlán againn: déanaimid é a shraithiú isteach i JSON agus é a shábháil i Hazelcast. Ní gá go mbeadh eolas ag Hazelcast ar struchtúr ár ranganna, agus is féidir linn nuashonrú a dhéanamh gan aga neamhfhónaimh. Tá leagan réada fearainn á rialú ag an bhfeidhmchlár. Is féidir le leaganacha éagsúla den fheidhmchlár a bheith ag rith ag an am céanna, agus d’fhéadfadh cás a bheith ann nuair a scríobhann an feidhmchlár nua rudaí le réimsí nua, ach níl a fhios ag an seancheann fós faoi na réimsí sin. Agus ag an am céanna, léann an t-iarratas nua rudaí atá scríofa ag an sean-iarratas nach bhfuil réimsí nua acu. Déanaimid cásanna den sórt sin a láimhseáil laistigh den fheidhmchlár, ach ar mhaithe le simplíocht ní dhéanaimid réimsí a athrú nó a scriosadh, ní dhéanaimid ach na ranganna a leathnú trí réimsí nua a chur leis.
Conas a chinntímid ardfheidhmíocht
Ceithre thuras go Hazelcast - go maith, dhá cheann go dtí an bunachar sonraí - olc
Is fearr i gcónaí dul chuig an taisce le haghaidh sonraí ná dul chuig an mbunachar sonraí, ach níl tú ag iarraidh taifid nach bhfuil in úsáid a stóráil ach an oiread. Fágaimid an cinneadh faoi cad atá le taisceadh go dtí an chéim dheireanach forbartha. Nuair a dhéantar an fheidhmiúlacht nua a chódú, cuirimid logáil na bhfiosruithe go léir i PostgreSQL ar siúl (log_min_duration_statement to 0) agus reáchtáilimid tástáil ualaigh ar feadh 20 nóiméad. Ag baint úsáide as na logaí bailithe, is féidir le fóntais cosúil le pgFouine agus pgBadger tuarascálacha anailíse a thógáil. I dtuarascálacha, lorgaimid fiosrúcháin mall agus rialta go príomha. I gcás fiosrúchán mall, déanaimid plean forghníomhaithe (MÍNIÚ) agus déanaimid measúnú ar cibé an féidir dlús a chur le fiosrúchán den sórt sin. Tagann iarratais go minic ar na sonraí ionchuir céanna go maith isteach sa taisce. Déanaimid iarracht fiosruithe a choinneáil “cothrom”, tábla amháin in aghaidh gach ceiste.
Saothrú
Cuireadh SV mar sheirbhís ar líne i bhfeidhm in earrach na bliana 2017, agus mar tháirge ar leithligh, scaoileadh SV i mí na Samhna 2017 (ag an am sin i stádas leagan béite).
I níos mó ná bliain oibríochta, ní raibh aon fadhbanna tromchúiseacha maidir le hoibriú na seirbhíse SL ar líne. Déanaimid monatóireacht ar an tseirbhís ar líne trí , a bhailiú agus a imscaradh ó .
Soláthraítear an dáileadh freastalaí SV i bhfoirm pacáistí dúchasacha: RPM, DEB, MSI. Sa bhreis ar Windows soláthraímid suiteálaí amháin i bhfoirm EXE amháin a shuiteálann an freastalaí, Hazelcast agus Elasticsearch ar mheaisín amháin. Thagair muid ar dtús don leagan seo den suiteáil mar an leagan “taispeána”, ach tá sé soiléir anois gurb é seo an rogha imlonnaithe is coitianta.
Foinse: will.com