VKontakte හි ගෘහ නිර්මාණ ශිල්පය සහ වැඩ පිළිබඳ නිතර අසන ප්රශ්න

VKontakte නිර්මාණය කිරීමේ ඉතිහාසය විකිපීඩියාවේ ඇත; එය පවෙල් විසින්ම පවසන ලදී. සෑම කෙනෙකුම දැනටමත් ඇයව හඳුනන බව පෙනේ. HighLoad++ Pavel හි වෙබ් අඩවියේ අභ්‍යන්තරය, ගෘහ නිර්මාණ ශිල්පය සහ ව්‍යුහය ගැන 2010 දී මට කිව්වා. එතැන් සිට බොහෝ සේවාදායකයන් කාන්දු වී ඇත, එබැවින් අපි තොරතුරු යාවත්කාලීන කරන්නෙමු: අපි එය විච්ඡේදනය කරන්නෙමු, ඇතුළත පිටතට ගන්නෙමු, එය කිරා මැන බලමු, සහ තාක්ෂණික දෘෂ්ටි කෝණයකින් VK උපාංගය දෙස බලන්න.

ඇලෙක්සි අකුලොවිච් (AterCattus) VKontakte කණ්ඩායමේ පසුපෙළ සංවර්ධකයා. මෙම වාර්තාවේ පිටපත වේදිකාවේ ක්‍රියාකාරිත්වය, යටිතල පහසුකම්, සේවාදායකයන් සහ ඒවා අතර අන්තර්ක්‍රියා පිළිබඳ නිතර අසන ප්‍රශ්නවලට සාමූහික පිළිතුරකි, නමුත් සංවර්ධනය පිළිබඳ නොවේ, එනම්. යකඩ ගැන. වෙනමම, දත්ත සමුදායන් සහ ඒ වෙනුවට VK සතුව ඇති දේ, ලඝු-සටහන් එකතු කිරීම සහ සමස්ත ව්‍යාපෘතිය අධීක්ෂණය කිරීම ගැන. කප්පාදුව යටතේ විස්තර.

වසර හතරකට වැඩි කාලයක් මම පසුපෙළ සම්බන්ධ සියලු ආකාරයේ කාර්යයන් සමඟ කටයුතු කර ඇත.

• මාධ්‍ය උඩුගත කිරීම, ගබඩා කිරීම, සැකසීම, බෙදා හැරීම: වීඩියෝ, සජීවී ප්‍රවාහය, ශ්‍රව්‍ය, ඡායාරූප, ලේඛන.
• යටිතල පහසුකම්, වේදිකාව, සංවර්ධක අධීක්ෂණය, ලඝු-සටහන්, කලාපීය හැඹිලි, CDN, හිමිකාර RPC ප්‍රොටෝකෝලය.
• බාහිර සේවාවන් සමඟ ඒකාබද්ධ වීම: තල්ලු දැනුම්දීම්, බාහිර සබැඳි විග්‍රහ කිරීම, RSS සංග්‍රහය.
• විවිධ ප්‍රශ්න සමඟ සගයන්ට උපකාර කිරීම, ඒවාට පිළිතුරු නොදන්නා කේතයකට කිමිදීම අවශ්‍ය වේ.

මෙම කාලය තුළ, මම වෙබ් අඩවියේ බොහෝ සංරචක වලට අත තැබුවෙමි. මට මේ අත්දැකීම බෙදාගන්න ඕන.

සාමාන්ය ගෘහ නිර්මාණ ශිල්පය

සෑම දෙයක්ම, සුපුරුදු පරිදි, ඉල්ලීම් පිළිගන්නා සේවාදායකයකින් හෝ සේවාදායක සමූහයකින් ආරම්භ වේ.

ඉදිරිපස සේවාදායකය

ඉදිරිපස සේවාදායකය HTTPS, RTMP සහ WSS හරහා ඉල්ලීම් පිළිගනී.

HTTPS - මේවා වෙබ් අඩවියේ ප්‍රධාන සහ ජංගම වෙබ් අනුවාද සඳහා වන ඉල්ලීම් වේ: vk.com සහ m.vk.com, සහ අපගේ API හි අනෙකුත් නිල සහ නිල නොවන සේවාදායකයින්: ජංගම සේවාදායකයින්, පණිවිඩකරුවන්. අපිට පිළිගැනීමේ උත්සවයක් තියෙනවා RTMP- වෙනම ඉදිරිපස සේවාදායකයන් සමඟ සජීවී විකාශන සඳහා තදබදය සහ WSS- Streaming API සඳහා සම්බන්ධතා.

සේවාදායකයන් මත HTTPS සහ WSS සඳහා එය වටී nginx. RTMP විකාශන සඳහා, අපි මෑතකදී අපගේම විසඳුම වෙත මාරු විය කිව්, නමුත් එය වාර්තාවේ විෂය පථයෙන් ඔබ්බට ය. දෝෂ ඉවසීම සඳහා, මෙම සේවාදායකයන් පොදු IP ලිපින ප්‍රචාරය කරන අතර කණ්ඩායම් වශයෙන් ක්‍රියා කරන අතර එමඟින් එක් සේවාදායකයක ගැටලුවක් තිබේ නම්, පරිශීලක ඉල්ලීම් නැති නොවේ. HTTPS සහ WSS සඳහා, මෙම සේවාදායකයන් විසින්ම CPU භාරයේ කොටසක් තමන් වෙත ලබා ගැනීම සඳහා ගමනාගමනය සංකේතනය කරයි.

අපි තවදුරටත් WSS සහ RTMP ගැන කතා නොකරමු, නමුත් සාමාන්‍යයෙන් වෙබ් ව්‍යාපෘතියක් සමඟ සම්බන්ධ වන සම්මත HTTPS ඉල්ලීම් ගැන පමණි.

පසුබිම

ඉදිරිපස පිටුපස සාමාන්‍යයෙන් backend servers ඇත. ඔවුන් ඉදිරිපස සේවාදායකයට සේවාදායකයින්ගෙන් ලැබෙන ඉල්ලීම් ක්‍රියාවට නංවයි.

මෙම kPHP සේවාදායකයන්, HTTP ඩීමන් ධාවනය වන, HTTPS දැනටමත් විකේතනය කර ඇති නිසා. kPHP යනු ක්‍රියාත්මක වන සේවාදායකයකි prefork ආකෘති: ප්‍රධාන ක්‍රියාවලියක් ආරම්භ කරයි, ළමා ක්‍රියාවලීන් සමූහයක්, ඔවුන්ට සවන්දීමේ සොකට් ලබා දෙයි සහ ඔවුන් ඔවුන්ගේ ඉල්ලීම් ක්‍රියා කරයි. මෙම අවස්ථාවෙහිදී, පරිශීලකයාගේ සෑම ඉල්ලීමක් අතරම ක්‍රියාවලි නැවත ආරම්භ නොකෙරේ, නමුත් ඒවායේ තත්වය මුල් ශුන්‍ය අගයට නැවත සකසන්න - නැවත ආරම්භ කිරීම වෙනුවට ඉල්ලීමෙන් පසු ඉල්ලීම.

පැටවීම බෙදා හැරීම

අපගේ සියලුම පසුබිම් ඕනෑම ඉල්ලීමක් ක්‍රියාවට නැංවිය හැකි විශාල යන්ත්‍ර සංචිතයක් නොවේ. අපි ඔවුන් වෙනම කණ්ඩායම් වලට බෙදා ඇත: සාමාන්‍ය, ජංගම, api, වීඩියෝ, වේදිකාගත කිරීම... වෙනම යන්ත්‍ර සමූහයක ඇති ගැටළුව අනෙක් සියල්ලටම බලපාන්නේ නැත. වීඩියෝ සමඟ ගැටළු ඇති විට, සංගීතයට සවන් දෙන පරිශීලකයා ගැටළු ගැන පවා නොදනී. ඉල්ලීම යැවිය යුත්තේ කුමන පසුබිමටද යන්න වින්‍යාසය අනුව ඉදිරිපස ඇති nginx විසින් තීරණය කරනු ලැබේ.

මෙට්රික් එකතු කිරීම සහ නැවත සමතුලිත කිරීම

එක් එක් කණ්ඩායම තුළ අපට කොපමණ මෝටර් රථ තිබිය යුතුද යන්න තේරුම් ගැනීමට, අපි QPS මත රඳා නොසිටින්න. පසුපෙළ වෙනස් වේ, ඒවාට විවිධ ඉල්ලීම් ඇත, එක් එක් ඉල්ලීමට QPS ගණනය කිරීමේ විවිධ සංකීර්ණත්වයක් ඇත. ඒකයි අපි අපි සමස්තයක් ලෙස සේවාදායකය මත පැටවීමේ සංකල්පය සමඟ ක්‍රියා කරමු - CPU සහ perf මත.

එවැනි සේවාදායකයන් දහස් ගණනක් අප සතුව ඇත. සෑම භෞතික සේවාදායකයක්ම සියලුම හරයන් ප්‍රතිචක්‍රීකරණය කිරීමට kPHP කණ්ඩායමක් ක්‍රියාත්මක කරයි (kPHP තනි නූල් එකක් නිසා).

අන්තර්ගත සේවාදායකය

CS හෝ Content Server යනු ගබඩාවකි. 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 සැප්තැම්බර් මාසයේදී, කලින් Sun මිලදී ගත් Oracle, හිරු සේවකයන් විශාල පිරිසක් සේවයෙන් පහ කළා. මේ මොහොතේ සමාගම පැවැත්ම නතර වූ බව අපට පැවසිය හැකිය. නව පද්ධතිය සඳහා නමක් තෝරාගැනීමේදී, අපගේ පරිපාලකයින් මෙම සමාගමේ මතකයට උපහාර දැක්වීමට තීරණය කළ අතර නව පද්ධතියට හිරු ලෙස නම් කරන ලදී. අප අතර අපි ඇයව සරලව හඳුන්වන්නේ "හිරු" යනුවෙනි.

pp හි ගැටළු කිහිපයක් තිබුණි. කණ්ඩායමකට එක් IP එකක් - අකාර්යක්ෂම හැඹිලිය. භෞතික සේවාදායකයන් කිහිපයක් පොදු IP ලිපිනයක් බෙදා ගන්නා අතර, ඉල්ලීම කුමන සේවාදායකය වෙත යා යුතුද යන්න පාලනය කිරීමට ක්‍රමයක් නොමැත. එමනිසා, එකම ගොනුව සඳහා විවිධ පරිශීලකයින් පැමිණෙන්නේ නම්, මෙම සේවාදායකයේ හැඹිලියක් තිබේ නම්, ගොනුව එක් එක් සේවාදායකයේ හැඹිලිය තුළ අවසන් වේ. මෙය ඉතා අකාර්යක්ෂම යෝජනා ක්රමයකි, නමුත් කිසිවක් කළ නොහැකි විය.

ප්රතිඵලයක් වශයෙන් - අපට අන්තර්ගතය කොටස් කළ නොහැක, අපට මෙම කණ්ඩායම සඳහා නිශ්චිත සේවාදායකයක් තෝරාගත නොහැකි නිසා - ඔවුන්ට පොදු IP එකක් ඇත. ඒ වගේම සමහර අභ්‍යන්තර හේතූන් නිසා අපට තිබෙනවා කලාපවල එවැනි සේවාදායකයන් ස්ථාපනය කිරීමට නොහැකි විය. ඔවුන් සිටියේ ශාන්ත පීටර්ස්බර්ග්හි පමණි.

හිරු සමඟ, අපි තේරීම් ක්රමය වෙනස් කළා. දැන් අපිට තියෙනවා ඕනෑම මාර්ගයක්: ගතික මාර්ගගත කිරීම, ඕනෑම විකාශනය, ස්වයං-පරීක්ෂණ ඩීමන්. සෑම සේවාදායකයකටම තමන්ගේම තනි IP ඇත, නමුත් පොදු උපජාලයක් ඇත. සෑම දෙයක්ම වින්‍යාස කර ඇත්තේ එක් සේවාදායකයක් අසමත් වුවහොත්, එම කාණ්ඩයේ අනෙක් සේවාදායකයන් හරහා ස්වයංක්‍රීයව ගමනාගමනය පැතිරෙන ආකාරයටය. දැන් ඔබට නිශ්චිත සේවාදායකයක් තෝරා ගත හැකිය, අනවශ්‍ය හැඹිලි නොමැත, සහ විශ්වසනීයත්වය බල නොපායි.

බර ආධාරක. දැන් අපට අවශ්‍ය පරිදි විවිධ බලයෙන් යුත් යන්ත්‍ර ස්ථාපනය කිරීමට දැරිය හැකි අතර, තාවකාලික ගැටළු ඇති විට, වැඩ කරන “හිරු” වල බර වෙනස් කර ඒවා මත බර අඩු කරන්න, එවිට ඔවුන් “විවේක” ගෙන නැවත වැඩ කිරීමට පටන් ගනිමු.

අන්තර්ගත හැඳුනුම්පත අනුව බෙදා ගැනීම. බෙදා හැරීම පිළිබඳ හාස්‍යජනක දෙයක්: අපි සාමාන්‍යයෙන් අන්තර්ගතය බෙදාහරින්නෙමු, එවිට විවිධ පරිශීලකයින් එකම “හිරු” හරහා එකම ගොනුවකට යන අතර එමඟින් ඔවුන්ට පොදු හැඹිලියක් ඇත.

අපි මෑතකදී "Clover" යෙදුම දියත් කළෙමු. මෙය සජීවී විකාශනයක ඔන්ලයින් ප්‍රශ්නාවලියකි, එහිදී සත්කාරක ප්‍රශ්න අසන අතර පරිශීලකයින් තත්‍ය කාලීනව පිළිතුරු ලබා දෙමින් විකල්ප තෝරා ගනී. යෙදුමට පරිශීලකයින්ට කතාබස් කළ හැකි කතාබහක් ඇත. විකාශනයට එකවර සම්බන්ධ විය හැක 100 කට වැඩි පිරිසක්. ඔවුන් සියල්ලෝම සියලුම සහභාගිවන්නන්ට යවන පණිවිඩ ලියන අතර පණිවිඩය සමඟ අවතාරයක් පැමිණේ. එක් "හිරු" තුළ එක් අවතාරයක් සඳහා පුද්ගලයින් 100 ක් පැමිණේ නම්, එය සමහර විට වලාකුළක් පිටුපස පෙරළිය හැකිය.

එකම ගොනුව සඳහා වන ඉල්ලීම්වලට ඔරොත්තු දීම සඳහා, අපි කලාපයේ පවතින සියලුම “හිරු” හරහා ගොනු විහිදුවන මෝඩ යෝජනා ක්‍රමයක් ක්‍රියාත්මක කරන්නේ යම් අන්තර්ගතයක් සඳහා ය.

ඇතුළත සිට හිරු

nginx මත ප්‍රතිලෝම ප්‍රොක්සි, RAM හෝ වේගවත් Optane/NVMe තැටි මත හැඹිලිය. උදාහරණයක්: http://sun4-2.userapi.com/c100500/path - දෙවන සේවාදායක කණ්ඩායම වන සිව්වන කලාපයේ පිහිටා ඇති "හිරු" වෙත සබැඳියක්. එය භෞතිකව 100500 සේවාදායකයේ ඇති මාර්ග ගොනුව වසා දමයි.

ආවරණය

අපි අපගේ වාස්තු විද්‍යාත්මක යෝජනා ක්‍රමයට තවත් එක් නෝඩයක් එකතු කරමු - හැඹිලි පරිසරය.

පහත දැක්වෙන්නේ පිරිසැලසුම් රූප සටහනයි කලාපීය හැඹිලි, ඒවායින් 20 ක් පමණ ඇත. මේවා හැඹිලි සහ "හිරු" පිහිටා ඇති ස්ථාන වන අතර, ඒවා හරහා ගමනාගමනය හැඹිලිගත කළ හැකිය.

මෙය බහුමාධ්‍ය අන්තර්ගතයන් හැඹිලිගත කිරීමකි; කිසිදු පරිශීලක දත්ත මෙහි ගබඩා නොවේ - සංගීතය, වීඩියෝ, ඡායාරූප පමණි.

පරිශීලකයාගේ කලාපය තීරණය කිරීම සඳහා, අපි අපි කලාපවල ප්‍රකාශයට පත් කරන ලද BGP ජාල උපසර්ග එකතු කරමු. ආපසු හැරීමේදී, අපට උපසර්ග මගින් IP සොයාගත නොහැකි නම්, අපට geoip දත්ත සමුදාය විග්‍රහ කිරීමටද සිදුවේ. පරිශීලකයාගේ IP මගින් අපි කලාපය තීරණය කරමු. කේතය තුළ, අපට පරිශීලකයාගේ කලාප එකක් හෝ කිහිපයක් දෙස බැලිය හැකිය - ඔහු භූගෝලීය වශයෙන් සමීපතම ස්ථාන.

එය ක්රියාත්මක වන්නේ කෙසේද?

අපි කලාපය අනුව ගොනු වල ජනප්‍රියතාවය ගණනය කරමු. පරිශීලකයා සිටින කලාපීය හැඹිලි ගණනාවක් ඇත, සහ ගොනු හඳුනාගැනීමක් - අපි මෙම යුගලය ගෙන එක් එක් බාගැනීම් සමඟ ශ්රේණිගත කිරීම වැඩි කරන්නෙමු.

ඒ අතරම, භූතයන් - කලාපවල සේවාවන් - වරින් වර API වෙත පැමිණ මෙසේ කියයි: “මම එවැනි හැඹිලියකි, තවමත් මා සතුව නොමැති මගේ කලාපයේ වඩාත්ම ජනප්‍රිය ලිපිගොනු ලැයිස්තුවක් මට දෙන්න. ” API ශ්‍රේණිගත කිරීම අනුව වර්ග කරන ලද ගොනු සමූහයක් ලබා දෙයි, ඩීමන් ඒවා බාගත කරයි, ඒවා කලාප වෙත ගෙන ගොස් එතැනින් ගොනු ලබා දෙයි. හැඹිලි වලින් pu/pp සහ Sun අතර ඇති මූලික වෙනස මෙයයි: මෙම ගොනුව හැඹිලියේ නොමැති වුවද, ඔවුන් වහාම ගොනුව තමන් හරහා ලබා දෙන අතර, හැඹිලිය මුලින්ම ගොනුව බාගත කර, පසුව එය ආපසු ලබා දීමට පටන් ගනී.

මෙම අවස්ථාවේ දී, අපට ලැබේ පරිශීලකයින්ට සමීප අන්තර්ගතය සහ ජාල භාරය පැතිරීම. උදාහරණයක් ලෙස, මොස්කව් හැඹිලියෙන් පමණක් අපි උපරිම පැය වලදී 1 Tbit / s ට වඩා බෙදා හරිමු.

නමුත් ගැටළු තිබේ - cache servers රබර් නොවේ. සුපිරි ජනප්‍රිය අන්තර්ගතයන් සඳහා, සමහර විට වෙනම සේවාදායකයක් සඳහා ප්‍රමාණවත් ජාලයක් නොමැත. අපගේ හැඹිලි සේවාදායකයන් 40-50 Gbit/s වේ, නමුත් එවැනි නාලිකාවක් සම්පූර්ණයෙන්ම අවහිර කරන අන්තර්ගතයක් ඇත. අපි කලාපයේ ජනප්‍රිය ගොනු පිටපත් එකකට වඩා ගබඩා කිරීම ක්‍රියාත්මක කිරීමට ගමන් කරමින් සිටිමු. අපි එය වසර අවසන් වන විට ක්‍රියාත්මක කිරීමට බලාපොරොත්තු වෙනවා.

අපි සාමාන්ය ගෘහ නිර්මාණ ශිල්පය දෙස බැලුවෙමු.

• ඉල්ලීම් පිළිගන්නා ඉදිරිපස සේවාදායකයන්.
• ඉල්ලීම් ක්‍රියාවලි කරන පසුබිම.
• ප්‍රොක්සි වර්ග දෙකකින් වසා ඇති ගබඩා.
• කලාපීය හැඹිලි.

මෙම රූප සටහනේ නැති වී ඇත්තේ කුමක්ද? ඇත්ත වශයෙන්ම, අපි දත්ත ගබඩා කරන දත්ත සමුදායන්.

දත්ත සමුදායන් හෝ එන්ජින්

අපි ඒවා දත්ත සමුදායන් නොව එන්ජින් ලෙස හඳුන්වමු - එන්ජින්, සාමාන්‍යයෙන් පිළිගත් අර්ථයෙන් අපට ප්‍රායෝගිකව දත්ත සමුදායන් නොමැති බැවිනි.

මෙය අවශ්ය පියවරකි. මෙය සිදු වූයේ 2008-2009 දී, VK ජනප්‍රියත්වයේ පුපුරන සුලු වර්ධනයක් ඇති විට, ව්‍යාපෘතිය සම්පූර්ණයෙන්ම MySQL සහ Memcache මත ක්‍රියාත්මක වූ අතර ගැටළු ඇති වූ බැවිනි. MySQL ගොනු බිඳවැටීමට සහ දූෂිත කිරීමට ප්‍රිය කළේය, ඉන් පසුව එය යථා තත්ත්වයට පත් නොවනු ඇත, සහ Memcache ක්‍රමයෙන් ක්‍රියාකාරීත්වය පිරිහී ගොස් නැවත ආරම්භ කිරීමට සිදු විය.

වැඩි වැඩියෙන් ජනප්‍රිය වූ ව්‍යාපෘතියේ දත්ත දූෂණය කරන ස්ථීර ගබඩාවක් සහ මන්දගාමී වන හැඹිලියක් තිබූ බව පෙනේ. එවැනි තත්වයන් තුළ, වර්ධනය වන ව්යාපෘතියක් සංවර්ධනය කිරීම දුෂ්කර ය. ව්‍යාපෘතියට යොමු වූ තීරණාත්මක දේවල් අපේම බයිසිකල්වල නැවත ලිවීමට උත්සාහ කිරීමට තීරණය විය.

විසඳුම සාර්ථක විය. මෙය සිදු කිරීමට අවස්ථාවක් මෙන්ම අතිශය අවශ්‍යතාවයක් ද පැවතියේ එකල පරිමාණය කිරීමේ වෙනත් ක්‍රම නොතිබූ බැවිනි. දත්ත සමුදායන් පොකුරක් නොතිබුණි, NoSQL තවමත් නොතිබුණි, MySQL, Memcache, PostrgreSQL පමණක් තිබුණි - එය එයයි.

විශ්ව මෙහෙයුම. අපගේ C සංවර්ධක කණ්ඩායම විසින් සංවර්ධනය මෙහෙයවන ලද අතර සෑම දෙයක්ම ස්ථාවර ආකාරයකින් සිදු කරන ලදී. එන්ජිම කුමක් වුවත්, ඔවුන් සියල්ලන්ටම තැටියට ලියා ඇති එකම ගොනු ආකෘතිය, එකම දියත් කිරීමේ පරාමිතීන්, එකම ආකාරයෙන් සැකසූ සංඥා සහ ආන්තික අවස්ථාවන් සහ ගැටළු වලදී ආසන්න වශයෙන් සමාන ලෙස හැසිරුණි. එන්ජින්වල වර්ධනයත් සමඟ, පරිපාලකයින්ට පද්ධතිය ක්‍රියාත්මක කිරීම පහසුය - නඩත්තු කිරීමට අවශ්‍ය සත්වෝද්‍යානයක් නොමැති අතර, එක් එක් නව තෙවන පාර්ශවීය දත්ත ගබඩාව ක්‍රියාත්මක කරන්නේ කෙසේදැයි ඔවුන් නැවත ඉගෙන ගත යුතු අතර එමඟින් ඉක්මනින් හා පහසුවෙන් වැඩි කිරීමට හැකි විය. ඔවුන්ගේ අංකය.

එන්ජින් වර්ග

කණ්ඩායම එන්ජින් කිහිපයක් ලිවීය. මෙන්න ඒවායින් කිහිපයක් පමණි: මිතුරා, ඉඟි, රූපය, ipdb, ලිපි, ලැයිස්තු, ලඝු-සටහන්, memcached, meowdb, news, nostradamus, photo, playlists, pmemcached, sandbox, search, storage, likes, tasks, ...

නිශ්චිත දත්ත ව්‍යුහයක් අවශ්‍ය හෝ අසාමාන්‍ය ඉල්ලීම් ක්‍රියාවට නංවන සෑම කාර්යයක් සඳහාම, C කණ්ඩායම නව එන්ජිමක් ලියයි. ඇයි නැත්තේ.

අපිට වෙනම එන්ජිමක් තියෙනවා memcached, එය සාමාන්‍ය එකකට සමාන නමුත් හොඳ දේවල් රාශියක් ඇති අතර එය මන්දගාමී නොවේ. ClickHouse නොවේ, නමුත් එය ද ක්රියා කරයි. වෙන් වෙන් වශයෙන් ලබා ගත හැක pmmcached - මෙය නොනවතින memcached, නැවත ආරම්භ කිරීමේදී දත්ත නැති නොවන පරිදි, RAM එකට ගැලපෙනවාට වඩා, තැටියේ දත්ත ගබඩා කළ හැක. තනි කාර්යයන් සඳහා විවිධ එන්ජින් තිබේ: පෝලිම්, ලැයිස්තු, කට්ටල - අපගේ ව්යාපෘතියට අවශ්ය සියල්ල.

පොකුරු

කේත දෘෂ්ටිකෝණයකින්, එන්ජින් හෝ දත්ත සමුදායන් ක්‍රියාවලි, ආයතන හෝ අවස්ථා ලෙස සිතීමට අවශ්‍ය නොවේ. කේතය විශේෂයෙන් පොකුරු සමඟ, එන්ජින් කණ්ඩායම් සමඟ ක්‍රියා කරයි - පොකුරකට එක් වර්ගයකි. අපි හිතමු memcached cluster එකක් තියෙනවා - ඒක යන්ත්‍ර සමූහයක් විතරයි.

කේතයට භෞතික පිහිටීම, ප්‍රමාණය හෝ සේවාදායක ගණන දැන ගැනීමට අවශ්‍ය නොවේ. ඔහු පොකුරට යන්නේ යම් හඳුනාගැනීමක් භාවිතා කරමිනි.

මෙය ක්‍රියා කිරීම සඳහා, ඔබ කේතය සහ එන්ජින් අතර පිහිටා ඇති තවත් එක් ආයතනයක් එක් කළ යුතුය - ප්රොක්සි.

RPC ප්‍රොක්සි

ප්‍රොක්සි සම්බන්ධක බස්, මුළු වෙබ් අඩවියම පාහේ ධාවනය වන. ඒ සමගම අපට තිබේ සේවා සොයාගැනීමක් නැත — ඒ වෙනුවට, මෙම ප්‍රොක්සි සඳහා වින්‍යාසයක් ඇත, එය මෙම පොකුරේ සියලුම පොකුරු සහ සියලුම කොටස්වල පිහිටීම දනී. මේක ඇඩ්මින්ලා කරන්නේ.

ක්‍රමලේඛකයින් කොපමණ, කොතැනක සහ කොපමණ මුදලක් වැය වේද යන්න ගැන කිසිසේත් තැකීමක් නොකරයි - ඔවුන් යන්නේ පොකුරට ය. මෙය අපට බොහෝ දේ ඉඩ සලසයි. ඉල්ලීමක් ලැබෙන විට, ප්‍රොක්සි විසින් ඉල්ලීම යළි හරවා යවයි, එය කොතැනදැයි දැන ගැනීම - එය එයම තීරණය කරයි.

මෙම අවස්ථාවෙහිදී, ප්‍රොක්සි යනු සේවා අසාර්ථකත්වයට එරෙහිව ආරක්ෂණ ලක්ෂ්‍යයකි. සමහර එන්ජිම මන්දගාමී වුවහොත් හෝ කඩා වැටුනහොත්, ප්‍රොක්සි මෙය තේරුම් ගෙන ඒ අනුව සේවාදායක පාර්ශවයට ප්‍රතිචාර දක්වයි. මෙය ඔබට කල් ඉකුත්වීම ඉවත් කිරීමට ඉඩ සලසයි - කේතය එන්ජිම ප්‍රතිචාර දැක්වීමට බලා නොසිටින නමුත් එය ක්‍රියා නොකරන බවත් කෙසේ හෝ වෙනස් ලෙස හැසිරීමට අවශ්‍ය බවත් තේරුම් ගනී. දත්ත සමුදායන් සැමවිටම ක්රියා නොකරන බව සඳහා කේතය සකස් කළ යුතුය.

විශේෂිත ක්රියාත්මක කිරීම්

සමහර විට අපට තවමත් එන්ජිමක් ලෙස යම් ආකාරයක සම්මත නොවන විසඳුමක් ලබා ගැනීමට අවශ්යයි. ඒ සමගම, අපගේ එන්ජින් සඳහා විශේෂයෙන් නිර්මාණය කරන ලද අපගේ සූදානම් කළ rpc-proxy භාවිතා නොකිරීමට තීරණය කරන ලදී, නමුත් කාර්යය සඳහා වෙනම ප්රොක්සියක් සෑදීමට.

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;

මෙය ද්විමය ප්‍රොටෝකෝලයකි, එහි ආසන්නතම ප්‍රතිසමය වේ protobuf. මෙම යෝජනා ක්‍රමය මඟින් විකල්ප ක්ෂේත්‍ර, සංකීර්ණ වර්ග - බිල්ට්-ඉන් ස්කේලර්වල දිගු කිරීම් සහ විමසුම් විස්තර කරයි. සෑම දෙයක්ම මෙම ප්රොටෝකෝලය අනුව ක්රියා කරයි.

RPC හරහා TL හරහා TCP/UDP... UDP?

TL යෝජනා ක්‍රමයට ඉහළින් ක්‍රියාත්මක වන එන්ජින් ඉල්ලීම් ක්‍රියාත්මක කිරීම සඳහා අපට RPC ප්‍රොටෝකෝලයක් ඇත. මේ සියල්ල TCP/UDP සම්බන්ධතාවයක් හරහා ක්‍රියා කරයි. TCP තේරුම් ගත හැකි නමුත්, අපට බොහෝ විට UDP අවශ්‍ය වන්නේ ඇයි?

UDP උදව් කරයි සේවාදායකයන් අතර සම්බන්ධතා විශාල සංඛ්‍යාවක ගැටළුව මඟහරවා ගන්න. සෑම සේවාදායකයකටම RPC ප්‍රොක්සියක් තිබේ නම් සහ සාමාන්‍යයෙන් එය ඕනෑම එන්ජිමකට යා හැකි නම්, එක් සේවාදායකයකට TCP සම්බන්ධතා දස දහස් ගණනක් ඇත. බඩුවක් තිබුනත් වැඩක් නෑ. UDP සම්බන්ධයෙන් මෙම ගැටළුව නොපවතී.

අනවශ්‍ය TCP අතට අත දීමක් නැත. මෙය සාමාන්‍ය ගැටළුවකි: නව එන්ජිමක් හෝ නව සේවාදායකයක් දියත් කරන විට, බොහෝ TCP සම්බන්ධතා එකවර ස්ථාපිත වේ. කුඩා සැහැල්ලු ඉල්ලීම් සඳහා, උදාහරණයක් ලෙස, UDP ගෙවීම, කේතය සහ එන්ජිම අතර සියලු සන්නිවේදනයන් වේ UDP පැකට් දෙකක්: එක් දිශාවකට පියාසර කරයි, දෙවැන්න අනෙක් දිශාවට ය. එක් වට සංචාරයක් - සහ කේතය අතට අත දීමකින් තොරව එන්ජිමෙන් ප්රතිචාරයක් ලැබිණි.

ඔව්, ඒ සියල්ල ක්‍රියාත්මක වේ පැකට් අලාභයේ ඉතා කුඩා ප්‍රතිශතයක් සමඟ. ප්‍රොටෝකෝලයට නැවත සම්ප්‍රේෂණය සහ කල් ඉකුත්වීම් සඳහා සහය ඇත, නමුත් අපට බොහෝ දේ අහිමි වුවහොත්, අපට පාහේ TCP ලැබෙනු ඇත, එය ලාභදායී නොවේ. අපි සාගර හරහා UDP ධාවනය කරන්නේ නැහැ.

අපට එවැනි සේවාදායකයන් දහස් ගණනක් ඇති අතර, යෝජනා ක්රමය සමාන වේ: එක් එක් භෞතික සේවාදායකය මත එන්ජින් පැකට්ටුවක් ස්ථාපනය කර ඇත. අවහිර කිරීමකින් තොරව හැකි ඉක්මනින් ධාවනය කිරීම සඳහා ඒවා බොහෝ විට තනි නූල් සහ තනි නූල් විසඳුම් ලෙස බෙදා ඇත. ඒ අතරම, මෙම එන්ජින් වලට වඩා විශ්වාසදායක කිසිවක් අප සතුව නොමැති අතර, නිරන්තර දත්ත ගබඩා කිරීම කෙරෙහි වැඩි අවධානයක් යොමු කෙරේ.

ස්ථිර දත්ත ගබඩා කිරීම

එන්ජින් බින්ලොග් ලියයි. බින්ලොග් යනු ගොනුවක් වන අතර එහි අවසානයේ තත්වයේ හෝ දත්තවල වෙනසක් සඳහා සිදුවීමක් එකතු කරනු ලැබේ. විවිධ විසඳුම් වලදී එය වෙනස් ලෙස හැඳින්වේ: ද්විමය ලොගය, වෝල්, AOF, නමුත් මූලධර්මය සමාන වේ.

නැවත ආරම්භ කරන විට එන්ජිම වසර ගණනාවක් මුළු බින්ලොග් නැවත කියවීම වැළැක්වීම සඳහා, එන්ජින් ලියයි snapshots - වත්මන් තත්ත්වය. අවශ්‍ය නම්, ඔවුන් මුලින්ම එයින් කියවයි, පසුව බින්ලොග් එකෙන් කියවා අවසන් කරයි. සියලුම බින්ලොග් එකම ද්විමය ආකෘතියෙන් ලියා ඇත - TL යෝජනා ක්‍රමයට අනුව, පරිපාලකයින්ට ඔවුන්ගේ මෙවලම් භාවිතයෙන් ඒවා සමානව පරිපාලනය කළ හැකිය. එවැනි ස්නැප්ෂොට් අවශ්‍ය නොවේ. කාගේ ස්නැප්ෂොට් එකද, එන්ජිමේ මැජික් එකද, කාටවත් වැදගත් නැති ශරීරයද යන සාමාන්‍ය ශීර්ෂයක් ඇත. මෙය ස්නැප්ෂොට් පටිගත කළ එන්ජිමේ ගැටලුවකි.

මම ඉක්මනින් ක්රියාත්මක කිරීමේ මූලධර්මය විස්තර කරමි. එන්ජිම ක්රියාත්මක වන සේවාදායකයක් ඇත. ඔහු ලිවීම සඳහා නව හිස් බින්ලොග් එකක් විවෘත කරන අතර එය වෙනස් කිරීම සඳහා සිදුවීමක් ලියයි.

යම් අවස්ථාවක දී, ඔහු තමා විසින්ම ඡායාරූපයක් ගැනීමට තීරණය කරයි, නැතහොත් ඔහුට සංඥාවක් ලැබේ. සේවාදායකය නව ගොනුවක් නිර්මාණය කරයි, එහි සම්පූර්ණ තත්ත්‍වය එයට ලියා, ගොනුවේ අවසානයට වත්මන් බින්ලොග් ප්‍රමාණය - ඕෆ්සෙට් - එකතු කර, තවදුරටත් ලිවීම දිගටම කරගෙන යයි. නව බින්ලොග් එකක් සාදනු නොලැබේ.

යම් අවස්ථාවක, එන්ජිම නැවත ආරම්භ කරන විට, තැටියේ බින්ලොග් සහ ස්නැප්ෂොට් යන දෙකම ඇත. එන්ජිම සම්පූර්ණ ස්නැප්ෂොට් එක කියවන අතර යම් අවස්ථාවක එහි තත්වය ඉහළ නංවයි.

ස්නැප්ෂොට් නිර්මාණය කරන අවස්ථාවේ තිබූ ස්ථානය සහ බින්ලොග් ප්‍රමාණය කියවයි.

වත්මන් තත්ත්වය ලබා ගැනීම සඳහා බින්ලොග් අවසානය කියවා වැඩිදුර සිදුවීම් ලිවීම දිගටම කරගෙන යයි. මෙය සරල යෝජනා ක්රමයකි; අපගේ සියලුම එන්ජින් ඒ අනුව ක්රියා කරයි.

දත්ත අනුකරණය

එහි ප්‍රතිඵලයක් වශයෙන්, අපගේ දත්ත පිටපත් කිරීම ප්රකාශය පදනම් කරගත් — අපි බින්ලොග් හි ලියන්නේ කිසිදු පිටුවක වෙනසක් නොව, එනම් ඉල්ලීම් වෙනස් කරන්න. ජාලය හරහා එන දේට බෙහෙවින් සමාන, සුළු වශයෙන් වෙනස් කර ඇත.

එකම යෝජනා ක්රමය අනුකරණය සඳහා පමණක් නොව, භාවිතා වේ උපස්ථ නිර්මාණය කිරීමට. අපට එන්ජිමක් ඇත - බින්ලොග් වෙත ලියන ලිවීමේ මාස්ටර්. පරිපාලකයින් එය සකසන වෙනත් ඕනෑම ස්ථානයක, මෙම බින්ලොග් පිටපත් කර ඇත, සහ එපමණයි - අපට උපස්ථයක් ඇත.

අවශ්ය නම් අනුරුව කියවීමCPU කියවීමේ බර අඩු කිරීම සඳහා, කියවීමේ එන්ජිම සරලව දියත් කරනු ලැබේ, එය බින්ලොග් අවසානය කියවන අතර මෙම විධානයන් දේශීයව ක්‍රියාත්මක කරයි.

මෙහි ප්‍රමාදය ඉතා කුඩා වන අතර, අනුරුව ස්වාමියාට වඩා කොපමණ පසුගාමී දැයි සොයා බැලිය හැකිය.

RPC ප්‍රොක්සියේ දත්ත බෙදා ගැනීම

බෙදා හැරීම ක්‍රියා කරන්නේ කෙසේද? ප්‍රොක්සිය තේරුම් ගන්නේ කුමන පොකුරු කැබැල්ලට යැවිය යුතුද? කේතය පවසන්නේ නැත: "15 කෑලි සඳහා යවන්න!" - නෑ, මේක කරන්නේ proxy එකෙන්.

සරලම යෝජනා ක්රමය වන්නේ firstint ය - ඉල්ලීමෙහි පළමු අංකය.

get(photo100_500) => 100 % N.

මෙය සරල memcached text protocol සඳහා උදාහරණයකි, නමුත්, ඇත්ත වශයෙන්ම, විමසුම් සංකීර්ණ සහ ව්‍යුහගත විය හැක. උදාහරණය විමසුමේ පළමු අංකය සහ පොකුරු ප්‍රමාණයෙන් බෙදූ විට ඉතිරිය ගනී.

අපට තනි ආයතනයක දත්ත ප්‍රදේශයක් ලබා ගැනීමට අවශ්‍ය වූ විට මෙය ප්‍රයෝජනවත් වේ. අපි කියමු 100 යනු පරිශීලක හෝ කණ්ඩායම් හැඳුනුම්පතක් වන අතර, අපට අවශ්‍ය වන්නේ සංකීර්ණ විමසුම් සඳහා එක් ආයතනයක සියලුම දත්ත එක කැබැල්ලක තිබීමයි.

ඉල්ලීම් පොකුර පුරා පැතිරෙන්නේ කෙසේද යන්න ගැන අපි තැකීමක් නොකරන්නේ නම්, තවත් විකල්පයක් ඇත - සම්පූර්ණ කොටස හෑෂ් කිරීම.

hash(photo100_500) => 3539886280 % N

හෑෂ්, කොට්ඨාශයේ ඉතිරිය සහ ෂාර්ඩ් අංකය ද අපට ලැබේ.

මෙම විකල්ප දෙකම ක්‍රියාත්මක වන්නේ අපි පොකුරේ ප්‍රමාණය වැඩි කරන විට, අපි එය බෙදීමට හෝ කිහිප ගුණයකින් වැඩි කිරීමට සූදානම් නම් පමණි. උදාහරණයක් ලෙස, අපට කැබලි 16 ක් තිබුණි, අපට ප්‍රමාණවත් නැත, අපට තවත් අවශ්‍ය වේ - අපට අක්‍රීය කාලයකින් තොරව 32 ක් ආරක්ෂිතව ලබා ගත හැකිය. අපට ගුණාකාරයන් නොව වැඩි කිරීමට අවශ්‍ය නම්, අක්‍රිය කාලයක් පවතිනු ඇත, මන්ද අපට පාඩු නොමැතිව සියල්ල නිවැරදිව බෙදීමට නොහැකි වනු ඇත. මෙම විකල්පයන් ප්රයෝජනවත් වේ, නමුත් සෑම විටම නොවේ.

අපට අත්තනෝමතික සේවාදායක සංඛ්‍යාවක් එකතු කිරීමට හෝ ඉවත් කිරීමට අවශ්‍ය නම්, අපි භාවිතා කරමු මුද්ද a la Ketama මත අඛණ්ඩව හෑෂ් කිරීම. නමුත් ඒ සමඟම, අපට දත්තවල ප්‍රදේශය සම්පූර්ණයෙන්ම නැති වී යයි; අපි ඉල්ලීම පොකුරට ඒකාබද්ධ කළ යුතු අතර එමඟින් සෑම කැබැල්ලක්ම එහි කුඩා ප්‍රතිචාරයක් ලබා දෙන අතර පසුව ප්‍රතිචාර ප්‍රොක්සියට ඒකාබද්ධ කළ යුතුය.

සුපිරි විශේෂිත ඉල්ලීම් තිබේ. එය පෙනෙන්නේ මෙයයි: RPC ප්‍රොක්සි ඉල්ලීම ලබා ගනී, කුමන පොකුරට යා යුතුද යන්න තීරණය කරයි සහ ෂාර්ඩ් තීරණය කරයි. එවිට එක්කෝ ලිවීමේ මාස්ටර් ඇත, නැතහොත්, පොකුරට අනුරූ ආධාරක තිබේ නම්, එය ඉල්ලුම මත අනුරුවකට යවයි. ප්‍රොක්සි තමයි මේ ඔක්කොම කරන්නේ.

සටහන්

අපි ක්‍රම කිහිපයකින් ලොග් ලියන්නෙමු. වඩාත්ම පැහැදිලි හා සරල එකකි memcache වෙත ලොග් ලියන්න.

ring-buffer: prefix.idx = line

ප්රධාන උපසර්ගයක් ඇත - ලොගයේ නම, රේඛාවක්, සහ මෙම ලොගයේ විශාලත්වය ඇත - පේළි ගණන. අපි අහඹු අංකයක් 0 සිට රේඛා ගණන 1 අඩු කරමු. memcache හි යතුර මෙම අහඹු අංකය සමඟ සංකලනය වූ උපසර්ගයකි. අපි ලොග් රේඛාව සහ වත්මන් කාලය අගයට සුරකිමු.

ලඝු-සටහන් කියවීමට අවශ්ය වූ විට, අපි සිදු කරන්නෙමු බහු ලබා ගැනීම සියලුම යතුරු, කාලය අනුව වර්ග කර, තත්‍ය කාලීනව නිෂ්පාදන ලොගයක් ලබා ගන්න. මෙම යෝජනා ක්‍රමය භාවිතා කරනුයේ ඔබට තථ්‍ය කාලීනව නිෂ්පාදනයේදී යමක් නිදොස් කිරීමට අවශ්‍ය වූ විට, කිසිවක් නොකැඩී, වෙනත් යන්ත්‍රවලට ගමනාගමනය නැවැත්වීමට හෝ ඉඩ නොදී, නමුත් මෙම ලොගය දිගු කල් පවතින්නේ නැත.

ලොග් වල විශ්වසනීය ගබඩා කිරීම සඳහා අපට එන්ජිමක් තිබේ logs-එන්ජිම. එය නිර්මාණය කර ඇති අතර එය විශාල පොකුරු ගණනක බහුලව භාවිතා වන්නේ එබැවිනි. මම දන්නා ලොකුම පොකුර 600 TB ඇසුරුම් කළ ලොග ගබඩා කරයි.

එන්ජිම ඉතා පැරණි ය, දැනටමත් අවුරුදු 6-7 ක් පැරණි පොකුරු ඇත. අපි විසඳීමට උත්සාහ කරන එහි ගැටළු තිබේ, උදාහරණයක් ලෙස, අපි ලොග් ගබඩා කිරීම සඳහා ClickHouse සක්‍රියව භාවිතා කිරීමට පටන් ගත්තෙමු.

ClickHouse හි ලොග් එකතු කිරීම

මෙම රූප සටහනෙන් පෙන්නුම් කරන්නේ අප අපගේ එන්ජින් තුළට ගමන් කරන ආකාරයයි.

දේශීයව RPC හරහා RPC-proxy වෙත යන කේතය ඇත, එය එන්ජිමට යා යුත්තේ කොතැනටද යන්න තේරුම් ගනී. අපට ClickHouse හි ලඝු-සටහන් ලිවීමට අවශ්‍ය නම්, අපි මෙම යෝජනා ක්‍රමයේ කොටස් දෙකක් වෙනස් කළ යුතුය:

• ක්ලික් හවුස් සමඟ එන්ජිමක් ප්‍රතිස්ථාපනය කරන්න;
• ClickHouse වෙත ප්‍රවේශ විය නොහැකි RPC ප්‍රොක්සිය වෙනුවට RPC හරහා කළ හැකි යම් විසඳුමක් සමඟ ප්‍රතිස්ථාපනය කරන්න.

එන්ජිම සරලයි - අපි එය ක්ලික්හවුස් සමඟ සේවාදායකයක් හෝ සේවාදායක පොකුරක් සමඟ ප්රතිස්ථාපනය කරමු.

ක්ලික්හවුස් වෙත යාමට, අපි කළෙමු කිටන් හවුස්. අපි KittenHouse සිට ClickHouse වෙත කෙලින්ම ගියහොත්, එයට මුහුණ නොදෙනු ඇත. ඉල්ලීම් නොමැතිව වුවද, එය විශාල යන්ත්‍ර ගණනක HTTP සම්බන්ධතා වලින් එකතු වේ. යෝජනා ක්‍රමය ක්‍රියා කිරීම සඳහා, ClickHouse සහිත සේවාදායකයක දේශීය ප්‍රතිලෝම ප්‍රොක්සිය ඉහළ නංවා ඇත, අවශ්ය වන සම්බන්ධතා පරිමාවන්ට ඔරොත්තු දිය හැකි ආකාරයෙන් ලියා ඇත. එයට සාපේක්ෂ විශ්වාසනීය ලෙස තමන් තුළම දත්ත බෆර් කළ හැක.

සමහර විට අපට RPC යෝජනා ක්‍රමය සම්මත නොවන විසඳුම්වල ක්‍රියාත්මක කිරීමට අවශ්‍ය නැත, උදාහරණයක් ලෙස, nginx හි. එබැවින් UDP හරහා ලොග් ලබා ගැනීමේ හැකියාව KittenHouse හට ඇත.

ලොග යවන්නා සහ ලබන්නා එකම යන්ත්‍රයක වැඩ කරන්නේ නම්, දේශීය ධාරකය තුළ UDP පැකට්ටුවක් අහිමි වීමේ සම්භාවිතාව තරමක් අඩුය. තෙවන පාර්ශවීය විසඳුමක් සහ විශ්වසනීයත්වය තුළ RPC ක්‍රියාත්මක කිරීමේ අවශ්‍යතාවය අතර සම්මුතියක් ලෙස, අපි හුදෙක් UDP යැවීම භාවිතා කරමු. අපි පසුව මෙම යෝජනා ක්රමය වෙත ආපසු යන්නෙමු.

අධීක්ෂණය

අපට ලොග් වර්ග දෙකක් තිබේ: පරිපාලකයින් විසින් ඔවුන්ගේ සේවාදායකයන් විසින් එකතු කරන ලද ඒවා සහ සංවර්ධකයින් විසින් කේතයෙන් ලියා ඇති ඒවා. ඒවා ප්‍රමිතික වර්ග දෙකකට අනුරූප වේ: පද්ධතිය සහ නිෂ්පාදනය.

පද්ධති මිනුම්

එය අපගේ සියලුම සේවාදායකයන් මත ක්‍රියා කරයි නෙට්ඩේටා, සංඛ්‍යාලේඛන එකතු කර ඒවා යවයි ග්රැෆයිට් කාබන්. එබැවින්, ClickHouse ගබඩා පද්ධතියක් ලෙස භාවිතා කරයි, උදාහරණයක් ලෙස Whisper නොවේ. අවශ්‍ය නම්, ඔබට 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 වෙතඇතුළත් කිරීම් සංඛ්යාව අඩු කිරීමට. කෙටි කාලයකට වරක් දේශීයව දියත් කරන ලදී stats-daemon සියලුම වාර්තා එකතු කරයි. මීළඟට, යක්ෂයා ප්‍රමිතික සේවාදායක ස්ථර දෙකකට ඒකාබද්ධ කරයි ලඝු-එකතු කරන්නන්, අපගේ යන්ත්‍ර පොකුරකින් සංඛ්‍යාලේඛන එකතු කරන අතර එමඟින් ඒවායේ පිටුපස ඇති තට්ටුව මිය නොයයි.

අවශ්ය නම්, අපට ලොග් එකතු කරන්නන් වෙත කෙලින්ම ලිවිය හැකිය.

නමුත් කේතයෙන් කෙලින්ම එකතුකරන්නන් වෙත ලිවීම, stas-daemom මගහැරීම, එකතුකරන්නා මත බර වැඩි කරන නිසා දුර්වල පරිමාණය කළ හැකි විසඳුමකි. විසඳුම සුදුසු වන්නේ කිසියම් හේතුවක් නිසා අපට memcache stats-daemon යන්ත්‍රයේ ඉහළ නැංවිය නොහැකි නම් හෝ එය කඩා වැටී අපි කෙලින්ම ගියහොත් පමණි.

ඊළඟට, ලඝු-එකතු කරන්නන් සංඛ්‍යාලේඛන ඒකාබද්ධ කරයි meowDB - මෙය අපගේ දත්ත ගබඩාව වන අතර, ප්‍රමිතික ද ගබඩා කළ හැක.

එවිට අපට කේතයෙන් ද්විමය “SQL ආසන්න” තේරීම් කළ හැකිය.

අත්හදා බැලීම

2018 ගිම්හානයේදී, අපට අභ්‍යන්තර හැකතන් එකක් තිබූ අතර, රූප සටහනේ රතු කොටස ක්ලික්හවුස් හි ප්‍රමිතික ගබඩා කළ හැකි යමක් සමඟ ප්‍රතිස්ථාපනය කිරීමට උත්සාහ කිරීමට අදහස පැමිණියේය. අපට ClickHouse හි ලොග තිබේ - එය උත්සාහ නොකරන්නේ මන්ද?

අපිට KittenHouse හරහා ලඝු-සටහන් ලියන යෝජනා ක්‍රමයක් තිබුණා.

අපි තීරණය කලා රූප සටහනට තවත් "* නිවසක්" එක් කරන්න, එය අපගේ කේතය UDP හරහා ලියන බැවින් ආකෘතියේ ඇති ප්‍රමිතික හරියටම ලැබෙනු ඇත. එවිට මෙම *හවුස් ඒවා ලොග් වැනි ඇතුළු කිරීම් බවට පත් කරයි, එය KittenHouse තේරුම් ගනී. ඔහුට මෙම ලඝු-සටහන් ක්ලික්හවුස් වෙත පරිපූර්ණව ලබා දිය හැකි අතර, ඒවා කියවීමට හැකි වේ.

memcache, stats-daemon සහ logs-collectors දත්ත සමුදාය සහිත යෝජනා ක්‍රමය මෙය සමඟ ප්‍රතිස්ථාපනය වේ.

memcache, stats-daemon සහ logs-collectors දත්ත සමුදාය සහිත යෝජනා ක්‍රමය මෙය සමඟ ප්‍රතිස්ථාපනය වේ.

• මෙහි කේතයෙන් යැවීමක් ඇත, එය StatsHouse හි දේශීයව ලියා ඇත.
• StatsHouse විසින් UDP ප්‍රමිතික, දැනටමත් SQL ඇතුළු කිරීම් බවට පරිවර්තනය කර, කණ්ඩායම් වශයෙන් KittenHouse වෙත ලියයි.
• KittenHouse ඒවා ClickHouse වෙත යවයි.
• අපට ඒවා කියවීමට අවශ්‍ය නම්, අපි ඒවා StatsHouse මඟහැර කියවමු - සාමාන්‍ය SQL භාවිතයෙන් ClickHouse වෙතින් කෙලින්ම.

එය තවමත් අත්හදා බැලීම, නමුත් අපි එය හැරෙන ආකාරය කැමතියි. අපි යෝජනා ක්රමය සමඟ ඇති ගැටළු නිරාකරණය කරන්නේ නම්, සමහර විට අපි එය සම්පූර්ණයෙන්ම මාරු කරනු ඇත. පුද්ගලිකව, මම එසේ බලාපොරොත්තු වෙමි.

යෝජනා ක්රමය යකඩ ඉතිරි නොකරයි. අඩු සේවාදායකයන් අවශ්‍ය වේ, දේශීය සංඛ්‍යාලේඛන-ඩේමන් සහ ලොග්-එකතු කරන්නන් අවශ්‍ය නොවේ, නමුත් ClickHouse සඳහා වත්මන් යෝජනා ක්‍රමයේ ඇති ඒවාට වඩා විශාල සේවාදායකයක් අවශ්‍ය වේ. අඩු සේවාදායකයන් අවශ්‍ය වේ, නමුත් ඒවා වඩා මිල අධික හා වඩා බලවත් විය යුතුය.

යොදවන්න

පළමුව, අපි PHP යෙදවීම දෙස බලමු. අපි සංවර්ධනය වෙමින් පවතී යන්න: භාවිත GitLab и TeamCity යෙදවීම සඳහා. සංවර්ධන ශාඛා ප්‍රධාන ශාඛාවට ඒකාබද්ධ කරනු ලැබේ, පරීක්ෂණ සඳහා ප්‍රධානියාගෙන් ඒවා වේදිකාගත කිරීමට සහ වේදිකාගත කිරීමේ සිට නිෂ්පාදනයට ඒකාබද්ධ වේ.

යෙදවීමට පෙර, වත්මන් නිෂ්පාදන ශාඛාව සහ පෙර එක ගෙන ඇති අතර, ඒවා තුළ වෙනස් ගොනු සලකා බලනු ලැබේ - වෙනස්කම්: සාදන ලද, මකා දැමූ, වෙනස් කරන ලදී. මෙම වෙනස සටහන් කර ඇත්තේ විශේෂ කොපිෆාස්ට් එන්ජිමක බින්ලොග් තුළ වන අතර එමඟින් අපගේ සම්පූර්ණ සේවාදායක බලඇණියට වෙනස්කම් ඉක්මනින් ප්‍රතිවර්තනය කළ හැකිය. මෙහි භාවිතා වන්නේ කෙලින්ම පිටපත් කිරීම නොව ඕපාදූප අනුකරණය, එක් සේවාදායකයක් එහි සමීපතම අසල්වැසියන්ට වෙනස්කම් යවන විට, ඒවා ඔවුන්ගේ අසල්වැසියන්ට යනාදිය. මෙමගින් ඔබට මුළු ඇණිය පුරාම තත්පර දහයකින් සහ ඒකක වලින් කේතය යාවත්කාලීන කිරීමට ඉඩ සලසයි. වෙනස දේශීය අනුරුවට ළඟා වූ විට, එය මෙම පැච් එහි යොදවයි දේශීය ගොනු පද්ධතිය. ආපසු හැරවීම ද එම යෝජනා ක්රමයට අනුව සිදු කෙරේ.

අපි kPHP ද බොහෝ සෙයින් යොදවන අතර එයට එහිම සංවර්ධනයක් ද ඇත යන්න ඉහත රූප සටහනට අනුව. මෙතැන් සිට HTTP සේවාදායක ද්විමය, එවිට අපට diff නිපදවිය නොහැක - මුදා හැරීමේ ද්විමය MB සිය ගණනක් බරයි. එබැවින්, මෙහි තවත් විකල්පයක් ඇත - අනුවාදය ලියා ඇත binlog copyfast. සෑම ගොඩනැගීමක් සමඟම එය වැඩි වන අතර ආපසු හැරීමේදී එය ද වැඩි වේ. පිටපත සේවාදායකයන්ට අනුවර්තනය කරන ලදී. දේශීය කොපිෆාස්ට් විසින් බින්ලොගයට නව අනුවාදයක් ඇතුළු වී ඇති බව දකින අතර, එම ඕපාදූප අනුකරණයෙන් ඔවුන් අපගේ ප්‍රධාන සේවාදායකය වෙහෙසට පත් නොකර, නමුත් ප්‍රවේශමෙන් ජාලය පුරා බර පතුරුවා හරිමින් ද්විමයයේ නවතම අනුවාදය ලබා ගනී. පහත සඳහන් දේ අලංකාර නැවත දියත් කිරීම නව අනුවාදය සඳහා.

අත්‍යවශ්‍යයෙන්ම ද්විමය වන අපගේ එන්ජින් සඳහා, යෝජනා ක්‍රමය බෙහෙවින් සමාන ය:

• git මාස්ටර් ශාඛාව;
• ද්විමය තුළ ඩී;
• අනුවාදය ලියා ඇත්තේ binlog copyfast සඳහා ය;
• සේවාදායකයන්ට අනුවර්තනය කරන ලදී;
• සේවාදායකය නැවුම් .dep එකක් ඇද දමයි;
• dpkg -i;
• නව අනුවාදයට අලංකාර ලෙස නැවත දියත් කිරීම.

වෙනස වන්නේ අපගේ ද්විමය ලේඛනාගාරයේ ඇසුරුම් කර තිබීමයි ඩී, සහ ඔවුන් පිටතට පොම්ප කරන විට dpkg -i පද්ධතිය මත තබා ඇත. kPHP ද්විමය ලෙස යොදවන්නේ ඇයි, සහ එන්ජින් dpkg ලෙස යොදවන්නේ ඇයි? ඒක එහෙම වුණා. එය ක්රියා කරයි - එය ස්පර්ශ නොකරන්න.

ප්‍රයෝජනවත් සබැඳි:

• වාර්තාව Anton Kiryushkin විසිනි "Vkontakte පද්ධති පරිපාලක. කෙසේද?" Copyfast සහ gossip ගැන විස්තර සහිතව.
• වාර්තාව Yuri Nasretdinov විසිනි "VK විසින් CLickHouse වෙත දස දහස් ගණනක සේවාදායකයන්ගෙන් දත්ත ඇතුල් කරන ආකාරය".
• මගේ වාර්තාව "VKontakte හි උදාහරණය භාවිතා කරමින් වර්ධනය වන ව්යාපෘතියක ගෘහ නිර්මාණ ශිල්පය", නමුත් සංවර්ධන දෘෂ්ටි කෝණයෙන්, දෘඪාංග නොවේ.

Alexey Akulovich යනු වැඩසටහන් කමිටුවේ කොටසක් ලෙස උපකාර කරන අයගෙන් කෙනෙකි PHP රුසියාව මැයි 17 වෙනිදා PHP සංවර්ධකයින් සඳහා මෑත කාලයේ විශාලතම සිදුවීම බවට පත්වනු ඇත. බලන්න අපිට මොනතරම් සිසිල් පරිගණකයක්ද, මොකක්ද කියලා කථිකයන් (ඒවායින් දෙකක් PHP හරය සංවර්ධනය වෙමින් පවතී!) - ඔබ PHP ලියන්නේ නම් ඔබට මග හැරිය නොහැකි දෙයක් ලෙස පෙනේ.

මූලාශ්රය: www.habr.com