ఈ వ్యాసంలో మనం ఎలా మరియు ఎందుకు అభివృద్ధి చేశాము అనే దాని గురించి మాట్లాడుతాము – క్లయింట్ అప్లికేషన్‌లు మరియు 1C: ఎంటర్‌ప్రైజ్ సర్వర్‌ల మధ్య సమాచారాన్ని బదిలీ చేసే మెకానిజం - టాస్క్‌ని సెట్ చేయడం నుండి ఆర్కిటెక్చర్ మరియు ఇంప్లిమెంటేషన్ వివరాల ద్వారా ఆలోచించడం వరకు.
ఇంటరాక్షన్ సిస్టమ్ (ఇకపై SVగా సూచిస్తారు) అనేది పంపిణీ చేయబడిన, గ్యారెంటీ డెలివరీతో కూడిన తప్పు-తట్టుకునే సందేశ వ్యవస్థ. SV అనేది అధిక స్కేలబిలిటీతో అధిక-లోడ్ సేవగా రూపొందించబడింది, ఇది ఆన్‌లైన్ సేవ (1C ద్వారా అందించబడింది) మరియు మీ స్వంత సర్వర్ సౌకర్యాలపై అమలు చేయగల భారీ-ఉత్పత్తి ఉత్పత్తి వలె అందుబాటులో ఉంటుంది.
SV పంపిణీ చేయబడిన నిల్వను ఉపయోగిస్తుంది మరియు శోధన ఇంజిన్ . మేము జావా గురించి మరియు PostgreSQLని అడ్డంగా స్కేల్ చేయడం గురించి కూడా మాట్లాడుతాము.
సమస్య యొక్క ప్రకటన
మేము ఇంటరాక్షన్ సిస్టమ్‌ను ఎందుకు సృష్టించామో స్పష్టం చేయడానికి, 1Cలో వ్యాపార అనువర్తనాల అభివృద్ధి ఎలా పని చేస్తుందో నేను మీకు కొంచెం చెబుతాను.
ప్రారంభించడానికి, మనం ఏమి చేయాలో ఇంకా తెలియని వారి కోసం మా గురించి కొంచెం :) మేము 1C: Enterprise టెక్నాలజీ ప్లాట్‌ఫారమ్‌ను తయారు చేస్తున్నాము. ప్లాట్‌ఫారమ్‌లో వ్యాపార అప్లికేషన్ డెవలప్‌మెంట్ టూల్, అలాగే వ్యాపార అప్లికేషన్‌లు క్రాస్-ప్లాట్‌ఫారమ్ వాతావరణంలో అమలు చేయడానికి అనుమతించే రన్‌టైమ్ కూడా ఉన్నాయి.
క్లయింట్-సర్వర్ అభివృద్ధి నమూనా
1C: Enterpriseలో సృష్టించబడిన వ్యాపార అనువర్తనాలు మూడు-స్థాయిలలో పనిచేస్తాయి ఆర్కిటెక్చర్ "DBMS - అప్లికేషన్ సర్వర్ - క్లయింట్". అప్లికేషన్ కోడ్ వ్రాయబడింది , అప్లికేషన్ సర్వర్‌లో లేదా క్లయింట్‌లో అమలు చేయవచ్చు. అప్లికేషన్ ఆబ్జెక్ట్‌లతో (డైరెక్టరీలు, పత్రాలు మొదలైనవి) అన్ని పని, అలాగే డేటాబేస్ చదవడం మరియు వ్రాయడం సర్వర్‌లో మాత్రమే నిర్వహించబడుతుంది. ఫారమ్‌లు మరియు కమాండ్ ఇంటర్‌ఫేస్ యొక్క కార్యాచరణ కూడా సర్వర్‌లో అమలు చేయబడుతుంది. క్లయింట్ ఫారమ్‌లను స్వీకరించడం, తెరవడం మరియు ప్రదర్శించడం, వినియోగదారుతో “కమ్యూనికేట్ చేయడం” (హెచ్చరికలు, ప్రశ్నలు...), శీఘ్ర ప్రతిస్పందన అవసరమయ్యే ఫారమ్‌లలో చిన్న గణనలు (ఉదాహరణకు, ధరను పరిమాణంతో గుణించడం), స్థానిక ఫైల్‌లతో పని చేయడం, పరికరాలు పని.
అప్లికేషన్ కోడ్‌లో, &AtClient / &AtServer ఆదేశాలను ఉపయోగించి (&AtClient / &AtServer భాష యొక్క ఆంగ్ల సంస్కరణలో) కోడ్ ఎక్కడ అమలు చేయబడుతుందో విధివిధానాలు మరియు ఫంక్షన్‌ల హెడర్‌లు స్పష్టంగా సూచించాలి. 1C డెవలపర్‌లు ఇప్పుడు డైరెక్ట్‌లు వాస్తవమని చెప్పి నన్ను సరిచేస్తారు , కానీ మాకు ఇది ఇప్పుడు ముఖ్యం కాదు.
మీరు క్లయింట్ కోడ్ నుండి సర్వర్ కోడ్‌కి కాల్ చేయవచ్చు, కానీ మీరు సర్వర్ కోడ్ నుండి క్లయింట్ కోడ్‌కి కాల్ చేయలేరు. ఇది అనేక కారణాల వల్ల మేము చేసిన ప్రాథమిక పరిమితి. ప్రత్యేకించి, సర్వర్ కోడ్‌ను క్లయింట్ నుండి లేదా సర్వర్ నుండి ఎక్కడ పిలిచినా అదే విధంగా అమలు చేసే విధంగా వ్రాయబడాలి. మరియు మరొక సర్వర్ కోడ్ నుండి సర్వర్ కోడ్‌ను కాల్ చేసే సందర్భంలో, అటువంటి క్లయింట్ ఎవరూ లేరు. మరియు సర్వర్ కోడ్ అమలు సమయంలో, దానిని కాల్ చేసిన క్లయింట్ మూసివేయవచ్చు, అప్లికేషన్ నుండి నిష్క్రమించవచ్చు మరియు సర్వర్ ఇకపై కాల్ చేయడానికి ఎవరికీ ఉండదు.
బటన్ క్లిక్‌ను నిర్వహించే కోడ్: క్లయింట్ నుండి సర్వర్ విధానాన్ని కాల్ చేయడం పని చేస్తుంది, సర్వర్ నుండి క్లయింట్ విధానాన్ని కాల్ చేయడం పని చేయదు
దీని అర్థం మనం సర్వర్ నుండి క్లయింట్ అప్లికేషన్‌కు కొంత సందేశాన్ని పంపాలనుకుంటే, ఉదాహరణకు, "దీర్ఘకాలిక" నివేదిక యొక్క తరం పూర్తయింది మరియు నివేదికను వీక్షించవచ్చు, మాకు అలాంటి పద్ధతి లేదు. మీరు ఉపాయాలను ఉపయోగించాలి, ఉదాహరణకు, క్లయింట్ కోడ్ నుండి క్రమానుగతంగా సర్వర్‌ను పోల్ చేయండి. కానీ ఈ విధానం అనవసరమైన కాల్‌లతో సిస్టమ్‌ను లోడ్ చేస్తుంది మరియు సాధారణంగా చాలా సొగసైనదిగా కనిపించదు.
మరియు ఒక అవసరం కూడా ఉంది, ఉదాహరణకు, ఒక టెలిఫోన్ కాల్ వచ్చినప్పుడు - కాల్ చేస్తున్నప్పుడు, దీని గురించి క్లయింట్ అప్లికేషన్‌కు తెలియజేయండి, తద్వారా అది కాలర్ నంబర్‌ను కౌంటర్‌పార్టీ డేటాబేస్లో కనుగొని, కాలింగ్ కౌంటర్‌పార్టీ గురించి వినియోగదారు సమాచారాన్ని చూపుతుంది. లేదా, ఉదాహరణకు, గిడ్డంగికి ఆర్డర్ వచ్చినప్పుడు, దీని గురించి కస్టమర్ క్లయింట్ అప్లికేషన్‌కు తెలియజేయండి. సాధారణంగా, అటువంటి యంత్రాంగం ఉపయోగకరంగా ఉండే అనేక సందర్భాలు ఉన్నాయి.
ఉత్పత్తి కూడా
సందేశ యంత్రాంగాన్ని సృష్టించండి. వేగంగా, విశ్వసనీయంగా, హామీతో కూడిన డెలివరీతో, మెసేజ్‌ల కోసం సులభంగా శోధించే సామర్థ్యంతో. మెకానిజం ఆధారంగా, 1C అప్లికేషన్‌లలో నడుస్తున్న మెసెంజర్ (సందేశాలు, వీడియో కాల్‌లు)ని అమలు చేయండి.
సిస్టమ్‌ను క్షితిజ సమాంతరంగా కొలవగలిగేలా రూపొందించండి. నోడ్ల సంఖ్యను పెంచడం ద్వారా పెరుగుతున్న లోడ్ తప్పనిసరిగా కవర్ చేయబడాలి.
అమలు
మేము SV యొక్క సర్వర్ భాగాన్ని నేరుగా 1C:Enterprise ప్లాట్‌ఫారమ్‌లో ఏకీకృతం చేయకూడదని నిర్ణయించుకున్నాము, కానీ దానిని ఒక ప్రత్యేక ఉత్పత్తిగా అమలు చేయాలని నిర్ణయించుకున్నాము, దీని APIని 1C అప్లికేషన్ సొల్యూషన్స్ కోడ్ నుండి పిలవవచ్చు. ఇది అనేక కారణాల వల్ల జరిగింది, అందులో ప్రధానమైనది ఏమిటంటే, వివిధ 1C అప్లికేషన్‌ల మధ్య (ఉదాహరణకు, ట్రేడ్ మేనేజ్‌మెంట్ మరియు అకౌంటింగ్ మధ్య) సందేశాలను మార్పిడి చేయడాన్ని నేను సాధ్యం చేయాలనుకుంటున్నాను. విభిన్న 1C అప్లికేషన్‌లు 1C:Enterprise ప్లాట్‌ఫారమ్ యొక్క విభిన్న వెర్షన్‌లలో రన్ అవుతాయి, వివిధ సర్వర్‌లలో ఉంటాయి. అటువంటి పరిస్థితులలో, 1C ఇన్‌స్టాలేషన్‌ల యొక్క “పక్కన” ఉన్న ప్రత్యేక ఉత్పత్తిగా SVని అమలు చేయడం సరైన పరిష్కారం.
కాబట్టి, మేము SVని ప్రత్యేక ఉత్పత్తిగా చేయాలని నిర్ణయించుకున్నాము. సర్వర్ యొక్క స్థానిక ఇన్‌స్టాలేషన్ మరియు కాన్ఫిగరేషన్‌తో అనుబంధించబడిన ఓవర్‌హెడ్ ఖర్చులను నివారించడానికి మేము మా క్లౌడ్ (wss://1cdialog.com)లో ఇన్‌స్టాల్ చేసిన CB సర్వర్‌ని చిన్న కంపెనీలు ఉపయోగించాలని మేము సిఫార్సు చేస్తున్నాము. పెద్ద క్లయింట్లు వారి సౌకర్యాల వద్ద వారి స్వంత CB సర్వర్‌ను ఇన్‌స్టాల్ చేసుకోవడం మంచిది. మేము మా క్లౌడ్ SaaS ఉత్పత్తిలో ఇదే విధానాన్ని ఉపయోగించాము - ఇది క్లయింట్‌ల సైట్‌లలో ఇన్‌స్టాలేషన్ కోసం భారీ-ఉత్పత్తి ఉత్పత్తిగా ఉత్పత్తి చేయబడుతుంది మరియు మా క్లౌడ్‌లో కూడా అమలు చేయబడుతుంది .
అప్లికేషన్
లోడ్ మరియు ఫాల్ట్ టాలరెన్స్‌ను పంపిణీ చేయడానికి, మేము ఒక జావా అప్లికేషన్‌ను కాదు, వాటి ముందు లోడ్ బ్యాలెన్సర్‌తో అనేక వాటిని అమలు చేస్తాము. మీరు నోడ్ నుండి నోడ్‌కు సందేశాన్ని బదిలీ చేయాలనుకుంటే, Hazelcastలో ప్రచురించండి/చందా చేసుకోండి.
క్లయింట్ మరియు సర్వర్ మధ్య కమ్యూనికేషన్ వెబ్‌సాకెట్ ద్వారా జరుగుతుంది. ఇది రియల్ టైమ్ సిస్టమ్‌లకు బాగా సరిపోతుంది.
పంపిణీ చేయబడిన కాష్
మేము Redis, Hazelcast మరియు Ehcache మధ్య ఎంచుకున్నాము. ఇది 2015. Redis ఇప్పుడే కొత్త క్లస్టర్‌ను విడుదల చేసింది (చాలా కొత్తది, భయానకంగా ఉంది), చాలా పరిమితులతో కూడిన సెంటినెల్ ఉంది. క్లస్టర్‌లో ఎలా సమీకరించాలో Ehcacheకి తెలియదు (ఈ కార్యాచరణ తర్వాత కనిపించింది). మేము దీన్ని Hazelcast 3.4తో ప్రయత్నించాలని నిర్ణయించుకున్నాము.
Hazelcast బాక్స్ వెలుపల ఒక క్లస్టర్‌లో సమావేశమై ఉంది. సింగిల్ నోడ్ మోడ్‌లో, ఇది చాలా ఉపయోగకరంగా ఉండదు మరియు కాష్‌గా మాత్రమే ఉపయోగించబడుతుంది - ఇది డిస్క్‌కి డేటాను ఎలా డంప్ చేయాలో తెలియదు, మీరు ఒకే నోడ్‌ను కోల్పోతే, మీరు డేటాను కోల్పోతారు. మేము అనేక హాజెల్‌క్యాస్ట్‌లను అమలు చేస్తాము, వాటి మధ్య మేము క్లిష్టమైన డేటాను బ్యాకప్ చేస్తాము. మేము కాష్‌ని బ్యాకప్ చేయము - మేము దానిని పట్టించుకోము.
మాకు, Hazelcast ఉంది:
- వినియోగదారు సెషన్‌ల నిల్వ. ప్రతిసారి సెషన్ కోసం డేటాబేస్‌కి వెళ్లడానికి చాలా సమయం పడుతుంది, కాబట్టి మేము అన్ని సెషన్‌లను Hazelcastలో ఉంచాము.
- కాష్. మీరు వినియోగదారు ప్రొఫైల్ కోసం చూస్తున్నట్లయితే, కాష్‌ని తనిఖీ చేయండి. కొత్త సందేశాన్ని వ్రాశారు - కాష్‌లో ఉంచండి.
- అప్లికేషన్ ఉదంతాల మధ్య కమ్యూనికేషన్ కోసం అంశాలు. నోడ్ ఒక ఈవెంట్‌ను రూపొందిస్తుంది మరియు దానిని Hazelcast అంశంలో ఉంచుతుంది. ఈ అంశానికి సభ్యత్వం పొందిన ఇతర అప్లికేషన్ నోడ్‌లు ఈవెంట్‌ను స్వీకరిస్తాయి మరియు ప్రాసెస్ చేస్తాయి.
- క్లస్టర్ తాళాలు. ఉదాహరణకు, మేము ప్రత్యేకమైన కీని ఉపయోగించి చర్చను సృష్టిస్తాము (1C డేటాబేస్‌లోని సింగిల్‌టన్ చర్చ):
conversationKeyChecker.check("БЕНЗОКОЛОНКА");
doInClusterLock("БЕНЗОКОЛОНКА", () -> {
conversationKeyChecker.check("БЕНЗОКОЛОНКА");
createChannel("БЕНЗОКОЛОНКА");
});మేము ఛానెల్ లేదని తనిఖీ చేసాము. మేము తాళాన్ని తీసుకొని, దాన్ని మళ్లీ తనిఖీ చేసి, సృష్టించాము. మీరు లాక్ తీసిన తర్వాత లాక్‌ని తనిఖీ చేయకపోతే, ఆ సమయంలో మరొక థ్రెడ్ కూడా తనిఖీ చేయబడి, ఇప్పుడు అదే చర్చను సృష్టించడానికి ప్రయత్నించే అవకాశం ఉంది - కానీ అది ఇప్పటికే ఉంది. మీరు సమకాలీకరించబడిన లేదా సాధారణ జావా లాక్‌ని ఉపయోగించి లాక్ చేయలేరు. డేటాబేస్ ద్వారా - ఇది నెమ్మదిగా ఉంది మరియు ఇది డేటాబేస్ కోసం జాలి ఉంది; Hazelcast ద్వారా - ఇది మీకు అవసరం.
DBMSని ఎంచుకోవడం
PostgreSQLతో పని చేయడం మరియు ఈ DBMS డెవలపర్‌లతో కలిసి పని చేయడంలో మాకు విస్తృతమైన మరియు విజయవంతమైన అనుభవం ఉంది.
PostgreSQL క్లస్టర్‌తో ఇది సులభం కాదు - ఉంది , , , కానీ సాధారణంగా ఇవి బాక్స్ వెలుపల స్కేల్ చేసే NoSQLలు కావు. మేము NoSQLని ప్రధాన నిల్వగా పరిగణించలేదు; మేము ఇంతకు ముందు పని చేయని Hazelcastని తీసుకుంటే సరిపోతుంది.
మీరు రిలేషనల్ డేటాబేస్ను స్కేల్ చేయాల్సిన అవసరం ఉంటే, దాని అర్థం . మీకు తెలిసినట్లుగా, షార్డింగ్‌తో మేము డేటాబేస్ను ప్రత్యేక భాగాలుగా విభజిస్తాము, తద్వారా వాటిలో ప్రతి ఒక్కటి ప్రత్యేక సర్వర్‌లో ఉంచబడతాయి.
మా భాగస్వామ్య మొదటి వెర్షన్ మా అప్లికేషన్ యొక్క ప్రతి టేబుల్‌లను వేర్వేరు సర్వర్‌లలో వేర్వేరు నిష్పత్తిలో పంపిణీ చేయగల సామర్థ్యాన్ని కలిగి ఉంది. సర్వర్ Aలో చాలా సందేశాలు ఉన్నాయి - దయచేసి, ఈ టేబుల్‌లోని కొంత భాగాన్ని సర్వర్ Bకి తరలిద్దాం. ఈ నిర్ణయం అకాల ఆప్టిమైజేషన్ గురించి కేకలు వేసింది, కాబట్టి మేము మమ్మల్ని బహుళ-అద్దెదారుల విధానానికి పరిమితం చేయాలని నిర్ణయించుకున్నాము.
మీరు బహుళ-అద్దెదారు గురించి చదువుకోవచ్చు, ఉదాహరణకు, వెబ్‌సైట్‌లో .
SVకి అప్లికేషన్ మరియు సబ్‌స్క్రైబర్ అనే భావనలు ఉన్నాయి. అప్లికేషన్ అనేది దాని వినియోగదారులు మరియు వ్యాపార డేటాతో ERP లేదా అకౌంటింగ్ వంటి వ్యాపార అప్లికేషన్ యొక్క నిర్దిష్ట ఇన్‌స్టాలేషన్. సబ్‌స్క్రైబర్ అనేది ఒక సంస్థ లేదా వ్యక్తి, దీని తరపున అప్లికేషన్ SV సర్వర్‌లో నమోదు చేయబడింది. ఒక చందాదారుడు అనేక అప్లికేషన్‌లను నమోదు చేసుకోవచ్చు మరియు ఈ అప్లికేషన్‌లు ఒకదానితో ఒకటి సందేశాలను మార్పిడి చేసుకోవచ్చు. చందాదారుడు మా సిస్టమ్‌లో అద్దెదారు అయ్యాడు. అనేక మంది చందాదారుల నుండి సందేశాలు ఒక భౌతిక డేటాబేస్లో ఉంటాయి; ఒక చందాదారుడు చాలా ట్రాఫిక్‌ని సృష్టించడం ప్రారంభించినట్లు మనం చూసినట్లయితే, మేము దానిని ప్రత్యేక భౌతిక డేటాబేస్‌కు (లేదా ప్రత్యేక డేటాబేస్ సర్వర్‌కి కూడా) తరలిస్తాము.
అన్ని సబ్‌స్క్రైబర్ డేటాబేస్‌ల స్థానం గురించిన సమాచారంతో రౌటింగ్ టేబుల్ నిల్వ చేయబడిన ప్రధాన డేటాబేస్ మా వద్ద ఉంది.
ప్రధాన డేటాబేస్ అడ్డంకిగా ఉండకుండా నిరోధించడానికి, మేము రౌటింగ్ పట్టికను (మరియు ఇతర తరచుగా అవసరమైన డేటా) కాష్‌లో ఉంచుతాము.
చందాదారుల డేటాబేస్ వేగాన్ని తగ్గించడం ప్రారంభిస్తే, మేము దానిని లోపల విభజనలుగా కట్ చేస్తాము. మేము ఉపయోగించే ఇతర ప్రాజెక్ట్‌లలో .
వినియోగదారు సందేశాలను కోల్పోవడం చెడ్డది కాబట్టి, మేము మా డేటాబేస్‌లను ప్రతిరూపాలతో నిర్వహిస్తాము. సింక్రోనస్ మరియు అసమకాలిక ప్రతిరూపాల కలయిక ప్రధాన డేటాబేస్ నష్టపోయిన సందర్భంలో మిమ్మల్ని మీరు బీమా చేసుకోవడానికి అనుమతిస్తుంది. ప్రైమరీ డేటాబేస్ మరియు దాని సింక్రోనస్ రెప్లికా ఏకకాలంలో విఫలమైతే మాత్రమే సందేశ నష్టం జరుగుతుంది.
సమకాలిక ప్రతిరూపం పోయినట్లయితే, అసమకాలిక ప్రతిరూపం సమకాలీకరించబడుతుంది.
ప్రధాన డేటాబేస్ పోయినట్లయితే, సింక్రోనస్ రెప్లికా ప్రధాన డేటాబేస్ అవుతుంది మరియు అసమకాలిక ప్రతిరూపం సింక్రోనస్ రెప్లికా అవుతుంది.
శోధన కోసం సాగే శోధన
ఇతర విషయాలతోపాటు, SV కూడా ఒక మెసెంజర్ కాబట్టి, దీనికి వేగవంతమైన, అనుకూలమైన మరియు సౌకర్యవంతమైన శోధన అవసరం, పదనిర్మాణ శాస్త్రాన్ని పరిగణనలోకి తీసుకుని, ఖచ్చితమైన సరిపోలికలను ఉపయోగిస్తుంది. మేము చక్రాన్ని తిరిగి ఆవిష్కరించకూడదని మరియు లైబ్రరీ ఆధారంగా సృష్టించబడిన ఉచిత శోధన ఇంజిన్ సాగే శోధనను ఉపయోగించకూడదని నిర్ణయించుకున్నాము . అప్లికేషన్ నోడ్‌లు విఫలమైనప్పుడు సమస్యలను తొలగించడానికి మేము క్లస్టర్‌లో (మాస్టర్ - డేటా - డేటా) సాగే శోధనను కూడా అమలు చేస్తాము.
గితుబ్‌లో మేము కనుగొన్నాము సాగే శోధన కోసం మరియు దానిని ఉపయోగించండి. సాగే శోధన సూచికలో మేము పద మూలాలను (ప్లగ్ఇన్ నిర్ణయిస్తుంది) మరియు N-గ్రాములను నిల్వ చేస్తాము. వినియోగదారు శోధించడానికి వచనాన్ని నమోదు చేసినప్పుడు, మేము N-గ్రాముల మధ్య టైప్ చేసిన వచనం కోసం చూస్తాము. ఇండెక్స్‌లో సేవ్ చేసినప్పుడు, "టెక్ట్స్" అనే పదం క్రింది N-గ్రాములుగా విభజించబడుతుంది:
[ఆ, టెక్, టెక్స్, టెక్స్ట్, టెక్స్ట్‌లు, ek, ex, ext, texts, ks, kst, ksty, st, sty, you],మరియు "టెక్స్ట్" అనే పదం యొక్క మూలం కూడా భద్రపరచబడుతుంది. ఈ విధానం పదం ప్రారంభంలో, మధ్యలో మరియు చివరిలో శోధించడానికి మిమ్మల్ని అనుమతిస్తుంది.
పెద్ద చిత్రం
వ్యాసం ప్రారంభం నుండి చిత్రాన్ని పునరావృతం చేయండి, కానీ వివరణలతో:
- బ్యాలెన్సర్ ఇంటర్నెట్‌లో బహిర్గతమైంది; మాకు nginx ఉంది, అది ఏదైనా కావచ్చు.
- జావా అప్లికేషన్ ఉదంతాలు Hazelcast ద్వారా ఒకదానితో ఒకటి సంభాషించుకుంటాయి.
- మేము ఉపయోగించే వెబ్ సాకెట్‌తో పని చేయడానికి .
- జావా అప్లికేషన్ జావా 8లో వ్రాయబడింది మరియు బండిల్‌లను కలిగి ఉంటుంది . ప్లాన్‌లలో జావా 10కి మైగ్రేషన్ మరియు మాడ్యూల్‌లకు మారడం ఉన్నాయి.
అభివృద్ధి మరియు పరీక్ష
SVని అభివృద్ధి చేసే మరియు పరీక్షించే ప్రక్రియలో, మేము ఉపయోగించే ఉత్పత్తుల యొక్క అనేక ఆసక్తికరమైన లక్షణాలను మేము చూశాము.
లోడ్ పరీక్ష మరియు మెమరీ లీక్‌లు
ప్రతి SV విడుదల విడుదలలో లోడ్ పరీక్ష ఉంటుంది. ఇది ఎప్పుడు విజయవంతమవుతుంది:
- పరీక్ష చాలా రోజులు పనిచేసింది మరియు సేవ వైఫల్యాలు లేవు
- కీలక కార్యకలాపాలకు ప్రతిస్పందన సమయం సౌకర్యవంతమైన థ్రెషోల్డ్‌ను మించలేదు
- మునుపటి సంస్కరణతో పోలిస్తే పనితీరు క్షీణత 10% కంటే ఎక్కువ కాదు.
మేము పరీక్ష డేటాబేస్ను డేటాతో నింపుతాము - దీన్ని చేయడానికి, మేము ప్రొడక్షన్ సర్వర్ నుండి అత్యంత యాక్టివ్ సబ్‌స్క్రైబర్ గురించి సమాచారాన్ని అందుకుంటాము, దాని సంఖ్యలను 5 (సందేశాలు, చర్చలు, వినియోగదారులు) ద్వారా గుణించండి మరియు దానిని ఆ విధంగా పరీక్షించండి.
మేము ఇంటరాక్షన్ సిస్టమ్ యొక్క లోడ్ టెస్టింగ్‌ను మూడు కాన్ఫిగరేషన్‌లలో నిర్వహిస్తాము:
- ఒత్తిడి పరీక్ష
- కనెక్షన్లు మాత్రమే
- చందాదారుల నమోదు
ఒత్తిడి పరీక్ష సమయంలో, మేము అనేక వందల థ్రెడ్‌లను ప్రారంభిస్తాము మరియు అవి ఆపకుండా సిస్టమ్‌ను లోడ్ చేస్తాయి: సందేశాలను వ్రాయడం, చర్చలను సృష్టించడం, సందేశాల జాబితాను స్వీకరించడం. మేము సాధారణ వినియోగదారుల చర్యలను (నా చదవని సందేశాల జాబితాను పొందండి, ఎవరికైనా వ్రాయండి) మరియు సాఫ్ట్‌వేర్ పరిష్కారాలను (వేరొక కాన్ఫిగరేషన్ యొక్క ప్యాకేజీని ప్రసారం చేయండి, హెచ్చరికను ప్రాసెస్ చేయండి) అనుకరిస్తాము.
ఉదాహరణకు, ఒత్తిడి పరీక్షలో భాగం ఇలా ఉంటుంది:
- వినియోగదారు లాగిన్
- మీ చదవని చర్చలను అభ్యర్థిస్తుంది
- 50% సందేశాలను చదివే అవకాశం ఉంది
- 50% వచనం పంపే అవకాశం ఉంది
- తదుపరి వినియోగదారు:
- కొత్త చర్చను సృష్టించడానికి 20% అవకాశం ఉంది
- యాదృచ్ఛికంగా దాని చర్చలలో దేనినైనా ఎంచుకుంటుంది
- లోపలికి వెళుతుంది
- సందేశాలు, వినియోగదారు ప్రొఫైల్‌లను అభ్యర్థిస్తుంది
- ఈ చర్చ నుండి యాదృచ్ఛిక వినియోగదారులకు ఉద్దేశించిన ఐదు సందేశాలను సృష్టిస్తుంది
- చర్చను వదిలివేస్తుంది
- 20 సార్లు పునరావృతమవుతుంది
- లాగ్ అవుట్ చేసి, స్క్రిప్ట్ ప్రారంభానికి తిరిగి వెళుతుంది
- ఒక చాట్‌బాట్ సిస్టమ్‌లోకి ప్రవేశిస్తుంది (అప్లికేషన్ కోడ్ నుండి సందేశాన్ని అనుకరిస్తుంది)
- డేటా మార్పిడి కోసం కొత్త ఛానెల్‌ని సృష్టించడానికి 50% అవకాశం ఉంది (ప్రత్యేక చర్చ)
- 50% ఇప్పటికే ఉన్న ఛానెల్‌లలో దేనికైనా సందేశాన్ని వ్రాయవచ్చు
"కనెక్షన్లు మాత్రమే" దృశ్యం ఒక కారణం కోసం కనిపించింది. ఒక పరిస్థితి ఉంది: వినియోగదారులు సిస్టమ్‌ను కనెక్ట్ చేసారు, కానీ ఇంకా పాలుపంచుకోలేదు. ప్రతి వినియోగదారు ఉదయం 09:00 గంటలకు కంప్యూటర్‌ను ఆన్ చేసి, సర్వర్‌కు కనెక్షన్‌ని ఏర్పాటు చేసి మౌనంగా ఉంటారు. ఈ కుర్రాళ్ళు ప్రమాదకరమైనవి, వారిలో చాలా మంది ఉన్నారు - వారి వద్ద ఉన్న ఏకైక ప్యాకేజీలు పింగ్/పాంగ్, కానీ వారు సర్వర్‌కి కనెక్షన్‌ని ఉంచుతారు (వారు దానిని కొనసాగించలేరు - కొత్త సందేశం ఉంటే ఏమి చేయాలి). అటువంటి వినియోగదారులు పెద్ద సంఖ్యలో అరగంటలో సిస్టమ్‌కు లాగిన్ అవ్వడానికి ప్రయత్నించే పరిస్థితిని పరీక్ష పునరుత్పత్తి చేస్తుంది. ఇది ఒత్తిడి పరీక్ష మాదిరిగానే ఉంటుంది, కానీ దాని దృష్టి ఖచ్చితంగా ఈ మొదటి ఇన్‌పుట్‌పై ఉంటుంది - తద్వారా వైఫల్యాలు లేవు (ఒక వ్యక్తి సిస్టమ్‌ను ఉపయోగించడు, మరియు అది ఇప్పటికే పడిపోయింది - అధ్వాన్నంగా ఆలోచించడం కష్టం).
సబ్‌స్క్రైబర్ రిజిస్ట్రేషన్ స్క్రిప్ట్ మొదటి లాంచ్ నుండి ప్రారంభమవుతుంది. మేము ఒత్తిడి పరీక్షను నిర్వహించాము మరియు కరస్పాండెన్స్ సమయంలో సిస్టమ్ నెమ్మదించలేదని నిర్ధారించుకున్నాము. కానీ వినియోగదారులు వచ్చారు మరియు గడువు ముగియడం వల్ల రిజిస్ట్రేషన్ విఫలమైంది. నమోదు చేసేటప్పుడు మేము ఉపయోగించాము , ఇది వ్యవస్థ యొక్క ఎంట్రోపీకి సంబంధించినది. సర్వర్‌కు తగినంత ఎంట్రోపీని సేకరించడానికి సమయం లేదు మరియు కొత్త SecureRandom అభ్యర్థించబడినప్పుడు, అది పది సెకన్లపాటు స్తంభించిపోయింది. ఈ పరిస్థితి నుండి బయటపడటానికి అనేక మార్గాలు ఉన్నాయి, ఉదాహరణకు: తక్కువ సురక్షితమైన /dev/urandomకి మారండి, ఎంట్రోపీని ఉత్పత్తి చేసే ప్రత్యేక బోర్డ్‌ను ఇన్‌స్టాల్ చేయండి, యాదృచ్ఛిక సంఖ్యలను ముందుగానే రూపొందించండి మరియు వాటిని పూల్‌లో నిల్వ చేయండి. మేము పూల్‌తో సమస్యను తాత్కాలికంగా మూసివేసాము, కానీ అప్పటి నుండి మేము కొత్త చందాదారులను నమోదు చేయడానికి ప్రత్యేక పరీక్షను అమలు చేస్తున్నాము.
మేము లోడ్ జనరేటర్‌గా ఉపయోగిస్తాము . వెబ్‌సాకెట్‌తో ఎలా పని చేయాలో దీనికి తెలియదు; దీనికి ప్లగ్ఇన్ అవసరం. "jmeter websocket" ప్రశ్న కోసం శోధన ఫలితాల్లో మొదటివి: , ఇది సిఫార్సు చేస్తుంది .
అక్కడే ప్రారంభించాలని నిర్ణయించుకున్నాం.
తీవ్రమైన పరీక్షను ప్రారంభించిన వెంటనే, JMeter మెమరీని లీక్ చేయడం ప్రారంభించిందని మేము కనుగొన్నాము.
ప్లగ్ఇన్ ఒక ప్రత్యేక పెద్ద కథనం; 176 నక్షత్రాలతో, ఇది గితుబ్‌లో 132 ఫోర్క్‌లను కలిగి ఉంది. రచయిత స్వయంగా 2015 నుండి దానికి కట్టుబడి లేదు (మేము దానిని 2015 లో తీసుకున్నాము, అప్పుడు అది అనుమానాలను పెంచలేదు), మెమరీ లీక్‌లకు సంబంధించి అనేక గిథబ్ సమస్యలు, 7 అన్‌క్లోజ్డ్ పుల్ అభ్యర్థనలు.
మీరు ఈ ప్లగ్‌ఇన్‌ని ఉపయోగించి లోడ్ పరీక్షను నిర్వహించాలని నిర్ణయించుకుంటే, దయచేసి క్రింది చర్చలకు శ్రద్ధ వహించండి:
- బహుళ-థ్రెడ్ వాతావరణంలో, సాధారణ లింక్డ్‌లిస్ట్ ఉపయోగించబడింది మరియు ఫలితం వచ్చింది రన్‌టైమ్‌లో. ఇది ConcurrentLinkedDequeకి మారడం ద్వారా లేదా సమకాలీకరించబడిన బ్లాక్‌ల ద్వారా పరిష్కరించబడుతుంది. మేము మా కోసం మొదటి ఎంపికను ఎంచుకున్నాము ().
- మెమరీ లీక్; డిస్‌కనెక్ట్ చేస్తున్నప్పుడు, కనెక్షన్ సమాచారం తొలగించబడదు ().
- స్ట్రీమింగ్ మోడ్‌లో (నమూనా చివరిలో వెబ్‌సాకెట్ మూసివేయబడనప్పుడు, కానీ ప్లాన్‌లో తర్వాత ఉపయోగించినప్పుడు), ప్రతిస్పందన నమూనాలు పని చేయవు ().
గితుబ్‌లో ఉన్న వాటిలో ఇది ఒకటి. మేము ఏమి చేసాము:
- తీసుకున్నారు (@elyrank) - ఇది 1 మరియు 3 సమస్యలను పరిష్కరిస్తుంది
- పరిష్కరించబడిన సమస్య 2
- 9.2.14 నుండి 9.3.12 వరకు జెట్టీని నవీకరించబడింది
- థ్రెడ్‌లోకల్‌లో ర్యాప్డ్ సింపుల్‌డేట్ ఫార్మాట్; SimpleDateFormat థ్రెడ్-సురక్షితమైనది కాదు, ఇది రన్‌టైమ్‌లో NPEకి దారితీసింది
- మరొక మెమరీ లీక్ పరిష్కరించబడింది (కనెక్షన్ డిస్‌కనెక్ట్ అయినప్పుడు తప్పుగా మూసివేయబడింది)
మరియు ఇంకా అది ప్రవహిస్తుంది!
జ్ఞాపకశక్తి ఒక్కరోజులో కాదు, రెండు రోజుల్లో అయిపోయింది. ఖచ్చితంగా సమయం లేదు, కాబట్టి మేము తక్కువ థ్రెడ్‌లను ప్రారంభించాలని నిర్ణయించుకున్నాము, కానీ నలుగురు ఏజెంట్లపై. ఇది కనీసం ఒక వారం పాటు సరిపోతుంది.
రెండు రోజులు గడిచాయి...
ఇప్పుడు Hazelcast మెమరీ అయిపోతోంది. రెండు రోజుల పరీక్ష తర్వాత, హాజెల్‌కాస్ట్ జ్ఞాపకశక్తి లోపం గురించి ఫిర్యాదు చేయడం ప్రారంభించిందని మరియు కొంత సమయం తరువాత క్లస్టర్ విడిపోయిందని మరియు నోడ్‌లు ఒక్కొక్కటిగా చనిపోతాయని లాగ్‌లు చూపించాయి. మేము JVisualVMని హాజెల్‌కాస్ట్‌కి కనెక్ట్ చేసాము మరియు "రైజింగ్ రంపాన్ని" చూసాము - ఇది క్రమం తప్పకుండా GC అని పిలువబడుతుంది, కానీ మెమరీని క్లియర్ చేయలేకపోయాము.
హాజెల్‌కాస్ట్ 3.4లో, మ్యాప్ / మల్టీమ్యాప్ (map.destroy())ని తొలగిస్తున్నప్పుడు, మెమరీ పూర్తిగా విడుదల చేయబడదని తేలింది:
బగ్ ఇప్పుడు 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");ప్రతి సబ్‌స్క్రిప్షన్ కోసం మల్టీమ్యాప్ సృష్టించబడింది మరియు అవసరం లేనప్పుడు తొలగించబడుతుంది. మేము మ్యాప్‌ని ప్రారంభించాలని నిర్ణయించుకున్నాము , కీ సబ్‌స్క్రిప్షన్ పేరు మరియు విలువలు సెషన్ ఐడెంటిఫైయర్‌లుగా ఉంటాయి (అవసరమైతే మీరు వినియోగదారు ఐడెంటిఫైయర్‌లను పొందవచ్చు).
public void join(Authentication auth, String sub) {
addValueToMap(sub, auth.getSessionId());
}
public void leave(Authentication auth, String sub) {
removeValueFromMap(sub, auth.getSessionId());
}చార్ట్‌లు మెరుగుపడ్డాయి.
లోడ్ పరీక్ష గురించి మనం ఇంకా ఏమి నేర్చుకున్నాము?
- JSR223 గ్రూవీలో వ్రాయబడాలి మరియు సంకలన కాష్‌ని చేర్చాలి - ఇది చాలా వేగంగా ఉంటుంది. .
- Jmeter-Plugins గ్రాఫ్‌లు ప్రామాణికమైన వాటి కంటే సులభంగా అర్థం చేసుకోవచ్చు. .
Hazelcastతో మా అనుభవం గురించి
Hazelcast మా కోసం ఒక కొత్త ఉత్పత్తి, మేము వెర్షన్ 3.4.1 నుండి దానితో పని చేయడం ప్రారంభించాము, ఇప్పుడు మా ప్రొడక్షన్ సర్వర్ వెర్షన్ 3.9.2ని అమలు చేస్తోంది (వ్రాసే సమయంలో, Hazelcast యొక్క తాజా వెర్షన్ 3.10).
ID జనరేషన్
మేము పూర్ణాంక ఐడెంటిఫైయర్‌లతో ప్రారంభించాము. కొత్త ఎంటిటీ కోసం మనకు మరో లాంగ్ అవసరమని ఊహించుకుందాం. డేటాబేస్‌లోని సీక్వెన్స్ తగినది కాదు, టేబుల్‌లు షేర్డింగ్‌లో పాల్గొంటాయి - DB1లో సందేశం ID=1 మరియు DB1లో సందేశం ID=2 ఉన్నట్లు తేలింది, మీరు ఈ IDని ఎలాస్టిక్‌సెర్చ్‌లో లేదా హాజెల్‌కాస్ట్‌లో ఉంచలేరు. , కానీ చెత్త విషయం ఏమిటంటే, మీరు రెండు డేటాబేస్‌ల నుండి డేటాను ఒకటిగా కలపాలనుకుంటే (ఉదాహరణకు, ఈ చందాదారులకు ఒక డేటాబేస్ సరిపోతుందని నిర్ణయించడం). మీరు Hazelcastకి అనేక అటామిక్‌లాంగ్‌లను జోడించవచ్చు మరియు కౌంటర్‌ను అక్కడ ఉంచవచ్చు, ఆపై కొత్త IDని పొందడం యొక్క పనితీరు ఇంక్రిమెంట్ అండ్ గెట్ మరియు Hazelcastకి అభ్యర్థన కోసం సమయం ఉంటుంది. కానీ హాజెల్‌కాస్ట్‌కు మరింత సరైనది ఉంది - ఫ్లేక్‌ఐడ్‌జెనరేటర్. ప్రతి క్లయింట్‌ను సంప్రదించినప్పుడు, వారికి ID పరిధి ఇవ్వబడుతుంది, ఉదాహరణకు, మొదటిది - 1 నుండి 10 వరకు, రెండవది - 000 నుండి 10 వరకు, మరియు మొదలైనవి. ఇప్పుడు క్లయింట్ దానికి జారీ చేసిన పరిధి ముగిసే వరకు దాని స్వంతంగా కొత్త ఐడెంటిఫైయర్‌లను జారీ చేయవచ్చు. ఇది త్వరగా పని చేస్తుంది, కానీ మీరు అప్లికేషన్ (మరియు Hazelcast క్లయింట్) పునఃప్రారంభించినప్పుడు, ఒక కొత్త క్రమం ప్రారంభమవుతుంది - అందుకే స్కిప్‌లు మొదలైనవి. అదనంగా, IDలు పూర్ణాంకం ఎందుకు అని డెవలపర్‌లు నిజంగా అర్థం చేసుకోలేరు, కానీ అవి చాలా అస్థిరంగా ఉన్నాయి. మేము అన్నింటినీ తూకం వేసి UUIDలకు మార్చాము.
మార్గం ద్వారా, ట్విట్టర్ లాగా ఉండాలనుకునే వారికి, అటువంటి స్నోకాస్ట్ లైబ్రరీ ఉంది - ఇది హాజెల్‌కాస్ట్ పైన స్నోఫ్లేక్ యొక్క అమలు. మీరు దీన్ని ఇక్కడ చూడవచ్చు:
కానీ మేము ఇకపై దాని చుట్టూ చేరుకోలేదు.
TransactionalMap.replace
మరొక ఆశ్చర్యం: 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 పని చేస్తుంది, కానీ లావాదేవీ మ్యాప్ ఉనికిలో లేదు.
పనికిరాని సమయం లేకుండా కొత్త JARని చొప్పించండి
మొదట, మేము హాజెల్‌కాస్ట్‌లో మా తరగతుల వస్తువులను రికార్డ్ చేయాలని నిర్ణయించుకున్నాము. ఉదాహరణకు, మాకు అప్లికేషన్ క్లాస్ ఉంది, మేము దానిని సేవ్ చేసి చదవాలనుకుంటున్నాము. సేవ్:
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ని తీసుకోదు. ఈ సమయంలో మేము ఇండెక్స్ శోధన లేకుండా జీవించవచ్చని నిర్ణయించుకున్నాము. అన్నింటికంటే, మీరు హాజెల్‌కాస్ట్‌ని కీ-వాల్యూ స్టోర్‌గా ఉపయోగిస్తే, అప్పుడు ప్రతిదీ పని చేస్తుందా? నిజంగా కాదు. ఇక్కడ మళ్లీ 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 to 0)లో అన్ని ప్రశ్నల లాగింగ్‌ని ఆన్ చేస్తాము మరియు 20 నిమిషాల పాటు లోడ్ టెస్టింగ్‌ను అమలు చేస్తాము. సేకరించిన లాగ్‌లను ఉపయోగించి, pgFouine మరియు pgBadger వంటి యుటిలిటీలు విశ్లేషణాత్మక నివేదికలను రూపొందించగలవు. నివేదికలలో, మేము ప్రధానంగా నెమ్మదిగా మరియు తరచుగా వచ్చే ప్రశ్నల కోసం చూస్తాము. స్లో క్వెరీల కోసం, మేము ఎగ్జిక్యూషన్ ప్లాన్‌ని (వివరించండి) నిర్మిస్తాము మరియు అటువంటి ప్రశ్నను వేగవంతం చేయవచ్చో లేదో అంచనా వేస్తాము. ఒకే ఇన్‌పుట్ డేటా కోసం తరచుగా వచ్చే అభ్యర్థనలు కాష్‌కి బాగా సరిపోతాయి. మేము ప్రశ్నలను "ఫ్లాట్"గా ఉంచడానికి ప్రయత్నిస్తాము, ప్రతి ప్రశ్నకు ఒక టేబుల్.
దోపిడీ
SV ఆన్‌లైన్ సేవగా 2017 వసంతకాలంలో అమలులోకి వచ్చింది మరియు ప్రత్యేక ఉత్పత్తిగా, SV నవంబర్ 2017లో విడుదలైంది (ఆ సమయంలో బీటా వెర్షన్ హోదాలో ఉంది).
ఒక సంవత్సరం కంటే ఎక్కువ ఆపరేషన్‌లో, CB ఆన్‌లైన్ సేవ యొక్క ఆపరేషన్‌లో తీవ్రమైన సమస్యలు లేవు. మేము దీని ద్వారా ఆన్‌లైన్ సేవను పర్యవేక్షిస్తాము , నుండి సేకరించండి మరియు అమలు చేయండి .
SV సర్వర్ పంపిణీ స్థానిక ప్యాకేజీల రూపంలో సరఫరా చేయబడుతుంది: RPM, DEB, MSI. Windows కోసం మేము ఒకే EXE రూపంలో ఒకే ఇన్‌స్టాలర్‌ను అందిస్తాము, అది సర్వర్, Hazelcast మరియు Elasticsearchని ఒక మెషీన్‌లో ఇన్‌స్టాల్ చేస్తుంది. మేము మొదట ఈ ఇన్‌స్టాలేషన్ వెర్షన్‌ను “డెమో” వెర్షన్‌గా సూచించాము, అయితే ఇది అత్యంత ప్రజాదరణ పొందిన విస్తరణ ఎంపిక అని ఇప్పుడు స్పష్టమైంది.
మూలం: www.habr.com