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

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

වඩාත් පොදු ප්‍රත්‍යස්ථතා උපාය මාර්ග අතර තොග ශීර්ෂය, හැඹිලිය, පසුබැසීම, නැවත උත්සාහ කිරීම සහ පරිපථ කඩනය ඇතුළත් වේ. මෙම ලිපියෙන් මම ඒවා වඩාත් විස්තරාත්මකව සාකච්ඡා කරමි, ඒවා විසඳීමට උපකාරී වන ගැටළු පිළිබඳ උදාහරණ සමඟ.

තොග හිස

අපි ඉහත සැකසුම දෙස බලමු. දත්ත කිහිපයක් ලබා ගැනීම සඳහා අපට පිටුපසින් ඇති පසුබිම් කිහිපයක් සහිත ඉතා සාමාන්‍ය යෙදුමක් අප සතුව ඇත. මෙම පසුබිම්වලට සම්බන්ධ HTTP සේවාලාභීන් කිහිපයක් ඇත. ඔවුන් සියල්ලන්ම එකම සම්බන්ධතා සංචිතයක් බෙදා ගන්නා බව පෙනේ! සහ CPU සහ RAM වැනි අනෙකුත් සම්පත්.

ඉහළ ඉල්ලීම් ප්‍රමාදයක් ඇති වන පරිදි එක් පසුබිමක යම් ආකාරයක ගැටලු ඇති වුවහොත් කුමක් සිදුවේද? ඉහළ ප්‍රතිචාර කාලය හේතුවෙන්, backend1 වෙතින් ප්‍රතිචාර සඳහා රැඳී සිටින ඉල්ලීම් මගින් සම්පූර්ණ සම්බන්ධතා සංචිතයම සම්පූර්ණයෙන්ම වාඩිලාගනු ඇත. එහි ප්‍රතිඵලයක් ලෙස, සෞඛ්‍ය සම්පන්න පසුපෙළ2 සහ පසුපෙළ3 සඳහා අදහස් කරන ඉල්ලීම් සංචිතය අවසන් වී ඇති නිසා ඉදිරියට යාමට නොහැකි වනු ඇත. මෙයින් අදහස් කරන්නේ අපගේ එක් පසුබිමක අසාර්ථක වීමක් සම්පූර්ණ යෙදුම හරහා අසාර්ථක වීමට හේතු විය හැකි බවයි. ඉතා මැනවින්, අපට අවශ්‍ය වන්නේ පිරිහීමක් අත්විඳීමට අසාර්ථක පසුබිම හා සම්බන්ධ ක්‍රියාකාරීත්වය පමණක් වන අතර, ඉතිරි යෙදුම සාමාන්‍ය පරිදි ක්‍රියාත්මක වේ.

මෙම ගැටලුව නිරාකරණය කිරීමට අපට තොග ශීර්ෂ රටාව භාවිතා කළ හැක්කේ කෙසේද?

Bulkhead රටාව යෙදුමක් තුළ විවිධ වර්ගයේ සම්පත් හුදකලා කිරීමට භාවිතා කළ හැක, එක් කොටසක අසාර්ථක වීමක් සම්පූර්ණ පද්ධතියට බලපෑම් කිරීම වළක්වයි. අපගේ ගැටලුව සඳහා එය යෙදිය හැකි ආකාරය මෙන්න:

1. සම්බන්ධතා තටාක හුදකලා කිරීම අපට එක් එක් පසුපෙළ සඳහා වෙන වෙනම සම්බන්ධතා තටාක සෑදිය හැක (backend1, backend2, backend3). මෙමගින් backend1 ඉහළ ප්‍රතිචාර කාලයන් හෝ අසාර්ථකත්වයන් අත්විඳින්නේ නම්, එහි සම්බන්ධතා සංචිතය ස්වාධීනව අවසන් වන බව සහතික කරයි, backend2 සහ backend3 සඳහා සම්බන්ධතා සංචිතවලට බලපෑමක් සිදු නොවේ. මෙම හුදකලා කිරීම සෞඛ්‍ය සම්පන්න පසුබිම්වලට සාමාන්‍ය පරිදි ඉල්ලීම් සැකසීමට ඉඩ සලසයි.
2. පසුබිම් ක්‍රියාකාරකම් සඳහා සම්පත් සීමා කිරීම Bulkheads භාවිතා කිරීමෙන්, අපට කණ්ඩායම් සැකසීම හෝ නියමිත කාර්යයන් වැනි පසුබිම් ක්‍රියාකාරකම් සඳහා නිශ්චිත සම්පත් වෙන් කළ හැක. මෙම ක්‍රියාකාරකම් තත්‍ය කාලීන මෙහෙයුම් සඳහා අවශ්‍ය සම්පත් පරිභෝජනය කිරීමෙන් වළක්වයි. උදාහරණයක් ලෙස, අපට ලැබෙන ඉල්ලීම් හැසිරවීමට ප්‍රමාණවත් සම්පත් පවතින බව සහතික කරමින් පසුබිම් කාර්යයන් සඳහා කැප වූ නූල් ගණන හෝ CPU භාවිතය සීමා කළ හැක.
3. පැමිණෙන ඉල්ලීම් සඳහා සීමාවන් සැකසීම, අයදුම්පත්‍රයේ විවිධ කොටස්වලට ලැබෙන ඉල්ලීම් ගණන සීමා කිරීමට තොග ශීර්ෂ ද යෙදිය හැක. උදාහරණයක් ලෙස, අපට එක් එක් උඩුගත සේවාව සඳහා සමගාමීව ක්‍රියා කළ හැකි ඉල්ලීම් ගණනෙහි උපරිම සීමාවක් සැකසිය හැක. මෙමගින් ඕනෑම තනි පසුබිමක් පද්ධතිය යටපත් කිරීම වළක්වන අතර, එකක් අධික බරක් යටතේ වුවද අනෙකුත් පසුපෙළ දිගටම ක්‍රියා කළ හැකි බව සහතික කරයි.

සචේ

අපි හිතමු අපේ පසුපෙළ පද්ධතිවලට තනි තනිව දෝෂ ඇතිවීමේ සම්භාවිතාව අඩුයි. කෙසේ වෙතත්, මෙහෙයුමකදී මෙම සියලු පසුබිම් සමාන්තරව විමසීමට සම්බන්ධ වන විට, එක් එක් ස්වාධීනව දෝෂයක් ලබා දිය හැක. මෙම දෝෂ ස්වාධීනව සිදුවන බැවින්, අපගේ යෙදුමේ දෝෂයක සමස්ත සම්භාවිතාව ඕනෑම තනි පසුබිමක දෝෂ සම්භාවිතාවට වඩා වැඩිය. සමුච්චිත දෝෂ සම්භාවිතාව P_total=1−(1−p)^n සූත්‍රය භාවිතයෙන් ගණනය කළ හැක, මෙහි n යනු පසුපෙළ පද්ධති ගණනයි.

උදාහරණයක් ලෙස, අපට පසුපෙළ දහයක් තිබේ නම්, එක් එක් දෝෂ සම්භාවිතාව p=0.001 (99.9% ක SLA ට අනුරූප වන), එහි ප්‍රතිඵලය වන දෝෂ සම්භාවිතාව වනුයේ:

P_total=1−(1−0.001)^10=0.009955

මෙයින් අදහස් කරන්නේ අපගේ ඒකාබද්ධ SLA ආසන්න වශයෙන් 99% දක්වා පහත වැටෙන අතර, සමාන්තරව බහු පසුපෙළ විමසන විට සමස්ත විශ්වසනීයත්වය අඩු වන ආකාරය නිරූපණය කරයි. මෙම ගැටළුව අවම කිරීම සඳහා, අපට මතකයේ ඇති හැඹිලියක් ක්‍රියාත්මක කළ හැක.

මතකයේ ඇති හැඹිලිය සමඟ අපට එය විසඳිය හැක්කේ කෙසේද?

මතකයේ ඇති හැඹිලියක් අධි වේග දත්ත බෆරයක් ලෙස ක්‍රියා කරයි, නිතර ප්‍රවේශ වන දත්ත ගබඩා කරයි සහ සෑම අවස්ථාවකම එය මන්දගාමී විය හැකි මූලාශ්‍රවලින් ලබා ගැනීමේ අවශ්‍යතාවය ඉවත් කරයි. මතකයේ ගබඩා කර ඇති හැඹිලි ජාලය හරහා දත්ත ලබා ගැනීම හා සසඳන විට 0% දෝෂයක් ඇති බැවින්, ඒවා අපගේ යෙදුමේ විශ්වසනීයත්වය සැලකිය යුතු ලෙස වැඩි කරයි. එපමණක් නොව, හැඹිලිගත කිරීම ජාල තදබදය අඩු කරයි, දෝෂ ඇතිවීමේ සම්භාවිතාව තවදුරටත් අඩු කරයි. එහි ප්‍රතිඵලයක් වශයෙන්, මතකයේ ඇති හැඹිලියක් භාවිතා කිරීමෙන්, අපගේ පසුපෙළ පද්ධතිවලට සාපේක්ෂව අපගේ යෙදුමේ ඊටත් වඩා අඩු දෝෂ අනුපාතයක් ලබා ගත හැක. මීට අමතරව, මතකයේ ඇති හැඹිලි ජාල පදනම් කර ගැනීමට වඩා වේගවත් දත්ත ලබා ගැනීමක් ලබා දෙයි, එමඟින් යෙදුම් ප්‍රමාදය අඩු කරයි - සැලකිය යුතු වාසියකි.

මතකයේ ඇති හැඹිලිය: පුද්ගලීකරණය කළ හැඹිලි

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

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

මතකයේ ඇති හැඹිලිය: දේශීය දත්ත අනුකරණය

අප හැඹිලිගත කිරීමට අදහස් කරන දත්ත තීරණාත්මක වන අතර අපගේ පද්ධතිය හසුරුවන ප්‍රවේශ ප්‍රතිපත්ති, දායකත්ව සැලසුම් හෝ අපගේ වසමේ ඇති වෙනත් වැදගත් ආයතන වැනි සෑම ඉල්ලීමකදීම භාවිතා කරන්නේ නම්-මෙම දත්තවල මූලාශ්‍රය අපගේ පද්ධතිය තුළ සැලකිය යුතු අසාර්ථකත්වයක් ඇති කළ හැකිය. මෙම අභියෝගයට මුහුණ දීම සඳහා, එක් ප්‍රවේශයක් වන්නේ මෙම දත්ත අපගේ යෙදුමේ මතකයට කෙලින්ම ප්‍රතිවර්තනය කිරීමයි.

මෙම අවස්ථාවෙහිදී, මූලාශ්‍රයේ දත්ත පරිමාව කළමනාකරණය කළ හැකි නම්, අපගේ යෙදුම ආරම්භයේදී මෙම දත්තවල ස්නැප්ෂොට් එකක් බාගත කිරීමෙන් අපට ක්‍රියාවලිය ආරම්භ කළ හැක. පසුව, හැඹිලිගත දත්ත මූලාශ්‍රය සමඟ සමමුහුර්තව පවතින බව සහතික කිරීම සඳහා අපට යාවත්කාලීන සිදුවීම් ලබා ගත හැක. මෙම ක්‍රමය අනුගමනය කිරීමෙන්, සෑම ප්‍රතිසාධනයක්ම 0% දෝෂ සම්භාවිතාවක් සහිතව මතකයෙන් සෘජුවම සිදුවන බැවින්, මෙම තීරණාත්මක දත්ත වෙත ප්‍රවේශ වීමේ විශ්වසනීයත්වය අපි වැඩි දියුණු කරමු. අතිරේකව, මතකයෙන් දත්ත ලබා ගැනීම සුවිශේෂී වේගවත් වන අතර, එමගින් අපගේ යෙදුමේ කාර්ය සාධනය ප්‍රශස්ත කරයි. මෙම උපාය මාර්ගය ඵලදායි ලෙස බාහිර දත්ත මූලාශ්‍රයක් මත විශ්වාසය තැබීම හා සම්බන්ධ අවදානම අවම කරයි, අපගේ යෙදුමේ ක්‍රියාකාරිත්වය සඳහා තීරණාත්මක තොරතුරු සඳහා ස්ථාවර සහ විශ්වාසදායක ප්‍රවේශයක් සහතික කරයි.

නැවත පූරණය කළ හැකි වින්‍යාසය

කෙසේ වෙතත්, යෙදුම් ආරම්භය පිළිබඳ දත්ත බාගත කිරීමේ අවශ්‍යතාවය, එමඟින් ආරම්භක ක්‍රියාවලිය ප්‍රමාද කිරීම, ඉක්මන් යෙදුම් ආරම්භය සඳහා පෙනී සිටින '12-සාධක යෙදුමේ' එක් මූලධර්මයක් උල්ලංඝනය කරයි. නමුත්, හැඹිලි භාවිතා කිරීමේ ප්‍රතිලාභ අහිමි කිරීමට අපට අවශ්‍ය නැත. මෙම උභතෝකෝටිකය විසඳීම සඳහා, විභව විසඳුම් ගවේෂණය කරමු.

විශේෂයෙන් විවිධ භෞතික නෝඩ් වෙත ඉක්මන් යෙදුම් සංක්‍රමණය මත යැපෙන Kubernetes වැනි වේදිකා සඳහා වේගවත් ආරම්භය ඉතා වැදගත් වේ. වාසනාවකට මෙන්, Kubernetes හට ආරම්භක පරීක්ෂණ වැනි විශේෂාංග භාවිතයෙන් මන්දගාමී-ආරම්භක යෙදුම් කළමනාකරණය කළ හැක.

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

මෙය විසඳීම සඳහා, එක් විසඳුමක් වන්නේ සමගාමී විචල්‍යයක වින්‍යාසයන් ගබඩා කිරීම සහ පසුබිම් නූලක් එය වරින් වර යාවත්කාලීන කිරීමයි. කෙසේ වෙතත්, HTTP ඉල්ලීම් කල් ඉකුත්වීම් වැනි ඇතැම් පරාමිතීන්, විභව අභියෝගයක් මතු කරමින්, අනුරූප වින්‍යාසය වෙනස් වන විට HTTP හෝ දත්ත සමුදා සේවාලාභීන් නැවත ආරම්භ කිරීම අවශ්‍ය විය හැක. එහෙත්, Java සඳහා Cassandra ධාවකය වැනි සමහර සේවාලාභීන්, මෙම ක්‍රියාවලිය සරල කරමින් වින්‍යාසයන් ස්වයංක්‍රීයව නැවත පූරණය කිරීමට සහය දක්වයි.

නැවත පූරණය කළ හැකි වින්‍යාසයන් ක්‍රියාත්මක කිරීමෙන් දිගු යෙදුම් ආරම්භක වේලාවන්හි ඍණාත්මක බලපෑම අවම කර ගත හැකි අතර විශේෂාංග ධජය ක්‍රියාත්මක කිරීමට පහසුකම් සැලසීම වැනි අමතර ප්‍රතිලාභ ලබා දිය හැක. මෙම ප්‍රවේශය මඟින් වින්‍යාස යාවත්කාලීන කාර්යක්ෂමව කළමනාකරණය කරන අතරම යෙදුම් විශ්වසනීයත්වය සහ ප්‍රතිචාර දැක්වීම පවත්වා ගැනීමට අපට හැකියාව ලැබේ.

පසුබැසීම

දැන් අපි තවත් ගැටලුවක් දෙස බලමු: අපගේ පද්ධතිය තුළ, පරිශීලක ඉල්ලීමක් ලැබුණු විට සහ පසුපෙළ හෝ දත්ත සමුදාය වෙත විමසුමක් යැවීමෙන්, විටින් විට, අපේක්ෂිත දත්ත වෙනුවට දෝෂ ප්‍රතිචාරයක් ලැබේ. පසුව, අපගේ පද්ධතිය පරිශීලකයාට 'දෝෂයක්' සමඟ ප්‍රතිචාර දක්වයි.

කෙසේ වෙතත්, බොහෝ අවස්ථා වලදී, පරිශීලකයාට විශාල රතු දෝෂ පණිවිඩයක් ලබා දෙනවාට වඩා, දත්ත නැවුම් කිරීමේ ප්‍රමාදයක් ඇති බව පෙන්නුම් කරන පණිවිඩයක් සමඟ තරමක් යල් පැන ගිය දත්ත ප්‍රදර්ශනය කිරීම වඩාත් සුදුසු විය හැකිය.

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

නැවත උත්සාහ කරන්න

ඔබ ඉහත පින්තූරය දෙස බැලුවහොත්, අප දැන් මුහුණ දෙන ගැටලුව සහ හැඹිලි උදාහරණය සමඟ අප මුහුණ දුන් ගැටලුව අතර සමානකමක් ඔබට පෙනෙනු ඇත.

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

Circuit Breaker

කෙසේ වෙතත්, විභව ප්‍රතිවිපාක සැලකිල්ලට නොගෙන නැවත උත්සාහ කිරීමේ උපාය මාර්ගයක් අනුගමනය කිරීම තවදුරටත් සංකූලතා ඇති කළ හැකිය.

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

මෙම අභියෝගයට මුහුණ දීම සඳහා, පරිපථ කඩන රටාව සමඟ නැවත උත්සාහ කිරීමේ රටාව සම්පූර්ණ කිරීම වැදගත් වේ. පරිපථ කඩනය පහළ සේවා වල දෝෂ අනුපාතය නිරීක්ෂණය කරන ආරක්ෂක යාන්ත්‍රණයක් ලෙස ක්‍රියා කරයි. දෝෂ අනුපාතය පූර්ව නිශ්චිත සීමාව ඉක්මවා ගිය විට, පරිපථ කඩනය මගින් බලපෑමට ලක් වූ සේවාවට නියමිත කාලසීමාව සඳහා ඉල්ලීම් බාධා කරයි. මෙම කාල පරිච්ෙඡ්දය තුළදී, අසමත් වූ සේවා කාලය නැවත ලබා ගැනීම සඳහා අතිරේක ඉල්ලීම් යැවීමෙන් පද්ධතිය වළක්වයි. නියමිත කාල සීමාවෙන් පසුව, පරිපථ කඩනය ප්‍රවේශමෙන් සීමිත ඉල්ලීම් සංඛ්‍යාවක් හරහා යාමට ඉඩ සලසයි, සේවාව ස්ථාවර වී ඇත්ද යන්න තහවුරු කරයි. සේවාව යථා තත්ත්වයට පත් වී ඇත්නම්, සාමාන්‍ය ගමනාගමනය ක්‍රමයෙන් යථා තත්ත්වයට පත් වේ; එසේ නොමැති නම්, සේවාව නැවත සාමාන්‍ය ක්‍රියාකාරිත්වය ආරම්භ වන තෙක් ඉල්ලීම් අවහිර කරමින් පරිපථය විවෘතව පවතී. නැවත උත්සාහ කිරීමේ තර්කයට සමගාමීව පරිපථ කඩන රටාව අනුකලනය කිරීමෙන්, අපට දෝශ තත්වයන් ඵලදායී ලෙස කළමනාකරණය කිරීමට සහ පසුපෙළ අසාර්ථක වීම් වලදී පද්ධතියේ අධි බර පැටවීම වැළැක්විය හැක.

එතීමෙන්

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