በ VKontakte ሥነ ሕንፃ እና ሥራ ላይ የሚጠየቁ ጥያቄዎች

የ VKontakte አፈጣጠር ታሪክ በዊኪፔዲያ ላይ ነው ፣ እሱ የተናገረው በፓቬል ራሱ ነው። ሁሉም ሰው አስቀድሞ የሚያውቃት ይመስላል። በHighLoad++ Pavel ላይ ስላለው የጣቢያው ውስጣዊ ነገሮች፣ አርክቴክቸር እና መዋቅር በ2010 መለሰልኝ. ከዚያን ጊዜ ጀምሮ ብዙ ሰርቨሮች ሾልከው ወጥተዋል፣ስለዚህ መረጃውን እናዘምነዋለን፡ እንገነጣዋለን፣ ውስጡን አውጥተነዋል፣ እንመዝነዋለን እና የቪኬ መሳሪያውን ከቴክኒካል እይታ አንፃር እንመለከታለን።

አሌክሲ አኩሎቪች (AterCattus) በ VKontakte ቡድን ውስጥ የኋላ ገንቢ። የዚህ ዘገባ ግልባጭ ስለ መድረክ አሠራር፣ መሠረተ ልማት፣ አገልጋዮች እና በመካከላቸው ስላለው መስተጋብር በተደጋጋሚ ለሚነሱ ጥያቄዎች የጋራ መልስ ነው፣ ነገር ግን ስለ ልማት አይደለም፣ ማለትም ስለ ብረት. በተናጥል ፣ ስለ ዳታቤዝ እና በምትኩ VK ስላለው ፣ ስለ ምዝግብ ማስታወሻዎች መሰብሰብ እና አጠቃላይ ፕሮጀክቱን ስለመቆጣጠር። በቆርጡ ስር ዝርዝሮች.

ከአራት አመታት በላይ ከጀርባው ጋር የተያያዙ ሁሉንም አይነት ስራዎችን እሰራ ነበር.

• በመስቀል ላይ፣ በማከማቸት፣ በማስኬድ፣ ሚዲያ ማሰራጨት፡ ቪዲዮ፣ የቀጥታ ስርጭት፣ ኦዲዮ፣ ፎቶዎች፣ ሰነዶች።
• መሠረተ ልማት፣ መድረክ፣ የገንቢ ክትትል፣ ምዝግብ ማስታወሻዎች፣ የክልል መሸጎጫዎች፣ ሲዲኤን፣ የባለቤትነት RPC ፕሮቶኮል።
• ከውጭ አገልግሎቶች ጋር ውህደት፡ የግፋ ማሳወቂያዎች፣ የውጪ ማገናኛ መተንተን፣ RSS ምግብ።
• የስራ ባልደረቦችን በተለያዩ ጥያቄዎች መርዳት፣ መልሱ ወደማይታወቅ ኮድ ዘልቆ መግባትን ይጠይቃል።

በዚህ ጊዜ, በጣቢያው ብዙ ክፍሎች ውስጥ እጄ ነበር. ይህንን ተሞክሮ ማካፈል እፈልጋለሁ።

አጠቃላይ አርክቴክቸር

ሁሉም ነገር እንደተለመደው ጥያቄዎችን በሚቀበል አገልጋይ ወይም ቡድን ይጀምራል።

የፊት አገልጋይ

የፊት አገልጋይ በ HTTPS፣ RTMP እና WSS በኩል ጥያቄዎችን ይቀበላል።

ኤችቲቲፒኤስ - እነዚህ ለጣቢያው ዋና እና የሞባይል ድር ስሪቶች ጥያቄዎች vk.com እና m.vk.com እና ሌሎች የእኛ ኤፒአይ ኦፊሴላዊ እና መደበኛ ያልሆኑ ደንበኞች የሞባይል ደንበኞች ፣ መልእክተኞች ናቸው። አቀባበል አለን። አር.ኤም.ፒ.ፒ.-ትራፊክ ለቀጥታ ስርጭቶች በተለየ የፊት አገልጋዮች እና WSS- ለዥረት ኤፒአይ ግንኙነቶች።

ለ HTTPS እና WSS በአገልጋዮች ላይ ዋጋ ያለው ነው። ሲንክስ. ለ RTMP ስርጭቶች፣ በቅርቡ ወደ የራሳችን መፍትሄ ቀይረናል። ኪቭነገር ግን ከሪፖርቱ ወሰን በላይ ነው። ለስህተት መቻቻል እነዚህ አገልጋዮች የተለመዱ የአይፒ አድራሻዎችን ያስተዋውቃሉ እና በቡድን ሆነው ይሠራሉ ስለዚህም በአንዱ አገልጋይ ላይ ችግር ካለ የተጠቃሚ ጥያቄዎች አይጠፉም. ለኤችቲቲፒኤስ እና ደብሊውኤስኤስ፣ እነዚሁ አገልጋዮች የሲፒዩ ጭነትን በራሳቸው ላይ ለመውሰድ ትራፊክን ያመሳስሉ።

ስለ WSS እና RTMP ተጨማሪ አንናገርም ነገር ግን ስለ መደበኛ HTTPS ጥያቄዎች ብቻ ነው፣ ይህም አብዛኛውን ጊዜ ከድር ፕሮጀክት ጋር ስለሚገናኙ።

ደጀን

ከፊት በስተጀርባ ብዙውን ጊዜ የኋላ አገልጋዮች አሉ። የፊት አገልጋይ ከደንበኞች የሚቀበላቸውን ጥያቄዎች ያዘጋጃሉ።

ይህ kPHP አገልጋዮችኤችቲቲፒ ዴሞን የሚሰራበት፣ ኤችቲቲፒኤስ አስቀድሞ ስለተፈታ ነው። kPHP የሚሰራ አገልጋይ ነው። prefork ሞዴሎች: የማስተር ሂደት ይጀምራል፣ ብዙ የልጅ ሂደቶች፣ የማዳመጥ ሶኬቶችን ያስተላልፋል እና ጥያቄያቸውን ያስተናግዳሉ። በዚህ ሁኔታ ሂደቶች ከተጠቃሚው በእያንዳንዱ ጥያቄ መካከል እንደገና አይጀመሩም ፣ ግን በቀላሉ ግዛታቸውን ወደ መጀመሪያው የዜሮ እሴት ሁኔታ እንደገና ያስጀምሩ - ከጥያቄ በኋላ ፣ እንደገና ከመጀመር ይልቅ።

የጭነት ስርጭት

ሁሉም ደጋፊዎቻችን ማንኛውንም ጥያቄ ማስተናገድ የሚችሉ ትልቅ ማሽኖች አይደሉም። እኛ እነሱ ወደ ተለያዩ ቡድኖች ተከፋፍሏል: አጠቃላይ፣ ሞባይል፣ ኤፒአይ፣ ቪዲዮ፣ ስቴጅንግ... በተለየ የማሽን ቡድን ላይ ያለው ችግር ሁሉንም አይነካም። በቪዲዮ ላይ ችግር በሚፈጠርበት ጊዜ ሙዚቃን የሚያዳምጥ ተጠቃሚ ስለ ችግሮቹ እንኳን አያውቅም. ጥያቄውን ለመላክ የትኛው ጀርባ በ ውቅሩ መሠረት ከፊት ለፊት ባለው nginx ይወሰናል.

ሜትሪክ መሰብሰብ እና ማመጣጠን

በእያንዳንዱ ቡድን ውስጥ ምን ያህል መኪኖች ሊኖረን እንደሚገባ ለመረዳት, እኛ በ QPS ላይ አይታመኑ. የኋላ ጀርባዎች የተለያዩ ናቸው፣ የተለያዩ ጥያቄዎች አሏቸው፣ እያንዳንዱ ጥያቄ QPSን ለማስላት የተለየ ውስብስብነት አለው። ለዚህ ነው እኛ በአጠቃላይ በአገልጋዩ ላይ የጭነት ጽንሰ-ሀሳብ እንሰራለን - በሲፒዩ እና በ 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.

ፑ የፎቶ ሰቀላ ታሪካዊ ስም ነው፣ እና pp የፎቶ ፕሮክሲ ነው።. ማለትም አንዱ አገልጋይ ፎቶዎችን ለመስቀል ሲሆን ሌላው ደግሞ ለመስቀል ነው። አሁን ፎቶዎች ብቻ አይጫኑም, ግን ስሙ ተጠብቆ ቆይቷል.

እነዚህ አገልጋዮች የኤችቲቲፒኤስ ክፍለ ጊዜዎችን ያቋርጡየማቀነባበሪያውን ጭነት ከማከማቻው ውስጥ ለማስወገድ. እንዲሁም የተጠቃሚ ፋይሎች በእነዚህ አገልጋዮች ላይ ስለሚሠሩ፣ በእነዚህ ማሽኖች ላይ የተከማቸ ሚስጥራዊነት ያለው መረጃ በመኖሩ የተሻለ ይሆናል። ለምሳሌ፣ HTTPS ምስጠራ ቁልፎች።

ማሽኖቹ በሌሎች ማሽኖቻችን የተዘጉ ስለሆኑ “ነጭ” ውጫዊ አይፒዎችን ልንሰጣቸው አንችልም ፣ እና "ግራጫ" መስጠት. በዚህ መንገድ በአይፒ ገንዳ ላይ የተቀመጥን እና ማሽኖቹን ከውጭ መዳረሻ ለመጠበቅ ዋስትና ሰጥተናል - በቀላሉ ወደ እሱ ለመግባት ምንም አይፒ የለም።

በተጋሩ አይፒዎች ላይ የመቋቋም ችሎታ. ከስህተት መቻቻል አንፃር ፣ መርሃግብሩ ተመሳሳይ ነው የሚሰራው - ብዙ አካላዊ አገልጋዮች አንድ የተለመደ አካላዊ አይፒ አላቸው ፣ እና ከፊታቸው ያለው ሃርድዌር ጥያቄውን የት እንደሚልክ ይመርጣል። ስለ ሌሎች አማራጮች በኋላ እናገራለሁ.

አወዛጋቢው ነጥብ በዚህ ጉዳይ ላይ ነው ደንበኛው ያነሱ ግንኙነቶችን ይይዛል. ለብዙ ማሽኖች አንድ አይነት አይፒ ካለ - ከተመሳሳይ አስተናጋጅ ጋር: pu.vk.com ወይም pp.vk.com, የደንበኛው አሳሽ ለአንድ አስተናጋጅ በአንድ ጊዜ የሚቀርቡ ጥያቄዎች ላይ ገደብ አለው. ግን በሁሉም ቦታ በኤችቲቲፒ/2 ጊዜ፣ ይህ ከአሁን በኋላ አግባብነት የለውም ብዬ አምናለሁ።

የመርሃግብሩ ግልጽ ኪሳራ የግድ መሆን አለበት ሁሉንም ትራፊክ ያፈስሱ, ወደ ማከማቻው የሚሄደው, በሌላ አገልጋይ በኩል. ትራፊክን በማሽን ውስጥ ስለምናፈስስ፣ ተመሳሳይ እቅድ በመጠቀም ከባድ ትራፊክን ለምሳሌ፣ ቪዲዮን ገና ማንሳት አንችልም። እኛ በቀጥታ እናስተላልፋለን - ለተለየ ማከማቻዎች በተለይ ለቪዲዮ የተለየ ቀጥተኛ ግንኙነት። ቀለል ያለ ይዘትን በፕሮክሲ በኩል እናስተላልፋለን።

ብዙም ሳይቆይ የተሻሻለ የተኪ ስሪት አግኝተናል። አሁን ከተራዎች እንዴት እንደሚለያዩ እና ለምን አስፈላጊ እንደሆነ እነግርዎታለሁ.

ጸሐይ

በሴፕቴምበር 2017 ኦራክል ቀደም ሲል ፀሐይን የገዛው እጅግ በጣም ብዙ የፀሃይ ሰራተኞችን አባረረ. በዚህ ጊዜ ኩባንያው መኖር አቆመ ማለት እንችላለን. ለአዲሱ ስርዓት ስም በሚመርጡበት ጊዜ አስተዳዳሪዎቻችን ለዚህ ኩባንያ ማህደረ ትውስታ ግብር ለመክፈል ወሰኑ እና አዲሱን ስርዓት ፀሐይ ብለው ሰየሙት። ከራሳችን መካከል በቀላሉ "ፀሐይ" ብለን እንጠራታለን.

pp ጥቂት ችግሮች ነበሩት። አንድ አይፒ በቡድን - ውጤታማ ያልሆነ መሸጎጫ. ብዙ አካላዊ አገልጋዮች አንድ የጋራ አይፒ አድራሻ ይጋራሉ፣ እና ጥያቄው ወደ የትኛው አገልጋይ እንደሚሄድ ለመቆጣጠር ምንም መንገድ የለም። ስለዚህ, የተለያዩ ተጠቃሚዎች ለተመሳሳይ ፋይል ከመጡ, በእነዚህ አገልጋዮች ላይ መሸጎጫ ካለ, ፋይሉ በእያንዳንዱ አገልጋይ መሸጎጫ ውስጥ ያበቃል. ይህ በጣም ውጤታማ ያልሆነ እቅድ ነው, ነገር ግን ምንም ማድረግ አይቻልም.

በዚህም ምክንያት - ይዘትን መከፋፈል አንችልም።ለዚህ ቡድን የተለየ አገልጋይ መምረጥ ስለማንችል - የጋራ አይፒ አላቸው። እንዲሁም በአንዳንድ ውስጣዊ ምክንያቶች አሉን። በክልሎች ውስጥ እንደዚህ ያሉ አገልጋዮችን መጫን አልተቻለም. በሴንት ፒተርስበርግ ብቻ ቆሙ.

ከፀሐይ ጋር, የምርጫ ስርዓቱን ቀይረናል. አሁን አለን። anycast Routing: ተለዋዋጭ ማዘዋወር, anycast, ራስን ማረጋገጥ ዴሞን. እያንዳንዱ አገልጋይ የራሱ የሆነ አይፒ አለው ፣ ግን አንድ የተለመደ ንዑስ መረብ። ሁሉም ነገር የሚዋቀረው አንድ አገልጋይ ካልተሳካ ትራፊኩ በሌሎቹ የአንድ ቡድን አገልጋዮች ላይ እንዲሰራጭ ነው። አሁን አንድ የተወሰነ አገልጋይ መምረጥ ይቻላል. ተደጋጋሚ መሸጎጫ የለም።, እና አስተማማኝነት አልተጎዳም.

የክብደት ድጋፍ. አሁን እንደ አስፈላጊነቱ የተለያየ ኃይል ያላቸው ማሽኖችን መጫን እንችላለን, እና እንዲሁም, ጊዜያዊ ችግሮች ሲከሰቱ, የሚሠሩትን "ፀሐይ" ክብደትን በመቀየር በእነሱ ላይ ያለውን ጭነት ለመቀነስ, "ያርፉ" እና እንደገና መስራት ይጀምራሉ.

በይዘት መታወቂያ ማጋራት።. ስለ ሻርዲንግ አንድ አስቂኝ ነገር፡ ብዙ ጊዜ ይዘቶችን እንሰርዳለን የተለያዩ ተጠቃሚዎች በተመሳሳይ “ፀሐይ” ወደ አንድ ፋይል እንዲሄዱ የጋራ መሸጎጫ እንዲኖራቸው።

በቅርቡ "Clover" መተግበሪያን ጀምረናል. ይህ በቀጥታ ስርጭት ውስጥ ያለ የመስመር ላይ ጥያቄ ነው፣ አስተናጋጁ ጥያቄዎችን ይጠይቃል እና ተጠቃሚዎች በቅጽበት መልስ ሲሰጡ አማራጮችን ይምረጡ። መተግበሪያው ተጠቃሚዎች መወያየት የሚችሉበት ውይይት አለው። በተመሳሳይ ጊዜ ከስርጭቱ ጋር መገናኘት ይችላል። ከ 100 ሺህ በላይ ሰዎች. ሁሉም ለሁሉም ተሳታፊዎች የሚላኩ መልዕክቶችን ይጽፋሉ, እና አምሳያ ከመልዕክቱ ጋር አብሮ ይመጣል. በአንድ "ፀሐይ" ውስጥ 100 ሺህ ሰዎች ለአንድ አምሳያ ቢመጡ አንዳንድ ጊዜ ከደመና በኋላ ይንከባለል ይሆናል.

ለተመሳሳይ ፋይል የሚነሱ ጥያቄዎችን ለመቋቋም፣ በክልሉ ውስጥ ባሉ ሁሉም “ፀሃይ” ላይ ፋይሎችን የሚያሰራጭ የሞኝ እቅድ የምንከፍተው ለተወሰነ የይዘት አይነት ነው።

ፀሐይ ከውስጥ

በ nginx ላይ የተገላቢጦሽ ፕሮክሲ፣ መሸጎጫ በ RAM ወይም በፈጣን ኦፕቴን/NVMe ዲስኮች ላይ። ለምሳሌ: http://sun4-2.userapi.com/c100500/path - በአራተኛው ክልል ውስጥ ወደሚገኘው የ "ፀሐይ" አገናኝ, ሁለተኛው የአገልጋይ ቡድን. በአገልጋይ 100500 ላይ በአካል ተኝቶ ያለውን የዱካ ፋይል ይዘጋል።

መሸጎጫ

በሥነ-ሕንጻ እቅዳችን ላይ አንድ ተጨማሪ መስቀለኛ መንገድ እንጨምራለን - መሸጎጫ አካባቢ።

ከዚህ በታች የአቀማመጥ ንድፍ ነው የክልል መሸጎጫዎችከእነዚህ ውስጥ 20 ያህሉ አሉ። እነዚህ መሸጎጫዎች እና "ፀሐይ" የሚገኙባቸው ቦታዎች ናቸው, ይህም ትራፊክን በራሳቸው መሸጎጥ ይችላሉ.

ይሄ የመልቲሚዲያ ይዘት መሸጎጫ ነው፤ ምንም የተጠቃሚ ውሂብ እዚህ አልተቀመጠም - ሙዚቃ፣ ቪዲዮ፣ ፎቶዎች ብቻ።

የተጠቃሚውን ክልል ለመወሰን እኛ በክልሎች የታወጁ የBGP አውታረ መረብ ቅድመ ቅጥያዎችን እንሰበስባለን።. ውድቀትን በተመለከተ፣ አይፒን በቅድመ-ቅጥያዎች ማግኘት ካልቻልን የጂኦአይፒ ዳታቤዝ መተንተን አለብን። ክልሉን በተጠቃሚው አይፒ እንወስናለን።. በኮዱ ውስጥ አንድ ወይም ከዚያ በላይ የተጠቃሚውን ክልሎች ማየት እንችላለን - እሱ በጂኦግራፊያዊ ቅርበት ያለው እነዚያን ነጥቦች።

ይህ የሚሠራው እንዴት ነው?

የፋይሎችን ተወዳጅነት በክልል እንቆጥራለን. ተጠቃሚው የሚገኝበት ብዙ የክልል መሸጎጫ እና የፋይል መለያ አለ - ይህንን ጥንድ እንወስዳለን እና በእያንዳንዱ ማውረድ ደረጃውን እንጨምራለን ።

በተመሳሳይ ጊዜ አጋንንት - በክልሎች ውስጥ ያሉ አገልግሎቶች - ከጊዜ ወደ ጊዜ ወደ ኤፒአይ ይመጣሉ እና እንዲህ ይበሉ: - “እኔ እንደዚህ ያለ እና እንደዚህ ያለ መሸጎጫ ነኝ ፣ በእኔ ላይ ገና ያልነበሩትን በክልሌ ውስጥ በጣም ተወዳጅ የሆኑ ፋይሎችን ዝርዝር ስጠኝ ። ” ኤፒአይ በደረጃ የተደረደሩ ብዙ ፋይሎችን ያቀርባል፣ ዳሞን ያወርዳቸዋል፣ ወደ ክልሎች ይወስዳቸዋል እና ፋይሎቹን ከዚያ ያደርሳቸዋል። ይህ በ pu/pp እና Sun መካከል ያለው መሠረታዊ ልዩነት ከመሸጎጫ ውስጥ ነው፡ ምንም እንኳን ይህ ፋይል በመሸጎጫው ውስጥ ባይኖርም ፋይሉን ወዲያውኑ በራሳቸው በኩል ይሰጣሉ እና መሸጎጫው መጀመሪያ ፋይሉን ወደ ራሱ አውርዶ ከዚያ መልሶ መስጠት ይጀምራል።

በዚህ ሁኔታ ውስጥ እናገኛለን ለተጠቃሚዎች የቀረበ ይዘት እና የአውታረ መረብ ጭነት መዘርጋት. ለምሳሌ, ከሞስኮ መሸጎጫ ብቻ ከ 1 Tbit / s በላይ በከፍተኛ ሰዓት እናሰራጫለን.

ግን ችግሮች አሉ- መሸጎጫ አገልጋዮች ጎማ አይደሉም. ለላቀ ታዋቂ ይዘት አንዳንድ ጊዜ ለተለየ አገልጋይ በቂ አውታረ መረብ የለም። የኛ መሸጎጫ ሰርቨሮች ከ40-50 Gbit/s ናቸው፣ ግን እንደዚህ አይነት ቻናልን ሙሉ በሙሉ የሚዘጋው ይዘት አለ። በክልሉ ውስጥ ከአንድ በላይ የታወቁ ፋይሎችን ማከማቻ ወደ ትግበራ እየሄድን ነው። በዓመቱ መጨረሻ ተግባራዊ እንደምናደርገው ተስፋ አደርጋለሁ።

አጠቃላይ አርክቴክቸርን ተመለከትን።

• ጥያቄዎችን የሚቀበሉ የፊት አገልጋዮች።
• የሚጠይቀውን ሂደት ይደግፋል።
• በሁለት ዓይነት ፕሮክሲዎች የተዘጉ ማከማቻዎች።
• የክልል መሸጎጫዎች.

ከዚህ ሥዕል ምን የጎደለው ነገር አለ? እርግጥ ነው, ውሂብ የምናከማችባቸው የውሂብ ጎታዎች.

የውሂብ ጎታዎች ወይም ሞተሮች

እኛ የምንጠራቸው የውሂብ ጎታ አይደለም ፣ ግን ሞተሮች - ሞተሮች ፣ ምክንያቱም በአጠቃላይ ተቀባይነት ባለው መልኩ የውሂብ ጎታዎች የሉንም።

ይህ አስፈላጊ መለኪያ ነው. ይህ የሆነበት ምክንያት በ 2008-2009, ቪኬ በታዋቂነት ፈንጂ እድገት ሲኖረው, ፕሮጀክቱ ሙሉ በሙሉ በ MySQL እና Memcache ላይ ሰርቷል እና ችግሮች ነበሩ. MySQL ፋይሎችን ማበላሸት እና ማበላሸት ይወድ ነበር፣ ከዚያ በኋላ አያገግምም፣ እና Memcache ቀስ በቀስ አፈፃፀሙን እያሽቆለቆለ እንደገና መጀመር ነበረበት።

ከጊዜ ወደ ጊዜ ታዋቂው ፕሮጀክት ውሂብን የሚያበላሽ ቋሚ ማከማቻ እና መሸጎጫ ያለው ሲሆን ይህም ፍጥነት ይቀንሳል። በእንደዚህ ዓይነት ሁኔታዎች ውስጥ እያደገ የሚሄድ ፕሮጀክት ማዘጋጀት አስቸጋሪ ነው. ፕሮጀክቱ በራሳችን ብስክሌቶች ላይ ያተኮረባቸውን ወሳኝ ነገሮች እንደገና ለመጻፍ ለመሞከር ተወስኗል.

መፍትሄው የተሳካ ነበር።. ይህንን ለማድረግ እድሉ ነበር, እንዲሁም እጅግ በጣም አስፈላጊ ነው, ምክንያቱም ሌሎች የማስዋቢያ መንገዶች በዚያን ጊዜ አልነበሩም. ብዙ የውሂብ ጎታዎች አልነበሩም፣ NoSQL እስካሁን የለም፣ MySQL፣ Memcache፣ PostrgreSQL ብቻ ነበሩ - እና ያ ነው።

ሁለንተናዊ አሠራር. ልማቱ የተመራው በእኛ ቡድን የC ገንቢዎች ሲሆን ሁሉም ነገር ወጥ በሆነ መልኩ ተከናውኗል። ሞተሩ ምንም ይሁን ምን፣ ሁሉም በግምት ተመሳሳይ የፋይል ፎርማት በዲስክ ላይ የተፃፈ፣ ተመሳሳይ የማስጀመሪያ ግቤቶች፣ በተመሳሳይ መንገድ የሚስተካከሉ ምልክቶች እና በዳርቻ ሁኔታዎች እና ችግሮች ውስጥ በግምት ተመሳሳይ ባህሪ ነበራቸው። በሞተሮች እድገት ፣ አስተዳዳሪዎች ስርዓቱን እንዲሰሩ ምቹ ናቸው - ምንም ዓይነት መካነ አራዊት የለም ፣ እናም እያንዳንዱን አዲስ የሶስተኛ ወገን የውሂብ ጎታ እንዴት እንደሚሰራ እንደገና መማር አለባቸው ፣ ይህም በፍጥነት እና ለመስራት አስችሏል ። በሚመች ሁኔታ ቁጥራቸውን ይጨምሩ.

የሞተር ዓይነቶች

ቡድኑ ጥቂት ሞተሮችን ጻፈ። ጥቂቶቹ እነኚሁና፡ ጓደኛ፣ ፍንጭ፣ ምስል፣ ipdb፣ ደብዳቤዎች፣ ዝርዝሮች፣ ምዝግብ ማስታወሻዎች፣ memcached፣ meowdb፣ ዜና፣ ኖስትራዳመስ፣ ፎቶ፣ አጫዋች ዝርዝሮች፣ pmemcached፣ ማጠሪያ፣ ፍለጋ፣ ማከማቻ፣ መውደዶች፣ ተግባሮች፣…

የተለየ የውሂብ መዋቅር ለሚፈልግ ለእያንዳንዱ ተግባር ወይም የተለመዱ ጥያቄዎችን፣ የC ቡድን አዲስ ሞተር ይጽፋል። ለምን አይሆንም.

የተለየ ሞተር አለን። memcached, እሱም ከመደበኛው ጋር ተመሳሳይ ነው, ነገር ግን ከጥሩ ነገሮች ስብስብ ጋር, እና የማይቀንስ. ClickHouse አይደለም፣ ግን ደግሞ ይሰራል። ለብቻው ይገኛል። pmemcached ነው የማያቋርጥ memcachedእንደገና በሚጀመርበት ጊዜ መረጃን ላለማጣት ፣ በተጨማሪም በ RAM ውስጥ ከሚገባው በላይ መረጃን በዲስክ ላይ ማከማቸት ይችላል። ለግለሰብ ተግባራት የተለያዩ ሞተሮች አሉ-ወረፋዎች ፣ ዝርዝሮች ፣ ስብስቦች - ፕሮጄክታችን የሚፈልገውን ሁሉ ።

ዘለላዎች

ከኮድ አንፃር፣ ሞተሮችን ወይም የውሂብ ጎታዎችን እንደ ሂደቶች፣ አካላት ወይም አጋጣሚዎች ማሰብ አያስፈልግም። ኮዱ በተለይ ከቡድኖች ፣ ከሞተሮች ጋር ይሰራል - በአንድ ክላስተር አንድ ዓይነት. የተከለለ ክላስተር አለ እንበል - ይህ የማሽን ስብስብ ነው።

ኮዱ አካላዊ አካባቢን፣ መጠንን ወይም የአገልጋዮችን ብዛት ማወቅ አያስፈልገውም። የተወሰነ መለያ በመጠቀም ወደ ክላስተር ይሄዳል።

ይህ እንዲሠራ በኮዱ እና በሞተሮች መካከል የሚገኝ አንድ ተጨማሪ አካል ማከል ያስፈልግዎታል - ተኪ.

የ RPC ተኪ

ተኪ ማገናኛ አውቶቡስ, ይህም ላይ ከሞላ ጎደል መላው ጣቢያ ይሰራል. በተመሳሳይ ጊዜ አለን ምንም የአገልግሎት ግኝት የለም - በምትኩ፣ የሁሉንም ስብስቦች እና የዚህ ክላስተር ሁሉንም ስብርባሪዎች መገኛ የሚያውቅ ለዚህ ፕሮክሲ ውቅር አለ። አስተዳዳሪዎች የሚያደርጉት ይህንን ነው።

ፕሮግራመሮች ምን ያህል፣ የት እና ምን እንደሚያስከፍሉ ግድ የላቸውም - ወደ ክላስተር ብቻ ይሄዳሉ። ይህ ብዙ ያስችለናል. ጥያቄን በሚቀበሉበት ጊዜ ተኪው ጥያቄውን ያዞራል, የት እንደሆነ ማወቅ - እሱ ራሱ ይወስናል.

በዚህ ሁኔታ ፕሮክሲ ከአገልግሎት ብልሽት የመከላከያ ነጥብ ነው። አንዳንድ ሞተሮች ከቀዘቀዙ ወይም ከተበላሹ ተኪው ይህንን ተረድቶ ለደንበኛው ጎን ምላሽ ይሰጣል። ይህ የጊዜ ማብቂያውን እንዲያስወግዱ ይፈቅድልዎታል - ኮዱ ሞተሩ ምላሽ እስኪሰጥ ድረስ አይጠብቅም, ነገር ግን እየሰራ እንዳልሆነ እና በሆነ መንገድ የተለየ ባህሪ ማሳየት እንዳለበት ይገነዘባል. የመረጃ ቋቶቹ ሁል ጊዜ የማይሰሩ ስለሆኑ ኮዱ መዘጋጀት አለበት።

የተወሰኑ ትግበራዎች

አንዳንድ ጊዜ አሁንም እንደ ሞተር መደበኛ ያልሆነ መፍትሄ አንዳንድ ዓይነት እንዲኖረን እንፈልጋለን። በተመሳሳይ ጊዜ, የእኛን ዝግጁ-ሰራሽ rpc-proxy, በተለይ ለሞተርዎቻችን የተፈጠረውን, ነገር ግን ለሥራው የተለየ ፕሮክሲ ለመሥራት ተወስኗል.

ለ MySQL ፣ አሁንም እዚህ እና እዚያ አለን ፣ db-proxy እንጠቀማለን ፣ እና ለ ClickHouse - ኪተን ሃውስ.

በአጠቃላይ እንደዚህ ይሰራል. የተወሰነ አገልጋይ አለ፣ kPHP፣ Go፣ Python ይሰራል - በአጠቃላይ፣ የእኛን RPC ፕሮቶኮል መጠቀም የሚችል ማንኛውም ኮድ። ኮዱ በአካባቢው የሚሰራው በ RPC ፕሮክሲ ላይ ነው - እያንዳንዱ ኮዱ የሚገኝበት አገልጋይ የራሱን አካባቢያዊ ፕሮክሲ ይሰራል። በተጠየቀ ጊዜ፣ ተኪው የት መሄድ እንዳለበት ይረዳል።

አንድ ሞተር ወደ ሌላ መሄድ ከፈለገ, ጎረቤት ቢሆንም, በፕሮክሲ በኩል ያልፋል, ምክንያቱም ጎረቤቱ በሌላ የመረጃ ማእከል ውስጥ ሊሆን ይችላል. ሞተሩ ከራሱ ሌላ ማንኛውንም ቦታ በማወቅ ላይ መተማመን የለበትም - ይህ የእኛ መደበኛ መፍትሄ ነው. ግን በእርግጥ ልዩ ሁኔታዎች አሉ :)

ሁሉም ሞተሮች የሚሰሩበት የ TL-scheme ምሳሌ።

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;

ይህ ሁለትዮሽ ፕሮቶኮል ነው, በጣም ቅርብ የሆነው አናሎግ ነው ፕሮቶቡፍ. መርሃግብሩ የአማራጭ መስኮችን ፣ ውስብስብ ዓይነቶችን - አብሮገነብ ስካላሮችን እና መጠይቆችን ይገልፃል። ሁሉም ነገር በዚህ ፕሮቶኮል መሰረት ይሰራል.

RPC በቲኤል ላይ በTCP/UDP… UDP?

በቲኤል እቅድ ላይ የሚሰሩ የሞተር ጥያቄዎችን ለማስፈጸም የ RPC ፕሮቶኮል አለን። ይሄ ሁሉም የሚሰራው በTCP/UDP ግንኙነት ነው። TCP ለመረዳት የሚቻል ነው, ግን ለምን UDP ብዙ ጊዜ ያስፈልገናል?

ዩዲፒ ይረዳል በአገልጋዮች መካከል ከፍተኛ ቁጥር ያላቸውን ግንኙነቶች ችግር ያስወግዱ. እያንዳንዱ አገልጋይ የ RPC ፕሮክሲ ካለው እና በአጠቃላይ ወደ ማንኛውም ሞተር ሊሄድ ይችላል፣ ከዚያ በአንድ አገልጋይ በአስር ሺዎች የሚቆጠሩ የ TCP ግንኙነቶች አሉ። ሸክም አለ, ግን ከንቱ ነው. በ UDP ሁኔታ ይህ ችግር የለም.

ምንም ተደጋጋሚ TCP የእጅ መጨባበጥ የለም።. ይህ የተለመደ ችግር ነው፡ አዲስ ሞተር ወይም አዲስ አገልጋይ ሲጀመር ብዙ የ TCP ግንኙነቶች በአንድ ጊዜ ይመሰረታሉ። ለአነስተኛ ቀላል ክብደት ጥያቄዎች፣ ለምሳሌ፣ UDP ክፍያ፣ በኮዱ እና በሞተሩ መካከል ያለው ግንኙነት ሁሉ ነው። ሁለት የ UDP ፓኬቶች; አንዱ በአንድ አቅጣጫ፣ ሁለተኛው በሌላኛው ይበርራል። አንድ ዙር ጉዞ - እና ኮድ ሳይጨበጥ ከኤንጂኑ ምላሽ አግኝቷል.

አዎ, ሁሉም ብቻ ይሰራል በጣም ትንሽ በሆነ የፓኬት ኪሳራ. ፕሮቶኮሉ ለድጋሚ ማስተላለፍ እና ጊዜ ማብቂያዎች ድጋፍ አለው, ነገር ግን ብዙ ከጠፋን, TCP ከሞላ ጎደል እናገኛለን, ይህ ጠቃሚ አይደለም. UDP በውቅያኖሶች ውስጥ አንነዳውም።

በሺዎች የሚቆጠሩ እንደዚህ ያሉ አገልጋዮች አሉን ፣ እና እቅዱ አንድ ነው በእያንዳንዱ አካላዊ አገልጋይ ላይ የሞተር ጥቅል ተጭኗል። ሳይታገዱ በተቻለ ፍጥነት ለመሮጥ በአብዛኛው ነጠላ-ክር ናቸው እና እንደ ነጠላ-ክር መፍትሄዎች የተቆራረጡ ናቸው. በተመሳሳይ ጊዜ, ከእነዚህ ሞተሮች የበለጠ አስተማማኝ ነገር የለንም, እና ለቀጣይ የውሂብ ማከማቻ ብዙ ትኩረት ተሰጥቷል.

የማያቋርጥ የውሂብ ማከማቻ

ሞተሮች ቢንሎግ ይጽፋሉ. ቢንሎግ በመጨረሻ በግዛት ወይም በመረጃ ላይ ለውጥ የሚመጣ ክስተት የሚጨመርበት ፋይል ነው። በተለያዩ መፍትሄዎች በተለየ መንገድ ይባላል-ሁለትዮሽ ሎግ, ወሌ, AOF, ግን መርሆው አንድ ነው.

እንደገና በሚነሳበት ጊዜ ኤንጂኑ ሙሉውን ቢንሎግ ለብዙ አመታት እንደገና እንዳያነብ ለመከላከል ሞተሮቹ ይጽፋሉ ቅጽበተ-ፎቶዎች - የአሁኑ ሁኔታ. አስፈላጊ ከሆነ መጀመሪያ ያነቡታል ከዚያም ከቢንሎግ ማንበብ ይጨርሳሉ። ሁሉም ቢንሎጎች የተፃፉት በተመሳሳይ ሁለትዮሽ ፎርማት ነው - በቲኤል እቅድ መሰረት አስተዳዳሪዎች መሳሪያቸውን ተጠቅመው በእኩልነት ያስተዳድሯቸው ዘንድ። ቅጽበታዊ ገጽ እይታዎች እንደዚህ አይነት አያስፈልግም። የማን ቅጽበታዊ ገጽ እይታ int, የሞተር አስማት እና የትኛው አካል ለማንም አስፈላጊ እንዳልሆነ የሚያመለክት አጠቃላይ ራስጌ አለ. ይህ ቅጽበተ-ፎቶውን በተመዘገበው ሞተር ላይ ያለው ችግር ነው.

የሥራውን መርህ በፍጥነት እገልጻለሁ. ሞተሩ የሚሰራበት አገልጋይ አለ። ለመጻፍ አዲስ ባዶ ቢንሎግ ከፍቶ ለለውጥ ክስተት ይጽፋል።

በአንድ ወቅት, እሱ ራሱ ፎቶ ለማንሳት ይወስናል, ወይም ምልክት ይቀበላል. አገልጋዩ አዲስ ፋይል ይፈጥራል፣ አጠቃላይ ሁኔታውን ይጽፋል፣ የአሁኑን የቢንሎግ መጠን - ማካካሻ - በፋይሉ መጨረሻ ላይ ጨምሯል እና የበለጠ መጻፉን ይቀጥላል። አዲስ ቢንሎግ አልተፈጠረም።

በአንድ ወቅት, ሞተሩ እንደገና ሲነሳ, በዲስክ ላይ ሁለቱም ቢንሎግ እና ቅጽበተ-ፎቶ ይኖራል. ሞተሩ ሙሉውን ቅጽበታዊ ገጽ እይታ ያነባል እና በተወሰነ ቦታ ላይ ያለውን ሁኔታ ያነሳል.

ቅጽበተ-ፎቶው በተፈጠረበት ጊዜ የነበረውን አቀማመጥ እና የቢንሎግ መጠን ያነባል።

የአሁኑን ሁኔታ ለማግኘት የቢንሎውን መጨረሻ ያነብባል እና ተጨማሪ ክስተቶችን መጻፉን ይቀጥላል። ይህ ቀላል እቅድ ነው, ሁሉም ሞተሮች በእሱ መሰረት ይሰራሉ.

የውሂብ ማባዛት

በውጤቱም, የውሂብ ማባዛት በእኛ መግለጫ ላይ የተመሠረተ - እኛ በቢንሎግ ውስጥ የምንጽፈው የትኛውንም የገጽ ለውጥ አይደለም ፣ ግን ማለትም ጥያቄዎችን ይቀይሩ. በአውታረ መረቡ ላይ ከሚመጣው ጋር በጣም ተመሳሳይ፣ በትንሹ የተሻሻለ።

ተመሳሳይ እቅድ ለማባዛት ብቻ ሳይሆን ጥቅም ላይ ይውላል ምትኬዎችን ለመፍጠር. ሞተር አለን - ወደ ቢንሎግ የሚጽፍ የጽሑፍ ማስተር። አስተዳዳሪዎች ባዘጋጁበት በማንኛውም ሌላ ቦታ ይህ ቢንሎግ ይገለበጣል፣ እና ያ ነው - ምትኬ አለን።

አስፈላጊ ከሆነ ቅጂ ማንበብየሲፒዩ ንባብ ጭነትን ለመቀነስ የንባብ ሞተሩ በቀላሉ ተጀምሯል፣ ይህም የቢንሎግ መጨረሻን ያነባል እና እነዚህን ትዕዛዞች በአካባቢው ያስፈጽማል።

እዚህ ያለው መዘግየት በጣም ትንሽ ነው, እና ቅጂው ከጌታው በስተጀርባ ምን ያህል እንደሚዘገይ ማወቅ ይቻላል.

በ RPC ፕሮክሲ ውስጥ የውሂብ መጋራት

ሻርዲንግ እንዴት ነው የሚሰራው? ተኪው ወደ የትኛው ክላስተር ሻርድ እንደሚልክ እንዴት ይረዳል? ኮዱ “ለ15 ሻርዶች ላክ!” አይልም። - አይ, ይህ የሚከናወነው በፕሮክሲው ነው.

በጣም ቀላሉ እቅድ የመጀመሪያ ደረጃ ነው - በጥያቄው ውስጥ የመጀመሪያው ቁጥር.

get(photo100_500) => 100 % N.

ይህ ለቀላል መሸጎጫ የጽሁፍ ፕሮቶኮል ምሳሌ ነው፣ ግን በእርግጥ፣ መጠይቆች ውስብስብ እና የተዋቀሩ ሊሆኑ ይችላሉ። ምሳሌው በጥያቄው ውስጥ የመጀመሪያውን ቁጥር እና ቀሪውን በክላስተር መጠን ሲካፈል ይወስዳል።

የአንድ ነጠላ አካል የውሂብ አካባቢ እንዲኖረን ስንፈልግ ይህ ጠቃሚ ነው። 100 የተጠቃሚ ወይም የቡድን መታወቂያ ነው እንበል፣ እና ሁሉም የአንድ አካል መረጃ ለተወሳሰቡ ጥያቄዎች በአንድ ሸርተቴ ላይ እንዲሆን እንፈልጋለን።

ጥያቄዎች በክላስተር ውስጥ እንዴት እንደሚተላለፉ ግድ የማይሰጠን ከሆነ ሌላ አማራጭ አለ - መላውን ስብርባሪ ማሸት.

hash(photo100_500) => 3539886280 % N

እንዲሁም ሃሽ, የተቀረው ክፍል እና የሻርድ ቁጥር እናገኛለን.

እነዚህ ሁለቱም አማራጮች የሚሠሩት የክላስተርን መጠን ስንጨምር ስንከፍለው ወይም ብዙ ጊዜ እንደምንጨምር ለመዘጋጀት ከተዘጋጀን ብቻ ነው። ለምሳሌ ፣ 16 ሻርዶች ነበሩን ፣ በቂ የለንም ፣ የበለጠ እንፈልጋለን - ያለማቋረጥ 32 ልንደርስ እንችላለን። ብዙ ያልሆኑትን ለመጨመር ከፈለግን, የእረፍት ጊዜ ይኖራል, ምክንያቱም ሁሉንም ነገር ያለምንም ኪሳራ በትክክል መከፋፈል ስለማንችል ነው. እነዚህ አማራጮች ጠቃሚ ናቸው, ግን ሁልጊዜ አይደለም.

የዘፈቀደ የአገልጋዮችን ቁጥር ማከል ወይም ማስወገድ ከፈለግን እንጠቀማለን። ቀለበቱ ላይ ያለማቋረጥ ሀሺንግ a la Ketama. ግን በተመሳሳይ ጊዜ የመረጃውን አካባቢያዊነት ሙሉ በሙሉ እናጣለን ፣ ጥያቄውን ወደ ክላስተር በማዋሃድ እያንዳንዱ ቁራጭ የራሱን ትንሽ ምላሽ እንዲመልስ እና ከዚያ ምላሾችን ወደ ፕሮክሲው ማዋሃድ አለብን።

እጅግ በጣም ልዩ የሆኑ ጥያቄዎች አሉ። ይህን ይመስላል፡ የ RPC ፕሮክሲ ጥያቄውን ተቀብሎ የትኛው ክላስተር መሄድ እንዳለበት ይወስናል እና ሸርተቴውን ይወስናል። ከዚያ ወይ የመጻፍ ጌቶች አሉ፣ ወይም፣ ክላስተር ቅጂ ድጋፍ ካለው፣ በፍላጎት ወደ ቅጂ ይልካል። ተኪው ይህንን ሁሉ ያደርጋል።

መዝገቦች

ምዝግብ ማስታወሻዎችን በተለያዩ መንገዶች እንጽፋለን. በጣም ግልጽ እና ቀላል የሆነው ምዝግብ ማስታወሻዎችን ወደ memcache ይጻፉ.

ring-buffer: prefix.idx = line

ቁልፍ ቅድመ ቅጥያ አለ - የምዝግብ ማስታወሻው ስም ፣ መስመር ፣ እና የዚህ ምዝግብ መጠን አለ - የመስመሮች ብዛት። የዘፈቀደ ቁጥርን ከ 0 ወደ የመስመሮች ቁጥር ስንቀነስ እንወስዳለን 1. በ memcache ውስጥ ያለው ቁልፍ ከዚህ የዘፈቀደ ቁጥር ጋር የተጣመረ ቅድመ ቅጥያ ነው። የምዝግብ ማስታወሻውን እና የአሁኑን ጊዜ ወደ እሴቱ እናስቀምጣለን።

ምዝግብ ማስታወሻዎችን ለማንበብ አስፈላጊ በሚሆንበት ጊዜ እንፈጽማለን Multi Get ሁሉም ቁልፎች፣ በጊዜ የተደረደሩ፣ እና በዚህም የምርት ምዝግብ ማስታወሻን በእውነተኛ ጊዜ ያግኙ። መርሃግብሩ ጥቅም ላይ የሚውለው በምርት ውስጥ የሆነን ነገር በእውነተኛ ጊዜ ማረም ሲፈልጉ ነው፣ ምንም ነገር ሳይሰበሩ፣ ሳይቆሙ ወይም ወደ ሌሎች ማሽኖች ትራፊክ ሳይፈቅዱ፣ ነገር ግን ይህ ምዝግብ ብዙ ጊዜ አይቆይም።

ለታማኝ የምዝግብ ማስታወሻዎች ማከማቻ ሞተር አለን። የምዝግብ ማስታወሻዎች-ሞተር. በትክክል የተፈጠረው ለዚህ ነው እና እጅግ በጣም ብዙ በሆኑ ስብስቦች ውስጥ በሰፊው ጥቅም ላይ የዋለው። እኔ የማውቀው ትልቁ ክላስተር 600 ቲቢ የታሸጉ ሎግ ያከማቻል።

ሞተሩ በጣም ያረጀ ነው, ከ6-7 አመት እድሜ ያላቸው ስብስቦች አሉ. እሱን ለመፍታት የምንሞክርባቸው ችግሮች አሉ ፣ ለምሳሌ ፣ መዝገቦችን ለማከማቸት ClickHouseን በንቃት መጠቀም ጀመርን ።

በ ClickHouse ውስጥ ምዝግብ ማስታወሻዎችን መሰብሰብ

ይህ ሥዕላዊ መግለጫ ወደ ሞተሮች እንዴት እንደምንገባ ያሳያል።

በአካባቢው በ RPC ወደ RPC-proxy የሚሄድ ኮድ አለ, እና ወደ ሞተሩ የት መሄድ እንዳለበት ይረዳል. በ ClickHouse ውስጥ ምዝግብ ማስታወሻዎችን ለመጻፍ ከፈለግን በዚህ እቅድ ውስጥ ሁለት ክፍሎችን መለወጥ አለብን.

• አንዳንድ ሞተርን በ ClickHouse መተካት;
• ClickHouseን መድረስ የማይችለውን የ RPC ተኪ፣ በሆነ መፍትሄ እና በ RPC ተካ።

ሞተሩ ቀላል ነው - በ ClickHouse በአገልጋይ ወይም የአገልጋዮች ስብስብ እንተካለን።

እና ወደ ClickHouse ለመሄድ፣ አደረግን። የድመት ቤት. በቀጥታ ከ KittenHouse ወደ ClickHouse ከሄድን አይቋቋምም። ምንም እንኳን ሳይጠየቅ፣ ከኤችቲቲፒ ግንኙነቶች እጅግ በጣም ብዙ ማሽኖችን ይጨምራል። ዕቅዱ እንዲሠራ፣ ClickHouse ባለው አገልጋይ ላይ የአካባቢ ተገላቢጦሽ ፕሮክሲ ይነሳልየሚፈለጉትን የግንኙነቶች ጥራዞች ለመቋቋም በሚያስችል መንገድ የተጻፈ ነው. እንዲሁም በአንፃራዊነት አስተማማኝ በሆነ መልኩ መረጃን በራሱ ውስጥ ማስቀመጥ ይችላል።

አንዳንድ ጊዜ የ RPC እቅድን መደበኛ ባልሆኑ መፍትሄዎች ለምሳሌ በ nginx ውስጥ መተግበር አንፈልግም. ስለዚህ, KittenHouse በ UDP በኩል ምዝግብ ማስታወሻዎችን የመቀበል ችሎታ አለው.

የምዝግብ ማስታወሻው ላኪ እና ተቀባይ በተመሳሳይ ማሽን ላይ የሚሰሩ ከሆነ በአካባቢው አስተናጋጅ ውስጥ የ UDP ፓኬት የማጣት እድሉ በጣም ዝቅተኛ ነው። RPCን በሶስተኛ ወገን መፍትሄ እና አስተማማኝነት ውስጥ የመተግበር አስፈላጊነት መካከል እንደ ስምምነት, በቀላሉ UDP መላክን እንጠቀማለን. ወደዚህ እቅድ በኋላ እንመለሳለን።

ክትትል

ሁለት አይነት ምዝግብ ማስታወሻዎች አሉን፡ በአስተዳዳሪዎች በአገልጋዮቻቸው የተሰበሰቡ እና በገንቢዎች ከኮድ የተፃፉ። እነሱ ከሁለት ዓይነት መለኪያዎች ጋር ይዛመዳሉ- ስርዓት እና ምርት.

የስርዓት መለኪያዎች

በሁሉም አገልጋዮቻችን ላይ ይሰራል ነታዳታ, ይህም ስታቲስቲክስ ይሰበስባል እና እነሱን ይልካል ግራፋይት ካርቦን. ስለዚህ, ClickHouse እንደ ማከማቻ ስርዓት ነው የሚያገለግለው, እና ለምሳሌ ሹክሹክታ አይደለም. አስፈላጊ ከሆነ በቀጥታ ከ ClickHouse ማንበብ ወይም መጠቀም ይችላሉ። ግራፋና ለሜትሪዎች፣ ግራፎች እና ሪፖርቶች። እንደ ገንቢዎች፣ የ Netdata እና Grafana በቂ መዳረሻ አለን።

የምርት መለኪያዎች

ለመመቻቸት, ብዙ ነገሮችን ጽፈናል. ለምሳሌ ፣ ቆጠራዎችን ፣ ልዩ ቆጠራዎችን ወደ ስታቲስቲክስ እንዲጽፉ የሚያስችልዎ ተራ ተግባራት ስብስብ አለ ፣ ወደ ሌላ ቦታ ይላካሉ።

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

$stats = statlogsStatData($params)

በመቀጠል ማጣሪያዎችን መደርደር እና ማቧደን እና ከስታቲስቲክስ የምንፈልገውን ሁሉ ማድረግ እንችላለን - ግራፎችን ይገንቡ ፣ Watchdogs ን ያዋቅሩ።

በጣም እንጽፋለን ብዙ መለኪያዎች የክስተቶቹ ብዛት በቀን ከ 600 ቢሊዮን ወደ 1 ትሪሊዮን ነው. ሆኖም ግን, እነሱን ማቆየት እንፈልጋለን ቢያንስ ሁለት ዓመታትበመለኪያዎች ውስጥ ያሉትን አዝማሚያዎች ለመረዳት. ሁሉንም በአንድ ላይ ማሰባሰብ እስካሁን ያልተፈታነው ትልቅ ችግር ነው። ላለፉት ጥቂት ዓመታት እንዴት እየሰራ እንደሆነ እነግርዎታለሁ።

እነዚህን መለኪያዎች የሚጽፉ ተግባራት አሉን። ወደ አካባቢያዊ memcacheየመግቢያዎችን ቁጥር ለመቀነስ. አንድ ጊዜ በአጭር ጊዜ ውስጥ በአካባቢው ተጀመረ ስታቲስቲክስ-ዳሞን ሁሉንም መዝገቦች ይሰበስባል. በመቀጠል, ጋኔኑ መለኪያዎችን ወደ ሁለት ንብርብሮች አገልጋይ ያዋህዳል የምዝግብ ማስታወሻዎች - ሰብሳቢዎች, ይህም ከኋላቸው ያለው ንብርብር እንዳይሞት ከማሽኖቻችን ስብስብ ውስጥ ስታቲስቲክስን ያጠቃለለ.

አስፈላጊ ከሆነ, በቀጥታ ወደ ሎግ-ሰብሳቢዎች መጻፍ እንችላለን.

ነገር ግን ከኮድ በቀጥታ ወደ ሰብሳቢዎች መፃፍ፣ ስታስ-ዳሞምን ማለፍ፣ በአሰባሳቢው ላይ ሸክሙን ስለሚጨምር በደንብ ሊለካ የማይችል መፍትሄ ነው። መፍትሄው ተስማሚ የሚሆነው በሆነ ምክንያት በማሽኑ ላይ ያለውን memcache stats-daemon ማሳደግ ካልቻልን ብቻ ነው፣ ወይም ተሰናክሏል እና በቀጥታ ከሄድን።

በመቀጠል፣ የምዝግብ ማስታወሻዎች-ሰብሳቢዎች ስታቲስቲክስን ያዋህዳሉ meowDB - ይህ የእኛ የውሂብ ጎታ ነው, እሱም መለኪያዎችንም ሊያከማች ይችላል.

ከዚያ ከኮዱ ሁለትዮሽ "በቅርብ-SQL" ምርጫዎችን ማድረግ እንችላለን.

ሙከራ

እ.ኤ.አ. በ 2018 የበጋ ወቅት ፣ ውስጣዊ ሃክታቶን ነበረን ፣ እና ሃሳቡ የዲያግራሙን ቀይ ክፍል በ ClickHouse ውስጥ መለኪያዎችን ሊያከማች በሚችል ነገር ለመተካት መሞከር ነበረበት። በ ClickHouse ላይ የምዝግብ ማስታወሻዎች አሉን - ለምን አይሞክሩም?

በKittenHouse በኩል ምዝግብ ማስታወሻዎችን የሚጽፍ እቅድ ነበረን።

ወስነናል። በስዕሉ ላይ ሌላ "*ቤት" ጨምርየእኛ ኮድ በ UDP በኩል እንደጻፋቸው በትክክል መለኪያዎችን በቅርጸቱ ይቀበላል። ከዚያ ይህ *ቤት እንደ ኪተን ሀውስ የሚረዳቸውን እንደ ሎግዎች ወደ ማስገቢያዎች ይቀይራቸዋል። እነዚህን ምዝግብ ማስታወሻዎች ማንበብ መቻል ያለበትን ወደ ClickHouse በትክክል ማድረስ ይችላል።

ሜምካሼ፣ ስታቲስቲክ-ዳሞን እና ሎግ-ሰብሳቢዎች ዳታቤዝ ያለው እቅድ በዚህ ተተክቷል።

ሜምካሼ፣ ስታቲስቲክ-ዳሞን እና ሎግ-ሰብሳቢዎች ዳታቤዝ ያለው እቅድ በዚህ ተተክቷል።

• እዚህ በStatsHouse ውስጥ በአገር ውስጥ የተጻፈ ከኮድ የተላከ መልእክት አለ።
• StatsHouse የ UDP መለኪያዎችን ይጽፋል፣ ቀድሞውንም ወደ SQL መክተቻዎች የተቀየረ፣ ወደ KittenHouse በቡድን ነው።
• KittenHouse ወደ ClickHouse ይልካቸዋል።
• ልናነብባቸው ከፈለግን ስታትሃውስን በማለፍ እናነባቸዋለን - በቀጥታ ከ ClickHouse መደበኛ SQL።

አሁንም ነው? ሙከራ, ግን እንዴት እንደሚሆን እንወዳለን. ችግሮቹን በእቅዱ ላይ ካስተካከልን ምናልባት ወደ እሱ ሙሉ በሙሉ እንቀይራለን። በግሌ ተስፋ አደርጋለሁ።

መርሃግብሩ ብረት አያድንም. ያነሱ አገልጋዮች ያስፈልጋሉ፣ የአካባቢ ስታቲስቲክስ-ዳሞኖች እና ሎግ-ሰብሳቢዎች አያስፈልጉም ፣ ግን ClickHouse አሁን ካለው እቅድ የበለጠ ትልቅ አገልጋይ ይፈልጋል። ጥቂት አገልጋዮች ያስፈልጋሉ፣ ግን የበለጠ ውድ እና የበለጠ ኃይለኛ መሆን አለባቸው.

አሰማር

በመጀመሪያ፣ የ PHP መዘርጋትን እንመልከት። ውስጥ እያደግን ነው። ሂድ: መጠቀም GitLab и TeamCity ለማሰማራት. የልማት ቅርንጫፎች ወደ ዋና ቅርንጫፍ ይዋሃዳሉ, ከመምህሩ ለሙከራ ወደ መድረክ ይዋሃዳሉ, እና ከመድረክ ወደ ምርት.

ከመሰማራቱ በፊት, የአሁኑ የምርት ቅርንጫፍ እና ቀዳሚው ተወስደዋል, እና ዲፍ ፋይሎች በውስጣቸው ግምት ውስጥ ይገባሉ - ለውጦች: ተፈጥሯል, ተሰርዟል, ተለውጧል. ይህ ለውጥ በልዩ ኮፒ ፋስት ኢንጂን ቢንሎግ ውስጥ ተመዝግቧል፣ ይህም ለውጦችን በአጠቃላይ የአገልጋያችን መርከቦች ላይ በፍጥነት ሊደግም ይችላል። እዚህ ጥቅም ላይ የሚውለው በቀጥታ መቅዳት አይደለም, ግን ወሬ ማባዛት, አንድ አገልጋይ ለውጦችን ለቅርብ ጎረቤቶቹ, ለጎረቤቶቻቸው, ወዘተ ለውጦችን ሲልክ. ይህ በጠቅላላው መርከቦች ውስጥ ኮዱን በአስር እና በሰከንዶች ውስጥ እንዲያዘምኑ ያስችልዎታል። ለውጡ ወደ አካባቢያዊ ቅጂው ሲደርስ እነዚህን ንጣፎች በእሱ ላይ ይተገበራል። የአካባቢ ፋይል ስርዓት. ሮልባክ በተመሳሳይ እቅድ መሰረት ይከናወናል.

በተጨማሪም kPHPን በብዛት እናሰማራዋለን እና የራሱ የሆነ እድገትም አለው። ሂድ ከላይ ባለው ንድፍ መሠረት. ከዚህ ጀምሮ HTTP አገልጋይ ሁለትዮሽ, ከዚያ ልዩነት መፍጠር አንችልም - የተለቀቀው ሁለትዮሽ ክብደት በመቶዎች የሚቆጠሩ ሜባ ነው። ስለዚህ, እዚህ ሌላ አማራጭ አለ - ስሪቱ የተፃፈ ነው የቢንሎግ ቅጂ ፈጣን. በእያንዳንዱ ግንባታ ይጨምራል, እና በሚመለስበት ጊዜ ደግሞ ይጨምራል. ሥሪት ወደ አገልጋዮች ተባዝቷል።. የሃገር ውስጥ ኮፒፋስቶች አዲስ እትም ወደ ቢንሎግ እንደገባ ያዩታል፣ እና በተመሳሳይ የሐሜት ማባዛት ጌታችንን አገልጋያችንን ሳይታክቱ፣ ነገር ግን ጭነቱን በጥንቃቄ በኔትወርኩ ላይ በማሰራጨት አዲሱን የሁለትዮሽ ቅጂ ለራሳቸው ወስደዋል። ምን ይከተላል በሚያምር ሁኔታ እንደገና መጀመር ለአዲሱ ስሪት.

ለኛ ሞተሮች ፣እንዲሁም በመሠረቱ ሁለትዮሽ ለሆኑት ፣ እቅዱ በጣም ተመሳሳይ ነው-

• git ዋና ቅርንጫፍ;
• ሁለትዮሽ ኢን .deb;
• ስሪቱ የተጻፈው ለቢንሎግ ቅጂ ፋስት;
• ወደ አገልጋዮች ተባዝቷል;
• አገልጋዩ ትኩስ .dep ያወጣል;
• dpkg -i;
• በሚያምር ሁኔታ ወደ አዲሱ ስሪት እንደገና መጀመር።

ልዩነቱ የእኛ ሁለትዮሽ በማህደር ውስጥ የታሸገ መሆኑ ነው። .deb, እና በሚወጡበት ጊዜ dpkg -i በስርዓቱ ላይ ተቀምጠዋል. ለምንድነው kPHP እንደ ሁለትዮሽ የሚሰራው፣ እና ሞተሮች እንደ dpkg የተሰማሩት? እንደዚያ ሆነ። ይሰራል - አይንኩት.

ጠቃሚ አገናኞች:

• ዘገባው በአንቶን ኪሪዩሽኪን ነው። "Vkontakte ስርዓት አስተዳዳሪ. እንዴት?" ስለ ኮፒፋስት እና ስለ ሐሜት ዝርዝሮች።
• ዘገባ በዩሪ ናስሬትዲኖቭ "ቪኬ በአስር ሺዎች ከሚቆጠሩ አገልጋዮች መረጃን ወደ ክሊክ ሃውስ እንዴት እንደሚያስገባ".
• የእኔ ዘገባ "የ VKontakte ምሳሌን በመጠቀም እያደገ ያለ ፕሮጀክት አርክቴክቸር", ነገር ግን ከግንባታ እይታ, ሃርድዌር አይደለም.

አሌክሲ አኩሎቪች እንደ የፕሮግራም ኮሚቴ አካል ከሆኑት መካከል አንዱ ነው ፒኤችፒ ሩሲያ ሜይ 17 በቅርብ ጊዜ ለPHP ገንቢዎች ትልቁ ክስተት ይሆናል። ምን አሪፍ ፒሲ እንዳለን ይመልከቱ ፣ ምን ተናጋሪዎች (ሁለቱም ፒኤችፒ ኮርን እያዳበሩ ነው!) - PHP ከጻፉ ሊያመልጡት የማይችሉት ነገር ይመስላል።

ምንጭ: hab.com