ඔබට අර්ධ සමමුහුර්ත අනුකරණයක් අවශ්‍ය විය හැක්කේ ඇයි?

ආයුබෝවන් සියල්ලටම. ව්ලැඩිස්ලාව් රොඩින් සම්බන්ධ වේ. මම දැනට OTUS හි Software Architecture සහ High-Stress Software Architecture පිළිබඳ පාඨමාලා උගන්වමි. නව පාඨමාලා විෂය ධාරාවක ආරම්භය අපේක්ෂාවෙන් "අධික බර ගෘහ නිර්මාණ ශිල්පියා" මම ඔබ සමඟ බෙදා ගැනීමට අවශ්ය මුල් ද්රව්යයේ කෙටි කොටසක් ලිවීමට තීරණය කළෙමි.

හැඳින්වීම

HDD හට තත්පරයකට මෙහෙයුම් 400-700 ක් පමණ සිදු කළ හැකි වීම (ඉහළ පැටවුම් පද්ධතියක් සඳහා සාමාන්‍ය rps සමඟ සැසඳිය නොහැක), සම්භාව්‍ය තැටි දත්ත සමුදාය ගෘහ නිර්මාණ ශිල්පයේ බාධකයයි. එමනිසා, මෙම ගබඩාවේ පරිමාණ රටා කෙරෙහි විශේෂ අවධානයක් යොමු කිරීම අවශ්ය වේ.

දැනට, දත්ත සමුදා පරිමාණ රටා 2ක් ඇත: අනුකරණය සහ බෙදා හැරීම. ෂර්ඩිං මඟින් ඔබට ලිවීමේ ක්‍රියාව පරිමාණය කිරීමට ඉඩ සලසයි, එහි ප්‍රතිඵලයක් ලෙස, ඔබේ පොකුරේ එක් එක් සේවාදායකයකට rps අඩු කරන්න. අනුවර්තනය ඔබට එකම දේ කිරීමට ඉඩ සලසයි, නමුත් කියවීමේ මෙහෙයුම් සමඟ. මෙම ලිපිය කැප කර ඇත්තේ මෙම රටාවයි.

අනුකරණය

ඔබ ඉතා ඉහළ මට්ටමකින් අනුකරණය දෙස බැලුවහොත්, එය සරල දෙයකි: ඔබට එක් සේවාදායකයක් තිබුණි, එහි දත්ත තිබුණි, එවිට මෙම දත්ත කියවීමේ බර සමඟ මෙම සේවාදායකයට තවදුරටත් කටයුතු කළ නොහැක. ඔබ තවත් සේවාදායකයන් කිහිපයක් එක් කරයි, සියලුම සේවාදායකයන් හරහා දත්ත සමමුහුර්ත කරන්න, සහ පරිශීලකයාට ඔබේ පොකුරේ ඇති ඕනෑම සේවාදායකයකින් කියවිය හැකිය.

එහි පෙනෙන සරල බව තිබියදීත්, මෙම යෝජනා ක්රමයේ විවිධ ක්රියාත්මක කිරීම් වර්ගීකරණය කිරීම සඳහා විකල්ප කිහිපයක් තිබේ:

• පොකුරේ භූමිකාවන් අනුව (මාස්ටර්-ස්වාමියා හෝ ස්වාමියා-දාසයා)
• යවන ලද වස්තු මගින් (පේළි-පාදක, ප්‍රකාශ-පාදක හෝ මිශ්‍ර)
• නෝඩ් සමමුහුර්ත කිරීමේ යාන්ත්රණය අනුව

අද අපි 3 වන කරුණ සමඟ කටයුතු කරන්නෙමු.

ගනුදෙනුවක් සිදු වන්නේ කෙසේද?

මෙම මාතෘකාව ප්‍රතිනිර්මාණයට සෘජුව සම්බන්ධ නැත; ඒ ගැන වෙනම ලිපියක් ලිවිය හැකිය, නමුත් ගනුදෙනු කිරීමේ යාන්ත්‍රණය තේරුම් නොගෙන වැඩිදුර කියවීමෙන් පලක් නොවන බැවින්, මම ඔබට වඩාත් මූලික දේ මතක් කරමි. ගනුදෙනුවක් අදියර 3 කින් සිදු වේ:

1. දත්ත සමුදා ලොගය වෙත ගනුදෙනුවක් ලොග් කිරීම.
2. දත්ත සමුදා එන්ජිමක ගනුදෙනුවක් භාවිතා කිරීම.
3. ගනුදෙනුව සාර්ථකව යෙදී ඇති බවට සේවාදායකයා වෙත තහවුරු කිරීම ආපසු ලබා දීම.

විවිධ දත්ත සමුදායන්හි, මෙම ඇල්ගොරිතමයට සූක්ෂ්මතා තිබිය හැක: නිදසුනක් ලෙස, MySQL දත්ත ගබඩාවේ InnoDB එන්ජිමෙහි ලඝු-සටහන් 2ක් ඇත: එකක් ප්‍රතිනිර්මාණය කිරීම සඳහා (ද්විමය ලඝු-සටහන), සහ අනෙක PostgreSQL හි සිටියදී ACID (අන්ඩෝ/නැවත ලොගය) පවත්වාගෙන යාම සඳහා කාර්යයන් දෙකම ඉටු කරන එක් ලොගයක් ඇත (ඉදිරියට ලියන්න log = WAL). නමුත් ඉහත ඉදිරිපත් කර ඇති දේ හරියටම පොදු සංකල්පය වන අතර එමඟින් එවැනි සූක්ෂ්ම කරුණු සැලකිල්ලට නොගැනීමට ඉඩ සලසයි.

සමමුහුර්ත (සමමුහුර්ත) අනුකරණය

ගනුදෙනු කැපවීමේ ඇල්ගොරිතමයට ලැබුණු වෙනස්කම් අනුකරණය කිරීමට තර්කනය එකතු කරමු:

1. දත්ත සමුදා ලොගය වෙත ගනුදෙනුවක් ලොග් කිරීම.
2. දත්ත සමුදා එන්ජිමක ගනුදෙනුවක් භාවිතා කිරීම.
3. සියලුම අනුපිටපත් වෙත දත්ත යැවීම.
4. සියලුම අනුපිටපත් මත ගනුදෙනුවක් අවසන් කර ඇති බවට තහවුරු කිරීමක් ලැබීම.
5. ගනුදෙනුව සාර්ථකව යෙදී ඇති බවට සේවාදායකයා වෙත තහවුරු කිරීම ආපසු ලබා දීම.

මෙම ප්රවේශය සමඟ අපට අවාසි ගණනාවක් ලැබේ:

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

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

51% (ගණපූරණය) සිට, උදාහරණයක් ලෙස, නෝඩ් වල නිශ්චිත ප්‍රතිශතයකින් පමණක් තහවුරු කිරීම සඳහා අපට බලා සිටිය හැකිද? ඔව්, අපට හැකිය, නමුත් සම්භාව්‍ය අනුවාදයේ, සියලුම නෝඩ් වලින් තහවුරු කිරීම අවශ්‍ය වේ, මන්ද අපට පොකුරේ සම්පූර්ණ දත්ත අනුකූලතාව සහතික කළ හැක්කේ මේ ආකාරයට වන අතර එය මෙම වර්ගයේ අනුකරණයේ නිසැකවම වාසියකි.

අසමමුහුර්ත (අසමමුහුර්ත) අනුකරණය

අපි කලින් ඇල්ගොරිතම වෙනස් කරමු. අපි "කලකට පසුව" අනුරූ වෙත දත්ත යවන්නෙමු, සහ "කලකට පසුව" වෙනස්කම් අනුරූ සඳහා යොදනු ලැබේ:

1. දත්ත සමුදා ලොගය වෙත ගනුදෙනුවක් ලොග් කිරීම.
2. දත්ත සමුදා එන්ජිමක ගනුදෙනුවක් භාවිතා කිරීම.
3. ගනුදෙනුව සාර්ථකව යෙදී ඇති බවට සේවාදායකයා වෙත තහවුරු කිරීම ආපසු ලබා දීම.
4. අනුරූ වෙත දත්ත යැවීම සහ ඒවාට වෙනස්කම් යෙදීම.

මෙම ප්‍රවේශය පොකුර ඉක්මනින් ක්‍රියා කරන බවට හේතු වේ, මන්ද අපි දත්ත අනුරූ වෙත ළඟා වන තෙක් සේවාදායකයා බලා නොසිටීම සහ කැපවී සිටිය යුතු බැවිනි.

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

අර්ධ සමමුහුර්ත පිටපත් කිරීම

අවසාන වශයෙන් අපි අර්ධ සමමුහුර්ත අනුවර්තනය වෙත පැමිණෙමු. මෙම ආකාරයේ අනුවර්තනය එතරම් ප්‍රසිද්ධ හෝ ඉතා සුලභ නොවේ, නමුත් එය සමමුහුර්ත සහ අසමමුහුර්ත ප්‍රතිනිර්මාණය යන දෙකෙහිම වාසි ඒකාබද්ධ කළ හැකි බැවින් එය සැලකිය යුතු උනන්දුවක් දක්වයි.

පෙර ප්රවේශයන් 2 ඒකාබද්ධ කිරීමට උත්සාහ කරමු. අපි සේවාලාභියා දිගු කලක් තබා නොගනිමු, නමුත් දත්ත අනුකරණය කිරීමට අපට අවශ්‍ය වනු ඇත:

1. දත්ත සමුදා ලොගය වෙත ගනුදෙනුවක් ලොග් කිරීම.
2. දත්ත සමුදා එන්ජිමක ගනුදෙනුවක් භාවිතා කිරීම.
3. අනුරූ වෙත දත්ත යැවීම.
4. වෙනස්කම් ලැබී ඇති බවට අනුරුවෙන් තහවුරු කිරීමක් ලැබීම (ඒවා "කලකට පසුව" යොදනු ලැබේ).
5. ගනුදෙනුව සාර්ථකව යෙදී ඇති බවට සේවාදායකයා වෙත තහවුරු කිරීම ආපසු ලබා දීම.

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

නමුත් මෙම ප්‍රවේශය සමඟ ෆැන්ටම් කියවීමේ අවදානමක් ඇත. අපි පහත දර්ශනය සිතමු: 4 පියවරේදී, අපට කිසිදු අනුරුවකින් තහවුරු කිරීමක් නොලැබුණි. අපි මෙම ගනුදෙනුව ආපසු හැරවිය යුතු අතර සේවාලාභියාට තහවුරු කිරීමක් ආපසු නොදිය යුතුය. පියවර 2 හි දත්ත යෙදූ බැවින්, 2 වන පියවරේ අවසානය සහ ගනුදෙනුවේ ආපසු හැරීම අතර කාල පරතරයක් පවතී, එම කාලය තුළ සමාන්තර ගනුදෙනු දත්ත ගබඩාවේ නොතිබිය යුතු වෙනස්කම් දැකිය හැක.

අහිමි-අඩු අර්ධ සමමුහුර්ත අනුකරණය

ඔබ ටිකක් සිතන්නේ නම්, ඔබට ඇල්ගොරිතමයේ පියවර ආපසු හැරවිය හැකි අතර මෙම අවස්ථාවෙහිදී ෆැන්ටම් කියවීමේ ගැටළුව විසඳා ගත හැකිය:

1. දත්ත සමුදා ලොගය වෙත ගනුදෙනුවක් ලොග් කිරීම.
2. අනුරූ දත්ත යැවීම.
3. වෙනස්කම් ලැබී ඇති බවට අනුරුවෙන් තහවුරු කිරීමක් ලැබීම (ඒවා "කලකට පසුව" යොදනු ලැබේ).
4. දත්ත සමුදා එන්ජිමක ගනුදෙනුවක් භාවිතා කිරීම.
5. ගනුදෙනුව සාර්ථකව යෙදී ඇති බවට සේවාදායකයා වෙත තහවුරු කිරීම ආපසු ලබා දීම.

දැන් අපි වෙනස්කම් සිදු කරන්නේ ඒවා අනුකරණය කර ඇත්නම් පමණි.

නිගමනය

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

එච්චරයි. හමුවෙමු පාඨමාලාව!

මූලාශ්රය: www.habr.com