බෙදා හරින ලද පද්ධතිවල විශ්වාසදායක පණිවිඩ යැවීම

ද්විත්ව ලිවීමේ ගැටලුව

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

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

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

පාහේ සැබෑ උදාහරණයක්

අපගේ වසමෙහි ණය අයදුම්පත් භාර ගැනීම, ඒවා තක්සේරු කිරීම සහ පාරිභෝගිකයින්ට දැනුම්දීම් ඇඟවීම් යැවීම ඇතුළත් වන අවස්ථාවක් සලකා බලමු.

තනි වගකීම් මූලධර්මය, කොන්වේගේ නීතිය සහ වසම මත පදනම් වූ සැලසුම් ප්‍රවේශය තුළ, සිදුවීම්-කුණාටු සැසි කිහිපයකට පසුව, සම්පූර්ණ වසම පැහැදිලි සීමා මායිම්, වසම් ආකෘති සහ සර්ව ව්‍යාප්ත භාෂාව සහිත නිර්වචනය කළ සීමා සහිත සන්දර්භයන් සමඟ උප ඩොමේන් තුනකට බෙදා ඇත.

පළමු කාර්යය වන්නේ නව ණය අයදුම්පත් ඇතුළත් කිරීම සහ සම්පාදනය කිරීමයි. දෙවන පද්ධතිය මෙම යෙදුම් ඇගයීමට ලක් කර ලබා දී ඇති දත්ත මත පදනම්ව තීරණ ගනී. KYC/KYB, antifraud, සහ ණය අවදානම් චෙක්පත් ඇතුළුව මෙම තක්සේරු ක්‍රියාවලිය කාලය ගත විය හැකි අතර, එකවර අයදුම්පත් දහස් ගණනක් හැසිරවීමේ හැකියාව අවශ්‍ය වේ. එහි ප්‍රතිඵලයක් ලෙස, මෙම ක්‍රියාකාරීත්වය ස්වාධීන පරිමාණයට ඉඩ සලසමින් එහිම දත්ත ගබඩාවක් සහිත කැප වූ ක්ෂුද්‍ර සේවාවක් වෙත පවරා ඇත.

තවද, මෙම උප පද්ධති විවිධ කණ්ඩායම් දෙකක් විසින් කළමනාකරණය කරනු ලබන අතර, ඒ සෑම එකක්ම තමන්ගේම මුදා හැරීමේ චක්‍ර, සේවා මට්ටමේ ගිවිසුම් (SLA) සහ පරිමාණ අවශ්‍යතා ඇත.

අවසාන වශයෙන් , පාරිභෝගිකයින්ට ඇඟවීම් යැවීමට විශේෂිත දැනුම් දීමේ සේවාවක් ඇත.

පද්ධතියේ ප්‍රාථමික භාවිත අවස්ථාව පිළිබඳ ශෝධිත විස්තරයක් මෙන්න:

1. ගනුදෙනුකරුවෙකු ණය අයදුම්පතක් ඉදිරිපත් කරයි.
2. ණය ඉල්ලුම්පත්‍ර සේවාව නව අයදුම්පත "පොරොත්තු" තත්ත්වයකින් වාර්තා කරන අතර අයදුම්පත තක්සේරු සේවාව වෙත යොමු කිරීමෙන් තක්සේරු ක්‍රියාවලිය ආරම්භ කරයි.
3. වරිපනම් සේවාව ලැබෙන ණය ඉල්ලුම් පත්‍රය ඇගයීමට ලක් කරන අතර පසුව එම තීරණය ණය අයදුම් කිරීමේ සේවාවට දන්වයි.
4. තීරණය ලැබුණු පසු, ණය ඉල්ලුම්පත්‍ර සේවාව ඒ අනුව ණය ඉල්ලුම්පත්‍ර තත්ත්වය යාවත්කාලීන කරන අතර ප්‍රතිඵලය පිළිබඳව පාරිභෝගිකයාට දැනුම් දීම සඳහා දැනුම්දීම් සේවාව ක්‍රියාත්මක කරයි.
5. දැනුම්දීම් සේවාව මෙම ඉල්ලීම ක්‍රියාවට නංවන අතර පාරිභෝගිකයාගේ සිටුවම්වලට අනුව විද්‍යුත් තැපෑල, SMS හෝ වෙනත් කැමති සන්නිවේදන ක්‍රම හරහා පාරිභෝගිකයා වෙත දැනුම්දීම් යවයි.

එය බැලූ බැල්මට ඉතා සරල සහ ප්‍රාථමික පද්ධතියකි, නමුත් ණය අයදුම් කිරීමේ සේවාව ඉදිරිපත් කරන්න ණය අයදුම්පත් විධානය ක්‍රියාවට නංවන ආකාරය ගැන අපි කිමිදෙමු.

සේවා අන්තර්ක්‍රියා සඳහා ප්‍රවේශයන් දෙකක් අපට සලකා බැලිය හැක:

1. පළමු-දේශීය-කොමිට්-ඉන්පසු-ප්‍රකාශනය: මෙම ප්‍රවේශයේදී, සේවාව එහි දේශීය දත්ත සමුදාය යාවත්කාලීන කරයි (කොමිට්) පසුව වෙනත් සේවාවන් වෙත සිදුවීමක් හෝ පණිවිඩයක් ප්‍රකාශයට පත් කරයි.

2. පළමුව ප්‍රකාශ කරන්න-පසුව-දේශීය-කොමිට්: ප්‍රතිවිරුද්ධව, මෙම ක්‍රමයට දේශීය දත්ත ගබඩාවේ වෙනස්කම් සිදු කිරීමට පෙර සිදුවීමක් හෝ පණිවිඩයක් ප්‍රකාශ කිරීම ඇතුළත් වේ.

   
   

මෙම ක්‍රම දෙකටම ඒවායේ අඩුපාඩු ඇති අතර බෙදා හරින ලද පද්ධතිවල සන්නිවේදනය සඳහා අර්ධ වශයෙන් අසාර්ථක-ආරක්ෂිත වේ.

මෙය පළමු ප්රවේශය යෙදීමේ අනුපිළිවෙල රූප සටහනකි.

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

සහ දෙවෙනි එක.

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

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

පණිවිඩ බෙදා හැරීමේ සහතිකය

අපට ලබා ගත හැකි සහතික වර්ග හතරක් තිබේ.

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

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

3. අවම වශයෙන් එක් වරක් බෙදා හැරීම\ පාරිභෝගිකයින්ට සෑම පණිවිඩයක්ම ලැබෙනු ඇත සහ සකසනු ඇත නමුත් එකම පණිවිඩය එක් වරකට වඩා ලැබෙනු ඇත.

4. හරියටම එක් වරක් බෙදා හැරීම\හරියටම වරක් බෙදා හැරීම යන්නෙන් අදහස් කරන්නේ පාරිභෝගිකයාට පණිවිඩය ඵලදායී ලෙස එක් වරක් ලැබෙනු ඇති බවයි.
   තාක්ෂණික වශයෙන්, එය Kafka ගනුදෙනු සහ නිෂ්පාදකයාගේ සහ පාරිභෝගිකයාගේ නිශ්චිත බල රහිත ක්‍රියාවට නැංවීමෙන් සාක්ෂාත් කරගත හැකිය.

   
   

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

විසඳුම්

මෙම ගැටලුවට බොහෝ විසඳුම් ඇත, ඒවායේ වාසි සහ අවාසි ඇත.

අදියර දෙකක කැපවීම

විකිපීඩියාවට අනුව, ද්වි-අදියර කොමිට් (2PC) යනු බෙදා හරින ලද ගනුදෙනුවල අනුකූලතාව සහ විශ්වසනීයත්වය සහතික කිරීම සඳහා පරිගණක විද්‍යාව සහ දත්ත සමුදා කළමනාකරණ පද්ධතිවල භාවිතා කරන බෙදා හරින ලද ගනුදෙනු ප්‍රොටෝකෝලයකි. එය නිර්මාණය කර ඇත්තේ බහුවිධ සම්පත් (උදා: දත්ත සමුදායන්) තනි ගනුදෙනුවකට සහභාගී වීමට අවශ්‍ය වන අවස්ථා සඳහා වන අතර, එක්කෝ ඔවුන් සියලු දෙනාම ගනුදෙනුව සිදු කිරීම හෝ ඔවුන් සියල්ලෝම එය නවතා දැමීම සහතික කරයි, එමඟින් දත්ත අනුකූලතාව පවත්වා ගනී. එය අපට අවශ්‍ය දේ හරියටම පෙනේ, නමුත් ද්වි-අදියර වගකීමට අඩුපාඩු කිහිපයක් තිබේ:

• එක් සහභාගි වන සම්පතක් ප්‍රතිචාර නොදක්වන්නේ නම් හෝ අසාර්ථක වීමක් අත්විඳින්නේ නම්, ගැටළුව විසඳන තෙක් සම්පූර්ණ ක්‍රියාවලියම අවහිර කළ හැක. මෙය විභව කාර්ය සාධනය සහ ලබා ගැනීමේ ගැටළු වලට හේතු විය හැක.
• ද්වි-අදියර වගකීම ගොඩනඟන ලද දෝෂ ඉවසීමේ යාන්ත්‍රණ සපයන්නේ නැත. එය අසාර්ථකත්වයන් හැසිරවීමට බාහිර යාන්ත්රණ හෝ අතින් මැදිහත්වීම් මත රඳා පවතී.
• සියලුම නවීන දත්ත සමුදායන් ද්වි-අදියර වගකීම සඳහා සහය නොදක්වයි.

බෙදාගත් දත්ත සමුදාය

ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පය සඳහා වඩාත්ම පැහැදිලි විසඳුම වන්නේ රටාවක් යෙදීමයි (හෝ සමහර විට පවා ප්‍රති-රටාව) - හවුල් දත්ත සමුදායක්. ඔබට විවිධ දත්ත සමුදායන්හි බහු වගු හරහා ගණුදෙණු අනුකුලතාවයක් අවශ්‍ය නම්, මෙම ක්ෂුද්‍ර සේවා සඳහා එක් හවුල් දත්ත ගබඩාවක් භාවිතා කරන්න.

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

ගනුදෙනු පිට පෙට්ටිය

' ගනුදෙනු පිට පෙට්ටිය ' යනු විශ්වාස කළ නොහැකි පණිවිඩ යැවීමේ පද්ධති හමුවේ වුවද විශ්වාසදායක පණිවිඩ ප්‍රචාරණය සහතික කිරීම සඳහා බෙදා හරින ලද පද්ධතිවල භාවිතා කරන සැලසුම් රටාවකි. මෙහෙයුම සිදු කරන ලද එකම ගනුදෙනුව තුළ නම් කරන ලද 'OutboxEvents' වගුවක සිදුවීම් ගබඩා කිරීම එයට ඇතුළත් වේ. මෙම ප්‍රවේශය සම්බන්ධතා දත්ත සමුදායේ ACID ගුණාංග සමඟ හොඳින් ගැලපේ. ඊට ප්‍රතිවිරුද්ධව, බොහෝ No-SQL දත්ත සමුදායන් ACID ගුණාංග සඳහා පූර්ණ සහය නොදක්වයි, ඒ වෙනුවට CAP ප්‍රමේයය සහ BASE දර්ශනයේ මූලධර්ම සඳහා තෝරා ගැනීම, දැඩි අනුකූලතාවයට වඩා ලබා ගත හැකි සහ අවසානයේ අනුකූලතාවයට ප්‍රමුඛත්වය දෙයි.

ගනුදෙනු පිට පෙට්ටියක් අවම වශයෙන් එක් වරක් සහතිකයක් ලබා දෙන අතර ප්‍රවේශයන් කිහිපයකින් ක්‍රියාත්මක කළ හැක:

1. ගනුදෙනු ලොග් වලිගය

2. ඡන්ද ප්රකාශක

   
   

ගනුදෙනු ලඝු-සටහන් ප්‍රවේශය CDC (දත්ත ග්‍රහණය වෙනස් කරන්න) වැනි දත්ත සමුදා-විශේෂිත විසඳුම් භාවිතා කරයි. එම ප්රවේශයේ ප්රධාන අවාසි වන්නේ:

• දත්ත සමුදාය විශේෂිත විසඳුම්

• CDC ක්‍රියාත්මක කිරීමේ විශේෂතා හේතුවෙන් ප්‍රමාදය වැඩි වීම

  
  

තවත් ක්‍රමයක් වන්නේ ඡන්ද ප්‍රකාශක , පිටත පෙට්ටි වගුව මත ඡන්දය ප්‍රකාශ කිරීම මගින් අවුට්බොක්ස් ඕෆ්ලෝඩ් කිරීමට පහසුකම් සපයයි. මෙම ප්‍රවේශයේ මූලික පසුබෑම වන්නේ දත්ත සමුදා භාරය වැඩි වීමේ හැකියාවයි, එය ඉහළ පිරිවැයකට තුඩු දිය හැකිය. තවද, සියලුම No-SQL දත්ත සමුදායන් නිශ්චිත ලේඛන කොටස් සඳහා කාර්යක්ෂම විමසීම් සඳහා සහාය නොදක්වයි. සම්පූර්ණ ලේඛන උපුටා ගැනීම, එබැවින්, කාර්ය සාධනය පිරිහීමට හේතු විය හැක.

එය ක්‍රියා කරන ආකාරය පැහැදිලි කරන කුඩා අනුක්‍රමික රූප සටහනක් මෙන්න.

ඔබටම සවන් දෙන්න

ගනුදෙනු පිට පෙට්ටි රටාව සමඟ ඇති මූලික අභියෝගය වන්නේ දත්ත සමුදාය ACID ගුණාංග මත යැපීමයි. සාමාන්‍ය OLTP දත්ත සමුදායන්හි එය සරල විය හැකි නමුත් NoSQL ක්ෂේත්‍රයේ අභියෝග මතු කරයි. මෙය විසඳීම සඳහා, විභව විසඳුමක් වන්නේ ඉල්ලීම් සැකසීම ආරම්භ කිරීමේ සිටම ඇමුණුම් ලොගය (උදාහරණයක් ලෙස, Kafka) භාවිතා කිරීමයි.

'submit loan application' විධානය සෘජුව සැකසීම වෙනුවට, අපි එය වහාම අභ්‍යන්තර Kafka මාතෘකාවකට යවා පසුව 'පිළිගත්' ප්‍රතිඵලයක් සේවාදායකයා වෙත ලබා දෙන්නෙමු. කෙසේ වෙතත්, විධානය තවමත් සැකසීමට අවශ්‍ය බව බොහෝ දුරට ඉඩ ඇති බැවින්, අපට ප්‍රතිඵලය ගැන පාරිභෝගිකයාට වහාම දැනුම් දිය නොහැක. මෙම අවසාන අනුකූලතාව කළමනාකරණය කිරීම සඳහා, අපට දිගු ඡන්ද විමසීම, සේවාලාභියා විසින් ආරම්භ කරන ලද ඡන්ද විමසීම්, ශුභවාදී UI යාවත්කාලීන කිරීම්, හෝ දැනුම්දීම් සඳහා WebSockets හෝ Server-Sent Events භාවිතා කිරීම වැනි ක්‍රම භාවිත කළ හැක. කෙසේ වෙතත්, මෙය සම්පූර්ණයෙන්ම වෙනස් මාතෘකාවකි, එබැවින් අපි අපගේ මුල් විෂය වෙත ආපසු යමු.

අපි අභ්‍යන්තර කෆ්කා මාතෘකාවක් මත පණිවිඩය යැව්වෙමු. ණය අයදුම් කිරීමේ සේවාව පසුව මෙම පණිවිඩය පරිභෝජනය කරයි - සේවාලාභියාගෙන් ලැබුණු එකම විධානය - සහ සැකසීම ආරම්භ කරයි. පළමුව, එය යම් ව්‍යාපාරික තර්කනයක් ක්‍රියාත්මක කරයි; මෙම තර්කය සාර්ථකව ක්‍රියාත්මක කර ප්‍රතිඵල නොනැසී පැවතීමෙන් පසුව පමණක් එය පොදු කෆ්කා මාතෘකාවක් මත නව පණිවිඩ ප්‍රකාශයට පත් කරයි.

අපි ව්‍යාජ කේත ටිකක් බලමු.

 public async Task HandleAsync(SubmitLoanApplicationCommand command, ...) { //First, process business logic var loanApplication = await _loanApplicationService.HandleCommandAsync(command, ...); //Then, send new events to public Kafka topic producer.Send(new LoanApplicationSubmittedEvent(loanApplication.Id)); //Then, commit offset consumer.Commit(); }

ව්‍යාපාර තර්කනය සැකසීම අසාර්ථක වුවහොත් කුමක් කළ යුතුද? කණගාටු නොවන්න, ඕෆ්සෙට් එක තවමත් සිදු කර නොමැති බැවින්, පණිවිඩය නැවත උත්සාහ කරනු ඇත.

කෆ්කා වෙත නව සිදුවීම් යැවීම අසාර්ථක වුවහොත් කුමක් කළ යුතුද? කණගාටු නොවන්න, ව්‍යාපාර තර්කනය දුර්වල බැවින්, එය අනුපිටපත් ණය අයදුම්පතක් නිර්මාණය නොකරනු ඇත. ඒ වෙනුවට, එය පොදු කෆ්කා මාතෘකාවට පණිවිඩ නැවත යැවීමට උත්සාහ කරනු ඇත.

කෆ්කා වෙත පණිවිඩ යැවූවත්, ඕෆ්සෙට් කැපවීම අසාර්ථක වුවහොත් කුමක් කළ යුතුද? කණගාටු නොවන්න, ව්‍යාපාර තර්කනය දුර්වල බැවින්, එය අනුපිටපත් ණය අයදුම්පතක් නිර්මාණය නොකරයි. ඒ වෙනුවට, එය පොදු කෆ්කා මාතෘකාවට පණිවිඩ යවන අතර මෙවර ඕෆ්සෙට් කැපවීම සාර්ථක වනු ඇතැයි බලාපොරොත්තු වේ.

මෙම ප්‍රවේශයේ ප්‍රධාන අවාසි අතරට නව ක්‍රමලේඛන විලාසයක් හා සම්බන්ධ එකතු කළ සංකීර්ණත්වය, අවසාන අනුකූලතාව (සේවාදායකයා ප්‍රතිඵලය ක්ෂණිකව දැන නොගන්නා බැවින්) සහ සියලු ව්‍යාපාර තර්කනය දුර්වල වීමේ අවශ්‍යතාවය ඇතුළත් වේ.

සිදුවීම් මූලාශ්ර

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

නිගමනය

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

1. ජාල අසාර්ථක වීම නොවැළැක්විය හැකි බැවින් සෑම විටම දුර්වල පාරිභෝගිකයින් වර්ධනය කරන්න.
2. වගකීම් අවශ්‍යතා පිළිබඳ පැහැදිලි අවබෝධයක් සහිතව පළමු-දේශීය-කොමිට්-ඉන්පසුව-ප්‍රකාශනය ප්‍රවේශමෙන් භාවිතා කරන්න.
3. ඔබේ පද්ධතියේ දැඩි දත්ත අනනුකූලතාවයට හේතු විය හැකි බැවින් කිසිවිටෙක පළමු ප්‍රකාශන-පසුව-දේශීය-කොමිට් ප්‍රවේශය භාවිතා නොකරන්න.
4. පවතින දත්ත සමුදා තේරීමේ තීරණය බොහෝ දුරට වෙනස් විය හැකි නම් හෝ ගැටලුව සඳහා හොඳම ගබඩා විසඳුම තෝරා ගැනීමට තාක්ෂණික උපාය අදහස් කරන්නේ නම් - CDC වැනි දත්ත සමුදා විසඳුම්වලට බැඳීමෙන් හවුල් පුස්තකාල ගොඩනඟන්න එපා.
5. අවම වශයෙන් එක් වරක් සහතික ලබා ගැනීම සඳහා සම්මත විසඳුමක් ලෙස ගනුදෙනු පිට පෙට්ටි ප්‍රවේශය භාවිතා කරන්න.
6. No-SQL දත්ත සමුදායන් උත්තෝලනය වන විට ඔබටම සවන් දෙන්න ප්‍රවේශය භාවිතා කිරීම සලකා බලන්න.

මීළඟ වතාවේ, ගනුදෙනු පිටවීමේ පෙට්ටියක් ක්‍රියාත්මක කිරීම පිළිබඳ වඩාත් ප්‍රායෝගික උදාහරණයක් අපි බලමු. බලන්න

ඔබ!