VKontakte యొక్క నిర్మాణం మరియు పనిపై తరచుగా అడిగే ప్రశ్నలు

VKontakte యొక్క సృష్టి చరిత్ర వికీపీడియాలో ఉంది; దీనిని పావెల్ స్వయంగా చెప్పారు. ఈమె అందరికి ముందే తెలుసని తెలుస్తోంది. హైలోడ్++ పావెల్‌లో సైట్ యొక్క అంతర్గత, నిర్మాణం మరియు నిర్మాణం గురించి 2010లో నాకు తిరిగి చెప్పారు. అప్పటి నుండి చాలా సర్వర్లు లీక్ అయ్యాయి, కాబట్టి మేము సమాచారాన్ని నవీకరిస్తాము: మేము దానిని విడదీస్తాము, లోపలి భాగాలను తీసివేస్తాము, దానిని తూకం చేస్తాము మరియు సాంకేతిక కోణం నుండి VK పరికరాన్ని చూస్తాము.

అలెక్సీ అకులోవిచ్ (AterCattus) VKontakte బృందంలో బ్యాకెండ్ డెవలపర్. ప్లాట్‌ఫారమ్, ఇన్‌ఫ్రాస్ట్రక్చర్, సర్వర్లు మరియు వాటి మధ్య పరస్పర చర్య గురించి తరచుగా అడిగే ప్రశ్నలకు ఈ నివేదిక యొక్క ట్రాన్స్క్రిప్ట్ సమిష్టి సమాధానం, కానీ అభివృద్ధి గురించి కాదు, అవి ఇనుము గురించి. విడిగా, డేటాబేస్‌ల గురించి మరియు బదులుగా VK ఏమి కలిగి ఉంది, లాగ్‌లను సేకరించడం మరియు మొత్తం ప్రాజెక్ట్‌ను పర్యవేక్షించడం గురించి. కట్ కింద వివరాలు.

నాలుగు సంవత్సరాలకు పైగా నేను బ్యాకెండ్‌కు సంబంధించిన అన్ని రకాల పనులను డీల్ చేస్తున్నాను.

• మీడియాను అప్‌లోడ్ చేయడం, నిల్వ చేయడం, ప్రాసెస్ చేయడం, పంపిణీ చేయడం: వీడియో, లైవ్ స్ట్రీమింగ్, ఆడియో, ఫోటోలు, పత్రాలు.
• మౌలిక సదుపాయాలు, ప్లాట్‌ఫారమ్, డెవలపర్ పర్యవేక్షణ, లాగ్‌లు, ప్రాంతీయ కాష్‌లు, CDN, యాజమాన్య RPC ప్రోటోకాల్.
• బాహ్య సేవలతో ఏకీకరణ: పుష్ నోటిఫికేషన్‌లు, బాహ్య లింక్ పార్సింగ్, RSS ఫీడ్.
• వివిధ ప్రశ్నలతో సహచరులకు సహాయం చేయడం, వాటికి సమాధానాలు తెలియని కోడ్‌లోకి ప్రవేశించడం అవసరం.

ఈ సమయంలో, నేను సైట్ యొక్క అనేక భాగాలలో చేయి కలిగి ఉన్నాను. నేను ఈ అనుభవాన్ని పంచుకోవాలనుకుంటున్నాను.

సాధారణ నిర్మాణం

ప్రతిదీ, ఎప్పటిలాగే, అభ్యర్థనలను ఆమోదించే సర్వర్ లేదా సర్వర్‌ల సమూహంతో ప్రారంభమవుతుంది.

ముందు సర్వర్

ముందు సర్వర్ HTTPS, RTMP మరియు WSS ద్వారా అభ్యర్థనలను అంగీకరిస్తుంది.

HTTPS - ఇవి సైట్ యొక్క ప్రధాన మరియు మొబైల్ వెబ్ వెర్షన్‌ల కోసం అభ్యర్థనలు: vk.com మరియు m.vk.com మరియు మా API యొక్క ఇతర అధికారిక మరియు అనధికారిక క్లయింట్లు: మొబైల్ క్లయింట్లు, మెసెంజర్‌లు. మాకు రిసెప్షన్ ఉంది RTMP-ప్రత్యేక ముందు సర్వర్‌లతో ప్రత్యక్ష ప్రసారాల కోసం ట్రాఫిక్ మరియు WSS- స్ట్రీమింగ్ API కోసం కనెక్షన్లు.

సర్వర్‌లలోని HTTPS మరియు WSS కోసం ఇది విలువైనది వికీపీడియా. RTMP ప్రసారాల కోసం, మేము ఇటీవల మా స్వంత పరిష్కారానికి మారాము కీవ్, కానీ అది నివేదిక పరిధికి మించినది. తప్పు సహనం కోసం, ఈ సర్వర్‌లు సాధారణ IP చిరునామాలను ప్రచారం చేస్తాయి మరియు సమూహాలలో పనిచేస్తాయి, తద్వారా సర్వర్‌లలో ఒకదానిలో సమస్య ఉంటే, వినియోగదారు అభ్యర్థనలు కోల్పోవు. HTTPS మరియు WSS కోసం, ఇదే సర్వర్‌లు తమపై తాము CPU లోడ్‌లో భాగం కావడానికి ట్రాఫిక్‌ను ఎన్‌క్రిప్ట్ చేస్తాయి.

మేము WSS మరియు RTMP గురించి మరింత మాట్లాడము, కానీ సాధారణంగా వెబ్ ప్రాజెక్ట్‌తో అనుబంధించబడిన ప్రామాణిక HTTPS అభ్యర్థనల గురించి మాత్రమే.

బ్యాకెండ్

ముందు వెనుక సాధారణంగా బ్యాకెండ్ సర్వర్లు ఉంటాయి. క్లయింట్ల నుండి ఫ్రంట్ సర్వర్ స్వీకరించే అభ్యర్థనలను వారు ప్రాసెస్ చేస్తారు.

ఈ kPHP సర్వర్లు, HTTP డెమోన్ రన్ అవుతోంది, ఎందుకంటే HTTPS ఇప్పటికే డీక్రిప్ట్ చేయబడింది. kPHP అనేది ఆన్‌లో పనిచేసే సర్వర్ ప్రీఫోర్క్ నమూనాలు: మాస్టర్ ప్రాసెస్‌ను ప్రారంభిస్తుంది, పిల్లల ప్రక్రియల సమూహం, వారికి వినడం సాకెట్‌లను పంపుతుంది మరియు వారు వారి అభ్యర్థనలను ప్రాసెస్ చేస్తారు. ఈ సందర్భంలో, వినియోగదారు నుండి ప్రతి అభ్యర్థనకు మధ్య ప్రక్రియలు పునఃప్రారంభించబడవు, కానీ వాటి స్థితిని అసలు సున్నా-విలువ స్థితికి రీసెట్ చేయండి - అభ్యర్థన తర్వాత అభ్యర్థన, పునఃప్రారంభించటానికి బదులుగా.

పంపిణీని లోడ్ చేయండి

మా బ్యాకెండ్‌లన్నీ ఏదైనా అభ్యర్థనను ప్రాసెస్ చేయగల యంత్రాల భారీ పూల్ కాదు. మేము వాటిని ప్రత్యేక సమూహాలుగా విభజించబడింది: సాధారణ, మొబైల్, api, వీడియో, స్టేజింగ్... యంత్రాల యొక్క ప్రత్యేక సమూహంలోని సమస్య మిగతావాటిని ప్రభావితం చేయదు. వీడియోతో సమస్యల విషయంలో, సంగీతం వినే వినియోగదారుకు సమస్యల గురించి కూడా తెలియదు. అభ్యర్థనను ఏ బ్యాకెండ్‌కు పంపాలనేది కాన్ఫిగరేషన్ ప్రకారం ముందువైపు nginx ద్వారా నిర్ణయించబడుతుంది.

మెట్రిక్ సేకరణ మరియు రీబ్యాలెన్సింగ్

ప్రతి సమూహంలో మనకు ఎన్ని కార్లు అవసరమో అర్థం చేసుకోవడానికి, మేము QPSపై ఆధారపడవద్దు. బ్యాకెండ్‌లు విభిన్నంగా ఉంటాయి, వాటికి వేర్వేరు అభ్యర్థనలు ఉన్నాయి, ప్రతి అభ్యర్థన QPSని లెక్కించడంలో విభిన్న సంక్లిష్టతను కలిగి ఉంటుంది. అందుకే మనం మేము మొత్తం సర్వర్‌పై లోడ్ భావనతో పని చేస్తాము - CPU మరియు perfలో.

మన దగ్గర ఇలాంటి సర్వర్‌లు వేల సంఖ్యలో ఉన్నాయి. ప్రతి భౌతిక సర్వర్ అన్ని కోర్లను రీసైకిల్ చేయడానికి kPHP సమూహాన్ని నడుపుతుంది (ఎందుకంటే kPHP సింగిల్ థ్రెడ్).

కంటెంట్ సర్వర్

CS లేదా కంటెంట్ సర్వర్ ఒక నిల్వ. CS అనేది ఫైల్‌లను నిల్వ చేసే సర్వర్ మరియు అప్‌లోడ్ చేసిన ఫైల్‌లను మరియు ప్రధాన వెబ్ ఫ్రంటెండ్ దానికి కేటాయించే అన్ని రకాల బ్యాక్‌గ్రౌండ్ సింక్రోనస్ టాస్క్‌లను కూడా ప్రాసెస్ చేస్తుంది.

ఫైల్‌లను నిల్వ చేసే పదివేల భౌతిక సర్వర్‌లు మా వద్ద ఉన్నాయి. వినియోగదారులు ఫైల్‌లను అప్‌లోడ్ చేయడానికి ఇష్టపడతారు మరియు మేము వాటిని నిల్వ చేయడానికి మరియు భాగస్వామ్యం చేయడానికి ఇష్టపడతాము. ఈ సర్వర్‌లలో కొన్ని ప్రత్యేక pu/pp సర్వర్‌ల ద్వారా మూసివేయబడ్డాయి.

pu/pp

మీరు VKలో నెట్‌వర్క్ ట్యాబ్‌ను తెరిస్తే, మీరు pu/ppని చూసారు.

pu/pp అంటే ఏమిటి? మేము ఒక సర్వర్ తర్వాత మరొక సర్వర్‌ని మూసివేస్తే, మూసివేసిన సర్వర్‌కు ఫైల్‌ను అప్‌లోడ్ చేయడానికి మరియు డౌన్‌లోడ్ చేయడానికి రెండు ఎంపికలు ఉన్నాయి: నేరుగా ద్వారా http://cs100500.userapi.com/path లేదా ఇంటర్మీడియట్ సర్వర్ ద్వారా - http://pu.vk.com/c100500/path.

Pu అనేది ఫోటో అప్‌లోడ్‌కు చారిత్రక పేరు మరియు pp అనేది ఫోటో ప్రాక్సీ. అంటే, ఒక సర్వర్ ఫోటోలను అప్‌లోడ్ చేయడానికి, మరొకటి అప్‌లోడ్ చేయడానికి. ఇప్పుడు ఫోటోలు మాత్రమే లోడ్ చేయబడవు, కానీ పేరు భద్రపరచబడింది.

ఈ సర్వర్లు HTTPS సెషన్‌లను ముగించండినిల్వ నుండి ప్రాసెసర్ లోడ్‌ను తీసివేయడానికి. అలాగే, ఈ సర్వర్‌లలో వినియోగదారు ఫైల్‌లు ప్రాసెస్ చేయబడినందున, ఈ మెషీన్‌లలో తక్కువ సున్నితమైన సమాచారం నిల్వ చేయబడితే అంత మంచిది. ఉదాహరణకు, HTTPS ఎన్‌క్రిప్షన్ కీలు.

మెషీన్లు మా ఇతర యంత్రాల ద్వారా మూసివేయబడినందున, మేము వాటికి "తెలుపు" బాహ్య IPలను ఇవ్వకుండా ఉండగలము మరియు "బూడిద" ఇవ్వండి. ఈ విధంగా మేము IP పూల్‌లో సేవ్ చేసాము మరియు బయటి యాక్సెస్ నుండి మెషీన్‌లను రక్షించడానికి హామీ ఇచ్చాము - దానిలోకి ప్రవేశించడానికి IP లేదు.

భాగస్వామ్య IPలపై స్థితిస్థాపకత. తప్పు సహనం పరంగా, పథకం అదే పని చేస్తుంది - అనేక భౌతిక సర్వర్‌లు సాధారణ భౌతిక IPని కలిగి ఉంటాయి మరియు వాటి ముందు ఉన్న హార్డ్‌వేర్ అభ్యర్థనను ఎక్కడ పంపాలో ఎంచుకుంటుంది. నేను ఇతర ఎంపికల గురించి తరువాత మాట్లాడుతాను.

ఈ విషయంలో వివాదాస్పద అంశం క్లయింట్ తక్కువ కనెక్షన్‌లను ఉంచుతుంది. అనేక మెషీన్‌లకు ఒకే IP ఉంటే - అదే హోస్ట్‌తో: pu.vk.com లేదా pp.vk.com, క్లయింట్ బ్రౌజర్‌లో ఒక హోస్ట్‌కి ఏకకాల అభ్యర్థనల సంఖ్యపై పరిమితి ఉంటుంది. కానీ సర్వత్రా ఉన్న HTTP/2 సమయంలో, ఇది ఇకపై అంత సందర్భోచితంగా లేదని నేను నమ్ముతున్నాను.

పథకం యొక్క స్పష్టమైన ప్రతికూలత ఏమిటంటే అది చేయాలి అన్ని ట్రాఫిక్‌ను పంప్ చేయండి, ఇది మరొక సర్వర్ ద్వారా నిల్వకు వెళుతుంది. మేము యంత్రాల ద్వారా ట్రాఫిక్‌ను పంప్ చేస్తున్నందున, మేము ఇంకా భారీ ట్రాఫిక్‌ను పంప్ చేయలేము, ఉదాహరణకు, వీడియో, అదే పథకాన్ని ఉపయోగిస్తాము. మేము దీన్ని నేరుగా ప్రసారం చేస్తాము - ప్రత్యేకంగా వీడియో కోసం ప్రత్యేక నిల్వల కోసం ప్రత్యేక ప్రత్యక్ష కనెక్షన్. మేము ప్రాక్సీ ద్వారా తేలికైన కంటెంట్‌ని ప్రసారం చేస్తాము.

కొంతకాలం క్రితం మేము ప్రాక్సీ యొక్క మెరుగైన సంస్కరణను పొందాము. అవి సాధారణ వాటి నుండి ఎలా భిన్నంగా ఉన్నాయో మరియు ఇది ఎందుకు అవసరమో ఇప్పుడు నేను మీకు చెప్తాను.

సన్

సెప్టెంబర్ 2017లో, గతంలో సన్‌ని కొనుగోలు చేసిన ఒరాకిల్, భారీ సంఖ్యలో సన్ ఉద్యోగులను తొలగించింది. ఈ సమయంలో కంపెనీ ఉనికిలో లేదని మేము చెప్పగలం. కొత్త సిస్టమ్ కోసం పేరును ఎంచుకున్నప్పుడు, మా నిర్వాహకులు ఈ సంస్థ యొక్క జ్ఞాపకార్థం నివాళులు అర్పించాలని నిర్ణయించుకున్నారు మరియు కొత్త సిస్టమ్‌కు సన్ అని పేరు పెట్టారు. మనలో మనం ఆమెను "సూర్యులు" అని పిలుస్తాము.

ppకి కొన్ని సమస్యలు ఉన్నాయి. సమూహానికి ఒక IP - పనికిరాని కాష్. అనేక భౌతిక సర్వర్‌లు సాధారణ IP చిరునామాను పంచుకుంటాయి మరియు అభ్యర్థన ఏ సర్వర్‌కు వెళ్లాలో నియంత్రించడానికి మార్గం లేదు. అందువల్ల, ఒకే ఫైల్ కోసం వేర్వేరు వినియోగదారులు వస్తే, ఈ సర్వర్‌లలో కాష్ ఉంటే, ఫైల్ ప్రతి సర్వర్ యొక్క కాష్‌లో ముగుస్తుంది. ఇది చాలా అసమర్థ పథకం, కానీ ఏమీ చేయలేము.

తత్ఫలితంగా - మేము కంటెంట్‌ను విభజించలేము, ఎందుకంటే మేము ఈ గుంపు కోసం నిర్దిష్ట సర్వర్‌ని ఎంచుకోలేము - వారికి సాధారణ IP ఉంది. అలాగే మనకు కొన్ని అంతర్గత కారణాల వల్ల కూడా ప్రాంతాలలో అటువంటి సర్వర్‌లను ఇన్‌స్టాల్ చేయడం సాధ్యం కాదు. వారు సెయింట్ పీటర్స్బర్గ్లో మాత్రమే నిలబడ్డారు.

ఎండలతో ఎంపిక విధానాన్ని మార్చాం. ఇప్పుడు మన దగ్గర ఉంది ఏదైనా రూటింగ్: డైనమిక్ రూటింగ్, ఏదైనా కాస్ట్, సెల్ఫ్ చెక్ డెమోన్. ప్రతి సర్వర్‌కు దాని స్వంత వ్యక్తిగత IP ఉంటుంది, కానీ ఒక సాధారణ సబ్‌నెట్. ఒక సర్వర్ విఫలమైతే, ట్రాఫిక్ స్వయంచాలకంగా అదే సమూహంలోని ఇతర సర్వర్‌లలో వ్యాపించే విధంగా ప్రతిదీ కాన్ఫిగర్ చేయబడింది. ఇప్పుడు నిర్దిష్ట సర్వర్‌ను ఎంచుకోవడం సాధ్యమవుతుంది, అనవసరమైన కాషింగ్ లేదు, మరియు విశ్వసనీయత ప్రభావితం కాలేదు.

బరువు మద్దతు. ఇప్పుడు మేము అవసరమైన విధంగా వేర్వేరు శక్తితో కూడిన యంత్రాలను వ్యవస్థాపించగలము మరియు తాత్కాలిక సమస్యల విషయంలో, పని చేసే "సూర్యుల" బరువులను మార్చడం ద్వారా వాటిపై భారాన్ని తగ్గించవచ్చు, తద్వారా అవి "విశ్రాంతి" మరియు మళ్లీ పని చేయడం ప్రారంభిస్తాయి.

కంటెంట్ ఐడి ద్వారా భాగస్వామ్యం చేయడం. షార్డింగ్ గురించిన ఒక తమాషా విషయం: మేము సాధారణంగా కంటెంట్‌ను షార్డ్ చేస్తాము, తద్వారా వేర్వేరు వినియోగదారులు ఒకే ఫైల్‌కి ఒకే “సూర్యుడు” ద్వారా వెళతారు, తద్వారా వారికి సాధారణ కాష్ ఉంటుంది.

మేము ఇటీవల "క్లోవర్" అప్లికేషన్‌ను ప్రారంభించాము. ఇది ప్రత్యక్ష ప్రసారంలో ఆన్‌లైన్ క్విజ్, ఇక్కడ హోస్ట్ ప్రశ్నలు అడుగుతారు మరియు వినియోగదారులు నిజ సమయంలో సమాధానాలు ఇస్తారు, ఎంపికలను ఎంచుకుంటారు. యాప్‌లో వినియోగదారులు చాట్ చేయగల చాట్ ఉంది. ప్రసారానికి ఏకకాలంలో కనెక్ట్ చేయవచ్చు 100 వేల కంటే ఎక్కువ మంది. వారు అందరూ పాల్గొనే వారందరికీ పంపబడే సందేశాలను వ్రాస్తారు మరియు సందేశంతో పాటు అవతార్ కూడా వస్తుంది. ఒక “సూర్యుడు”లో ఒక అవతార్ కోసం 100 వేల మంది వ్యక్తులు వస్తే, అది కొన్నిసార్లు మేఘం వెనుక తిరుగుతుంది.

ఒకే ఫైల్ కోసం అభ్యర్థనల పేలుళ్లను తట్టుకోవడానికి, మేము నిర్దిష్ట రకం కంటెంట్ కోసం, ఈ ప్రాంతంలో అందుబాటులో ఉన్న అన్ని “సన్‌లు” అంతటా ఫైల్‌లను విస్తరించే స్టుపిడ్ స్కీమ్‌ను ఆన్ చేస్తాము.

లోపలి నుండి సూర్యుడు

nginxలో రివర్స్ ప్రాక్సీ, RAMలో లేదా వేగవంతమైన Optane/NVMe డిస్క్‌లలో కాష్. ఉదాహరణ: http://sun4-2.userapi.com/c100500/path — నాల్గవ ప్రాంతం, రెండవ సర్వర్ సమూహంలో ఉన్న “సూర్యుడు”కి లింక్. ఇది భౌతికంగా సర్వర్ 100500లో ఉన్న పాత్ ఫైల్‌ను మూసివేస్తుంది.

కవర్

మేము మా ఆర్కిటెక్చరల్ స్కీమ్‌కి మరో నోడ్‌ని జోడిస్తాము - కాషింగ్ ఎన్విరాన్మెంట్.

క్రింద లేఅవుట్ రేఖాచిత్రం ఉంది ప్రాంతీయ కాష్‌లు, వాటిలో దాదాపు 20 ఉన్నాయి. ఇవి కాష్‌లు మరియు "సన్‌లు" ఉన్న ప్రదేశాలు, ఇవి తమ ద్వారానే ట్రాఫిక్‌ను కాష్ చేయగలవు.

ఇది మల్టీమీడియా కంటెంట్‌ను కాషింగ్ చేయడం; ఇక్కడ వినియోగదారు డేటా ఏదీ నిల్వ చేయబడదు - కేవలం సంగీతం, వీడియో, ఫోటోలు.

వినియోగదారు ప్రాంతాన్ని గుర్తించడానికి, మేము మేము ప్రాంతాలలో ప్రకటించిన BGP నెట్‌వర్క్ ప్రిఫిక్స్‌లను సేకరిస్తాము. ఫాల్‌బ్యాక్ విషయంలో, మేము ప్రిఫిక్స్‌ల ద్వారా IPని కనుగొనలేకపోతే మేము జియోప్ డేటాబేస్‌ను కూడా అన్వయించవలసి ఉంటుంది. మేము వినియోగదారు యొక్క IP ద్వారా ప్రాంతాన్ని నిర్ణయిస్తాము. కోడ్‌లో, వినియోగదారు యొక్క ఒకటి లేదా అంతకంటే ఎక్కువ ప్రాంతాలను మనం చూడవచ్చు - అతను భౌగోళికంగా దగ్గరగా ఉన్న పాయింట్లు.

అది ఎలా పనిచేస్తుంది?

మేము ప్రాంతాల వారీగా ఫైల్‌ల ప్రజాదరణను లెక్కిస్తాము. వినియోగదారు ఉన్న అనేక ప్రాంతీయ కాష్ మరియు ఫైల్ ఐడెంటిఫైయర్ ఉన్నాయి - మేము ఈ జతని తీసుకొని ప్రతి డౌన్‌లోడ్‌తో రేటింగ్‌ను పెంచుతాము.

అదే సమయంలో, దెయ్యాలు - ప్రాంతాలలో సేవలు - ఎప్పటికప్పుడు APIకి వచ్చి ఇలా అంటాయి: “నేను అలాంటి కాష్‌ని, నా ప్రాంతంలో ఇంకా నా వద్ద లేని అత్యంత ప్రజాదరణ పొందిన ఫైల్‌ల జాబితాను నాకు ఇవ్వండి. ” API రేటింగ్ ద్వారా క్రమబద్ధీకరించబడిన ఫైల్‌ల సమూహాన్ని అందిస్తుంది, డెమోన్ వాటిని డౌన్‌లోడ్ చేస్తుంది, వాటిని ప్రాంతాలకు తీసుకువెళుతుంది మరియు అక్కడ నుండి ఫైల్‌లను బట్వాడా చేస్తుంది. ఇది కాష్‌ల నుండి pu/pp మరియు Sun మధ్య ఉన్న ప్రాథమిక వ్యత్యాసం: ఈ ఫైల్ కాష్‌లో లేనప్పటికీ, వారు ఫైల్‌ను వెంటనే తమ ద్వారా అందజేస్తారు మరియు కాష్ మొదట ఫైల్‌ను డౌన్‌లోడ్ చేసి, ఆపై దాన్ని తిరిగి ఇవ్వడం ప్రారంభిస్తుంది.

ఈ సందర్భంలో మనకు లభిస్తుంది కంటెంట్ వినియోగదారులకు దగ్గరగా ఉంటుంది మరియు నెట్‌వర్క్ లోడ్‌ను విస్తరించడం. ఉదాహరణకు, మాస్కో కాష్ నుండి మాత్రమే మేము పీక్ అవర్స్‌లో 1 Tbit/s కంటే ఎక్కువ పంపిణీ చేస్తాము.

కానీ సమస్యలు ఉన్నాయి - కాష్ సర్వర్లు రబ్బరు కాదు. సూపర్ పాపులర్ కంటెంట్ కోసం, కొన్నిసార్లు ప్రత్యేక సర్వర్ కోసం తగినంత నెట్‌వర్క్ ఉండదు. మా కాష్ సర్వర్లు 40-50 Gbit/s, కానీ అలాంటి ఛానెల్‌ని పూర్తిగా అడ్డుకునే కంటెంట్ ఉంది. మేము ఈ ప్రాంతంలో జనాదరణ పొందిన ఫైల్‌ల యొక్క ఒకటి కంటే ఎక్కువ కాపీల నిల్వను అమలు చేసే దిశగా కదులుతున్నాము. ఈ ఏడాది చివరికల్లా అమలు చేస్తామని ఆశిస్తున్నాను.

మేము సాధారణ నిర్మాణాన్ని చూశాము.

• అభ్యర్థనలను అంగీకరించే ముందు సర్వర్లు.
• అభ్యర్థనలను ప్రాసెస్ చేసే బ్యాకెండ్.
• రెండు రకాల ప్రాక్సీల ద్వారా మూసివేయబడిన నిల్వలు.
• ప్రాంతీయ కాష్‌లు.

ఈ రేఖాచిత్రంలో ఏమి లేదు? వాస్తవానికి, మేము డేటాను నిల్వ చేసే డేటాబేస్‌లు.

డేటాబేస్లు లేదా ఇంజిన్లు

మేము వాటిని డేటాబేస్‌లు కాదు, ఇంజిన్‌లు అని పిలుస్తాము - ఇంజిన్‌లు, ఎందుకంటే మాకు ఆచరణాత్మకంగా సాధారణంగా ఆమోదించబడిన అర్థంలో డేటాబేస్‌లు లేవు.

ఇది అవసరమైన కొలత. ఇది జరిగింది ఎందుకంటే 2008-2009లో, VK జనాదరణలో పేలుడు వృద్ధిని కలిగి ఉన్నప్పుడు, ప్రాజెక్ట్ పూర్తిగా MySQL మరియు Memcacheలో పని చేసింది మరియు సమస్యలు ఉన్నాయి. MySQL క్రాష్ మరియు పాడైన ఫైల్‌లను ఇష్టపడింది, దాని తర్వాత అది పునరుద్ధరించబడదు మరియు మెమ్‌కాష్ పనితీరులో క్రమంగా క్షీణించింది మరియు పునఃప్రారంభించవలసి వచ్చింది.

పెరుగుతున్న జనాదరణ పొందిన ప్రాజెక్ట్‌లో నిరంతర నిల్వ ఉందని, ఇది డేటాను పాడు చేస్తుంది మరియు కాష్ నెమ్మదిస్తుంది. అటువంటి పరిస్థితులలో, పెరుగుతున్న ప్రాజెక్ట్ను అభివృద్ధి చేయడం కష్టం. ప్రాజెక్ట్‌పై దృష్టి సారించిన క్లిష్టమైన విషయాలను మన స్వంత సైకిళ్లపై తిరిగి వ్రాయడానికి ప్రయత్నించాలని నిర్ణయించబడింది.

పరిష్కారం విజయవంతమైంది. ఆ సమయంలో స్కేలింగ్ యొక్క ఇతర మార్గాలు లేనందున దీన్ని చేయడానికి అవకాశం ఉంది, అలాగే తీవ్ర అవసరం. డేటాబేస్‌ల సమూహం లేదు, NoSQL ఇంకా ఉనికిలో లేదు, MySQL, Memcache, PostrgreSQL మాత్రమే ఉన్నాయి - మరియు అంతే.

యూనివర్సల్ ఆపరేషన్. అభివృద్ధిని మా సి డెవలపర్‌ల బృందం నడిపించింది మరియు ప్రతిదీ స్థిరమైన పద్ధతిలో జరిగింది. ఇంజిన్‌తో సంబంధం లేకుండా, అవన్నీ డిస్క్‌కు వ్రాసిన ఒకే ఫైల్ ఫార్మాట్, అదే లాంచ్ పారామితులు, అదే విధంగా ప్రాసెస్ చేయబడిన సిగ్నల్‌లను కలిగి ఉంటాయి మరియు అంచు పరిస్థితులు మరియు సమస్యల విషయంలో దాదాపు ఒకే విధంగా ప్రవర్తించాయి. ఇంజిన్ల పెరుగుదలతో, నిర్వాహకులు సిస్టమ్‌ను ఆపరేట్ చేయడం సౌకర్యంగా ఉంటుంది - నిర్వహించాల్సిన అవసరం ఉన్న జంతుప్రదర్శనశాల లేదు, మరియు వారు ప్రతి కొత్త మూడవ పక్ష డేటాబేస్‌ను ఎలా ఆపరేట్ చేయాలో మళ్లీ నేర్చుకోవాలి, ఇది త్వరగా మరియు సౌకర్యవంతంగా పెంచడం సాధ్యం చేసింది. వారి సంఖ్య.

ఇంజిన్ల రకాలు

బృందం చాలా కొన్ని ఇంజిన్లను వ్రాసింది. వాటిలో కొన్ని ఇక్కడ ఉన్నాయి: స్నేహితుడు, సూచనలు, చిత్రం, ipdb, అక్షరాలు, జాబితాలు, లాగ్‌లు, memcached, meowdb, వార్తలు, నోస్ట్రాడమస్, ఫోటో, ప్లేజాబితాలు, pmemcached, శాండ్‌బాక్స్, శోధన, నిల్వ, ఇష్టాలు, పనులు, …

నిర్దిష్ట డేటా నిర్మాణం లేదా వైవిధ్య అభ్యర్థనలను ప్రాసెస్ చేసే ప్రతి పని కోసం, C బృందం కొత్త ఇంజిన్‌ను వ్రాస్తుంది. ఎందుకు కాదు.

మాకు ప్రత్యేక ఇంజిన్ ఉంది memcached, ఇది సాధారణ మాదిరిగానే ఉంటుంది, కానీ చాలా గూడీస్‌తో ఉంటుంది మరియు వేగాన్ని తగ్గించదు. క్లిక్‌హౌస్ కాదు, ఇది కూడా పనిచేస్తుంది. విడిగా అందుబాటులో ఉన్నాయి pmmcached అది - నిరంతర memcached, ఇది డిస్క్‌లో డేటాను నిల్వ చేయగలదు, అంతేకాకుండా, RAMకి సరిపోయే దానికంటే, పునఃప్రారంభించేటప్పుడు డేటాను కోల్పోకుండా ఉంటుంది. వ్యక్తిగత పనుల కోసం వివిధ ఇంజిన్‌లు ఉన్నాయి: క్యూలు, జాబితాలు, సెట్‌లు - మా ప్రాజెక్ట్‌కు అవసరమైన ప్రతిదీ.

క్లస్టర్లు

కోడ్ కోణం నుండి, ఇంజిన్‌లు లేదా డేటాబేస్‌లను ప్రక్రియలు, ఎంటిటీలు లేదా సందర్భాలుగా భావించాల్సిన అవసరం లేదు. కోడ్ ప్రత్యేకంగా క్లస్టర్‌లతో, ఇంజిన్‌ల సమూహాలతో పనిచేస్తుంది - ఒక క్లస్టర్‌కి ఒక రకం. మెమ్‌క్యాచ్డ్ క్లస్టర్ ఉందనుకుందాం - ఇది కేవలం యంత్రాల సమూహం.

కోడ్ భౌతిక స్థానం, పరిమాణం లేదా సర్వర్‌ల సంఖ్యను తెలుసుకోవాల్సిన అవసరం లేదు. అతను ఒక నిర్దిష్ట ఐడెంటిఫైయర్‌ని ఉపయోగించి క్లస్టర్‌కి వెళ్తాడు.

ఇది పని చేయడానికి, మీరు కోడ్ మరియు ఇంజిన్‌ల మధ్య ఉన్న మరో ఎంటిటీని జోడించాలి - ప్రాక్సీ.

RPC ప్రాక్సీ

ప్రాక్సీ కనెక్ట్ బస్సు, దాదాపు మొత్తం సైట్ నడుస్తుంది. అదే సమయంలో మనకు ఉంది సేవ ఆవిష్కరణ లేదు — బదులుగా, ఈ ప్రాక్సీ కోసం ఒక కాన్ఫిగర్ ఉంది, ఇది ఈ క్లస్టర్‌లోని అన్ని క్లస్టర్‌లు మరియు అన్ని షార్డ్‌ల స్థానాన్ని తెలుసుకుంటుంది. నిర్వాహకులు చేసేది ఇదే.

ప్రోగ్రామర్లు ఎంత, ఎక్కడ మరియు ఏమి ఖర్చవుతుందని అస్సలు పట్టించుకోరు - వారు కేవలం క్లస్టర్‌కి వెళతారు. ఇది మాకు చాలా అనుమతిస్తుంది. అభ్యర్థనను స్వీకరించినప్పుడు, ప్రాక్సీ అభ్యర్థనను దారి మళ్లిస్తుంది, ఎక్కడ తెలుసుకోవడం - ఇది స్వయంగా నిర్ణయిస్తుంది.

ఈ సందర్భంలో, ప్రాక్సీ అనేది సేవ వైఫల్యానికి వ్యతిరేకంగా రక్షణ యొక్క పాయింట్. కొన్ని ఇంజన్ స్లో అయితే లేదా క్రాష్ అయినట్లయితే, ప్రాక్సీ దీన్ని అర్థం చేసుకుంటుంది మరియు క్లయింట్ వైపు తదనుగుణంగా ప్రతిస్పందిస్తుంది. ఇది గడువును తీసివేయడానికి మిమ్మల్ని అనుమతిస్తుంది - ఇంజిన్ ప్రతిస్పందించడానికి కోడ్ వేచి ఉండదు, కానీ అది పనిచేయడం లేదని అర్థం చేసుకుంటుంది మరియు ఏదో ఒకవిధంగా భిన్నంగా ప్రవర్తించాల్సిన అవసరం ఉంది. డేటాబేస్‌లు ఎల్లప్పుడూ పని చేయవు అనే వాస్తవం కోసం కోడ్ సిద్ధం చేయాలి.

నిర్దిష్ట అమలులు

కొన్నిసార్లు మేము ఇప్పటికీ ఇంజిన్‌గా ప్రామాణికం కాని పరిష్కారాన్ని కలిగి ఉండాలని కోరుకుంటున్నాము. అదే సమయంలో, మా ఇంజిన్ల కోసం ప్రత్యేకంగా సృష్టించబడిన మా రెడీమేడ్ rpc-ప్రాక్సీని ఉపయోగించకూడదని నిర్ణయించబడింది, కానీ పని కోసం ప్రత్యేక ప్రాక్సీని తయారు చేయడానికి.

MySQL కోసం, మేము ఇప్పటికీ ఇక్కడ మరియు అక్కడ కలిగి ఉన్నాము, మేము db-proxyని ఉపయోగిస్తాము మరియు ClickHouse కోసం - కిట్టెన్‌హౌస్.

ఇది సాధారణంగా ఇలా పనిచేస్తుంది. ఒక నిర్దిష్ట సర్వర్ ఉంది, ఇది kPHP, Go, Python - సాధారణంగా, మా RPC ప్రోటోకాల్‌ని ఉపయోగించే ఏదైనా కోడ్‌ని అమలు చేస్తుంది. కోడ్ స్థానికంగా RPC ప్రాక్సీలో నడుస్తుంది - కోడ్ ఉన్న ప్రతి సర్వర్ దాని స్వంత స్థానిక ప్రాక్సీని అమలు చేస్తుంది. అభ్యర్థనపై, ప్రాక్సీ ఎక్కడికి వెళ్లాలో అర్థం చేసుకుంటుంది.

ఒక ఇంజన్ మరొకదానికి వెళ్లాలనుకుంటే, అది పొరుగువారి అయినప్పటికీ, అది ప్రాక్సీ ద్వారా వెళుతుంది, ఎందుకంటే పొరుగువారు మరొక డేటా సెంటర్‌లో ఉండవచ్చు. ఇంజిన్ తనంతట తాను కాకుండా మరేదైనా స్థానాన్ని తెలుసుకోవడంపై ఆధారపడకూడదు - ఇది మా ప్రామాణిక పరిష్కారం. కానీ వాస్తవానికి మినహాయింపులు ఉన్నాయి :)

అన్ని ఇంజిన్లు పనిచేసే TL-పథకానికి ఉదాహరణ.

memcache.not_found                                = memcache.Value;
memcache.strvalue	value:string flags:int = memcache.Value;
memcache.addOrIncr key:string flags:int delay:int value:long = memcache.Value;

tasks.task
    fields_mask:#
    flags:int
    tag:%(Vector int)
    data:string
    id:fields_mask.0?long
    retries:fields_mask.1?int
    scheduled_time:fields_mask.2?int
    deadline:fields_mask.3?int
    = tasks.Task;
 
tasks.addTask type_name:string queue_id:%(Vector int) task:%tasks.Task = Long;

ఇది బైనరీ ప్రోటోకాల్, దీని దగ్గరి అనలాగ్ ప్రోటోబఫ్. స్కీమా ఐచ్ఛిక ఫీల్డ్‌లు, సంక్లిష్ట రకాలు - అంతర్నిర్మిత స్కేలర్‌ల పొడిగింపులు మరియు ప్రశ్నలను నిర్దేశిస్తుంది. ప్రతిదీ ఈ ప్రోటోకాల్ ప్రకారం పనిచేస్తుంది.

TCP/UDP మీద TL మీద RPC... UDP?

TL స్కీమ్ పైన అమలవుతున్న ఇంజిన్ అభ్యర్థనలను అమలు చేయడానికి మా వద్ద RPC ప్రోటోకాల్ ఉంది. ఇదంతా TCP/UDP కనెక్షన్ ద్వారా పని చేస్తుంది. TCP అర్థమయ్యేలా ఉంది, అయితే మనకు తరచుగా UDP ఎందుకు అవసరం?

UDP సహాయం చేస్తుంది సర్వర్‌ల మధ్య భారీ సంఖ్యలో కనెక్షన్‌ల సమస్యను నివారించండి. ప్రతి సర్వర్‌కు RPC ప్రాక్సీ ఉంటే మరియు సాధారణంగా, అది ఏదైనా ఇంజిన్‌కి వెళ్లవచ్చు, అప్పుడు సర్వర్‌కు పదివేల TCP కనెక్షన్‌లు ఉంటాయి. లోడ్ ఉంది, కానీ అది పనికిరానిది. UDP విషయంలో ఈ సమస్య ఉండదు.

అనవసరమైన TCP హ్యాండ్‌షేక్ లేదు. ఇది ఒక సాధారణ సమస్య: కొత్త ఇంజిన్ లేదా కొత్త సర్వర్ ప్రారంభించబడినప్పుడు, అనేక TCP కనెక్షన్‌లు ఒకేసారి ఏర్పాటు చేయబడతాయి. చిన్న తేలికైన అభ్యర్థనల కోసం, ఉదాహరణకు, UDP పేలోడ్, కోడ్ మరియు ఇంజిన్ మధ్య అన్ని కమ్యూనికేషన్ రెండు UDP ప్యాకెట్లు: ఒకటి ఒక దిశలో, రెండవది మరొక దిశలో ఎగురుతుంది. ఒక రౌండ్ ట్రిప్ - మరియు కోడ్ హ్యాండ్‌షేక్ లేకుండా ఇంజిన్ నుండి ప్రతిస్పందనను పొందింది.

అవును, ఇదంతా పని చేస్తుంది ప్యాకెట్ నష్టం చాలా తక్కువ శాతంతో. ప్రోటోకాల్ రీట్రాన్స్‌మిట్‌లు మరియు టైమ్‌అవుట్‌లకు మద్దతునిస్తుంది, కానీ మనం చాలా కోల్పోతే, మేము దాదాపు TCPని పొందుతాము, ఇది లాభదాయకం కాదు. మేము UDPని మహాసముద్రాల మీదుగా నడిపించము.

మేము అలాంటి వేలాది సర్వర్‌లను కలిగి ఉన్నాము మరియు పథకం ఒకేలా ఉంటుంది: ప్రతి భౌతిక సర్వర్‌లో ఇంజిన్‌ల ప్యాక్ ఇన్‌స్టాల్ చేయబడింది. నిరోధించకుండా వీలైనంత త్వరగా అమలు చేయడానికి అవి ఎక్కువగా సింగిల్-థ్రెడ్‌గా ఉంటాయి మరియు సింగిల్-థ్రెడ్ సొల్యూషన్స్‌గా విభజించబడతాయి. అదే సమయంలో, ఈ ఇంజిన్‌ల కంటే మాకు నమ్మదగినది ఏదీ లేదు మరియు నిరంతర డేటా నిల్వపై చాలా శ్రద్ధ ఉంటుంది.

నిరంతర డేటా నిల్వ

ఇంజిన్లు బిన్‌లాగ్‌లను వ్రాస్తాయి. బిన్‌లాగ్ అనేది ఫైల్ చివరిలో స్థితి లేదా డేటాలో మార్పు కోసం ఈవెంట్ జోడించబడుతుంది. వేర్వేరు పరిష్కారాలలో దీనిని విభిన్నంగా పిలుస్తారు: బైనరీ లాగ్, గోడ, AOF, కానీ సూత్రం ఒకటే.

పునఃప్రారంభించేటప్పుడు ఇంజిన్ మొత్తం బిన్‌లాగ్‌ను చాలా సంవత్సరాలు తిరిగి చదవకుండా నిరోధించడానికి, ఇంజిన్‌లు వ్రాస్తాయి స్నాప్‌షాట్‌లు - ప్రస్తుత స్థితి. అవసరమైతే, వారు మొదట దాని నుండి చదివి, ఆపై బిన్లాగ్ నుండి చదవడం పూర్తి చేస్తారు. అన్ని బిన్‌లాగ్‌లు ఒకే బైనరీ ఆకృతిలో వ్రాయబడ్డాయి - TL పథకం ప్రకారం, నిర్వాహకులు తమ సాధనాలను ఉపయోగించి వాటిని సమానంగా నిర్వహించగలరు. అలాంటి స్నాప్‌షాట్‌ల అవసరం లేదు. ఎవరి స్నాప్‌షాట్ పూర్ణాంకం, ఇంజిన్ యొక్క మ్యాజిక్ మరియు ఎవరికీ ముఖ్యమైనది కాదని సూచించే సాధారణ హెడర్ ఉంది. ఇది స్నాప్‌షాట్‌ను రికార్డ్ చేసిన ఇంజిన్‌తో సమస్య.

నేను త్వరగా ఆపరేషన్ సూత్రాన్ని వివరిస్తాను. ఇంజిన్ పనిచేసే సర్వర్ ఉంది. అతను వ్రాయడం కోసం కొత్త ఖాళీ బిన్‌లాగ్‌ను తెరుస్తాడు మరియు దానికి మార్పు కోసం ఒక ఈవెంట్‌ను వ్రాస్తాడు.

ఏదో ఒక సమయంలో, అతను స్వయంగా ఒక స్నాప్‌షాట్ తీయాలని నిర్ణయించుకుంటాడు లేదా అతను సిగ్నల్ అందుకుంటాడు. సర్వర్ ఒక కొత్త ఫైల్‌ను సృష్టిస్తుంది, దాని మొత్తం స్థితిని దానిలో వ్రాసి, ప్రస్తుత బిన్‌లాగ్ పరిమాణాన్ని - ఆఫ్‌సెట్ - ఫైల్ చివరి వరకు జతచేస్తుంది మరియు మరింత రాయడం కొనసాగిస్తుంది. కొత్త బిన్‌లాగ్ సృష్టించబడలేదు.

ఏదో ఒక సమయంలో, ఇంజిన్ పునఃప్రారంభించబడినప్పుడు, డిస్క్‌లో బిన్‌లాగ్ మరియు స్నాప్‌షాట్ రెండూ ఉంటాయి. ఇంజిన్ మొత్తం స్నాప్‌షాట్‌ను చదువుతుంది మరియు ఒక నిర్దిష్ట సమయంలో దాని స్థితిని పెంచుతుంది.

స్నాప్‌షాట్ సృష్టించబడిన సమయంలో ఉన్న స్థానం మరియు బిన్‌లాగ్ పరిమాణాన్ని చదువుతుంది.

ప్రస్తుత స్థితిని పొందడానికి బిన్‌లాగ్ ముగింపును చదివి, తదుపరి ఈవెంట్‌లను వ్రాయడం కొనసాగిస్తుంది. ఇది ఒక సాధారణ పథకం; మా అన్ని ఇంజిన్లు దాని ప్రకారం పని చేస్తాయి.

డేటా ప్రతిరూపణ

ఫలితంగా, మాలో డేటా రెప్లికేషన్ ప్రకటన ఆధారిత — మేము బిన్‌లాగ్‌లో ఏ పేజీ మార్పులను వ్రాస్తాము, కానీ అవి అభ్యర్థనలను మార్చండి. నెట్‌వర్క్‌లో వచ్చే వాటికి చాలా పోలి ఉంటుంది, కొద్దిగా సవరించబడింది.

అదే పథకం ప్రతిరూపణకు మాత్రమే కాకుండా, ఉపయోగించబడుతుంది బ్యాకప్‌లను సృష్టించడానికి. మాకు ఇంజిన్ ఉంది - బిన్‌లాగ్‌కు వ్రాసే రైటింగ్ మాస్టర్. నిర్వాహకులు దీన్ని సెటప్ చేసిన మరే ఇతర ప్రదేశంలోనైనా, ఈ బిన్‌లాగ్ కాపీ చేయబడింది మరియు అంతే - మాకు బ్యాకప్ ఉంది.

అవసరం అయితే పఠన ప్రతిరూపంCPU రీడింగ్ లోడ్‌ను తగ్గించడానికి, రీడింగ్ ఇంజిన్ కేవలం ప్రారంభించబడుతుంది, ఇది బిన్‌లాగ్ ముగింపును చదివి స్థానికంగా ఈ ఆదేశాలను అమలు చేస్తుంది.

ఇక్కడ లాగ్ చాలా చిన్నది, మరియు ప్రతిరూపం మాస్టర్ కంటే ఎంత వెనుకబడి ఉందో కనుగొనడం సాధ్యమవుతుంది.

RPC ప్రాక్సీలో డేటా షేడింగ్

షార్డింగ్ ఎలా పని చేస్తుంది? ఏ క్లస్టర్ షార్డ్‌కు పంపాలో ప్రాక్సీ ఎలా అర్థం చేసుకుంటుంది? కోడ్ ఇలా చెప్పలేదు: “15 ముక్కల కోసం పంపండి!” - లేదు, ఇది ప్రాక్సీ ద్వారా చేయబడుతుంది.

సరళమైన పథకం ఫస్ట్ఇంట్ - అభ్యర్థనలో మొదటి సంఖ్య.

get(photo100_500) => 100 % N.

ఇది సాధారణ మెమ్‌క్యాచ్డ్ టెక్స్ట్ ప్రోటోకాల్‌కు ఉదాహరణ, అయితే, ప్రశ్నలు సంక్లిష్టంగా మరియు నిర్మాణాత్మకంగా ఉంటాయి. ఉదాహరణ ప్రశ్నలోని మొదటి సంఖ్యను తీసుకుంటుంది మరియు క్లస్టర్ పరిమాణంతో విభజించినప్పుడు మిగిలినది.

మేము ఒకే ఎంటిటీ యొక్క డేటా స్థానికతను కలిగి ఉండాలనుకున్నప్పుడు ఇది ఉపయోగకరంగా ఉంటుంది. 100 అనేది వినియోగదారు లేదా సమూహ ID అని అనుకుందాం మరియు సంక్లిష్ట ప్రశ్నల కోసం ఒక ఎంటిటీ యొక్క మొత్తం డేటా ఒకే షార్డ్‌లో ఉండాలని మేము కోరుకుంటున్నాము.

క్లస్టర్‌లో అభ్యర్థనలు ఎలా వ్యాపించాయో మేము పట్టించుకోనట్లయితే, మరొక ఎంపిక ఉంది - మొత్తం ముక్కను హ్యాష్ చేయడం.

hash(photo100_500) => 3539886280 % N

మేము హాష్, విభజన యొక్క శేషం మరియు షార్డ్ సంఖ్యను కూడా పొందుతాము.

మేము క్లస్టర్ యొక్క పరిమాణాన్ని పెంచినప్పుడు, మేము దానిని విభజించడం లేదా అనేక సార్లు పెంచడం అనే వాస్తవం కోసం మేము సిద్ధంగా ఉంటే మాత్రమే ఈ రెండు ఎంపికలు పని చేస్తాయి. ఉదాహరణకు, మాకు 16 ముక్కలు ఉన్నాయి, మాకు తగినంత లేదు, మాకు మరిన్ని కావాలి - మేము పనికిరాని సమయం లేకుండా సురక్షితంగా 32 పొందవచ్చు. మేము గుణకాలు కాకుండా పెంచాలనుకుంటే, పనికిరాని సమయం ఉంటుంది, ఎందుకంటే నష్టాలు లేకుండా ప్రతిదాన్ని ఖచ్చితంగా విభజించలేము. ఈ ఎంపికలు ఉపయోగకరంగా ఉంటాయి, కానీ ఎల్లప్పుడూ కాదు.

మేము ఏకపక్ష సర్వర్‌ల సంఖ్యను జోడించడం లేదా తీసివేయడం అవసరమైతే, మేము ఉపయోగిస్తాము రింగ్ ఎ లా కెటమాపై స్థిరమైన హాషింగ్. కానీ అదే సమయంలో, మేము డేటా యొక్క స్థానికతను పూర్తిగా కోల్పోతాము; మేము అభ్యర్థనను క్లస్టర్‌కు విలీనం చేయాలి, తద్వారా ప్రతి భాగం దాని స్వంత చిన్న ప్రతిస్పందనను తిరిగి ఇస్తుంది, ఆపై ప్రతిస్పందనలను ప్రాక్సీకి విలీనం చేస్తుంది.

సూపర్-నిర్దిష్ట అభ్యర్థనలు ఉన్నాయి. ఇది ఇలా కనిపిస్తుంది: RPC ప్రాక్సీ అభ్యర్థనను స్వీకరిస్తుంది, ఏ క్లస్టర్‌కు వెళ్లాలో నిర్ణయిస్తుంది మరియు షార్డ్‌ను నిర్ణయిస్తుంది. అప్పుడు రైటింగ్ మాస్టర్‌లు ఉంటారు, లేదా, క్లస్టర్‌కు ప్రతిరూప మద్దతు ఉంటే, అది డిమాండ్‌పై ప్రతిరూపానికి పంపుతుంది. ప్రాక్సీ ఇదంతా చేస్తుంది.

లాగ్‌లు

మేము అనేక విధాలుగా లాగ్లను వ్రాస్తాము. అత్యంత స్పష్టమైన మరియు సరళమైనది మెమ్‌కాష్‌కు లాగ్‌లను వ్రాయండి.

ring-buffer: prefix.idx = line

ఒక కీ ఉపసర్గ ఉంది - లాగ్ పేరు, ఒక లైన్, మరియు ఈ లాగ్ యొక్క పరిమాణం ఉంది - పంక్తుల సంఖ్య. మేము 0 నుండి పంక్తుల సంఖ్య మైనస్ 1 వరకు యాదృచ్ఛిక సంఖ్యను తీసుకుంటాము. మెమ్‌కాష్‌లోని కీ ఈ యాదృచ్ఛిక సంఖ్యతో సంయోగం చేయబడిన ఉపసర్గ. మేము లాగ్ లైన్ మరియు ప్రస్తుత సమయాన్ని విలువకు సేవ్ చేస్తాము.

లాగ్లను చదవడం అవసరం అయినప్పుడు, మేము నిర్వహిస్తాము బహుళ పొందండి అన్ని కీలు, సమయం ద్వారా క్రమబద్ధీకరించబడతాయి మరియు తద్వారా నిజ సమయంలో ఉత్పత్తి లాగ్‌ను పొందండి. మీరు నిజ సమయంలో ఉత్పత్తిలో ఏదైనా డీబగ్ చేయవలసి వచ్చినప్పుడు, ఏదైనా విచ్ఛిన్నం చేయకుండా, ఇతర యంత్రాలకు ట్రాఫిక్‌ను ఆపకుండా లేదా అనుమతించకుండా ఈ పథకం ఉపయోగించబడుతుంది, అయితే ఈ లాగ్ ఎక్కువ కాలం ఉండదు.

లాగ్‌ల విశ్వసనీయ నిల్వ కోసం మనకు ఇంజిన్ ఉంది లాగ్స్-ఇంజిన్. ఇది ఖచ్చితంగా ఎందుకు సృష్టించబడింది మరియు భారీ సంఖ్యలో క్లస్టర్లలో విస్తృతంగా ఉపయోగించబడుతుంది. నాకు తెలిసిన అతిపెద్ద క్లస్టర్‌లో 600 TB ప్యాక్ చేసిన లాగ్‌లు ఉన్నాయి.

ఇంజిన్ చాలా పాతది, ఇప్పటికే 6-7 సంవత్సరాల వయస్సు ఉన్న క్లస్టర్లు ఉన్నాయి. మేము పరిష్కరించడానికి ప్రయత్నిస్తున్న దానితో సమస్యలు ఉన్నాయి, ఉదాహరణకు, మేము లాగ్‌లను నిల్వ చేయడానికి క్లిక్‌హౌస్‌ను చురుకుగా ఉపయోగించడం ప్రారంభించాము.

క్లిక్‌హౌస్‌లో లాగ్‌లను సేకరిస్తోంది

ఈ రేఖాచిత్రం మనం మన ఇంజిన్‌లలోకి ఎలా నడుస్తామో చూపిస్తుంది.

స్థానికంగా RPC ద్వారా RPC-ప్రాక్సీకి వెళ్లే కోడ్ ఉంది మరియు ఇంజిన్‌కు ఎక్కడికి వెళ్లాలో అది అర్థం చేసుకుంటుంది. మనం క్లిక్‌హౌస్‌లో లాగ్‌లను వ్రాయాలనుకుంటే, ఈ పథకంలో మనం రెండు భాగాలను మార్చాలి:

• క్లిక్‌హౌస్‌తో కొంత ఇంజిన్‌ను భర్తీ చేయండి;
• RPC ప్రాక్సీని భర్తీ చేయండి, ఇది ClickHouseని యాక్సెస్ చేయలేము, కొన్ని పరిష్కారాలతో మరియు RPC ద్వారా.

ఇంజిన్ చాలా సులభం - మేము దానిని క్లిక్‌హౌస్‌తో సర్వర్ లేదా సర్వర్‌ల క్లస్టర్‌తో భర్తీ చేస్తాము.

మరియు క్లిక్‌హౌస్‌కి వెళ్లడానికి, మేము చేసాము కిట్టెన్ హౌస్. మేము నేరుగా KittenHouse నుండి ClickHouseకి వెళితే, అది భరించదు. అభ్యర్థనలు లేకుండా కూడా, ఇది భారీ సంఖ్యలో యంత్రాల HTTP కనెక్షన్‌ల నుండి జోడించబడుతుంది. పథకం పని చేయడానికి, ClickHouseతో సర్వర్‌లో స్థానిక రివర్స్ ప్రాక్సీ పెంచబడింది, ఇది కనెక్షన్ల అవసరమైన వాల్యూమ్లను తట్టుకోగలిగే విధంగా వ్రాయబడింది. ఇది డేటాను సాపేక్షంగా విశ్వసనీయంగా బఫర్ చేయగలదు.

కొన్నిసార్లు మేము RPC పథకాన్ని ప్రామాణికం కాని పరిష్కారాలలో అమలు చేయకూడదనుకుంటున్నాము, ఉదాహరణకు, nginxలో. అందువల్ల, KittenHouse UDP ద్వారా లాగ్‌లను స్వీకరించగల సామర్థ్యాన్ని కలిగి ఉంది.

లాగ్‌లను పంపినవారు మరియు గ్రహీత ఒకే మెషీన్‌లో పని చేస్తే, స్థానిక హోస్ట్‌లో UDP ప్యాకెట్‌ను కోల్పోయే సంభావ్యత చాలా తక్కువగా ఉంటుంది. థర్డ్-పార్టీ సొల్యూషన్ మరియు విశ్వసనీయతలో RPCని అమలు చేయాల్సిన అవసరం మధ్య రాజీగా, మేము కేవలం UDP పంపడాన్ని ఉపయోగిస్తాము. మేము తర్వాత ఈ స్కీమ్‌కి తిరిగి వస్తాము.

పర్యవేక్షణ

మా వద్ద రెండు రకాల లాగ్‌లు ఉన్నాయి: నిర్వాహకులు వారి సర్వర్‌లలో సేకరించినవి మరియు డెవలపర్‌లు కోడ్ నుండి వ్రాసినవి. అవి రెండు రకాల కొలమానాలకు అనుగుణంగా ఉంటాయి: వ్యవస్థ మరియు ఉత్పత్తి.

సిస్టమ్ మెట్రిక్స్

ఇది మా సర్వర్‌లన్నింటిలో పని చేస్తుంది నెట్‌డేటా, ఇది గణాంకాలను సేకరించి వాటిని పంపుతుంది గ్రాఫైట్ కార్బన్. అందువల్ల, క్లిక్‌హౌస్ నిల్వ వ్యవస్థగా ఉపయోగించబడుతుంది మరియు ఉదాహరణకు, విస్పర్ కాదు. అవసరమైతే, మీరు నేరుగా ClickHouse నుండి చదవవచ్చు లేదా ఉపయోగించవచ్చు గ్రాఫనా కొలమానాలు, గ్రాఫ్‌లు మరియు నివేదికల కోసం. డెవలపర్‌లుగా, మాకు Netdata మరియు Grafanaకి తగినంత యాక్సెస్ ఉంది.

ఉత్పత్తి కొలమానాలు

సౌలభ్యం కోసం, మేము చాలా విషయాలు వ్రాసాము. ఉదాహరణకు, గణనలు, ప్రత్యేక గణనల విలువలను గణాంకాలలో వ్రాయడానికి మిమ్మల్ని అనుమతించే సాధారణ ఫంక్షన్‌ల సమితి ఉంది, అవి ఎక్కడికో పంపబడతాయి.

statlogsCountEvent   ( ‘stat_name’,            $key1, $key2, …)
statlogsUniqueCount ( ‘stat_name’, $uid,    $key1, $key2, …)
statlogsValuetEvent  ( ‘stat_name’, $value, $key1, $key2, …)

$stats = statlogsStatData($params)

తదనంతరం, మేము ఫిల్టర్‌లను క్రమబద్ధీకరించడం మరియు సమూహపరచడం ఉపయోగించవచ్చు మరియు గణాంకాల నుండి మనకు కావలసిన ప్రతిదాన్ని చేయవచ్చు - గ్రాఫ్‌లను రూపొందించడం, వాచ్‌డాగ్‌లను కాన్ఫిగర్ చేయడం.

మేము చాలా వ్రాస్తాము అనేక కొలమానాలు సంఘటనల సంఖ్య రోజుకు 600 బిలియన్ల నుండి 1 ట్రిలియన్ వరకు ఉంది. అయితే, మేము వాటిని ఉంచాలనుకుంటున్నాము కనీసం రెండు సంవత్సరాలుకొలమానాలలో ట్రెండ్‌లను అర్థం చేసుకోవడానికి. అన్నింటినీ కలిపి ఉంచడం అనేది మనం ఇంకా పరిష్కరించని పెద్ద సమస్య. గత కొన్ని సంవత్సరాలుగా ఇది ఎలా పని చేస్తుందో నేను మీకు చెప్తాను.

ఈ కొలమానాలను వ్రాసే విధులు మాకు ఉన్నాయి స్థానిక memcache కుఎంట్రీల సంఖ్యను తగ్గించడానికి. తక్కువ వ్యవధిలో ఒకసారి స్థానికంగా ప్రారంభించబడింది గణాంకాలు-డెమోన్ అన్ని రికార్డులను సేకరిస్తుంది. తర్వాత, భూతం కొలమానాలను సర్వర్‌ల యొక్క రెండు పొరలుగా విలీనం చేస్తుంది లాగ్స్-కలెక్టర్లు, ఇది మా యంత్రాల సమూహం నుండి గణాంకాలను సమగ్రం చేస్తుంది, తద్వారా వాటి వెనుక ఉన్న పొర చనిపోదు.

అవసరమైతే, మేము నేరుగా లాగ్స్-కలెక్టర్లకు వ్రాయవచ్చు.

కానీ కోడ్ నుండి నేరుగా కలెక్టర్‌లకు రాయడం, స్టాస్-డెమోమ్‌ను దాటవేయడం అనేది పేలవమైన స్కేలబుల్ పరిష్కారం ఎందుకంటే ఇది కలెక్టర్‌పై లోడ్‌ను పెంచుతుంది. కొన్ని కారణాల వల్ల మనం మెషీన్‌లో మెమ్‌కాష్ గణాంకాలు-డెమోన్‌ను పెంచలేకపోతే లేదా అది క్రాష్ అయి మేము నేరుగా వెళ్లినప్పుడు మాత్రమే పరిష్కారం అనుకూలంగా ఉంటుంది.

తర్వాత, లాగ్‌లు-కలెక్టర్లు గణాంకాలను విలీనం చేస్తాయి meowDB - ఇది మా డేటాబేస్, ఇది కొలమానాలను కూడా నిల్వ చేయగలదు.

అప్పుడు మనం కోడ్ నుండి బైనరీ “SQL దగ్గర” ఎంపికలను చేయవచ్చు.

ప్రయోగం

2018 వేసవిలో, మేము అంతర్గత హ్యాకథాన్‌ని కలిగి ఉన్నాము మరియు రేఖాచిత్రంలోని ఎరుపు భాగాన్ని క్లిక్‌హౌస్‌లో కొలమానాలను నిల్వ చేయగల వాటితో భర్తీ చేయడానికి ప్రయత్నించాలనే ఆలోచన వచ్చింది. క్లిక్‌హౌస్‌లో మాకు లాగ్‌లు ఉన్నాయి - దీన్ని ఎందుకు ప్రయత్నించకూడదు?

మేము కిట్టెన్‌హౌస్ ద్వారా లాగ్‌లను వ్రాసే పథకాన్ని కలిగి ఉన్నాము.

మేము నిర్ణయించుకున్నాం రేఖాచిత్రానికి మరొక "*హౌస్" జోడించండి, ఇది మా కోడ్ UDP ద్వారా వాటిని వ్రాసేటప్పుడు ఫార్మాట్‌లోని మెట్రిక్‌లను ఖచ్చితంగా స్వీకరిస్తుంది. అప్పుడు ఈ *హౌస్ వాటిని లాగ్‌ల వంటి ఇన్సర్ట్‌లుగా మారుస్తుంది, వీటిని కిట్టెన్‌హౌస్ అర్థం చేసుకుంటుంది. అతను ఈ లాగ్‌లను క్లిక్‌హౌస్‌కి ఖచ్చితంగా బట్వాడా చేయగలడు, అది వాటిని చదవగలదు.

memcache, stats-demon మరియు logs-collectors డేటాబేస్‌తో ఉన్న పథకం దీనితో భర్తీ చేయబడింది.

memcache, stats-demon మరియు logs-collectors డేటాబేస్‌తో ఉన్న పథకం దీనితో భర్తీ చేయబడింది.

• ఇక్కడ కోడ్ నుండి డిస్పాచ్ ఉంది, ఇది స్థానికంగా StatsHouseలో వ్రాయబడింది.
• StatsHouse ఇప్పటికే SQL ఇన్‌సర్ట్‌లుగా మార్చబడిన UDP మెట్రిక్‌లను బ్యాచ్‌లలో KittenHouseకి వ్రాస్తుంది.
• KittenHouse వాటిని ClickHouseకి పంపుతుంది.
• మనం వాటిని చదవాలనుకుంటే, సాధారణ SQLని ఉపయోగించి నేరుగా ClickHouse నుండి - StatsHouseని బైపాస్ చేస్తూ వాటిని చదువుతాము.

ఇది ఇంకా ఉందా ప్రయోగం, కానీ అది ఎలా మారుతుందో మేము ఇష్టపడతాము. మేము పథకంతో సమస్యలను పరిష్కరిస్తే, బహుశా మేము దానిని పూర్తిగా మారుస్తాము. వ్యక్తిగతంగా, నేను ఆశిస్తున్నాను.

పథకం ఇనుమును ఆదా చేయదు. తక్కువ సర్వర్‌లు అవసరం, స్థానిక గణాంకాలు-డెమన్‌లు మరియు లాగ్‌లు-కలెక్టర్లు అవసరం లేదు, కానీ ClickHouseకి ప్రస్తుత స్కీమ్‌లో ఉన్న వాటి కంటే పెద్ద సర్వర్ అవసరం. తక్కువ సర్వర్‌లు అవసరం, కానీ అవి ఖరీదైనవి మరియు మరింత శక్తివంతమైనవిగా ఉండాలి.

మోహరించేందుకు

మొదట, PHP విస్తరణను చూద్దాం. లో అభివృద్ధి చేస్తున్నాం వెళ్ళండి: వా డు GitLab и TeamCity విస్తరణ కోసం. డెవలప్‌మెంట్ బ్రాంచ్‌లు మాస్టర్ బ్రాంచ్‌లో విలీనం చేయబడ్డాయి, మాస్టర్ నుండి పరీక్ష కోసం అవి స్టేజింగ్‌లోకి మరియు స్టేజింగ్ నుండి ప్రొడక్షన్‌లోకి విలీనం చేయబడతాయి.

విస్తరణకు ముందు, ప్రస్తుత ఉత్పత్తి శాఖ మరియు మునుపటిది తీసుకోబడింది మరియు వాటిలో తేడా ఫైల్‌లు పరిగణించబడతాయి - మార్పులు: సృష్టించబడ్డాయి, తొలగించబడ్డాయి, మార్చబడ్డాయి. ఈ మార్పు ప్రత్యేక కాపీఫాస్ట్ ఇంజిన్ యొక్క బిన్‌లాగ్‌లో నమోదు చేయబడింది, ఇది మా మొత్తం సర్వర్ ఫ్లీట్‌లో మార్పులను త్వరగా పునరావృతం చేయగలదు. ఇక్కడ ఉపయోగించినది నేరుగా కాపీ చేయడం కాదు, కానీ గాసిప్ ప్రతిరూపం, ఒక సర్వర్ తన సన్నిహిత పొరుగువారికి, వారి పొరుగువారికి మరియు మొదలైన వాటికి మార్పులను పంపినప్పుడు. ఇది మొత్తం ఫ్లీట్‌లో పదుల మరియు యూనిట్ల సెకన్లలో కోడ్‌ను నవీకరించడానికి మిమ్మల్ని అనుమతిస్తుంది. మార్పు స్థానిక ప్రతిరూపానికి చేరుకున్నప్పుడు, అది ఈ ప్యాచ్‌లను దానికి వర్తిస్తుంది స్థానిక ఫైల్ సిస్టమ్. అదే పథకం ప్రకారం రోల్బ్యాక్ కూడా నిర్వహించబడుతుంది.

మేము kPHPని కూడా చాలా అమలు చేస్తాము మరియు ఇది దాని స్వంత అభివృద్ధిని కూడా కలిగి ఉంది వెళ్ళండి పై రేఖాచిత్రం ప్రకారం. దీని నుండి HTTP సర్వర్ బైనరీ, అప్పుడు మేము తేడాను ఉత్పత్తి చేయలేము - విడుదల బైనరీ వందల MB బరువు ఉంటుంది. అందువల్ల, ఇక్కడ మరొక ఎంపిక ఉంది - సంస్కరణ వ్రాయబడింది బిన్‌లాగ్ కాపీ ఫాస్ట్. ప్రతి బిల్డ్‌తో అది పెరుగుతుంది మరియు రోల్‌బ్యాక్ సమయంలో కూడా పెరుగుతుంది. సంస్కరణ: Telugu సర్వర్‌లకు ప్రతిరూపం. స్థానిక కాపీఫాస్ట్‌లు బిన్‌లాగ్‌లోకి కొత్త వెర్షన్ ప్రవేశించినట్లు చూస్తారు మరియు అదే గాసిప్ రెప్లికేషన్ ద్వారా వారు మా మాస్టర్ సర్వర్‌ను అలసిపోకుండా బైనరీ యొక్క తాజా వెర్షన్‌ను తమ కోసం తీసుకుంటారు, కానీ నెట్‌వర్క్ అంతటా లోడ్‌ను జాగ్రత్తగా వ్యాప్తి చేస్తారు. ఏమి అనుసరిస్తుంది మనోహరమైన పునఃప్రారంభం కొత్త వెర్షన్ కోసం.

మా ఇంజిన్‌ల కోసం, ముఖ్యంగా బైనరీలు కూడా, పథకం చాలా పోలి ఉంటుంది:

• git మాస్టర్ శాఖ;
• బైనరీ ఇన్ .deb;
• సంస్కరణ బిన్‌లాగ్ కాపీ ఫాస్ట్‌కు వ్రాయబడింది;
• సర్వర్‌లకు ప్రతిరూపం;
• సర్వర్ తాజా .depని బయటకు తీస్తుంది;
• dpkg -i;
• కొత్త సంస్కరణకు అందమైన పునఃప్రారంభం.

తేడా ఏమిటంటే మా బైనరీ ఆర్కైవ్‌లలో ప్యాక్ చేయబడింది .deb, మరియు వాటిని పంపింగ్ చేసేటప్పుడు dpkg -i సిస్టమ్‌లో ఉంచబడతాయి. kPHP బైనరీగా ఎందుకు అమలు చేయబడింది మరియు ఇంజిన్లు dpkgగా ఎందుకు ఉపయోగించబడతాయి? అది అలా జరిగింది. ఇది పనిచేస్తుంది - దానిని తాకవద్దు.

ఉపయోగకరమైన లింకులు:

• అంటోన్ కిర్యుష్కిన్ ద్వారా నివేదిక “Vkontakte సిస్టమ్ అడ్మినిస్ట్రేటర్. ఎలా?" కాపీఫాస్ట్ మరియు గాసిప్ గురించి వివరాలతో.
• యూరి నస్రెట్డినోవ్ ద్వారా నివేదిక "VK పదివేల సర్వర్‌ల నుండి క్లిక్‌హౌస్‌లోకి డేటాను ఎలా ఇన్సర్ట్ చేస్తుంది".
• నా నివేదిక "VKontakte యొక్క ఉదాహరణను ఉపయోగించి పెరుగుతున్న ప్రాజెక్ట్ యొక్క ఆర్కిటెక్చర్", కానీ అభివృద్ధి కోణం నుండి, హార్డ్‌వేర్ కాదు.

ప్రోగ్రామ్ కమిటీలో భాగంగా సహాయం చేసే వారిలో అలెక్సీ అకులోవిచ్ ఒకరు PHP రష్యా మే 17వ తేదీన PHP డెవలపర్‌లకు ఇటీవలి కాలంలో అతిపెద్ద ఈవెంట్ అవుతుంది. మన దగ్గర ఎంత కూల్ పిసి ఉందో చూడండి స్పీకర్లు (వాటిలో రెండు PHP కోర్‌ని అభివృద్ధి చేస్తున్నాయి!) - మీరు PHP అని వ్రాస్తే మీరు మిస్ చేయలేరని అనిపిస్తుంది.

మూలం: www.habr.com