మిఖాయిల్ సలోసిన్ (ఇకపై - MS): - అందరికి వందనాలు! నా పేరు మైఖేల్. నేను MC2 సాఫ్ట్‌వేర్‌లో బ్యాకెండ్ డెవలపర్‌గా పని చేస్తున్నాను మరియు Look+ మొబైల్ అప్లికేషన్ యొక్క బ్యాకెండ్‌లో Goని ఉపయోగించడం గురించి మాట్లాడతాను.
ఇక్కడ ఎవరైనా హాకీని ఇష్టపడతారా?
అప్పుడు ఈ అప్లికేషన్ మీ కోసం. ఇది Android మరియు iOS కోసం మరియు ఆన్‌లైన్‌లో మరియు రికార్డ్ చేయబడిన వివిధ క్రీడా ఈవెంట్‌ల ప్రసారాలను చూడటానికి ఉపయోగించబడుతుంది. అప్లికేషన్ వివిధ గణాంకాలు, వచన ప్రసారాలు, సమావేశాల కోసం పట్టికలు, టోర్నమెంట్‌లు మరియు అభిమానులకు ఉపయోగపడే ఇతర సమాచారాన్ని కూడా కలిగి ఉంది.
అప్లికేషన్‌లో వీడియో క్షణాలు వంటి విషయం కూడా ఉంది, అనగా మీరు మ్యాచ్‌ల యొక్క ముఖ్యమైన క్షణాలను చూడవచ్చు (గోల్స్, ఫైట్లు, షూటౌట్‌లు మొదలైనవి). మీరు మొత్తం ప్రసారాన్ని చూడకూడదనుకుంటే, మీరు చాలా ఆసక్తికరమైన వాటిని మాత్రమే చూడవచ్చు.
మీరు అభివృద్ధిలో ఏమి ఉపయోగించారు?
ప్రధాన భాగం గోలో వ్రాయబడింది. మొబైల్ క్లయింట్లు కమ్యూనికేట్ చేసిన API గోలో వ్రాయబడింది. మొబైల్ ఫోన్‌లకు పుష్ నోటిఫికేషన్‌లను పంపే సేవ కూడా గోలో వ్రాయబడింది. మేము మా స్వంత ORM ను కూడా వ్రాయవలసి వచ్చింది, దాని గురించి మనం ఏదో ఒక రోజు మాట్లాడవచ్చు. సరే, కొన్ని చిన్న సేవలు Goలో వ్రాయబడ్డాయి: ఎడిటర్‌ల కోసం చిత్రాల పరిమాణాన్ని మార్చడం మరియు లోడ్ చేయడం...
మేము PostgreSQLని డేటాబేస్‌గా ఉపయోగించాము. ఎడిటర్ ఇంటర్‌ఫేస్ యాక్టివ్ అడ్మిన్ రత్నాన్ని ఉపయోగించి రూబీ ఆన్ రైల్స్‌లో వ్రాయబడింది. స్టాటిస్టిక్స్ ప్రొవైడర్ నుండి గణాంకాలను దిగుమతి చేసుకోవడం కూడా రూబీలో వ్రాయబడింది.
సిస్టమ్ API పరీక్షల కోసం, మేము పైథాన్ యూనిట్‌టెస్ట్‌ని ఉపయోగించాము. Memcached API చెల్లింపు కాల్‌లను థ్రోటిల్ చేయడానికి ఉపయోగించబడుతుంది, కాన్ఫిగరేషన్‌ని నియంత్రించడానికి “చెఫ్” ఉపయోగించబడుతుంది, అంతర్గత సిస్టమ్ గణాంకాలను సేకరించడానికి మరియు పర్యవేక్షించడానికి Zabbix ఉపయోగించబడుతుంది. Graylog2 అనేది లాగ్‌లను సేకరించడం కోసం, స్లేట్ అనేది క్లయింట్‌ల కోసం API డాక్యుమెంటేషన్.
ప్రోటోకాల్ ఎంపిక
మేము ఎదుర్కొన్న మొదటి సమస్య: కింది పాయింట్‌ల ఆధారంగా బ్యాకెండ్ మరియు మొబైల్ క్లయింట్‌ల మధ్య పరస్పర చర్య కోసం మేము ప్రోటోకాల్‌ను ఎంచుకోవాలి...
- అతి ముఖ్యమైన అవసరం: క్లయింట్‌లపై డేటా తప్పనిసరిగా నిజ సమయంలో అప్‌డేట్ చేయబడాలి. అంటే, ప్రస్తుతం ప్రసారాన్ని చూస్తున్న ప్రతి ఒక్కరూ దాదాపు తక్షణమే నవీకరణలను స్వీకరించాలి.
- విషయాలను సులభతరం చేయడానికి, క్లయింట్‌లతో సమకాలీకరించబడిన డేటా తొలగించబడదని, ప్రత్యేక ఫ్లాగ్‌లను ఉపయోగించి దాచబడిందని మేము భావించాము.
- అన్ని రకాల అరుదైన అభ్యర్థనలు (గణాంకాలు, జట్టు కూర్పులు, జట్టు గణాంకాలు వంటివి) సాధారణ GET అభ్యర్థనల ద్వారా పొందబడతాయి.
- అదనంగా, సిస్టమ్ ఒకే సమయంలో 100 వేల మంది వినియోగదారులకు సులభంగా మద్దతు ఇవ్వాలి.
దీని ఆధారంగా, మాకు రెండు ప్రోటోకాల్ ఎంపికలు ఉన్నాయి:
- వెబ్‌సాకెట్‌లు. కానీ మాకు క్లయింట్ నుండి సర్వర్‌కు ఛానెల్‌లు అవసరం లేదు. మేము సర్వర్ నుండి క్లయింట్‌కు నవీకరణలను మాత్రమే పంపాలి, కాబట్టి వెబ్‌సాకెట్ అనేది అనవసరమైన ఎంపిక.
- సర్వర్-పంపిన ఈవెంట్‌లు (SSE) సరిగ్గా వచ్చాయి! ఇది చాలా సులభం మరియు ప్రాథమికంగా మనకు అవసరమైన ప్రతిదాన్ని సంతృప్తిపరుస్తుంది.
సర్వర్-పంపిన ఈవెంట్‌లు
ఈ విషయం ఎలా పని చేస్తుందనే దాని గురించి కొన్ని మాటలు...
ఇది http కనెక్షన్ పైన నడుస్తుంది. క్లయింట్ అభ్యర్థనను పంపుతుంది, సర్వర్ కంటెంట్-రకం: టెక్స్ట్/ఈవెంట్-స్ట్రీమ్‌తో ప్రతిస్పందిస్తుంది మరియు క్లయింట్‌తో కనెక్షన్‌ను మూసివేయదు, కానీ కనెక్షన్‌కు డేటాను వ్రాయడం కొనసాగిస్తుంది:
క్లయింట్‌లతో అంగీకరించిన ఫార్మాట్‌లో డేటాను పంపవచ్చు. మా విషయంలో, మేము దీన్ని ఈ ఫారమ్‌లో పంపాము: మార్చబడిన నిర్మాణం (వ్యక్తి, ప్లేయర్) పేరు ఈవెంట్ ఫీల్డ్‌కు పంపబడింది మరియు ప్లేయర్ కోసం కొత్త, మార్చబడిన ఫీల్డ్‌లతో JSON డేటా ఫీల్డ్‌కు పంపబడింది.
ఇప్పుడు పరస్పర చర్య ఎలా పనిచేస్తుందనే దాని గురించి మాట్లాడుదాం.
- క్లయింట్ చేసే మొదటి పని సేవతో చివరిసారి సమకాలీకరణను నిర్ణయించడం: ఇది దాని స్థానిక డేటాబేస్‌ను చూస్తుంది మరియు దాని ద్వారా నమోదు చేయబడిన చివరి మార్పు తేదీని నిర్ణయిస్తుంది.
- ఇది ఈ తేదీతో అభ్యర్థనను పంపుతుంది.
- ప్రతిస్పందనగా, మేము ఆ తేదీ నుండి సంభవించిన అన్ని నవీకరణలను అతనికి పంపాము.
- ఆ తర్వాత, ఇది లైవ్ ఛానెల్‌కి కనెక్షన్ చేస్తుంది మరియు దీనికి ఈ అప్‌డేట్‌లు అవసరమయ్యే వరకు మూసివేయదు:
మేము అతనికి మార్పుల జాబితాను పంపుతాము: ఎవరైనా గోల్ చేస్తే, మేము మ్యాచ్ స్కోర్‌ను మారుస్తాము, అతను గాయపడినట్లయితే, ఇది నిజ సమయంలో కూడా పంపబడుతుంది. అందువల్ల, క్లయింట్లు మ్యాచ్ ఈవెంట్ ఫీడ్‌లో తక్షణమే తాజా డేటాను స్వీకరిస్తారు. క్రమానుగతంగా, సర్వర్ చనిపోలేదని క్లయింట్ అర్థం చేసుకోవడానికి, దానికి ఏమీ జరగలేదని, మేము ప్రతి 15 సెకన్లకు టైమ్‌స్టాంప్‌ను పంపుతాము - తద్వారా ప్రతిదీ సక్రమంగా ఉందని మరియు మళ్లీ కనెక్ట్ చేయవలసిన అవసరం లేదని తెలుస్తుంది.
ప్రత్యక్ష కనెక్షన్ ఎలా అందించబడుతుంది?
- అన్నింటిలో మొదటిది, మేము బఫర్ చేయబడిన నవీకరణలను స్వీకరించే ఛానెల్‌ని సృష్టిస్తాము.
- ఆ తర్వాత, అప్‌డేట్‌లను అందుకోవడానికి మేము ఈ ఛానెల్‌ని సబ్‌స్క్రైబ్ చేస్తాము.
- మేము సరైన హెడర్‌ని సెట్ చేసాము, తద్వారా క్లయింట్‌కు ప్రతిదీ సరిగ్గా ఉందని తెలుస్తుంది.
- మొదటి పింగ్ పంపండి. మేము ప్రస్తుత కనెక్షన్ టైమ్‌స్టాంప్‌ను రికార్డ్ చేస్తాము.
- ఆ తర్వాత, అప్‌డేట్ ఛానెల్ మూసివేయబడే వరకు మేము ఛానెల్ నుండి లూప్‌లో చదువుతాము. ఛానెల్ క్రమానుగతంగా ప్రస్తుత టైమ్‌స్టాంప్ లేదా కనెక్షన్‌లను తెరవడానికి మేము ఇప్పటికే వ్రాస్తున్న మార్పులను స్వీకరిస్తుంది.
మేము ఎదుర్కొన్న మొదటి సమస్య ఏమిటంటే: క్లయింట్‌తో తెరిచిన ప్రతి కనెక్షన్ కోసం, మేము ప్రతి 15 సెకన్లకు ఒకసారి టిక్ చేసే టైమర్‌ను సృష్టించాము - మేము ఒక మెషీన్‌తో (ఒక API సర్వర్‌తో) 6 వేల కనెక్షన్‌లను తెరిచినట్లయితే, 6 అని తేలింది. వెయ్యి టైమర్లు సృష్టించబడ్డాయి. ఇది యంత్రం అవసరమైన లోడ్‌ను కలిగి ఉండకపోవడానికి దారితీసింది. సమస్య మాకు అంత స్పష్టంగా కనిపించలేదు, కానీ మేము కొద్దిగా సహాయం పొంది దాన్ని పరిష్కరించాము.
ఫలితంగా, ఇప్పుడు మన పింగ్ అదే ఛానెల్ నుండి నవీకరణ వస్తుంది.
దీని ప్రకారం, ప్రతి 15 సెకన్లకు ఒకసారి టిక్ చేసే ఒక టైమర్ మాత్రమే ఉంది.
ఇక్కడ అనేక సహాయక విధులు ఉన్నాయి - హెడర్, పింగ్ మరియు నిర్మాణాన్ని పంపడం. అంటే, పట్టిక పేరు (వ్యక్తి, మ్యాచ్, సీజన్) మరియు ఈ ఎంట్రీ గురించిన సమాచారం ఇక్కడ ప్రసారం చేయబడుతుంది:
నవీకరణలను పంపడానికి మెకానిజం
మార్పులు ఎక్కడ నుండి వచ్చాయో ఇప్పుడు కొంచెం. ప్రసారాన్ని నిజ సమయంలో చూసే అనేక మంది వ్యక్తులు, సంపాదకులు ఉన్నారు. వారు అన్ని ఈవెంట్‌లను సృష్టిస్తారు: ఎవరైనా పంపబడ్డారు, ఎవరైనా గాయపడ్డారు, ఒక రకమైన భర్తీ...
CMS ఉపయోగించి, డేటా డేటాబేస్లోకి ప్రవేశిస్తుంది. దీని తర్వాత, డేటాబేస్ దీని గురించి API సర్వర్‌లకు Listen/Notify మెకానిజం ఉపయోగించి తెలియజేస్తుంది. API సర్వర్లు ఇప్పటికే ఈ సమాచారాన్ని క్లయింట్‌లకు పంపాయి. అందువల్ల, మేము తప్పనిసరిగా డేటాబేస్కు కొన్ని సర్వర్‌లను మాత్రమే కనెక్ట్ చేసాము మరియు డేటాబేస్‌పై ప్రత్యేక లోడ్ లేదు, ఎందుకంటే క్లయింట్ డేటాబేస్‌తో నేరుగా ఏ విధంగానూ సంకర్షణ చెందదు:
PostgreSQL: వినండి/నోటిఫై చేయండి
పోస్ట్‌గ్రెస్‌లోని లిసన్/నోటిఫై మెకానిజం ఈవెంట్ సబ్‌స్క్రైబర్‌లకు కొంత ఈవెంట్ మారిందని తెలియజేయడానికి మిమ్మల్ని అనుమతిస్తుంది - డేటాబేస్‌లో కొంత రికార్డ్ సృష్టించబడింది. దీన్ని చేయడానికి, మేము ఒక సాధారణ ట్రిగ్గర్ మరియు ఫంక్షన్‌ని వ్రాసాము:
రికార్డ్‌ను చొప్పించేటప్పుడు లేదా మార్చేటప్పుడు, మేము డేటా_అప్‌డేట్‌ల ఛానెల్‌లో నోటిఫికేషన్ ఫంక్షన్‌ని పిలుస్తాము, టేబుల్ పేరు మరియు మార్చబడిన లేదా చొప్పించిన రికార్డ్ యొక్క ఐడెంటిఫైయర్‌ని అక్కడ పంపుతాము.
క్లయింట్‌తో సమకాలీకరించబడే అన్ని పట్టికల కోసం, మేము ఒక ట్రిగ్గర్‌ను నిర్వచిస్తాము, ఇది రికార్డ్‌ను మార్చిన / నవీకరించిన తర్వాత, దిగువ స్లయిడ్‌లో సూచించిన ఫంక్షన్‌ను కాల్ చేస్తుంది.
ఈ మార్పులకు API ఎలా సభ్యత్వం పొందుతుంది?
ఫ్యాన్అవుట్ మెకానిజం సృష్టించబడింది - ఇది క్లయింట్‌కు సందేశాలను పంపుతుంది. ఇది అన్ని కస్టమర్ ఛానెల్‌లను సేకరిస్తుంది మరియు ఈ ఛానెల్‌ల ద్వారా అందుకున్న అప్‌డేట్‌లను పంపుతుంది:
ఇక్కడ స్టాండర్డ్ pq లైబ్రరీ, ఇది డేటాబేస్కు కనెక్ట్ చేసి, ఛానెల్ (డేటా_అప్‌డేట్‌లు) వినాలనుకుంటున్నట్లు చెబుతుంది, కనెక్షన్ తెరిచి ఉందని మరియు అంతా బాగానే ఉందో లేదో తనిఖీ చేస్తుంది. నేను స్థలాన్ని ఆదా చేయడానికి ఎర్రర్ తనిఖీని విస్మరిస్తున్నాను (తనిఖీ చేయకపోవడం ప్రమాదకరం).
తర్వాత, మేము టిక్కర్‌ను అసమకాలికంగా సెట్ చేస్తాము, ఇది ప్రతి 15 సెకన్లకు ఒక పింగ్‌ని పంపుతుంది మరియు మేము సబ్‌స్క్రైబ్ చేసిన ఛానెల్‌ని వినడం ప్రారంభిస్తాము. మేము పింగ్‌ను స్వీకరిస్తే, మేము ఈ పింగ్‌ను ప్రచురిస్తాము. మేము ఒక రకమైన ఎంట్రీని స్వీకరిస్తే, ఈ ఫానౌట్ యొక్క సభ్యులందరికీ మేము ఈ ఎంట్రీని ప్రచురిస్తాము.
ఫ్యాన్ అవుట్ ఎలా పని చేస్తుంది?
రష్యన్ భాషలో ఇది "స్ప్లిటర్" అని అనువదిస్తుంది. కొన్ని అప్‌డేట్‌లను స్వీకరించాలనుకునే సబ్‌స్క్రైబర్‌లను నమోదు చేసే ఒక వస్తువు మా వద్ద ఉంది. మరియు ఈ ఆబ్జెక్ట్‌కి అప్‌డేట్ వచ్చిన వెంటనే, అది ఈ అప్‌డేట్‌ని తన సబ్‌స్క్రైబర్‌లందరికీ పంపిణీ చేస్తుంది. తగినంత సరళమైనది:
Goలో ఇది ఎలా అమలు చేయబడింది:
ఒక నిర్మాణం ఉంది, ఇది Mutexes ఉపయోగించి సమకాలీకరించబడింది. ఇది డేటాబేస్కు Fanout యొక్క కనెక్షన్ స్థితిని సేవ్ చేసే ఫీల్డ్‌ను కలిగి ఉంది, అనగా ఇది ప్రస్తుతం వింటోంది మరియు అప్‌డేట్‌లను స్వీకరిస్తుంది, అలాగే అందుబాటులో ఉన్న అన్ని ఛానెల్‌ల జాబితా - మ్యాప్, దీని కీ ఛానెల్ మరియు దీని రూపంలో రూపొందించబడింది విలువలు (ముఖ్యంగా ఇది ఏ విధంగానూ ఉపయోగించబడదు).
రెండు పద్ధతులు - కనెక్ట్ చేయబడింది మరియు డిస్‌కనెక్ట్ చేయబడింది - మాకు బేస్‌కి కనెక్షన్ ఉందని, అది కనిపించిందని మరియు బేస్‌కి కనెక్షన్ విచ్ఛిన్నమైందని ఫ్యానౌట్‌కు చెప్పడానికి మమ్మల్ని అనుమతిస్తుంది. రెండవ సందర్భంలో, మీరు క్లయింట్‌లందరినీ డిస్‌కనెక్ట్ చేసి, వారు ఇకపై ఏదైనా వినలేరని మరియు వారికి కనెక్షన్ మూసివేయబడినందున వారు మళ్లీ కనెక్ట్ అవుతారని వారికి చెప్పాలి.
"శ్రోతలు"కి ఛానెల్‌ని జోడించే సబ్‌స్క్రైబ్ పద్ధతి కూడా ఉంది:
ఒక అన్‌సబ్‌స్క్రయిబ్ పద్ధతి ఉంది, ఇది క్లయింట్ డిస్‌కనెక్ట్ అయినట్లయితే శ్రోతల నుండి ఛానెల్‌ని తీసివేస్తుంది, అలాగే మీరు చందాదారులందరికీ సందేశాన్ని పంపడానికి అనుమతించే పబ్లిష్ పద్ధతి.
ప్రశ్న: – ఈ ఛానెల్ ద్వారా ఏమి ప్రసారం చేయబడుతుంది?
కుమారి: – మార్చబడిన మోడల్ లేదా పింగ్ ప్రసారం చేయబడుతుంది (ముఖ్యంగా కేవలం ఒక సంఖ్య, పూర్ణాంకం).
కుమారి: - మీరు ఏదైనా పంపవచ్చు, ఏదైనా నిర్మాణాన్ని పంపవచ్చు, ప్రచురించవచ్చు - ఇది JSONగా మారుతుంది మరియు అంతే.
కుమారి: – మేము Postgres నుండి నోటిఫికేషన్‌ను స్వీకరిస్తాము – ఇది టేబుల్ పేరు మరియు ఐడెంటిఫైయర్‌ని కలిగి ఉంటుంది. పట్టిక పేరు మరియు ఐడెంటిఫైయర్ ఆధారంగా, మనకు అవసరమైన రికార్డును మేము పొందుతాము, ఆపై మేము ఈ నిర్మాణాన్ని ప్రచురణ కోసం పంపుతాము.
మౌలిక
ఇన్‌ఫ్రాస్ట్రక్చర్ కోణం నుండి ఇది ఎలా కనిపిస్తుంది? మాకు 7 హార్డ్‌వేర్ సర్వర్లు ఉన్నాయి: వాటిలో ఒకటి పూర్తిగా డేటాబేస్కు అంకితం చేయబడింది, మిగిలిన ఆరు వర్చువల్ మిషన్‌లను అమలు చేస్తుంది. API యొక్క 6 కాపీలు ఉన్నాయి: APIతో ఉన్న ప్రతి వర్చువల్ మెషీన్ ప్రత్యేక హార్డ్‌వేర్ సర్వర్‌లో నడుస్తుంది - ఇది విశ్వసనీయత కోసం.
యాక్సెసిబిలిటీని మెరుగుపరచడానికి Keepalivedతో మేము రెండు ఫ్రంటెండ్‌లను ఇన్‌స్టాల్ చేసాము, తద్వారా ఏదైనా జరిగితే, ఒక ఫ్రంటెండ్ మరొకదానిని భర్తీ చేయగలదు. అలాగే - CMS యొక్క రెండు కాపీలు.
స్టాటిస్టిక్స్ దిగుమతిదారు కూడా ఉన్నారు. ఒక DB స్లేవ్ ఉంది, దీని నుండి బ్యాకప్‌లు క్రమానుగతంగా తయారు చేయబడతాయి. పావురం పుషర్ ఉంది, క్లయింట్‌లకు పుష్ నోటిఫికేషన్‌లను పంపే అప్లికేషన్, అలాగే మౌలిక సదుపాయాల అంశాలు: Zabbix, Graylog2 మరియు Chef.
వాస్తవానికి, ఈ అవస్థాపన అనవసరమైనది, ఎందుకంటే 100 వేలకు తక్కువ సర్వర్‌లతో సేవ చేయవచ్చు. కానీ ఇనుము ఉంది - మేము దానిని ఉపయోగించాము (అది సాధ్యమేనని మాకు చెప్పబడింది - ఎందుకు కాదు).
గో యొక్క ప్రోస్
మేము ఈ అప్లికేషన్‌పై పని చేసిన తర్వాత, గో యొక్క అటువంటి స్పష్టమైన ప్రయోజనాలు ఉద్భవించాయి.
- కూల్ http లైబ్రరీ. దానితో మీరు బాక్స్ నుండి చాలా చాలా సృష్టించవచ్చు.
- అదనంగా, క్లయింట్‌లకు నోటిఫికేషన్‌లను పంపే మెకానిజమ్‌ను చాలా సులభంగా అమలు చేయడానికి మమ్మల్ని అనుమతించిన ఛానెల్‌లు.
- అద్భుతమైన విషయం రేస్ డిటెక్టర్ మాకు అనేక క్లిష్టమైన బగ్‌లను (స్టేజింగ్ ఇన్‌ఫ్రాస్ట్రక్చర్) తొలగించడానికి అనుమతించింది. స్టేజింగ్‌లో పనిచేసే ప్రతిదీ ప్రారంభించబడింది, రేస్ కీతో కంపైల్ చేయబడింది; మరియు మేము, తదనుగుణంగా, మనకు ఎలాంటి సంభావ్య సమస్యలు ఉన్నాయో తెలుసుకోవడానికి స్టేజింగ్ ఇన్‌ఫ్రాస్ట్రక్చర్‌ని చూడవచ్చు.
- మినిమలిజం మరియు భాష యొక్క సరళత.
మేము డెవలపర్‌ల కోసం చూస్తున్నాము! ఎవరైనా కోరుకుంటే, దయచేసి.
మీ ప్రశ్నలు
ప్రేక్షకుల నుండి ప్రశ్న (ఇకపై – బి): – మీరు ఫ్యాన్-అవుట్‌కి సంబంధించి ఒక ముఖ్యమైన విషయాన్ని మిస్ అయినట్లు నాకు అనిపిస్తోంది. మీరు క్లయింట్‌కి ప్రతిస్పందనను పంపినప్పుడు, క్లయింట్ చదవకూడదనుకుంటే మీరు బ్లాక్ చేస్తారని నేను అర్థం చేసుకోవడం సరైనదేనా?
కుమారి: - లేదు, మేము నిరోధించడం లేదు. ముందుగా, మేము nginx వెనుక ఇవన్నీ కలిగి ఉన్నాము, అంటే, స్లో క్లయింట్‌లతో ఎటువంటి సమస్యలు లేవు. రెండవది, క్లయింట్‌కు బఫర్‌తో ఛానెల్ ఉంది - వాస్తవానికి, మేము అక్కడ వంద వరకు అప్‌డేట్‌లను ఉంచగలము... మనం ఛానెల్‌కు వ్రాయలేకపోతే, అది దానిని తొలగిస్తుంది. ఛానెల్ బ్లాక్ చేయబడిందని మేము చూస్తే, మేము ఛానెల్‌ని మూసివేస్తాము మరియు అంతే - ఏదైనా సమస్య తలెత్తితే క్లయింట్ మళ్లీ కనెక్ట్ అవుతుంది. అందువలన, సూత్రప్రాయంగా, ఇక్కడ నిరోధించడం లేదు.
AT: – ఐడెంటిఫైయర్ టేబుల్‌కి కాకుండా వినడానికి/నోటిఫై చేయడానికి రికార్డ్‌ను వెంటనే పంపడం సాధ్యం కాదా?
కుమారి: – వినండి/నోటిఫై పంపే ప్రీలోడ్‌పై 8 వేల బైట్‌ల పరిమితి ఉంటుంది. సూత్రప్రాయంగా, మేము తక్కువ మొత్తంలో డేటాతో వ్యవహరిస్తుంటే పంపడం సాధ్యమవుతుంది, కానీ ఈ మార్గం [మనం చేసే విధానం] మరింత నమ్మదగినదని నాకు అనిపిస్తోంది. పరిమితులు పోస్ట్‌గ్రెస్‌లోనే ఉన్నాయి.
AT: – కస్టమర్‌లు తమకు ఆసక్తి లేని మ్యాచ్‌లపై అప్‌డేట్‌లను స్వీకరిస్తారా?
కుమారి: - సాధారణంగా, అవును. నియమం ప్రకారం, 2-3 మ్యాచ్‌లు సమాంతరంగా జరుగుతున్నాయి మరియు చాలా అరుదుగా కూడా ఉన్నాయి. క్లయింట్ ఏదైనా చూస్తున్నట్లయితే, అతను సాధారణంగా జరుగుతున్న మ్యాచ్‌ని చూస్తున్నాడు. అప్పుడు, క్లయింట్ ఈ అప్‌డేట్‌లన్నింటినీ జోడించిన స్థానిక డేటాబేస్‌ను కలిగి ఉంటుంది మరియు ఇంటర్నెట్ కనెక్షన్ లేకుండా కూడా, క్లయింట్ తనకు అప్‌డేట్‌లను కలిగి ఉన్న అన్ని గత మ్యాచ్‌లను వీక్షించవచ్చు. ముఖ్యంగా, మేము క్లయింట్ యొక్క స్థానిక డేటాబేస్‌తో సర్వర్‌లోని మా డేటాబేస్‌ను సమకాలీకరించాము, తద్వారా అతను ఆఫ్‌లైన్‌లో పని చేయవచ్చు.
AT: – మీరు మీ స్వంత ORMని ఎందుకు తయారు చేసుకున్నారు?
అలెక్సీ (లుక్+ డెవలపర్‌లలో ఒకరు): – ఆ సమయంలో (ఇది ఒక సంవత్సరం క్రితం) ఇప్పుడు కంటే తక్కువ ORMలు ఉన్నాయి, అవి చాలా ఎక్కువగా ఉన్నాయి. అక్కడ ఉన్న చాలా ORMల గురించి నాకు ఇష్టమైన విషయం ఏమిటంటే, వాటిలో చాలా వరకు ఖాళీ ఇంటర్‌ఫేస్‌లలో నడుస్తాయి. అంటే, ఈ ORMలలోని పద్ధతులు ఏదైనా తీసుకోవడానికి సిద్ధంగా ఉన్నాయి: ఒక నిర్మాణం, ఒక స్ట్రక్చర్ పాయింటర్, ఒక సంఖ్య, పూర్తిగా అసంబద్ధం...
మా ORM డేటా మోడల్ ఆధారంగా నిర్మాణాలను రూపొందిస్తుంది. నేనే. అందువల్ల అన్ని పద్ధతులు కాంక్రీటుగా ఉంటాయి, ప్రతిబింబాన్ని ఉపయోగించవద్దు, మొదలైనవి. వారు నిర్మాణాలను అంగీకరిస్తారు మరియు వచ్చిన నిర్మాణాలను ఉపయోగించాలని ఆశిస్తారు.
AT: - ఎంత మంది పాల్గొన్నారు?
కుమారి: - ప్రారంభ దశలో, ఇద్దరు వ్యక్తులు పాల్గొన్నారు. మేము జూన్‌లో ఎక్కడా ప్రారంభించాము మరియు ఆగస్టులో ప్రధాన భాగం సిద్ధంగా ఉంది (మొదటి వెర్షన్). సెప్టెంబర్‌లో విడుదలైంది.
AT: – మీరు SSEని వివరించే చోట, మీరు గడువు ముగింపుని ఉపయోగించరు. అది ఎందుకు?
కుమారి: – నిజం చెప్పాలంటే, SSE ఇప్పటికీ html5 ప్రోటోకాల్: SSE ప్రమాణం నేను అర్థం చేసుకున్నంత వరకు బ్రౌజర్‌లతో కమ్యూనికేట్ చేయడానికి రూపొందించబడింది. ఇది అదనపు ఫీచర్‌లను కలిగి ఉంది, తద్వారా బ్రౌజర్‌లు మళ్లీ కనెక్ట్ చేయగలవు (మరియు మొదలైనవి), కానీ మాకు అవి అవసరం లేదు, ఎందుకంటే సమాచారాన్ని కనెక్ట్ చేయడానికి మరియు స్వీకరించడానికి ఏదైనా లాజిక్‌ను అమలు చేయగల క్లయింట్లు మా వద్ద ఉన్నారు. మేము SSEని తయారు చేయలేదు, కానీ SSEని పోలి ఉంటుంది. ఇది ప్రోటోకాల్ కాదు.
అవసరం లేకపోయింది. నేను అర్థం చేసుకున్నంత వరకు, క్లయింట్లు దాదాపు మొదటి నుండి కనెక్షన్ మెకానిజంను అమలు చేశారు. వారు అసలు పట్టించుకోలేదు.
AT: - మీరు ఏ అదనపు యుటిలిటీలను ఉపయోగించారు?
కుమారి: – మేము శైలిని ఏకీకృతం చేయడానికి, అలాగే gofmtని చేయడానికి గోవెట్ మరియు గోలింట్‌లను చాలా చురుకుగా ఉపయోగించాము. ఇంకేమీ ఉపయోగించలేదు.
AT: - డీబగ్ చేయడానికి మీరు ఏమి ఉపయోగించారు?
కుమారి: - డీబగ్గింగ్ ఎక్కువగా పరీక్షలను ఉపయోగించి నిర్వహించబడింది. మేము ఏ డీబగ్గర్ లేదా GOPని ఉపయోగించలేదు.
AT: – మీరు పబ్లిష్ ఫంక్షన్ అమలు చేయబడిన స్లయిడ్‌ను తిరిగి ఇవ్వగలరా? ఒకే అక్షరం వేరియబుల్ పేర్లు మిమ్మల్ని గందరగోళానికి గురిచేస్తున్నాయా?
కుమారి: - లేదు. వారు దృశ్యమానత యొక్క "ఇరుకైన" పరిధిని కలిగి ఉన్నారు. అవి ఇక్కడ తప్ప మరెక్కడా ఉపయోగించబడవు (ఈ తరగతి యొక్క అంతర్గత మినహా), మరియు ఇది చాలా కాంపాక్ట్ - దీనికి 7 పంక్తులు మాత్రమే పడుతుంది.
AT: - ఏదో ఒకవిధంగా ఇది ఇప్పటికీ స్పష్టమైనది కాదు ...
కుమారి: - లేదు, లేదు, ఇది నిజమైన కోడ్! ఇది శైలి గురించి కాదు. ఇది చాలా ప్రయోజనకరమైన, చాలా చిన్న తరగతి - తరగతి లోపల కేవలం 3 ఫీల్డ్‌లు మాత్రమే...
కుమారి: – పెద్దగా, క్లయింట్‌లతో (సీజన్ మ్యాచ్‌లు, ప్లేయర్‌లు) సమకాలీకరించబడిన మొత్తం డేటా మారదు. స్థూలంగా చెప్పాలంటే, మనం మ్యాచ్‌ని మార్చాల్సిన అవసరం ఉన్న మరొక క్రీడను చేస్తే, క్లయింట్ యొక్క కొత్త వెర్షన్‌లో మేము ప్రతిదీ పరిగణనలోకి తీసుకుంటాము మరియు క్లయింట్ యొక్క పాత సంస్కరణలు నిషేధించబడతాయి.
AT: – ఏవైనా థర్డ్-పార్టీ డిపెండెన్సీ మేనేజ్‌మెంట్ ప్యాకేజీలు ఉన్నాయా?
కుమారి: – మేము go dep ఉపయోగించాము.
AT: – నివేదిక అంశంలో వీడియో గురించి ఏదో ఉంది, కానీ వీడియో గురించి నివేదికలో ఏమీ లేదు.
కుమారి: – లేదు, వీడియో గురించిన అంశంలో నా దగ్గర ఏమీ లేదు. దీని పేరు “లుక్+” - ఇది అప్లికేషన్ పేరు.
AT: - ఇది క్లయింట్‌లకు ప్రసారం చేయబడిందని మీరు చెప్పారా?..
కుమారి: – మేము స్ట్రీమింగ్ వీడియోలో పాల్గొనలేదు. దీన్ని పూర్తిగా మెగాఫోన్ చేసింది. అవును, అప్లికేషన్ MegaFon అని నేను చెప్పలేదు.
కుమారి: – గో – మొత్తం డేటాను పంపడం కోసం – స్కోర్‌పై, మ్యాచ్ ఈవెంట్‌లు, గణాంకాలపై... గో అనేది అప్లికేషన్‌కు మొత్తం బ్యాకెండ్. వినియోగదారు మ్యాచ్‌ని చూడగలిగేలా ప్లేయర్ కోసం ఏ లింక్ ఉపయోగించాలో క్లయింట్ తప్పనిసరిగా ఎక్కడి నుండైనా తెలుసుకోవాలి. మేము సిద్ధం చేసిన వీడియోలు మరియు స్ట్రీమ్‌లకు లింక్‌లను కలిగి ఉన్నాము.
కొన్ని ప్రకటనలు 🙂
మాతో ఉన్నందుకు ధన్యవాదాలు. మీరు మా కథనాలను ఇష్టపడుతున్నారా? మరింత ఆసక్తికరమైన కంటెంట్‌ని చూడాలనుకుంటున్నారా? ఆర్డర్ చేయడం ద్వారా లేదా స్నేహితులకు సిఫార్సు చేయడం ద్వారా మాకు మద్దతు ఇవ్వండి, , ఎంట్రీ-లెవల్ సర్వర్‌ల యొక్క ప్రత్యేకమైన అనలాగ్, ఇది మీ కోసం మా ద్వారా కనుగొనబడింది: (RAID1 మరియు RAID10తో అందుబాటులో ఉంది, గరిష్టంగా 24 కోర్లు మరియు 40GB DDR4 వరకు).
ఆమ్‌స్టర్‌డామ్‌లోని ఈక్వినిక్స్ టైర్ IV డేటా సెంటర్‌లో Dell R730xd 2x చౌకగా ఉందా? ఇక్కడ మాత్రమే నెదర్లాండ్స్‌లో! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 నుండి! గురించి చదవండి
మూలం: www.habr.com