මෙය හුවමාරුවේ ක්‍රියාකාරිත්වය සහතික කරන බලගතු, අධික බර පද්ධතියක් නිර්මාණය කිරීම සඳහා අපගේ කටු සහිත මාර්ගය පිළිබඳ දිගු කතාවක අඛණ්ඩ පැවැත්මකි. පළමු කොටස මෙන්න:
අද්භූත දෝෂයක්
බොහෝ පරීක්ෂණ වලින් පසුව, යාවත්කාලීන කරන ලද වෙළඳ සහ නිෂ්කාශන පද්ධතිය ක්රියාත්මක කරන ලද අතර, අපට රහස් පරීක්ෂක-ගුප්ත කතාවක් ලිවිය හැකි දෝෂයක් අපට හමු විය.
ප්රධාන සේවාදායකයේ දියත් කිරීමෙන් ටික කලකට පසු, එක් ගනුදෙනුවක් දෝෂයක් සමඟ සැකසුණි. කෙසේ වෙතත්, උපස්ථ සේවාදායකයේ සියල්ල හොඳින් විය. ප්රධාන සේවාදායකයේ ඝාතකය ගණනය කිරීමේ සරල ගණිතමය මෙහෙයුමක් සැබෑ තර්කයෙන් ඍණාත්මක ප්රතිඵලයක් ලබා දුන් බව පෙනී ගියේය! අපි අපගේ පර්යේෂණ දිගටම කරගෙන ගිය අතර, SSE2 ලේඛනයේ දී අපි එක බිට් එකක වෙනසක් සොයා ගත්තෙමු, එය පාවෙන ලක්ෂ්‍ය අංක සමඟ වැඩ කිරීමේදී වටකුරු කිරීම සඳහා වගකිව යුතුය.
වටකුරු බිටු කට්ටලය සමඟ ඝාතකය ගණනය කිරීම සඳහා අපි සරල පරීක්ෂණ උපයෝගීතාවයක් ලිව්වෙමු. අපි භාවිතා කළ RedHat Linux අනුවාදයේ, අවාසනාවන්ත බිට් එක ඇතුළු කළ විට ගණිතමය ශ්‍රිතය සමඟ වැඩ කිරීමේ දෝෂයක් ඇති බව පෙනී ගියේය. අපි මෙය RedHat වෙත වාර්තා කළෙමු, ටික වේලාවකට පසු අපට ඔවුන්ගෙන් පැච් එකක් ලැබී එය රෝල් කළා. දෝෂය තවදුරටත් සිදු නොවීය, නමුත් මෙම බිට් එක පැමිණියේ කොහෙන්ද යන්න පැහැදිලි නැත. කාර්යය එයට වගකිව යුතු විය fesetround සී භාෂාවෙන් අපි අපේ කේතය ප්‍රවේශමෙන් විශ්ලේෂණය කළේ යැයි කියනු ලබන දෝෂය සෙවීම සඳහා: අපි හැකි සියලු අවස්ථා පරීක්ෂා කළෙමු; වටකුරු භාවිතා කරන සියලුම කාර්යයන් දෙස බැලුවා; අසාර්ථක සැසියක් ප්රතිනිෂ්පාදනය කිරීමට උත්සාහ කළා; විවිධ විකල්ප සමඟ විවිධ සම්පාදක භාවිතා කරන ලදී; ස්ථිතික සහ ගතික විශ්ලේෂණය භාවිතා කරන ලදී.
දෝෂයට හේතුව සොයාගත නොහැකි විය.
ඉන්පසු ඔවුන් දෘඩාංග පරීක්ෂා කිරීමට පටන් ගත්හ: ඔවුන් ප්‍රොසෙසරවල බර පරීක්ෂා කිරීම සිදු කළහ; RAM පරීක්ෂා කළා; අපි එක් සෛලයක බහු-බිට් දෝෂයක් ඇති විය නොහැකි අවස්ථාව සඳහා පරීක්ෂණ පවා සිදු කළෙමු. ඵලක් නැත.
අවසානයේදී, අපි අධි ශක්ති භෞතික විද්‍යා ලෝකයේ න්‍යායක් මත පදිංචි විය: සමහර අධි ශක්ති අංශුවක් අපගේ දත්ත මධ්‍යස්ථානයට පියාසර කර, කේස් බිත්තිය සිදුරු කර, ප්‍රොසෙසරයේ වැදී, ප්‍රේරක අගුල එම ටිකේම ඇලවීමට හේතු විය. මෙම විකාර සිද්ධාන්තය හැඳින්වූයේ "නියුට්‍රිනෝ" යනුවෙනි. ඔබ අංශු භෞතික විද්‍යාවෙන් ඈත්ව සිටින්නේ නම්: නියුට්‍රිනෝ බාහිර ලෝකය සමඟ පාහේ අන්තර් ක්රියා නොකරන අතර, ප්‍රොසෙසරයේ ක්‍රියාකාරිත්වයට නිසැකවම බලපෑම් කිරීමට හැකියාවක් නැත.
අසාර්ථක වීමට හේතුව සොයා ගැනීමට නොහැකි වූ නිසා, "අහිතකර" සේවාදායකය ක්රියාවෙන් ඉවත් කරන ලදී.
ටික වේලාවකට පසු, අපි උණුසුම් උපස්ථ පද්ධතිය වැඩිදියුණු කිරීමට පටන් ගත්තෙමු: අපි ඊනියා “උණුසුම් සංචිත” (උණුසුම්) - අසමමුහුර්ත අනුරූ හඳුන්වා දුන්නෙමු. විවිධ දත්ත මධ්‍යස්ථානවල ස්ථානගත කළ හැකි ගනුදෙනු ප්‍රවාහයක් ඔවුන්ට ලැබුණි, නමුත් උණුසුම වෙනත් සේවාදායකයන් සමඟ සක්‍රියව අන්තර්ක්රියා කළේ නැත.
මෙය සිදු කළේ ඇයි? උපස්ථ සේවාදායකය අසමත් වුවහොත්, ප්රධාන සේවාදායකයට සම්බන්ධ වූ උණුසුම් නව උපස්ථය බවට පත්වේ. එනම්, අසාර්ථක වීමෙන් පසුව, වෙළඳ සැසිය අවසන් වන තෙක් පද්ධතිය එක් ප්රධාන සේවාදායකයක් සමඟ නොපවතී.
තවද පද්ධතියේ නව අනුවාදය පරීක්ෂා කර ක්රියාත්මක කළ විට, වටකුරු බිට් දෝෂය නැවත සිදු විය. එපමණක් නොව, උණුසුම් සේවාදායකයන් සංඛ්යාව වැඩිවීමත් සමග, දෝෂය බොහෝ විට පෙනෙන්නට පටන් ගත්තේය. ඒ අතරම, නිශ්චිත සාක්ෂි නොමැති බැවින්, වෙළෙන්දාට පෙන්වීමට කිසිවක් නොතිබුණි.
තත්වය පිළිබඳ ඊළඟ විශ්ලේෂණය අතරතුර, ගැටළුව OS සමඟ සම්බන්ධ විය හැකි බවට න්‍යායක් මතු විය. අපි නිමක් නැති ලූපයක ශ්‍රිතයක් කැඳවන සරල වැඩසටහනක් ලිව්වෙමු fesetround, වත්මන් තත්ත්වය මතක තබාගෙන එය නින්ද හරහා පරීක්ෂා කරයි, මෙය බොහෝ තරඟකාරී නූල් වල සිදු කෙරේ. නින්ද සඳහා පරාමිතීන් සහ නූල් ගණන තෝරා ගැනීමෙන් පසුව, උපයෝගීතාව ක්රියාත්මක කිරීමෙන් විනාඩි 5 ක් පමණ පසු අපි බිට් අසාර්ථකත්වය නිරන්තරයෙන් ප්රතිනිෂ්පාදනය කිරීමට පටන් ගත්තෙමු. කෙසේ වෙතත්, Red Hat සහායට එය ප්රතිනිෂ්පාදනය කිරීමට නොහැකි විය. අපගේ අනෙකුත් සේවාදායකයන් පරීක්ෂා කිරීමෙන් පෙන්නුම් කර ඇත්තේ ඇතැම් ප්‍රොසෙසර ඇති ඒවා පමණක් දෝෂයට ගොදුරු විය හැකි බවයි. ඒ සමගම, නව කර්නලයකට මාරු වීමෙන් ගැටළුව විසඳා ඇත. අවසානයේදී, අපි සරලවම OS වෙනුවට ආදේශ කළ අතර, දෝෂයේ සැබෑ හේතුව අපැහැදිලි විය.
පසුගිය වසරේ හදිසියේම හබ්රේ හි ලිපියක් පළ විය." එහි විස්තර කර ඇති තත්වය අපගේ තත්වයට බෙහෙවින් සමාන වූ නමුත් කතුවරයා විමර්ශනය තවදුරටත් ඉදිරියට ගෙන ගොස් දෝෂය මයික්‍රොකෝඩ් හි ඇති බවට න්‍යායක් ඉදිරිපත් කළේය. ලිනක්ස් කර්නල් යාවත්කාලීන කරන විට, නිෂ්පාදකයින් මයික්‍රොකෝඩ් යාවත්කාලීන කරයි.
පද්ධතියේ තවදුරටත් සංවර්ධනය
අපි දෝෂයෙන් මිදුනත්, පද්ධති ගෘහ නිර්මාණ ශිල්පය නැවත සලකා බැලීමට මෙම කතාව අපට බල කළේය. ඇත්ත වශයෙන්ම, එවැනි දෝෂ පුනරාවර්තනයෙන් අපව ආරක්ෂා කර නැත.
වෙන් කිරීමේ ක්‍රමයේ මීළඟ වැඩිදියුණු කිරීම් සඳහා පහත සඳහන් මූලධර්ම පදනම් විය:
- ඔබට කිසිවෙකු විශ්වාස කළ නොහැක. සේවාදායකයන් නිසි ලෙස ක්රියා නොකරනු ඇත.
- බහුතර වෙන් කිරීම.
- සම්මුතිය සහතික කිරීම. බහුතර වෙන් කිරීම සඳහා තාර්කික එකතු කිරීමක් ලෙස.
- ද්විත්ව අසාර්ථකත්වයන් හැකි ය.
- ජීව ගුණය. නව උණුසුම් පොරොත්තු යෝජනා ක්රමය පෙර එකට වඩා නරක නොවිය යුතුය. වෙළඳාම අවසන් සේවාදායකය තෙක් අඛණ්ඩව සිදු විය යුතුය.
- ප්රමාදයේ සුළු වැඩිවීමක්. ඕනෑම අක්‍රිය කාලයක් විශාල මූල්‍ය පාඩු ඇති කරයි.
- ප්‍රමාදය හැකිතාක් අඩු මට්ටමක තබා ගැනීමට අවම ජාල අන්තර්ක්රියා.
- තත්පර කිහිපයකින් නව ප්රධාන සේවාදායකයක් තෝරා ගැනීම.
වෙළඳපොලේ ඇති විසඳුම් කිසිවක් අපට නොගැලපෙන අතර, Raft protocol තවමත් එහි ආරම්භක අවධියේ පැවතියේ, එබැවින් අපි අපගේම විසඳුමක් නිර්මාණය කළෙමු.
ජාලකරණය
වෙන් කිරීමේ පද්ධතියට අමතරව, අපි ජාල අන්තර්ක්රියා නවීකරණය කිරීම ආරම්භ කළෙමු. I/O උප පද්ධතිය බොහෝ ක්‍රියාවලි වලින් සමන්විත වූ අතර, එය ජ්වලිතය සහ ප්‍රමාදය කෙරෙහි නරකම බලපෑමක් ඇති කළේය. TCP සම්බන්ධතා හසුරුවන ක්‍රියාවලි සිය ගණනක් සමඟින්, ඒවා අතර නිරන්තරයෙන් මාරු වීමට අපට බල කෙරුණු අතර, මයික්‍රෝ තත්පර පරිමාණයෙන් මෙය තරමක් කාලය ගතවන මෙහෙයුමකි. නමුත් නරකම දෙය නම්, ක්‍රියාවලියකට සැකසීම සඳහා පැකට්ටුවක් ලැබුණු විට, එය එක් SystemV පෝලිමකට යවා වෙනත් SystemV පෝලිමකින් සිදුවීමක් එනතෙක් බලා සිටීමයි. කෙසේ වෙතත්, නෝඩ් විශාල සංඛ්‍යාවක් ඇති විට, එක් ක්‍රියාවලියක නව TCP පැකට්ටුවක් පැමිණීම සහ තවත් ක්‍රියාවලියක පෝලිමේ දත්ත ලැබීම OS සඳහා තරඟකාරී සිදුවීම් දෙකක් නියෝජනය කරයි. මෙම අවස්ථාවේදී, කාර්යයන් දෙකම සඳහා භෞතික සකසනයන් නොමැති නම්, එකක් සකසනු ලබන අතර, දෙවැන්න පොරොත්තු පෝලිමක තබා ඇත. ප්රතිවිපාක ගැන අනාවැකි කිව නොහැක.
එවැනි අවස්ථාවන්හිදී, ගතික ක්‍රියාවලි ප්‍රමුඛතා පාලනය භාවිතා කළ හැක, නමුත් මේ සඳහා සම්පත්-දැඩි පද්ධති ඇමතුම් භාවිතා කිරීම අවශ්ය වේ. එහි ප්රතිඵලයක් වශයෙන්, අපි සම්භාව්‍ය epoll භාවිතයෙන් එක් ත්‍රෙඩ් එකකට මාරු වූවෙමු, මෙය වේගය බෙහෙවින් වැඩි කර ගනුදෙනු සැකසීමේ කාලය අඩු කළේය. අපි වෙනම ජාල සන්නිවේදන ක්‍රියාවලීන් සහ SystemV හරහා සන්නිවේදනය ඉවත් කර, පද්ධති ඇමතුම් ගණන සැලකිය යුතු ලෙස අඩු කර මෙහෙයුම්වල ප්‍රමුඛතා පාලනය කිරීමට පටන් ගත්තෙමු. I/O උප පද්ධතිය මත පමණක්, තත්වය අනුව, මයික්‍රෝ තත්පර 8-17ක් පමණ ඉතිරි කර ගැනීමට හැකි විය. මෙම තනි නූල් යෝජනා ක්රමය එතැන් සිට නොවෙනස්ව භාවිතා කර ඇත; සියලු සම්බන්ධතා සඳහා ආන්තිකයක් සහිත එක් epoll නූල් එකක් ප්‍රමාණවත් වේ.
ගනුදෙනු සැකසීම
අපගේ පද්ධතියේ වැඩෙන බරට එහි සියලුම සංරචක පාහේ යාවත්කාලීන කිරීමට අවශ්ය විය. එහෙත්, අවාසනාවකට මෙන්, මෑත වසරවල ප්‍රොසෙසර ඔරලෝසු වේගයේ වර්ධනයේ එකතැන පල්වීම නිසා තවදුරටත් ක්‍රියාවලි හිස මත පරිමාණය කිරීමට නොහැකි වී ඇත. එබැවින්, එන්ජින් ක්‍රියාවලිය මට්ටම් තුනකට බෙදීමට අපි තීරණය කළෙමු, ඒවායින් වඩාත් කාර්යබහුල වන්නේ අවදානම් පිරික්සුම් පද්ධතිය වන අතර, එමඟින් ගිණුම්වල අරමුදල් තිබේද යන්න තක්සේරු කර ගනුදෙනු තමන් විසින්ම සිදු කරයි. නමුත් මුදල් විවිධ මුදල් වලින් විය හැකි අතර, ඉල්ලීම් සැකසීම බෙදිය යුත්තේ කුමන පදනමක් මතදැයි සොයා බැලීම අවශ්ය විය.
තාර්කික විසඳුම වන්නේ එය මුදල් වලින් බෙදීමයි: එක් සේවාදායකයක් ඩොලර් වලින්, තවත් එකක් පවුම් වලින් සහ තුනෙන් එකක් යුරෝ වලින් වෙළඳාම් කරයි. නමුත් මෙම යෝජනා ක්රමය සමඟ විවිධ මුදල් වර්ග මිලදී ගැනීම සඳහා ගනුදෙනු දෙකක් යවනු ලැබුවහොත්, මුදල් පසුම්බිය සමමුහුර්ත කිරීමේ ගැටළුව පැන නගී. නමුත් සමමුහුර්ත කිරීම දුෂ්කර හා මිල අධිකයි. ඒ නිසා මුදල් පසුම්බි වලින් වෙන වෙනමත් උපකරණ වලින් වෙන වෙනමත් කඩනවා නම් නිවැරදියි. මාර්ගය වන විට, බොහෝ බටහිර හුවමාරුවලට අප මෙන් හදිසි අවදානම් පරීක්ෂා කිරීමේ කාර්යයක් නොමැත, එබැවින් බොහෝ විට මෙය නොබැඳි ලෙස සිදු කෙරේ. අපට සබැඳි සත්‍යාපනය ක්රියාත්මක කිරීමට අවශ්ය විය.
උදාහරණයකින් පැහැදිලි කරමු. වෙළෙන්දෙකුට ඩොලර් 30 ක් මිලදී ගැනීමට අවශ්ය වන අතර, ඉල්ලීම ගනුදෙනු වලංගු කිරීම වෙත යයි: මෙම වෙළෙන්දාට මෙම වෙළඳ ප්‍රකාරයට අවසර තිබේද සහ ඔහුට අවශ්ය අයිතිවාසිකම් තිබේද යන්න අපි පරීක්ෂා කරමු. සෑම දෙයක්ම පිළිවෙලට තිබේ නම්, ඉල්ලීම අවදානම් තහවුරු කිරීමේ පද්ධතියට යයි, i.e. ගනුදෙනුවක් අවසන් කිරීම සඳහා අරමුදල් ප්රමාණවත්දැයි පරීක්ෂා කිරීමට. අවශ්ය ප්‍රමාණය දැනට අවහිර කර ඇති බවට සටහනක් ඇත. ඉල්ලීම පසුව ගනුදෙනුව අනුමත කරන හෝ ප්රතික්ෂේප කරන වෙළඳ පද්ධතියට යවනු ලැබේ. ගනුදෙනුව අනුමත කර ඇතැයි කියමු - එවිට අවදානම් සත්‍යාපන පද්ධතිය මුදල් අවහිර කර ඇති බව සලකුණු කරන අතර රුබල් ඩොලර් බවට පත් වේ.
පොදුවේ ගත් කල, අවදානම් පිරික්සුම් පද්ධතිය සංකීර්ණ ඇල්ගොරිතම අඩංගු වන අතර ඉතා සම්පත්-දැඩි ගණනය කිරීම් විශාල ප්‍රමාණයක් සිදු කරයි, සහ බැලූ බැල්මට පෙනෙන පරිදි “ගිණුම් ශේෂය” සරලව පරීක්ෂා නොකරයි.
අපි එන්ජින් ක්‍රියාවලිය මට්ටම් වලට බෙදීමට පටන් ගත් විට, අපට ගැටලුවකට මුහුණ දීමට සිදු විය: එකල ලබා ගත හැකි කේතය වලංගු කිරීමේ සහ සත්‍යාපන අදියරේදී එකම දත්ත මාලාවක් ක්‍රියාකාරීව භාවිතා කළ අතර, ඒ සඳහා සම්පූර්ණ කේත පදනම නැවත ලිවීමට අවශ්ය විය. එහි ප්රතිඵලයක් වශයෙන්, අපි නවීන ප්රොසෙසරයන්ගෙන් උපදෙස් සැකසීම සඳහා තාක්ෂණයක් ණයට ගත්තෙමු: ඒවා එක් එක් කුඩා අදියරවලට බෙදී ඇති අතර එක් චක්රයක් තුළ ක්රියාවන් කිහිපයක් සමාන්තරව සිදු කරනු ලැබේ.
කේතයේ කුඩා අනුවර්තනයකින් පසුව, අපි සමාන්තර ගනුදෙනු සැකසීම සඳහා නල මාර්ගයක් නිර්මාණය කළෙමු, එහිදී ගනුදෙනුව නල මාර්ගයේ අදියර 4 කට බෙදා ඇත: ජාල අන්තර්ක්රියා, වලංගුකරණය, ක්රියාත්මක කිරීම සහ ප්‍රතිඵලය ප්‍රකාශනය කිරීම
අපි උදාහරණයක් බලමු. අපට අනුක්‍රමික සහ සමාන්තර සැකසුම් පද්ධති දෙකක් ඇත. පළමු ගනුදෙනුව පැමිණ පද්ධති දෙකෙහිම වලංගු කිරීම සඳහා යවනු ලැබේ. දෙවන ගනුදෙනුව වහාම පැමිණේ: සමාන්තර පද්ධතියක එය වහාම ක්රියාත්මක වන අතර අනුක්‍රමික පද්ධතියක එය පළමු ගනුදෙනුව වත්මන් සැකසුම් අදියර හරහා යාමට බලා සිටින පෝලිමක තබා ඇත. එනම්, නල මාර්ග සැකසීමේ ප්රධාන වාසිය වන්නේ අපි ගනුදෙනු පෝලිම වේගයෙන් සැකසීමයි.
මේ විදියට තමයි අපි ASTS+ පද්ධතිය ගෙනාවේ.
වාහක සමඟ සෑම දෙයක්ම එතරම් සුමට නොවන බව ඇත්තකි. අසල්වැසි ගනුදෙනුවක දත්ත අරාවලට බලපාන ගනුදෙනුවක් අප සතුව ඇතැයි කියමු; මෙය හුවමාරුවක් සඳහා සාමාන්‍ය තත්ත්වයකි. එවැනි ගනුදෙනුවක් නල මාර්ගයක් තුළ සිදු කළ නොහැක, මන්ද එය අන් අයට බලපානු ඇත. මෙම තත්ත්වය දත්ත උපද්රව ලෙස හඳුන්වනු ලබන අතර, එවැනි ගනුදෙනු සරලව සකසනු ලැබේ: පෝලිමේ "වේගවත්" ගනුදෙනු අවසන් වූ විට, නල මාර්ගය නතර වේ, පද්ධතිය "මන්දගාමී" ගනුදෙනුව සකසයි, පසුව නැවත නල මාර්ගය ආරම්භ කරයි. වාසනාවකට මෙන්, සමස්ත ප්රවාහයේ එවැනි ගනුදෙනු වල අනුපාතය ඉතා කුඩා වන අතර, එම නිසා නල මාර්ගය ඉතා කලාතුරකින් නතර වන අතර එය සමස්ත කාර්යසාධනයට බලපාන්නේ නැත.
ඉන්පසුව අපි ක්රියාත්මක කිරීමේ නූල් තුනක් සමමුහුර්ත කිරීමේ ගැටලුව විසඳීමට පටන් ගත්තෙමු. එහි ප්‍රතිඵලය වූයේ ස්ථාවර ප්‍රමාණයේ සෛල සහිත මුදු බෆරයක් මත පදනම් වූ පද්ධතියකි. මෙම පද්ධතිය තුළ, සෑම දෙයක්ම සැකසුම් වේගයට යටත් වේ; දත්ත පිටපත් නොකෙරේ.
- පැමිණෙන සියලුම ජාල පැකට් වෙන් කිරීමේ අදියරට ඇතුල් වේ.
- අපි ඒවා අරාවක තබා #1 අදියර සඳහා ලබා ගත හැකි ලෙස සලකුණු කරමු.
- දෙවන ගනුදෙනුව පැමිණ ඇත, එය නැවත අදියර අංක 1 සඳහා ලබා ගත හැකිය.
- පළමු සැකසුම් ත්‍රෙඩ් එක පවතින ගනුදෙනු දකියි, ඒවා ක්‍රියාවට නංවා, ඒවා දෙවන සැකසුම් නූලෙහි ඊළඟ අදියර වෙත ගෙන යයි.
- එය පසුව පළමු ගනුදෙනුව සකසන අතර අදාළ කොටුව සලකුණු කරයි
deleted- එය දැන් නව භාවිතය සඳහා ලබා ගත හැකිය.
සම්පූර්ණ පෝලිම මේ ආකාරයෙන් සකස් කර ඇත.
එක් එක් අදියර සැකසීමට ඒකක හෝ මයික්‍රො තත්පර දස ගණනක් ගතවේ. තවද අපි සම්මත OS සමමුහුර්තකරණ යෝජනා ක්රම භාවිතා කරන්නේ නම්, සමමුහුර්තකරණයේදීම අපට වැඩි කාලයක් අහිමි වනු ඇත. ඒකයි අපි ස්පින්ලොක් පාවිච්චි කරන්න පටන් ගත්තේ. කෙසේ වෙතත්, මෙය තත්‍ය කාලීන පද්ධතියක ඉතා නරක ආකාරයක් වන අතර, RedHat මෙය කිරීමට දැඩි ලෙස නිර්දේශ නොකරයි, එබැවින් අපි 100 ms සඳහා ස්පින්ලොක් එකක් යොදන්නෙමු, පසුව අවහිර වීමේ හැකියාව ඉවත් කිරීම සඳහා සෙමාෆෝර් ප්‍රකාරයට මාරු වෙමු.
එහි ප්රතිඵලයක් වශයෙන් අපි තත්පරයකට ගනුදෙනු මිලියන 8ක පමණ කාර්ය සාධනයක් ලබා ගත්තෙමු. සහ වචනාර්ථයෙන් මාස දෙකකට පසුව LMAX Disruptor ගැන අපි එකම ක්‍රියාකාරීත්වයක් සහිත පරිපථයක විස්තරයක් දුටුවෙමු.
දැන් එක් අදියරකදී ක්රියාත්මක කිරීමේ නූල් කිහිපයක් තිබිය හැකිය. සියලුම ගනුදෙනු එකින් එක, ලැබුණු අනුපිළිවෙල අනුව සකස් කරන ලදී. එහි ප්රතිඵලයක් වශයෙන්, උපරිම කාර්ය සාධනය තත්පරයකට ගනුදෙනු 18 සිට 50 දක්වා වැඩි විය.
හුවමාරු අවදානම් කළමනාකරණ පද්ධතිය
පරිපූර්ණත්වයට සීමාවක් නොමැති අතර, ඉක්මනින්ම අපි නැවත නවීකරණය ආරම්භ කළෙමු: ASTS+ රාමුව තුළ, අපි අවදානම් කළමනාකරණය සහ බේරුම්කරණ මෙහෙයුම් පද්ධති ස්වයංක්‍රීය සංරචක බවට ගෙන යාමට පටන් ගත්තෙමු. අපි නම්‍යශීලී නවීන ගෘහනිර්මාණ ශිල්පයක් සහ නව ධූරාවලි අවදානම් ආකෘතියක් වර්ධනය කර, හැකි සෑම තැනකම පන්තිය භාවිතා කිරීමට උත්සාහ කළෙමු fixed_point වෙනුවට double.
නමුත් වහාම ගැටළුවක් මතු විය: වසර ගණනාවක් තිස්සේ වැඩ කර ඇති සියලුම ව්යාපාර තර්කනය සමමුහුර්ත කර එය නව පද්ධතියට මාරු කරන්නේ කෙසේද? එහි ප්රතිඵලයක් වශයෙන්, නව පද්ධතියේ මූලාකෘතියේ පළමු අනුවාදය අත්හැර දැමීමට සිදු විය. දැනට නිෂ්පාදනයේ ක්රියාත්මක වන දෙවන අනුවාදය, වෙළඳාම සහ අවදානම් කොටස් දෙකෙහිම ක්රියා කරන එකම කේතය මත පදනම් වේ. සංවර්ධනය අතරතුර, කළ යුතු දුෂ්කරම දෙය නම් අනුවාද දෙකක් අතර git ඒකාබද්ධ කිරීමයි. අපගේ සගයා Evgeniy Mazurenok සෑම සතියකම මෙම මෙහෙයුම සිදු කළ අතර සෑම අවස්ථාවකදීම ඔහු ඉතා දිගු කාලයක් ශාප කළේය.
නව පද්ධතියක් තෝරාගැනීමේදී, අපි වහාම අන්තර්ක්රියා පිළිබඳ ගැටළුව විසඳීමට සිදු විය. දත්ත බසයක් තෝරාගැනීමේදී, ස්ථාවර ජ්වලිතය සහ අවම ප්‍රමාදය සහතික කිරීම අවශ්ය විය. InfiniBand RDMA ජාලය මේ සඳහා වඩාත් සුදුසු විය: සාමාන්‍ය සැකසුම් කාලය G Ethernet ජාල 4 ට වඩා 10 ගුණයකින් අඩුය. නමුත් ඇත්ත වශයෙන්ම අපව ආකර්ෂණය කළේ ප්‍රතිශතවල වෙනසයි - 99 සහ 99,9.
ඇත්ත වශයෙන්ම, InfiniBand එහි අභියෝග ඇත. පළමුව, වෙනත් API - සොකට් වෙනුවට ibverbs. දෙවනුව, පුළුල් ලෙස ලබා ගත හැකි විවෘත මූලාශ්ර පණිවිඩකරණ විසඳුම් නොමැති තරම්ය. අපි අපේම මූලාකෘතියක් සෑදීමට උත්සාහ කළෙමු, නමුත් එය ඉතා අපහසු විය, එබැවින් අපි වාණිජ විසඳුමක් තෝරා ගත්තෙමු - Confinity Low Latency Messaging (කලින් IBM MQ LLM).
එවිට අවදානම් පද්ධතිය නිසි ලෙස බෙදීමේ කාර්යය මතු විය. ඔබ හුදෙක් අවදානම් එන්ජිම ඉවත් කර අතරමැදි නෝඩයක් නිර්මාණය නොකරන්නේ නම්, මූලාශ්ර දෙකකින් ගනුදෙනු මිශ්ර කළ හැක.
ඊනියා Ultra Low Latency විසඳුම්වලට නැවත ඇණවුම් කිරීමේ මාදිලියක් ඇත: මූලාශ්ර දෙකකින් ගනුදෙනු ලැබීමෙන් පසු අවශ්ය අනුපිළිවෙලට සකස් කළ හැකිය; ඇණවුම පිළිබඳ තොරතුරු හුවමාරු කර ගැනීම සඳහා වෙනම නාලිකාවක් භාවිතයෙන් මෙය ක්රියාත්මක වේ. නමුත් අපි තවමත් මෙම මාදිලිය භාවිතා නොකරමු: එය සමස්ත ක්රියාවලියම සංකීර්ණ වන අතර, විසඳුම් ගණනාවකින් එය කිසිසේත්ම සහාය නොදක්වයි. මීට අමතරව, සෑම ගනුදෙනුවකටම අනුරූප වේලා මුද්දර පැවරිය යුතු අතර, අපගේ යෝජනා ක්රමය තුළ මෙම යාන්ත්‍රණය නිවැරදිව ක්රියාත්මක කිරීම ඉතා අපහසු වේ. එමනිසා, අපි සම්භාව්‍ය යෝජනා ක්රමය භාවිතා කළේ පණිවිඩ තැරැව්කරුවෙකු සමඟ, එනම් අවදානම් එන්ජිම අතර පණිවිඩ බෙදා හරින ඩිස්පචර් සමඟ ය.
දෙවන ගැටළුව සේවාලාභී ප්‍රවේශයට සම්බන්ධ විය: අවදානම් ද්වාර කිහිපයක් තිබේ නම්, සේවාලාභියාට ඒ සෑම එකක්ම සම්බන්ධ කිරීමට අවශ්ය වන අතර, මෙය සේවාදායක ස්ථරයට වෙනස්කම් අවශ්ය වේ. අපට මෙම අදියරේදී මෙයින් ඉවත් වීමට අවශ්ය විය, එබැවින් වත්මන් අවදානම් ද්වාර සැලසුම සමස්ත දත්ත ප්‍රවාහයම සකසයි. මෙය උපරිම ප්‍රතිදානය බෙහෙවින් සීමා කරයි, නමුත් පද්ධති ඒකාබද්ධ කිරීම බෙහෙවින් සරල කරයි.
අනුපිටපතක්
අපගේ පද්ධතියට අසාර්ථක වීමේ එක් කරුණක් නොතිබිය යුතුය, එනම් පණිවිඩ තැරැව්කරු ඇතුළුව සියලුම සංරචක අනුපිටපත් කළ යුතුය. අපි CLLM පද්ධතිය භාවිතයෙන් මෙම ගැටළුව විසඳා ගත්තෙමු: එහි RCMS පොකුරක් අඩංගු වන අතර එහි පිටත් කරන්නන් දෙදෙනෙකුට මාස්ටර්-ස්ලේව් මාදිලියේ වැඩ කළ හැකි අතර, එකක් අසමත් වූ විට, පද්ධතිය ස්වයංක්‍රීයව අනෙකට මාරු වේ.
උපස්ථ දත්ත මධ්‍යස්ථානයක් සමඟ වැඩ කිරීම
InfiniBand දේශීය ජාලයක් ලෙස ක්රියා කිරීම සඳහා ප්‍රශස්ත කර ඇත, එනම්, රාක්ක සවිකිරීම් උපකරණ සම්බන්ධ කිරීම සඳහා, සහ භූගෝලීය වශයෙන් බෙදා හරින ලද දත්ත මධ්‍යස්ථාන දෙකක් අතර InfiniBand ජාලයක් තැබිය නොහැක. එබැවින්, අපි සාමාන්‍ය ඊතර්නෙට් ජාල හරහා පණිවිඩ ගබඩාවට සම්බන්ධ වන අතර සියලුම ගනුදෙනු දෙවන IB ජාලයකට රිලේ කරන පාලමක්/ඩිස්පැචර් එකක් ක්රියාත්මක කළෙමු. අපට දත්ත මධ්‍යස්ථානයකින් සංක්‍රමණය වීමට අවශ්ය වූ විට, අපට දැන් ක්රියා කළ යුතු දත්ත මධ්‍යස්ථානය තෝරාගත හැක.
ප්රතිඵල
ඉහත සියල්ල එකවර සිදු නොකළ අතර නව ගෘහ නිර්මාණ ශිල්පයක් සංවර්ධනය කිරීම සඳහා පුනරාවර්තන කිහිපයක් ගත විය. අපි මාසයක් තුළ මූලාකෘතිය නිර්මාණය කළ නමුත්, එය ක්රියාකාරී තත්ත්වයට පත් කිරීමට වසර දෙකකට වඩා වැඩි කාලයක් ගත විය. ගනුදෙනු සැකසීමේ කාලය වැඩි කිරීම සහ පද්ධති විශ්වසනීයත්වය වැඩි කිරීම අතර හොඳම සම්මුතිය ලබා ගැනීමට අපි උත්සාහ කළෙමු.
පද්ධතිය දැඩි ලෙස යාවත්කාලීන කර ඇති බැවින්, අපි ස්වාධීන මූලාශ්ර දෙකකින් දත්ත ප්‍රතිසාධනය ක්රියාත්මක කළෙමු. කිසියම් හේතුවක් නිසා පණිවිඩ ගබඩාව නිවැරදිව ක්රියාත්මක නොවන්නේ නම්, ඔබට ගනුදෙනු ලොගය දෙවන මූලාශ්‍රයකින් - අවදානම් එන්ජිමෙන් ගත හැකිය. මෙම මූලධර්මය පද්ධතිය පුරා නිරීක්ෂණය කරනු ලැබේ.
වෙනත් දේ අතර, නව ගෘහ නිර්මාණ ශිල්පය සඳහා තැරැව්කරුවන්ට හෝ වෙනත් කිසිවෙකුට සැලකිය යුතු ප්‍රතිනිර්මාණයක් අවශ්ය නොවන පරිදි සේවාදායක API සංරක්ෂණය කිරීමට අපට හැකි විය. අපට සමහර අතුරුමුහුණත් වෙනස් කිරීමට සිදු විය, නමුත් මෙහෙයුම් ආකෘතියේ සැලකිය යුතු වෙනස්කම් කිරීමට අවශ්ය නොවීය.
අපි අපගේ වේදිකාවේ වත්මන් අනුවාදය Rebus ලෙස හැඳින්වුවෙමු - ගෘහ නිර්මාණ ශිල්පයේ වඩාත්ම කැපී පෙනෙන නවෝත්පාදනයන් දෙක වන අවදානම් එන්ජිම සහ BUS සඳහා කෙටි යෙදුමක් ලෙස.
මුලදී, අපට අවශ්ය වූයේ පිරිසිදු කිරීමේ කොටස පමණක් වෙන් කිරීමට, නමුත් ප්‍රතිඵලය වූයේ විශාල බෙදාහැරීමේ පද්ධතියකි. ගනුදෙනුකරුවන්ට දැන් වෙළඳ ද්වාරය, නිෂ්කාශන ද්වාරය හෝ දෙකම සමඟ අන්තර් ක්රියා කළ හැක.
අපි අවසානයේ ලබා ගත් දේ:
ප්‍රමාද මට්ටම අඩු කළා. කුඩා ගනුදෙනු පරිමාවක් සමඟ, පද්ධතිය පෙර අනුවාදයට සමානව ක්රියා කරයි, නමුත් ඒ සමඟම වැඩි බරකට ඔරොත්තු දිය හැකිය.
උපරිම කාර්ය සාධනය තත්පරයකට ගනුදෙනු 50 සිට 180 දක්වා වැඩි විය. අනුපිළිවෙල ගැලපීමේ එකම ප්‍රවාහය මගින් තවත් වැඩි වීමක් බාධා වේ.
තව දුරටත් වැඩිදියුණු කිරීම සඳහා ක්රම දෙකක් තිබේ: ගැලපීම සමාන්තරකරණය කිරීම සහ එය Gateway සමඟ ක්රියා කරන ආකාරය වෙනස් කිරීම. දැන් සියලුම ගේට්වේ ක්රියාත්මක වන්නේ ප්‍රතිනිර්මාණ යෝජනා ක්‍රමයකට අනුව වන අතර, එවැනි බරක් යටතේ සාමාන්‍යයෙන් ක්රියා කිරීම නවත්වයි.
අවසාන වශයෙන්, ව්යවසාය පද්ධති අවසන් කරන අයට උපදෙස් කිහිපයක් ලබා දිය හැකිය:
- සෑම විටම නරකම දේ සඳහා සූදානම්ව සිටින්න. ගැටළු සෑම විටම අනපේක්ෂිත ලෙස පැන නගී.
- ගෘහ නිර්මාණ ශිල්පය ඉක්මනින් ප්‍රතිනිර්මාණය කිරීම සාමාන්‍යයෙන් කළ නොහැක්කකි. විශේෂයෙන්ම ඔබට බහු දර්ශක හරහා උපරිම විශ්වසනීයත්වය ලබා ගැනීමට අවශ්ය නම්. නෝඩ් වැඩි වන තරමට ආධාරකයට අවශ්ය සම්පත් වැඩි වේ.
- සියලුම අභිරුචි සහ හිමිකාර විසඳුම් සඳහා පර්යේෂණ, සහාය සහ නඩත්තුව සඳහා අමතර සම්පත් අවශ්ය වේ.
- පද්ධතියේ විශ්වසනීයත්වය සහ අසාර්ථක වීමෙන් පසු යථා තත්ත්වයට පත් කිරීම පිළිබඳ ගැටළු විසඳීම කල් නොදමන්න; ආරම්භක සැලසුම් අවධියේදී ඒවා සැලකිල්ලට ගන්න.
මූලාශ්රය: www.habr.com