የሞስኮ ልውውጥ የግብይት እና የማጽዳት ስርዓት ሥነ ሕንፃ ዝግመተ ለውጥ። ክፍል 2

ይህ የልውውጡን አሠራር የሚያረጋግጥ ኃይለኛ እና ከፍተኛ ጭነት ስርዓት ለመፍጠር ስለ እሾህ መንገዳችን የረጅም ታሪክ ቀጣይ ነው። የመጀመሪያው ክፍል እዚህ አለ፡- habr.com/am/post/444300

ሚስጥራዊ ስህተት

ከብዙ ሙከራዎች በኋላ፣ የዘመነው የግብይት እና የማጥራት ስርዓት ስራ ላይ ዋለ፣ እና ስለ መርማሪ - ሚስጥራዊ ታሪክ የምንጽፍበት ስህተት አጋጥሞናል።

በዋናው አገልጋይ ላይ ከተጀመረ ብዙም ሳይቆይ ከግብይቶቹ አንዱ በስህተት ተካሄዷል። ሆኖም በመጠባበቂያ አገልጋዩ ላይ ሁሉም ነገር ጥሩ ነበር። በዋናው አገልጋይ ላይ ያለውን ገላጭ ለማስላት ቀላል የሂሳብ አሰራር ከትክክለኛው መከራከሪያ አሉታዊ ውጤት እንዳስገኘ ተገለጠ! ምርምራችንን ቀጠልን፣ እና በ SSE2 መዝገብ ውስጥ በአንድ ቢት ልዩነት አግኝተናል፣ ይህም በተንሳፋፊ ነጥብ ቁጥሮች ሲሰራ የማጠጋጋት ሃላፊነት ነው።

ገላጩን ከክብ ቢት ስብስብ ጋር ለማስላት ቀለል ያለ የሙከራ መገልገያ ጽፈናል። እኛ በተጠቀምንበት የሬድሃት ሊኑክስ ስሪት ውስጥ የታመመው ቢት ወደ ውስጥ ሲገባ ከሂሳብ ተግባሩ ጋር አብሮ በመስራት ላይ ችግር ነበር። ይህንን ለሬድሃት ሪፖርት አድርገናል፣ ከትንሽ ጊዜ በኋላ ከነሱ ፓቼ ተቀብለን ተንከባለልነው። ስህተቱ ከአሁን በኋላ አልተከሰተም፣ ግን ይህ ትንሽ ከየት እንደመጣ ግልጽ አልነበረም? ተግባሩ ተጠያቂ ነበር fesetround ከ C ቋንቋ.የተገመተውን ስህተት ለመፈለግ ኮዳችንን በጥንቃቄ ተንትነናል-ሁሉንም ሊሆኑ የሚችሉ ሁኔታዎችን አረጋግጠናል; ማጠጋጋትን የተጠቀሙትን ሁሉንም ተግባራት ተመልክቷል; ያልተሳካውን ክፍለ ጊዜ እንደገና ለማራባት ሞክሯል; ከተለያዩ አማራጮች ጋር የተለያዩ ማቀነባበሪያዎችን ተጠቅሟል; የማይለዋወጥ እና ተለዋዋጭ ትንተና ጥቅም ላይ ውሏል.

የስህተቱ መንስኤ ሊገኝ አልቻለም።

ከዚያም ሃርድዌር መፈተሽ ጀመሩ: የማቀነባበሪያዎቹን የጭነት ሙከራ አደረጉ; ራም አረጋግጧል; በአንድ ሕዋስ ውስጥ ላለው የብዝሃ-ቢት ስህተት በጣም የማይመስል ሁኔታን እንኳን ሙከራዎችን አደረግን። ምንም ጥቅም የለውም።

በስተመጨረሻ ከሀይ-ኢነርጂ ፊዚክስ አለም በተገኘ ቲዎሪ ላይ ተቀመጥን፡ አንዳንድ ሃይል ሃይል ያለው ቅንጣት ወደ ዳታ ማእከላችን በረረ፣የኬዝ ግድግዳውን ወጋ፣ ፕሮሰሰሩን በመምታት ቀስቅሴው መቀርቀሪያ በዛ ውስጥ እንዲጣበቅ አደረገ። ይህ የማይረባ ንድፈ ሐሳብ “neutrino” ተብሎ ይጠራ ነበር። ከቅንጣት ፊዚክስ የራቁ ከሆኑ ኒውትሪኖስ ማለት ይቻላል ከውጭው ዓለም ጋር አይገናኙም ፣ እና በእርግጠኝነት የማቀነባበሪያውን አሠራር ሊነኩ አይችሉም።

የውድቀቱን ምክንያት ማግኘት ስላልተቻለ “አስከፋኝ” አገልጋዩ ከስራው ተወግዷል።

ከተወሰነ ጊዜ በኋላ ትኩስ የመጠባበቂያ ስርዓቱን ማሻሻል ጀመርን-"ሞቅ ያለ ክምችት" (ሙቅ) የሚባሉትን አስተዋውቀናል - ያልተመሳሰሉ ቅጂዎች። በተለያዩ የውሂብ ማዕከሎች ውስጥ ሊገኙ የሚችሉ የግብይቶች ዥረት ተቀብለዋል, ነገር ግን ሞቅቶች ከሌሎች አገልጋዮች ጋር በንቃት አልተገናኙም.

ይህ ለምን ተደረገ? የመጠባበቂያ አገልጋዩ ካልተሳካ ከዋናው አገልጋይ ጋር የተሳሰረ ሙቅ አዲሱ ምትኬ ይሆናል። ማለትም፣ ከተሳካ በኋላ ስርዓቱ እስከ የንግድ ክፍለ ጊዜ ማብቂያ ድረስ ከአንድ ዋና አገልጋይ ጋር አይቆይም።

እና አዲሱ የስርዓቱ ስሪት ተፈትኖ ወደ ስራ ሲገባ የማዞሪያ ቢት ስህተቱ እንደገና ተከስቷል። ከዚህም በላይ የሞቀ አገልጋዮች ቁጥር እየጨመረ በመምጣቱ ስህተቱ ብዙ ጊዜ መታየት ጀመረ. በተመሳሳይ ጊዜ, ምንም ተጨባጭ ማስረጃ ስላልነበረ ሻጩ ምንም የሚያሳየው ነገር አልነበረም.

በሚቀጥለው የሁኔታ ትንተና ላይ ችግሩ ከስርዓተ ክወናው ጋር ሊዛመድ እንደሚችል አንድ ንድፈ ሀሳብ ተነሳ. ተግባርን ማለቂያ በሌለው loop ውስጥ የሚጠራ ቀላል ፕሮግራም ጻፍን። fesetround, አሁን ያለውን ሁኔታ ያስታውሳል እና በእንቅልፍ ይፈትሻል, እና ይህ በብዙ ተፎካካሪ ክሮች ውስጥ ይከናወናል. ለእንቅልፍ እና የክሮች ብዛት መለኪያዎችን ከመረጥን በኋላ መገልገያውን ከጀመርን ከ 5 ደቂቃዎች በኋላ የቢት ውድቀትን በተከታታይ ማባዛት ጀመርን ። ይሁን እንጂ የቀይ ኮፍያ ድጋፍ እንደገና ማባዛት አልቻለም። የእኛ የሌሎች አገልጋዮች ሙከራ እንደሚያሳየው የተወሰኑ ፕሮሰሰር ያላቸው ብቻ ለስህተቱ ተጋላጭ ናቸው። በተመሳሳይ ጊዜ ወደ አዲስ ከርነል መቀየር ችግሩን ፈታው. በመጨረሻ፣ በቀላሉ OSውን ተክተናል፣ እና ትክክለኛው የሳንካ መንስኤ ግልጽ አልሆነም።

እና በድንገት ባለፈው አመት በሀበሬ ላይ አንድ መጣጥፍ ታትሟል "በIntel Skylake ፕሮሰሰር ውስጥ እንዴት ስህተት እንዳገኘሁ" በውስጡ የተገለጸው ሁኔታ ከእኛ ጋር በጣም ተመሳሳይ ነበር, ነገር ግን ደራሲው ምርመራውን የበለጠ ወስዶ ስህተቱ በማይክሮኮድ ውስጥ እንዳለ ንድፈ ሃሳብ አቅርቧል. እና የሊኑክስ ኮርነሎች ሲዘምኑ አምራቾችም ማይክሮኮዱን ያዘምኑታል።

የስርዓቱ ተጨማሪ እድገት

ስህተቱን ብናስወግድም, ይህ ታሪክ የስርዓቱን አርክቴክቸር እንደገና እንድናጤን አስገድዶናል. ከሁሉም በላይ, እንደዚህ አይነት ስህተቶች ከመደጋገም አልተጠበቅንም.

የሚከተሉት መርሆዎች በቦታ ማስያዣ ስርዓቱ ላይ ለሚቀጥሉት ማሻሻያዎች መሠረት ሆነዋል።

• ማንንም ማመን አይችሉም። አገልጋዮች በአግባቡ ላይሠሩ ይችላሉ።
• አብዛኛው ቦታ ማስያዝ።
• መግባባትን ማረጋገጥ. ለአብዛኛዎቹ ቦታ ማስያዝ እንደ ምክንያታዊ ተጨማሪ።
• ድርብ አለመሳካቶች ሊኖሩ ይችላሉ።
• ወሳኝነት። አዲሱ ትኩስ የመጠባበቂያ እቅድ ከቀዳሚው የከፋ መሆን የለበትም. ግብይት እስከ መጨረሻው አገልጋይ ድረስ ያለማቋረጥ መቀጠል አለበት።
• የመዘግየት ትንሽ ጭማሪ። ማንኛውም የእረፍት ጊዜ ትልቅ የገንዘብ ኪሳራ ያስከትላል።
• መዘግየትን በተቻለ መጠን ዝቅተኛ ለማድረግ አነስተኛ የአውታረ መረብ መስተጋብር።
• በሰከንዶች ውስጥ አዲስ ዋና አገልጋይ መምረጥ።

በገበያ ላይ ከሚገኙት መፍትሔዎች ውስጥ አንዳቸውም ለእኛ ተስማሚ አይደሉም, እና የ Raft ፕሮቶኮል ገና በጅምር ላይ ነበር, ስለዚህ እኛ የራሳችንን መፍትሄ ፈጠርን.

አውታረ መረብ

ከቦታ ማስያዣ ስርዓቱ በተጨማሪ የኔትወርክ መስተጋብርን ማዘመን ጀመርን። የ I/O ንኡስ ስርዓት ብዙ ሂደቶችን ያቀፈ ነው፣ ይህም በጅት እና መዘግየት ላይ የከፋ ተጽእኖ ነበረው። የTCP ግንኙነቶችን በሚቆጣጠሩ በመቶዎች የሚቆጠሩ ሂደቶች፣ በመካከላቸው ያለማቋረጥ ለመቀያየር ተገደናል፣ እና በማይክሮ ሰከንድ ሚዛን ይህ ጊዜ የሚወስድ ክወና ነው። ነገር ግን በጣም መጥፎው ነገር አንድ ሂደት ለሂደቱ ፓኬት ሲደርሰው ወደ አንድ የSystemV ወረፋ ልኮ ከዚያ ሌላ የSystemV ወረፋ ክስተትን መጠበቁ ነው። ይሁን እንጂ ብዙ ቁጥር ያላቸው አንጓዎች ሲኖሩ, በአንድ ሂደት ውስጥ አዲስ የ TCP ፓኬት መምጣት እና በሌላ ወረፋ ውስጥ ያለው መረጃ መቀበል ለ OS ሁለት ተፎካካሪ ክስተቶችን ይወክላል. በዚህ ሁኔታ, ለሁለቱም ስራዎች ምንም አይነት አካላዊ ማቀነባበሪያዎች ከሌሉ, አንዱ ይከናወናል, ሁለተኛው ደግሞ በመጠባበቅ ወረፋ ውስጥ ይቀመጣል. ውጤቱን ለመተንበይ አይቻልም.

በእንደዚህ ዓይነት ሁኔታዎች ውስጥ ተለዋዋጭ የሂደት ቅድሚያ ቁጥጥርን መጠቀም ይቻላል, ነገር ግን ይህ በንብረት ላይ የተጠናከረ የስርዓት ጥሪዎችን መጠቀምን ይጠይቃል. በውጤቱም, ክላሲክ epollን በመጠቀም ወደ አንድ ክር ቀይረናል, ይህም ፍጥነቱን በእጅጉ ጨምሯል እና የግብይቱን ሂደት ጊዜ ይቀንሳል. እንዲሁም በSystemV በኩል የተለየ የአውታረ መረብ ግንኙነት ሂደቶችን እና ግንኙነቶችን አስወግደናል ፣ የስርዓት ጥሪዎችን ቁጥር በከፍተኛ ሁኔታ ቀንሷል እና የኦፕሬሽኖችን ቅድሚያ የሚሰጣቸውን ነገሮች መቆጣጠር ጀመርን። በ I/O ንኡስ ስርዓት ላይ ብቻ እንደ ሁኔታው ​​ከ8-17 ማይክሮ ሰከንድ መቆጠብ ተችሏል። ይህ ባለአንድ-ክር እቅድ ከዚያን ጊዜ ጀምሮ ሳይለወጥ ጥቅም ላይ ውሏል፡ አንድ የኤፖል ክር ከህዳግ ጋር ሁሉንም ግንኙነቶች ለማገልገል በቂ ነው።

የግብይት ሂደት

በስርዓታችን ላይ እያደገ የመጣው ሸክም ሁሉንም ክፍሎቹን ማሻሻልን ይጠይቃል። ግን እንደ አለመታደል ሆኖ ፣ በቅርብ ዓመታት ውስጥ በአቀነባባሪው የሰዓት ፍጥነት እድገት ውስጥ መቀዛቀዝ ሂደቶችን በግንባር ቀደምትነት ማስፋት አልቻለም። ስለዚህ, የሞተርን ሂደት በሶስት ደረጃዎች ለመከፋፈል ወስነናል, ከነሱ ውስጥ በጣም የተጨናነቀው የአደጋ ማረጋገጫ ስርዓት ነው, ይህም በሂሳብ ውስጥ የገንዘብ መገኘቱን የሚገመግም እና ግብይቶችን እራሳቸው ይፈጥራል. ነገር ግን ገንዘቡ በተለያዩ ምንዛሬዎች ሊሆን ይችላል, እና የጥያቄዎች ሂደት በምን መሰረት መከፋፈል እንዳለበት ማወቅ አስፈላጊ ነበር.

አመክንዮአዊው መፍትሄ በገንዘብ መከፋፈል ነው፡ አንዱ አገልጋይ በዶላር፣ ሌላው በፖውንድ እና ሶስተኛው በዩሮ ይገበያያል። ነገር ግን በእንደዚህ አይነት እቅድ ሁለት ግብይቶች የተለያዩ ገንዘቦችን ለመግዛት ከተላኩ የኪስ ቦርሳውን አለመመሳሰል ችግር ይፈጠራል. ግን ማመሳሰል አስቸጋሪ እና ውድ ነው። ስለዚህ በኪስ ቦርሳ እና በተናጠል በመሳሪያዎች መቆራረጥ ትክክል ይሆናል. በነገራችን ላይ፣ አብዛኞቹ የምዕራባውያን ልውውጦች እንደ እኛ አደጋዎችን የመመርመር ተግባር የላቸውም፣ ስለዚህ ብዙውን ጊዜ ይህ ከመስመር ውጭ ነው። በመስመር ላይ ማረጋገጥን መተግበር ያስፈልገናል.

በምሳሌ እናብራራ። አንድ ነጋዴ 30 ዶላር መግዛት ይፈልጋል, እና ጥያቄው ወደ ግብይቱ ማረጋገጫ ይሄዳል: ይህ ነጋዴ ወደዚህ የንግድ ሁነታ ተፈቅዶለት እንደሆነ እና አስፈላጊዎቹ መብቶች እንዳሉት እናረጋግጣለን. ሁሉም ነገር በቅደም ተከተል ከሆነ, ጥያቄው ወደ አደጋ ማረጋገጫ ስርዓት ይሄዳል, ማለትም. የገንዘብ ልውውጥን ለመጨረስ የገንዘብ መጠንን ለመፈተሽ. የሚፈለገው መጠን በአሁኑ ጊዜ እንደታገደ ማስታወሻ አለ. ከዚያም ጥያቄው ወደ የንግድ ሥርዓት ተላልፏል, ይህም ግብይቱን ያጸድቃል ወይም አይቀበለውም. ግብይቱ ተፈቅዷል እንበል - ከዚያም የአደጋ ማረጋገጫ ስርዓቱ ገንዘቡ እንደታገደ እና ሩብሎች ወደ ዶላር ይለወጣሉ.

በአጠቃላይ የአደጋ ፍተሻ ስርዓቱ ውስብስብ ስልተ ቀመሮችን ይይዛል እና እጅግ በጣም ብዙ ሀብትን የሚጠይቁ ስሌቶችን ያከናውናል፣ እና በአንደኛው እይታ እንደሚመስለው በቀላሉ “የመለያ ቀሪ ሒሳብን” አያረጋግጥም።

የኢንጂንን ሂደት በደረጃ መከፋፈል ስንጀምር ችግር አጋጥሞናል፡ በዚያን ጊዜ የነበረው ኮድ በማረጋገጫ እና በማረጋገጫ ደረጃዎች ላይ ተመሳሳይ የመረጃ ድርድርን በንቃት ይጠቀም ነበር ይህም ሙሉውን የኮድ መሰረት እንደገና መፃፍ ያስፈልገዋል። በዚህ ምክንያት ከዘመናዊ ማቀነባበሪያዎች መመሪያዎችን ለማስኬድ ቴክኒኮችን ወስደናል-እያንዳንዳቸው በትንሽ ደረጃዎች የተከፋፈሉ እና ብዙ ድርጊቶች በአንድ ዑደት ውስጥ በትይዩ ይከናወናሉ.

ከኮዱ ትንሽ መላመድ በኋላ ለትይዩ የግብይት ሂደት ቧንቧ መስመር ፈጠርን ፣ በዚህ ውስጥ ግብይቱ በ 4 የቧንቧ መስመር ደረጃዎች የተከፈለው የአውታረ መረብ መስተጋብር ፣ ማረጋገጫ ፣ አፈፃፀም እና ውጤቱን ማተም

አንድ ምሳሌ እንመልከት። ሁለት የማቀነባበሪያ ስርዓቶች አሉን, ተከታታይ እና ትይዩ. የመጀመሪያው ግብይት ይደርሳል እና በሁለቱም ስርዓቶች ውስጥ ለማረጋገጥ ይላካል. ሁለተኛው ግብይት ወዲያውኑ ይደርሳል: በትይዩ ስርዓት ውስጥ ወዲያውኑ ወደ ሥራ ይወሰዳል, እና በቅደም ተከተል ስርዓት ውስጥ የመጀመሪያውን ግብይት አሁን ባለው ሂደት ውስጥ ለማለፍ ወረፋ ይጠብቃል. ያም ማለት የቧንቧ ማቀነባበሪያ ዋናው ጥቅም የግብይቱን ወረፋ በፍጥነት ማካሄድ ነው.

የ ASTS+ ስርዓትን ያገኘነው በዚህ መንገድ ነው።

እውነት ነው, ሁሉም ነገር በማጓጓዣዎች እንዲሁ ለስላሳ አይደለም. በአጎራባች ግብይት ውስጥ ባሉ የውሂብ አደራደሮች ላይ ተጽእኖ የሚያሳድር ግብይት አለን እንበል፤ ይህ ለወጭ ልውውጥ የተለመደ ሁኔታ ነው። እንዲህ ዓይነቱ ግብይት በሌሎች ላይ ተጽዕኖ ስለሚያሳድር በቧንቧ ውስጥ ሊከናወን አይችልም. ይህ ሁኔታ የውሂብ አደጋ ተብሎ ይጠራል, እና እንደዚህ አይነት ግብይቶች በቀላሉ በተናጥል ይከናወናሉ: በወረፋው ውስጥ ያለው "ፈጣን" ግብይቶች ሲያልቅ, የቧንቧ መስመር ይቆማል, ስርዓቱ "ዝግተኛ" ግብይቱን ያስኬዳል, ከዚያም የቧንቧ መስመርን እንደገና ይጀምራል. እንደ እድል ሆኖ, በአጠቃላይ ፍሰቱ ውስጥ የእንደዚህ አይነት ግብይቶች መጠን በጣም ትንሽ ነው, ስለዚህ የቧንቧ መስመር በጣም አልፎ አልፎ ስለሚቆም አጠቃላይ አፈፃፀምን አይጎዳውም.

ከዚያም ሶስት የአፈፃፀም ክሮች የማመሳሰልን ችግር መፍታት ጀመርን. ውጤቱም ቋሚ መጠን ያላቸው ሴሎች ባለው ቀለበት ቋት ላይ የተመሰረተ ስርዓት ነበር። በዚህ ስርዓት ሁሉም ነገር ለሂደቱ ፍጥነት ተገዢ ነው, ውሂብ አልተገለበጠም.

• ሁሉም ገቢ የአውታረ መረብ እሽጎች ወደ ምደባው ደረጃ ይገባሉ።
• በአንድ ድርድር ውስጥ እናስቀምጣቸዋለን እና ለደረጃ #1 እንደሚገኙ ምልክት እናደርጋለን።
• ሁለተኛው ግብይት ደርሷል, እንደገና ለደረጃ ቁጥር 1 ይገኛል.
• የመጀመሪያው የማቀነባበሪያ ክር ያሉትን ግብይቶች ያያል፣ ያስኬዳቸዋል እና ወደ ሁለተኛው የሂደት ክር ወደሚቀጥለው ደረጃ ያንቀሳቅሳቸዋል።
• ከዚያም የመጀመሪያውን ግብይት ያስኬዳል እና ተጓዳኙን ሕዋስ ይጠቁማል deleted - አሁን ለአዲስ አገልግሎት ይገኛል።

ወረፋው በሙሉ በዚህ መንገድ ይከናወናል።

የእያንዳንዱ ደረጃ ሂደት አሃዶች ወይም አስር ማይክሮ ሰከንድ ይወስዳል። እና መደበኛ የስርዓተ ክወና ማመሳሰል መርሃግብሮችን ከተጠቀምን ፣ ከዚያ በራሱ ማመሳሰል ላይ ብዙ ጊዜ እናጠፋለን። ስፒንሎክን መጠቀም የጀመርነው ለዚህ ነው። ሆኖም ፣ ይህ በእውነተኛ ጊዜ ስርዓት ውስጥ በጣም መጥፎ ቅርፅ ነው ፣ እና ሬድሃት ይህንን እንዲያደርጉ በጥብቅ አይመክርም ፣ ስለሆነም ለ 100 ms ስፒንሎክን እንተገብራለን ፣ እና ከዚያ የመዘግየት እድልን ለማስወገድ ወደ ሴማፎር ሁነታ እንለውጣለን ።

በዚህም በሴኮንድ ወደ 8 ሚሊዮን የሚጠጋ ግብይት አፈጻጸም አስመዝግበናል። እና በትክክል ከሁለት ወራት በኋላ ጽሑፍ ስለ LMAX Disruptor ተመሳሳይ ተግባር ያለው የወረዳ መግለጫ አይተናል።

አሁን በአንድ ደረጃ ላይ በርካታ የማስፈጸሚያ ክሮች ሊኖሩ ይችላሉ። ሁሉም ግብይቶች በተቀበሉት ቅደም ተከተል አንድ በአንድ ተካሂደዋል። በዚህም ከፍተኛ አፈጻጸም በሰከንድ ከ18ሺህ ወደ 50ሺህ ግብይቶች አድጓል።

የልውውጥ ስጋት አስተዳደር ስርዓት

ለፍጹምነት ምንም ገደብ የለም፣ እና ብዙም ሳይቆይ ዘመናዊነትን እንደገና ጀመርን-በ ASTS+ ማዕቀፍ ውስጥ የአደጋ አስተዳደር እና የሰፈራ ኦፕሬሽን ስርዓቶችን ወደ ገለልተኛ አካላት ማንቀሳቀስ ጀመርን። ተለዋዋጭ ዘመናዊ አርክቴክቸር እና አዲስ ተዋረዳዊ ስጋት ሞዴል አዘጋጅተናል፣ እና ክፍሉን በተቻለ መጠን ለመጠቀም ሞክረናል። fixed_point በ double.

ግን አንድ ችግር ወዲያውኑ ተከሰተ-ለብዙ ዓመታት ሲሰራ የነበረውን የንግድ ሥራ አመክንዮ እንዴት ማመሳሰል እና ወደ አዲሱ ስርዓት እንዴት ማስተላለፍ እንደሚቻል? በዚህ ምክንያት የአዲሱ ስርዓት የመጀመሪያ ስሪት መተው ነበረበት። በአሁኑ ጊዜ በምርት ላይ የሚሰራው ሁለተኛው ስሪት በተመሳሳይ ኮድ ላይ የተመሰረተ ነው, እሱም በሁለቱም የንግድ እና የአደጋ ክፍሎች ውስጥ ይሰራል. በእድገት ጊዜ በጣም አስቸጋሪው ነገር በሁለት ስሪቶች መካከል መቀላቀል ነው። ባልደረባችን Evgeniy Mazurenok በየሳምንቱ ይህንን ቀዶ ጥገና ያደርግ ነበር እናም በእያንዳንዱ ጊዜ በጣም ረጅም ጊዜ ይራገም ነበር.

አዲስ ስርዓት በምንመርጥበት ጊዜ, ወዲያውኑ የመስተጋብርን ችግር መፍታት ነበረብን. የውሂብ አውቶቡስ በሚመርጡበት ጊዜ የተረጋጋ ጅራትን እና አነስተኛ መዘግየትን ማረጋገጥ አስፈላጊ ነበር። የInfiniBand RDMA አውታረ መረብ ለዚህ በጣም ተስማሚ ነበር፡ አማካኝ የማስኬጃ ጊዜ ከ4 ጂ ኢተርኔት ኔትወርኮች በ10 እጥፍ ያነሰ ነው። ግን የማረከን የፐርሰንታይል ልዩነት - 99 እና 99,9 ነው።

በእርግጥ InfiniBand የራሱ ፈተናዎች አሉት። በመጀመሪያ, የተለየ ኤፒአይ - ከሶኬቶች ይልቅ ibverbs. በሁለተኛ ደረጃ፣ በስፋት የሚገኙ ክፍት ምንጭ የመልእክት መፍትሄዎች የሉም ማለት ይቻላል። የራሳችንን ፕሮቶታይፕ ለመሥራት ሞክረን ነበር፣ ነገር ግን በጣም አስቸጋሪ ሆኖ ተገኘ፣ ስለዚህ የንግድ መፍትሄን መረጥን - Confinity Low Latency Messaging (የቀድሞው IBM MQ LLM)።

ከዚያም የአደጋውን ስርዓት በትክክል የመከፋፈል ተግባር ተነሳ. በቀላሉ አደጋ ሞተርን ካስወገዱ እና መካከለኛ መስቀለኛ መንገድ ካልፈጠሩ, ከሁለት ምንጮች ግብይቶች ሊቀላቀሉ ይችላሉ.

Ultra Low Latency መፍትሄዎች የሚባሉት የመልሶ ማዘዣ ሁነታ አላቸው፡ ከሁለት ምንጮች የሚደረጉ ግብይቶች እንደደረሱ በሚፈለገው ቅደም ተከተል ሊደረደሩ ይችላሉ፡ ይህ ስለ ትዕዛዙ መረጃ ለመለዋወጥ የተለየ ቻናል በመጠቀም ይተገበራል። ግን ይህንን ሁነታ እስካሁን አንጠቀምም: አጠቃላይ ሂደቱን ያወሳስበዋል, እና በበርካታ መፍትሄዎች ውስጥ ምንም አይነት ድጋፍ አይሰጥም. በተጨማሪም ፣ እያንዳንዱ ግብይት ተጓዳኝ የጊዜ ማህተሞች መመደብ አለበት ፣ እና በእኛ እቅድ ውስጥ ይህ ዘዴ በትክክል ለመተግበር በጣም ከባድ ነው። ስለዚህ፣ ክላሲክ ዕቅድን በመልእክት ደላላ፣ ማለትም፣ በስጋት ሞተር መካከል መልዕክቶችን ከሚያሰራጭ ላኪ ጋር ተጠቀምን።

ሁለተኛው ችግር ከደንበኛ ተደራሽነት ጋር የተያያዘ ነበር፡ ብዙ የአደጋ መግቢያ መንገዶች ካሉ ደንበኛው ከእያንዳንዳቸው ጋር መገናኘት አለበት፣ እና ይሄ በደንበኛው ንብርብር ላይ ለውጦችን ይፈልጋል። በዚህ ደረጃ ከዚህ ለመውጣት እንፈልጋለን፣ ስለዚህ አሁን ያለው የአደጋ ጌትዌይ ዲዛይን አጠቃላይ የመረጃ ዥረቱን ያስኬዳል። ይህ ከፍተኛውን የፍተሻ መጠን በእጅጉ ይገድባል, ነገር ግን የስርዓት ውህደትን በእጅጉ ያቃልላል.

አስመስሎ መሥራት

ስርዓታችን አንድም የውድቀት ነጥብ ሊኖረው አይገባም ማለትም ሁሉም አካላት የመልእክት ደላላን ጨምሮ መባዛት አለባቸው። ይህንን ችግር የ CLLM ስርዓትን በመጠቀም ፈትተናል፡ በውስጡ ሁለት ላኪዎች በማስተር-ባሪያ ሁነታ የሚሰሩበት የ RCMS ክላስተር ይዟል፣ እና አንዱ ሲወድቅ ስርዓቱ በራስ-ሰር ወደ ሌላው ይቀየራል።

ከመጠባበቂያ የውሂብ ማዕከል ጋር በመስራት ላይ

InfiniBand እንደ አካባቢያዊ አውታረመረብ ለመስራት የተመቻቸ ነው ፣ ማለትም ፣ የራክ-mount መሳሪያዎችን ለማገናኘት ፣ እና የኢንፊኒባንድ አውታረ መረብ በሁለት መልክዓ ምድራዊ አቀማመጥ በተከፋፈሉ የመረጃ ማዕከሎች መካከል መዘርጋት አይችልም። ስለዚህ፣ ከመልዕክት ማከማቻ ጋር በመደበኛ የኤተርኔት ኔትወርኮች የሚገናኝ እና ሁሉንም ግብይቶች ወደ ሁለተኛ IB አውታረ መረብ የሚያስተላልፍ ድልድይ/ላኪን ተግባራዊ አድርገናል። ከውሂብ ማእከል መሰደድ ስንፈልግ ከየትኛው የመረጃ ማዕከል ጋር አሁን መስራት እንዳለብን መምረጥ እንችላለን።

ውጤቶች

ከላይ ያሉት ሁሉም በአንድ ጊዜ አልተከናወኑም፤ አዲስ አርክቴክቸር ለመፍጠር ብዙ ተደጋጋሚ ድግግሞሾችን ፈጅቷል። ፕሮቶታይፕን በአንድ ወር ውስጥ ፈጠርን, ነገር ግን ወደ ሥራ ሁኔታ ለመግባት ከሁለት ዓመት በላይ ፈጅቷል. የግብይት ሂደት ጊዜን በመጨመር እና የስርዓት አስተማማኝነትን በማሳደግ መካከል የተሻለውን ስምምነት ለማግኘት ሞክረናል።

ስርዓቱ በጣም ስለዘመነ፣ ከሁለት ገለልተኛ ምንጮች የመረጃ መልሶ ማግኛን ተግባራዊ አድርገናል። የመልእክት ማከማቻው በሆነ ምክንያት በትክክል የማይሰራ ከሆነ የግብይቱን ምዝግብ ማስታወሻ ከሁለተኛ ምንጭ - ከስጋት ሞተር መውሰድ ይችላሉ። ይህ መርህ በአጠቃላይ ስርዓቱ ውስጥ ይታያል.

ከሌሎች ነገሮች በተጨማሪ፣ ደላላም ሆነ ሌላ ማንም ሰው ለአዲሱ አርክቴክቸር ጉልህ የሆነ ዳግም መስራት እንዳይፈልግ የደንበኛውን ኤፒአይ መጠበቅ ችለናል። አንዳንድ በይነገጾችን መለወጥ ነበረብን፣ ነገር ግን በስርዓተ ክወናው ሞዴል ላይ ጉልህ ለውጦችን ማድረግ አያስፈልግም ነበር።

የአሁኑን የመድረክታችንን እትም Rebus ብለን እንጠራዋለን - በሥነ ሕንፃ ውስጥ ላሉ ሁለት በጣም ታዋቂ ፈጠራዎች ፣ አደጋ ሞተር እና ባስ።

መጀመሪያ ላይ የጽዳት ክፍሉን ብቻ ለመመደብ ፈልገን ነበር, ነገር ግን ውጤቱ ትልቅ የተከፋፈለ ስርዓት ነበር. ደንበኞች አሁን ከTrade Gateway፣ ከክሊንግ ጌትዌይ ወይም ከሁለቱም ጋር መስተጋብር መፍጠር ይችላሉ።

በመጨረሻ ያገኘነው ነገር፡-

የመዘግየት ደረጃ ቀንሷል። በትንሽ የግብይቶች መጠን, ስርዓቱ ከቀዳሚው ስሪት ጋር ተመሳሳይ ነው, ግን በተመሳሳይ ጊዜ ከፍተኛ ጭነት መቋቋም ይችላል.

ከፍተኛ አፈፃፀም በሰከንድ ከ 50 ሺህ ወደ 180 ሺህ ግብይቶች አድጓል። ብቸኛው የትዕዛዝ ማዛመጃ ዥረት ተጨማሪ ጭማሪ ይስተጓጎላል።

ለበለጠ መሻሻል ሁለት መንገዶች አሉ፡ ትይዩ ማዛመድ እና ከጌትዌይ ጋር የሚሰራበትን መንገድ መቀየር። አሁን ሁሉም ጌትዌይስ የሚሠሩት በማባዛት ዕቅድ መሠረት ነው፣ እሱም እንዲህ ባለው ጭነት፣ በመደበኛነት መሥራት ያቆማል።

በመጨረሻም፣ የድርጅት ስርአቶችን እያጠናቀቁ ላሉት አንዳንድ ምክር መስጠት እችላለሁ፡-

• በማንኛውም ጊዜ ለክፉው ዝግጁ ይሁኑ። ችግሮች ሁልጊዜም ሳይታሰብ ይነሳሉ.
• ብዙውን ጊዜ አርክቴክቸርን በፍጥነት እንደገና ለመሥራት የማይቻል ነው. በተለይም በበርካታ ጠቋሚዎች ላይ ከፍተኛውን አስተማማኝነት ማግኘት ከፈለጉ. ብዙ አንጓዎች፣ ለድጋፍ የሚያስፈልጉ ተጨማሪ ሀብቶች።
• ሁሉም ብጁ እና የባለቤትነት መፍትሄዎች ለምርምር፣ ድጋፍ እና ጥገና ተጨማሪ ግብዓቶችን ይፈልጋሉ።
• ከውድቀቶች በኋላ የስርዓት አስተማማኝነት እና መልሶ ማገገም ጉዳዮችን መፍታት አያቁሙ ፣ በመነሻ ዲዛይን ደረጃ ላይ ግምት ውስጥ ያስገቡ።

ምንጭ: hab.com