"Hadoop. ZooKeeper" යන දේශනයෙහි පිටපත කියවීමට මම ඔබට යෝජනා කරන්නේ "Hadoop හි විශාල දත්ත පරිමාවන් බෙදා හැරීමේ ක්‍රම" මාලාවෙන්
ZooKeeper යනු කුමක්ද, Hadoop පරිසර පද්ධතිය තුළ එහි ස්ථානය. බෙදා හරින ලද පරිගණකකරණය පිළිබඳ අසත්‍ය. සම්මත බෙදාහැරීමේ පද්ධතියක රූප සටහන. බෙදා හරින ලද පද්ධති සම්බන්ධීකරණය කිරීමේ අපහසුතාව. සාමාන්ය සම්බන්ධීකරණ ගැටළු. ZooKeeper හි සැලසුම පිටුපස ඇති මූලධර්ම. ZooKeeper දත්ත ආකෘතිය. znode කොඩි. සැසිවාර. සේවාලාභී API. ප්රාථමික (වින්‍යාස කිරීම, කණ්ඩායම් සාමාජිකත්වය, සරල අගුල්, නායක මැතිවරණය, රංචු බලපෑමක් නොමැතිව අගුලු දැමීම). ZooKeeper ගෘහ නිර්මාණ ශිල්පය. ZooKeeper DB. ZAB. ඉල්ලීම හසුරුවන්න.
අද අපි ZooKeeper ගැන කතා කරමු. මෙම කරුණ ඉතා ප්රයෝජනවත් වේ. ඕනෑම Apache Hadoop නිෂ්පාදනයක් මෙන් එයට ලාංඡනයක් ඇත. එය මිනිසෙකු නිරූපණය කරයි.
මෙයට පෙර අපි ප්රධාන වශයෙන් කතා කළේ එහි දත්ත සැකසෙන ආකාරය, ගබඩා කරන්නේ කෙසේද, එනම් එය කෙසේ හෝ භාවිතා කර එය සමඟ වැඩ කරන්නේ කෙසේද යන්නයි. අද මම බෙදා හරින ලද යෙදුම් ගොඩනැගීම ගැන ටිකක් කතා කිරීමට කැමැත්තෙමි. තවද ZooKeeper යනු මෙම කාරණය සරල කිරීමට ඔබට ඉඩ සලසන දේවල් වලින් එකකි. මෙය බෙදා හරින ලද යෙදුම්වල, බෙදා හරින ලද පද්ධතිවල ක්රියාවලීන්ගේ අන්තර්ක්‍රියාකාරිත්වයේ යම් ආකාරයක සම්බන්ධීකරණයක් සඳහා අදහස් කරන සේවාවකි.
එවැනි යෙදුම්වල අවශ්‍යතාවය දිනෙන් දින වැඩි වෙමින් පවතී, අපගේ පාඨමාලාව එයයි. එක් අතකින්, MapReduce සහ මෙම සූදානම් කළ රාමුව ඔබට මෙම සංකීර්ණත්වය සමතලා කිරීමට සහ ක්‍රමලේඛකයා අන්තර්ක්‍රියා සහ ක්‍රියාවලි සම්බන්ධීකරණය වැනි ප්රාථමික ලිවීමෙන් නිදහස් කිරීමට ඉඩ සලසයි. නමුත් අනෙක් අතට, මෙය කෙසේ හෝ සිදු කිරීමට සිදු නොවන බවට කිසිවෙකු සහතික නොවේ. MapReduce හෝ වෙනත් සූදානම් කළ රාමු සෑම විටම මෙය භාවිතයෙන් ක්රියාත්මක කළ නොහැකි සමහර අවස්ථා සම්පූර්ණයෙන්ම ප්‍රතිස්ථාපනය නොකරයි. MapReduce සහ වෙනත් Apache ව්‍යාපෘති සමූහයක් ඇතුළුව; ඒවා ඇත්ත වශයෙන්ම බෙදා හරින ලද යෙදුම් ද වේ. සහ ලිවීම පහසු කිරීම සඳහා, ඔවුන් ZooKeeper ලිවීය.
Hadoop සම්බන්ධ සියලුම යෙදුම් මෙන්, එය Yahoo විසින් වැඩි දියුණු කරන ලදී! එය දැන් නිල Apache යෙදුමක් ද වේ. එය HBase තරම් සක්‍රීයව සංවර්ධනය වී නොමැත. ඔබ JIRA HBase වෙත ගියහොත්, සෑම දිනකම දෝෂ වාර්තා පොකුරක්, යමක් ප්රශස්ත කිරීම සඳහා යෝජනා සමූහයක්, එනම් ව්‍යාපෘතියේ ජීවිතය නිරන්තරයෙන් සිදුවෙමින් පවතී. තවද ZooKeeper, එක් අතකින්, සාපේක්ෂව සරල නිෂ්පාදනයක් වන අතර, අනෙක් අතට, මෙය එහි විශ්වසනීයත්වය සහතික කරයි. එය භාවිතා කිරීම තරමක් පහසු ය, එබැවින් එය Hadoop පරිසර පද්ධතිය තුළ යෙදුම්වල ප්‍රමිතියක් බවට පත්ව ඇත. එබැවින් එය ක්රියා කරන ආකාරය සහ එය භාවිතා කරන්නේ කෙසේද යන්න තේරුම් ගැනීමට එය සමාලෝචනය කිරීම ප්රයෝජනවත් යැයි මම සිතුවෙමි.
මේ අපි පැවැත්වූ දේශනයක පින්තූරයකි. අප මෙතෙක් සලකා බැලූ සෑම දෙයකටම එය විකලාංග යැයි අපට පැවසිය හැකිය. මෙහි දක්වා ඇති සෑම දෙයක්ම, එක් මට්ටමකට හෝ වෙනත් ආකාරයකින්, ZooKeeper සමඟ ක්රියා කරයි, එනම්, එය මෙම සියලු නිෂ්පාදන භාවිතා කරන සේවාවකි. HDFS හෝ MapReduce ඔවුන් සඳහා විශේෂයෙන් වැඩ කරන ඔවුන්ගේම සමාන සේවාවන් ලියන්නේ නැත. ඒ අනුව ZooKeeper භාවිතා වේ. තවද මෙය සංවර්ධනය සහ දෝෂ සම්බන්ධ සමහර දේවල් සරල කරයි.
මේ සියල්ල පැමිණෙන්නේ කොහෙන්ද? අපි විවිධ පරිගණකවල සමාන්තරව යෙදුම් දෙකක් දියත් කර, ඒවා නූලකින් හෝ දැලකින් සම්බන්ධ කර ඇති බව පෙනේ, සියල්ල ක්රියාත්මක වේ. නමුත් ගැටළුව වන්නේ ජාලය විශ්වාස කළ නොහැකි වීමයි, ඔබ ගමනාගමනය උදුරා බැලුවහොත් හෝ එහි සිදුවන දේ පහත් මට්ටමින් බැලුවහොත්, සේවාදායකයින් ජාලයේ අන්තර්ක්‍රියා කරන ආකාරය, සමහර පැකට් නැති වී හෝ නැවත යවන බව ඔබට බොහෝ විට දැකිය හැකිය. TCP ප්‍රොටෝකෝල නිර්මාණය කර ඇත්තේ නිකම්ම නොවේ, එමඟින් ඔබට යම් සැසියක් ස්ථාපිත කිරීමට සහ පණිවිඩ බෙදා හැරීම සහතික කිරීමට ඉඩ සලසයි. නමුත් ඕනෑම අවස්ථාවක, TCP පවා ඔබව සැමවිටම සුරැකිය නොහැක. සෑම දෙයකටම කල් ඉකුත්වීමක් ඇත. ජාලය ටික වේලාවකට බිඳ වැටිය හැක. එය නිකම්ම ඇසිපිය හෙළනවා විය හැක. මේ සියල්ල ඔබට ජාලය විශ්වාසදායක වීම මත විශ්වාසය තැබිය නොහැකි බවට හේතු වේ. මතකයේ වඩා විශ්වාසදායක දත්ත හුවමාරු බසයක් ඇති ජාලයක් නොමැති එක් පරිගණකයක හෝ එක් සුපිරි පරිගණකයක ක්රියාත්මක වන සමාන්තර යෙදුම් ලිවීමේ ප්රධාන වෙනස මෙයයි. තවද මෙය මූලික වෙනසකි.
වෙනත් දේ අතර, ජාලය භාවිතා කරන විට, සෑම විටම යම් ප්රමාදයක් පවතී. තැටියේ ද එය ඇත, නමුත් ජාලයේ එය වැඩි ය. ප්‍රමාදය යනු යම් ප්‍රමාද කාලයකි, එය කුඩා හෝ තරමක් වැදගත් විය හැක.
ජාල ස්ථලකය වෙනස් වෙමින් පවතී. ස්ථලකය යනු කුමක්ද - මෙය අපගේ ජාල උපකරණ ස්ථානගත කිරීමයි. දත්ත මධ්‍යස්ථාන තියෙනවා, රාක්ක තියෙනවා, ඉටිපන්දම් තියෙනවා. මේ සියල්ල නැවත සම්බන්ධ කිරීම, මාරු කිරීම ආදිය කළ හැකිය. මේ සියල්ල ද සැලකිල්ලට ගත යුතුය. IP නම් වෙනස් වේ, අපගේ ගමනාගමනය ගමන් කරන මාර්ග වෙනස් වේ. මෙයද සැලකිල්ලට ගත යුතුය.
උපකරණ අනුව ජාලය ද වෙනස් විය හැකිය. පුහුණුවීම් වලින්, අපගේ ජාල ඉංජිනේරුවන් ඉටිපන්දම් මත යමක් වරින් වර යාවත්කාලීන කිරීමට කැමති බව මට පැවසිය හැකිය. හදිසියේම නව ස්ථිරාංගයක් පැමිණි අතර ඔවුන් සමහර Hadoop පොකුරක් ගැන විශේෂයෙන් උනන්දු වූයේ නැත. ඔවුන්ට ඔවුන්ගේම රැකියාවක් තිබේ. ඔවුන් සඳහා, ප්රධාන දෙය වන්නේ ජාලය ක්රියා කිරීමයි. ඒ අනුව, ඔවුන්ට එහි යමක් නැවත උඩුගත කිරීමට අවශ්ය වන අතර, ඔවුන්ගේ දෘඩාංගවල ෆ්ලෑෂ් කිරීමක් කිරීමට අවශ්ය වන අතර දෘඩාංග ද කාලානුරූපව වෙනස් වේ. මේ සියල්ල කෙසේ හෝ සැලකිල්ලට ගත යුතුය. මේ සියල්ල අපගේ බෙදා හරින ලද යෙදුමට බලපායි.
සාමාන්යයෙන් කිසියම් හේතුවක් නිසා විශාල දත්ත ප්‍රමාණයක් සමඟ වැඩ කිරීමට පටන් ගන්නා පුද්ගලයින් අන්තර්ජාලය අසීමිත බව විශ්වාස කරයි. ටෙරාබයිට් කිහිපයක ගොනුවක් එහි තිබේ නම්, ඔබට එය ඔබේ සේවාදායකයට හෝ පරිගණකයට ගෙන ගොස් එය භාවිතයෙන් විවෘත කළ හැකිය. බළලා සහ නැරඹීම. තවත් දෝෂයක් ඇත විම් ලඝු-සටහන් දෙස බලන්න. නරක නිසා කවදාවත් මේක කරන්න එපා. Vim සෑම දෙයක්ම බෆර් කිරීමට උත්සාහ කරන නිසා, සෑම දෙයක්ම මතකයට පැටවීමට, විශේෂයෙන්ම අපි මෙම ලොගය හරහා ගමන් කිරීමට සහ යමක් සෙවීමට පටන් ගන්නා විට. මේවා අමතක වූ නමුත් සලකා බැලීම වටී.
එක ප්‍රොසෙසරයකින් එක පරිගණකයක ක්රියාත්මක වන එක් වැඩසටහනක් ලිවීම පහසුයි.
අපගේ පද්ධතිය වර්ධනය වන විට, අපට ඒ සියල්ල සමාන්තරව කිරීමට අවශ්ය වන අතර, එය පරිගණකයේ පමණක් නොව, පොකුරක් මතද සමාන්තර කිරීමට අවශ්ය වේ. ප්රශ්නය පැනනගින්නේ: මෙම කාරණය සම්බන්ධීකරණය කරන්නේ කෙසේද? අපගේ යෙදුම් එකිනෙක සමඟ අන්තර් ක්රියා නොකරනු ඇත, නමුත් අපි සේවාදායකයන් කිහිපයක සමාන්තරව ක්‍රියාවලි කිහිපයක් ක්රියාත්මක කළෙමු. ඔවුන් සඳහා සෑම දෙයක්ම හොඳින් සිදුවන බව නිරීක්ෂණය කරන්නේ කෙසේද? උදාහරණයක් ලෙස, ඔවුන් අන්තර්ජාලය හරහා යමක් යවයි. ඔවුන් කොතැනක හෝ ඔවුන්ගේ තත්වය ගැන ලිවිය යුතුය, උදාහරණයක් ලෙස, යම් ආකාරයක දත්ත සමුදායක හෝ ලොගයක, පසුව මෙම ලොගය එකතු කර එය කොතැනක හෝ විශ්ලේෂණය කරන්න. ඊට අමතරව, ක්රියාවලිය ක්රියාත්මක වන අතර ක්රියාත්මක වන බව අප සැලකිල්ලට ගත යුතුය, හදිසියේම එහි යම් දෝෂයක් දර්ශනය වී හෝ එය කඩා වැටුණි, එවිට අපි ඒ ගැන කෙතරම් ඉක්මනින් සොයා ගනිමුද?
මේ සියල්ල ඉක්මනින් නිරීක්ෂණය කළ හැකි බව පැහැදිලිය. මේකත් හොදයි, නමුත් අධීක්‍ෂණය කියන්නේ සමහර දේවල් ඉහලම මට්ටමින් නිරීක්ෂණය කරන්න පුළුවන් සීමිත දෙයක්.
අපගේ ක්‍රියාවලීන් එකිනෙකා සමඟ අන්තර් ක්රියා කිරීමට පටන් ගැනීමට අපට අවශ්ය වූ විට, උදාහරණයක් ලෙස, එකිනෙකාට යම් දත්ත යැවීමට, එවිට ප්රශ්නය ද පැන නගී - මෙය සිදු වන්නේ කෙසේද? මොකක් හරි ජාතියේ කොන්දේසියක් එයිද, එක එක්කෙනා උඩින් ලියයිද, ඩේටා හරියට එයිද, මගදි මොනවා හරි නැති වෙයිද? අපි යම් ආකාරයක ප්රොටෝකෝලයක් ආදිය සකස් කළ යුතුයි.
මේ සියලු ක්‍රියාවලීන් සම්බන්ධීකරණය කිරීම සුළුපටු දෙයක් නොවේ. එය සංවර්ධකයාට ඊටත් වඩා පහළ මට්ටමකට යාමට බල කරන අතර මුල සිටම පද්ධති ලිවීමට හෝ මුල සිටම නොවේ, නමුත් මෙය එතරම් සරල නැත.
ඔබ ගුප්ත ලේඛන ඇල්ගොරිතමයක් ඉදිරිපත් කරන්නේ නම් හෝ එය ක්රියාත්මක කරන්නේ නම්, එය වහාම ඉවතට විසි කරන්න, මන්ද බොහෝ විට එය ඔබට ක්රියා නොකරනු ඇත. ඔබට සැපයීමට අමතක වූ දෝෂ රාශියක් එහි බොහෝ විට අඩංගු වනු ඇත. එය බොහෝ විට අස්ථායී විය හැකි බැවින් එය කිසි විටෙක බරපතල කිසිවක් සඳහා භාවිතා නොකරන්න. මක්නිසාද යත් පවතින සියලුම ඇල්ගොරිතම ඉතා දිගු කාලයක් තිස්සේ කාලය විසින් පරීක්ෂා කර ඇති බැවිනි. එය ප්‍රජාව විසින් දෝෂ සහිතය. මෙය වෙනම මාතෘකාවකි. ඒ වගේම මෙතනත් එහෙමයි. යම් ආකාරයක ක්‍රියාවලි සමමුහුර්ත කිරීමක් ඔබම ක්රියාත්මක නොකිරීමට හැකි නම්, මෙය නොකිරීමට වඩා හොඳය, මන්ද එය තරමක් සංකීර්ණ වන අතර නිරන්තරයෙන් දෝෂ සෙවීමේ සොලවන මාවතට ඔබව ගෙන යයි.
අද අපි කතා කරන්නේ ZooKeeper ගැන. එක් අතකින්, එය රාමුවක් වන අතර, අනෙක් අතට, එය සංවර්ධකයා සඳහා ජීවිතය පහසු කරවන සේවාවක් වන අතර හැකිතාක් දුරට අපගේ ක්රියාවලීන්ගේ තර්කනය සහ සම්බන්ධීකරණය ක්රියාත්මක කිරීම සරල කරයි.
සම්මත බෙදාහැරීමේ පද්ධතියක් කෙබඳු විය හැකිද යන්න මතක තබා ගනිමු. අපි කතා කළේ මෙයයි - HDFS, HBase. කම්කරුවන් සහ වහල් ක්‍රියාවලීන් කළමනාකරණය කරන ප්රධාන ක්‍රියාවලියක් ඇත. කාර්යයන් සම්බන්ධීකරණය සහ බෙදා හැරීම, සේවකයින් නැවත ආරම්භ කිරීම, නව ඒවා දියත් කිරීම සහ බර බෙදා හැරීම සඳහා ඔහු වගකිව යුතුය.
වඩා දියුණු දෙයක් නම් සම්බන්ධීකරණ සේවාවයි, එනම්, සම්බන්ධීකරණ කාර්යය වෙනම ක්‍රියාවලියකට ගෙන යන්න, ඊට අමතරව යම් ආකාරයක උපස්ථයක් හෝ ස්ටැන්බි මාස්ටර් සමාන්තරව ක්රියාත්මක කරන්න, මන්ද මාස්ටර් අසමත් විය හැක. සහ මාස්ටර් වැටුණොත්, අපේ පද්ධතිය ක්රියා නොකරනු ඇත. අපි උපස්ථ ධාවනය කරමින් සිටිමු. උපස්ථ කිරීමට මාස්ටර් අනුකරණය කිරීමට අවශ්ය බව සමහර ප්‍රකාශ කරයි. මෙය සම්බන්ධීකරණ සේවයට ද පැවරිය හැකිය. නමුත් මෙම රූප සටහනේ, සේවකයින් සම්බන්ධීකරණය කිරීම සඳහා ස්වාමියා වගකිව යුතුය; මෙහි සේවාව දත්ත අනුරූකරණ කටයුතු සම්බන්ධීකරණය කරයි.
වඩාත් දියුණු විකල්පයක් වන්නේ සාමාන්යයෙන් සිදු කරන පරිදි සියලුම සම්බන්ධීකරණය අපගේ සේවාව මගින් හසුරුවන විටය. සෑම දෙයක්ම ක්රියාත්මක වන බවට වග බලා ගැනීම සඳහා ඔහු වගකීම දරයි. යමක් වැඩ නොකරන්නේ නම්, අපි ඒ ගැන සොයා බලා මෙම තත්වය මඟහරවා ගැනීමට උත්සාහ කරමු. කෙසේ වෙතත්, අපට ඉතිරිව ඇත්තේ වහලුන් සමඟ කෙසේ හෝ අන්තර් ක්රියා කරන සහ යම් සේවාවක් හරහා දත්ත, තොරතුරු, පණිවිඩ යනාදිය යැවිය හැකි ස්වාමියෙකු ය.
ඊටත් වඩා දියුණු යෝජනා ක්රමයක් තිබේ, අපට මාස්ටර් නොමැති විට, සියලුම නෝඩ් ප්රධාන වහලුන් වේ, ඔවුන්ගේ හැසිරීම් වලින් වෙනස් වේ. නමුත් ඔවුන් තවමත් එකිනෙකා සමඟ අන්තර් ක්රියා කිරීමට අවශ්ය වේ, එබැවින් මෙම ක්රියාවන් සම්බන්ධීකරණය කිරීමට තවමත් යම් සේවාවක් ඉතිරිව ඇත. බොහෝ විට, මෙම මූලධර්මය මත ක්රියා කරන කැසැන්ඩ්රා, මෙම යෝජනා ක්රමයට ගැලපේ.
මෙම යෝජනා ක්‍රමවලින් වඩා හොඳින් ක්රියා කරන්නේ කුමක්දැයි කීමට අපහසුය. සෑම කෙනෙකුටම තමන්ගේම වාසි සහ අවාසි ඇත.
තවද, මාස්ටර් සමඟ සමහර දේවල් වලට බිය විය යුතු නැත, මන්ද, පුහුණුවීම් පෙන්නුම් කරන පරිදි, ඔහු නිරන්තරයෙන් සේවය කිරීමට එතරම් ගොදුරු නොවේ. මෙහි ඇති ප්‍රධානතම දෙය නම්, මෙම සේවාවට ප්‍රමාණවත් සම්පත් ඇති වන පරිදි, හැකි නම්, පරිශීලකයින්ට එහි ප්රවේශය නොමැති වන පරිදි, මෙම ක්රියාවලිය අහම්බෙන් විනාශ නොවන පරිදි, මෙම සේවාව වෙනම බලවත් නෝඩයක් මත සත්කාරකත්වය සැපයීම සඳහා නිවැරදි විසඳුම තෝරා ගැනීමයි. නමුත් ඒ සමගම, එවැනි යෝජනා ක්රමයක් තුළ මාස්ටර් ක්රියාවලියෙන් කම්කරුවන් කළමනාකරණය කිරීම වඩාත් පහසු වේ, එනම් මෙම යෝජනා ක්රමය ක්රියාත්මක කිරීමේ දෘෂ්ටි කෝණයෙන් සරල ය.
තවද මෙම යෝජනා ක්රමය (ඉහළ) බොහෝ විට වඩාත් සංකීර්ණ, නමුත් වඩා විශ්වාසදායක ය.
ප්රධාන ගැටළුව වන්නේ අර්ධ අසාර්ථකත්වයයි. උදාහරණයක් ලෙස, අපි ජාලය හරහා පණිවිඩයක් යවන විට, යම් ආකාරයක අනතුරක් සිදු වන අතර, පණිවිඩය යැවූ තැනැත්තා ඔහුගේ පණිවිඩය ලැබුනේද යන්න සහ ලබන්නාගේ පැත්තෙන් සිදුවූයේ කුමක්ද, පණිවිඩය නිවැරදිව සකසා ඇත්දැයි නොදනී. , එනම් ඔහුට කිසිදු තහවුරු කිරීමක් නොලැබෙනු ඇත.
ඒ අනුව අපි මේ තත්ත්වය සකස් කළ යුතුයි. තවද සරලම දෙය නම් මෙම පණිවිඩය නැවත යවා අපට ප්‍රතිචාරයක් ලැබෙන තෙක් රැඳී සිටීමයි. මෙම අවස්ථාවේදී, ග්රාහකයාගේ තත්වය වෙනස් වී තිබේද යන්න සැලකිල්ලට නොගනී. අපි පණිවිඩයක් යවා එකම දත්ත දෙවරක් එකතු කළ හැක.
ZooKeeper එවැනි ප්‍රතික්ෂේප කිරීම් සමඟ කටයුතු කිරීමට ක්‍රම ඉදිරිපත් කරයි, එය අපගේ ජීවිත පහසු කරයි.
මඳක් කලින් සඳහන් කළ පරිදි, මෙය බහු-නූල් වැඩසටහන් ලිවීමට සමාන ය, නමුත් ප්රධාන වෙනස නම් අපි විවිධ යන්ත්‍ර මත ගොඩනඟන බෙදා හරින ලද යෙදුම්වල සන්නිවේදනය කිරීමට ඇති එකම ක්රමය ජාලයයි. අත්යවශ්යයෙන්ම, මෙය හවුල්-කිසිවක් නැති ගෘහ නිර්මාණ ශිල්පයකි. එක් යන්ත්‍රයක ක්රියාත්මක වන සෑම ක්‍රියාවලියක් හෝ සේවාවක්ම තමන්ගේම මතකයක්, තමන්ගේම තැටියක්, තමන්ගේම ප්‍රොසෙසරයක් ඇත, එය කිසිවෙකු සමඟ බෙදා නොගනී.
අපි එක් පරිගණකයක බහු-නූල් වැඩසටහනක් ලියන්නේ නම්, දත්ත හුවමාරු කිරීම සඳහා හවුල් මතකය භාවිතා කළ හැකිය. අපට එහි සන්දර්භය ස්විචයක් ඇත, ක්‍රියාවලි මාරු විය හැක. මෙය කාර්ය සාධනයට බලපායි. එක් අතකින්, පොකුරු මත වැඩසටහනේ එවැනි දෙයක් නැත, නමුත් ජාලයේ ගැටළු තිබේ.
ඒ අනුව, බෙදා හරින ලද පද්ධති ලිවීමේදී පැන නගින ප්රධාන ගැටළු වන්නේ වින්‍යාසයයි. අපි යම් ආකාරයක අයදුම්පතක් ලියන්නෙමු. එය සරල නම්, අපි කේතයේ සියලු වර්ගවල අංක දෘඪ කේතය කරන්නෙමු, නමුත් මෙය අපහසුය, මන්ද තත්පර භාගයක කාල සීමාවක් වෙනුවට අපට තත්පරයක කාල සීමාවක් අවශ්ය බව අප තීරණය කරන්නේ නම්, අපි යෙදුම නැවත සම්පාදනය කළ යුතුය. සියල්ල නැවත පෙරළන්න. එය එක් යන්ත්‍රයක් මත ඇති විට, ඔබට එය නැවත ආරම්භ කළ හැකි විට එය එක දෙයකි, නමුත් අපට බොහෝ යන්ත්‍ර ඇති විට, අපට සෑම දෙයක්ම නිරන්තරයෙන් පිටපත් කිරීමට සිදුවේ. අපි යෙදුම වින්‍යාසගත කිරීමට උත්සාහ කළ යුතුයි.
මෙහිදී අපි පද්ධති ක්‍රියාවලි සඳහා ස්ථිතික වින්‍යාසය ගැන කතා කරමු. මෙය සම්පූර්ණයෙන්ම නොවේ, සමහර විට මෙහෙයුම් පද්ධතියේ දෘෂ්ටි කෝණයෙන්, එය අපගේ ක්‍රියාවලීන් සඳහා ස්ථිතික වින්යාසයක් විය හැකිය, එනම් මෙය සරලව ගෙන යා නොහැකි වින්‍යාසයකි.
ගතික වින්යාසයක් ද ඇත. අපි පියාසර කරන විට වෙනස් කිරීමට අවශ්ය පරාමිති මේවාය, එවිට ඒවා එතැනට ගෙන එයි.
මෙහි ඇති ගැටලුව කුමක්ද? අපි වින්‍යාසය යාවත්කාලීන කළෙමු, එය පෙරළා ගත්තෙමු, ඉතින් කුමක් ද? ගැටලුව විය හැක්කේ එක් අතකින් අපි වින්‍යාසය පෙරළා දැමූ නමුත් අලුත් දේ ගැන අමතක වූ නමුත් වින්‍යාසය එහි පැවතීමයි. දෙවනුව, අපි එළිදක්වන අතරතුර, වින්‍යාසය සමහර ස්ථානවල යාවත්කාලීන කර ඇත, නමුත් අනෙක් ඒවා නොවේ. එක් යන්ත්‍රයක ක්රියාත්මක වන අපගේ යෙදුමේ සමහර ක්‍රියාවලීන් නව වින්‍යාසයකින් සහ කොහේ හරි පැරණි එකක් සමඟ නැවත ආරම්භ කරන ලදී. මෙය අපගේ බෙදා හරින ලද යෙදුම වින්‍යාස කිරීමේ ඉදිරිදර්ශනයකින් අනනුකූල වීමට හේතු විය හැක. මෙම ගැටළුව පොදු වේ. ගතික වින්යාසයක් සඳහා, එය වඩාත් අදාළ වන්නේ එය පියාසර කිරීමේදී වෙනස් කළ හැකි බව ඇඟවුම් කරන බැවිනි.
තවත් ගැටළුවක් වන්නේ කණ්ඩායම් සාමාජිකත්වයයි. අපට සෑම විටම කම්කරුවන් කට්ටලයක් ඇත, ඔවුන්ගෙන් කවුරුන් ජීවතුන් අතර සිටින්නේද, ඔවුන්ගෙන් කවුරුන් මිය ගොස් ඇත්දැයි දැන ගැනීමට අපට සැමවිටම අවශ්‍යය. ස්වාමියෙකු සිටී නම්, ගණනය කිරීම් හෝ දත්ත සමඟ වැඩ කිරීම සඳහා සේවාදායකයින් වෙත හරවා යැවිය හැක්කේ කුමන සේවකයින්ද යන්න ඔහු තේරුම් ගත යුතුය. නිරන්තරයෙන් පැන නගින ගැටළුවක් වන්නේ අපගේ පොකුරේ වැඩ කරන්නේ කවුරුන්ද යන්න අප දැනගත යුතුය.
තවත් සාමාන්ය ගැටලුවක් වන්නේ නායකත්ව මැතිවරණය, අපට භාරව සිටින්නේ කවුද යන්න දැන ගැනීමට අවශ්ය වූ විටය. එක් උදාහරණයක් නම්, අප සතුව යම් ක්‍රියාවලියක් ඇති විට, ලිවීමේ මෙහෙයුම් ලැබෙන අතර පසුව ඒවා වෙනත් ක්‍රියාවලීන් අතර ප්‍රතිවර්තනය කරයි. ඔහු නායකයා වනු ඇත, අන් සියල්ලන්ම ඔහුට කීකරු වනු ඇත, ඔහු අනුගමනය කරනු ඇත. ක්‍රියාවලියක් තෝරා ගැනීම අවශ්ය වන අතර එමඟින් එය සෑම කෙනෙකුටම නොපැහැදිලි වේ, එවිට නායකයින් දෙදෙනෙකු තෝරාගෙන ඇති බවක් නොපෙනේ.
අන්‍යෝන්‍ය වශයෙන් ප්රවේශය ද ඇත. මෙහි ගැටලුව වඩාත් සංකීර්ණයි. mutex වැනි දෙයක් තිබේ, ඔබ බහු-නූල් වැඩසටහන් ලියන විට සහ යම් සම්පතකට ප්‍රවේශ වීමට අවශ්ය විට, උදාහරණයක් ලෙස, මතක සෛලයක්, සීමා කර එක් නූලකින් පමණක් සිදු කළ යුතුය. මෙහිදී සම්පත වඩාත් වියුක්ත දෙයක් විය හැකිය. තවද අපගේ ජාලයේ විවිධ නෝඩ් වලින් විවිධ යෙදුම් ලබා ගත යුත්තේ ලබා දී ඇති සම්පතකට පමණක් ප්‍රවේශ විය යුතු අතර, සෑම කෙනෙකුටම එය වෙනස් කිරීමට හෝ එහි යමක් ලිවීමට නොහැකි වනු ඇත. මේවා ඊනියා අගුල් ය.
ZooKeeper ඔබට මෙම සියලු ගැටළු එක් හෝ තවත් මට්ටමකට විසඳීමට ඉඩ සලසයි. එය ඔබට මෙය කිරීමට ඉඩ දෙන්නේ කෙසේදැයි මම උදාහරණ සමඟ පෙන්වන්නම්.
අවහිර කරන ප්‍රාථමිකයන් නොමැත. අපි යමක් භාවිතා කිරීමට පටන් ගත් විට, මෙම ප්‍රාථමිකය කිසිදු සිදුවීමක් සිදුවන තෙක් බලා නොසිටිනු ඇත. බොහෝ දුරට ඉඩ ඇති පරිදි, මෙම දෙය අසමමුහුර්තව ක්රියා කරනු ඇත, එමඟින් ක්‍රියාවලීන් යමක් බලාපොරොත්තුවෙන් සිටින අතරතුර එල්ලා නොයෑමට ඉඩ සලසයි. මේක ගොඩක් ප්රයෝජනවත් දෙයක්.
සියලුම සේවාලාභීන්ගේ ඉල්ලීම් සාමාන්ය පෝලිමේ අනුපිළිවෙලට සකසා ඇත.
තවද සේවාදායකයා විසින් වෙනස් කරන ලද දත්ත තමන් විසින්ම දැකීමට පෙර, යම් ප්‍රාන්තයක සිදුවන වෙනස්කම්, දත්තවල වෙනස්වීම් පිළිබඳව දැනුම්දීමක් ලබා ගැනීමට සේවාදායකයන්ට අවස්ථාව තිබේ.
ZooKeeper හට ආකාර දෙකකින් වැඩ කළ හැක. පළමුවැන්න ස්වාධීන, එක් නෝඩයක් මත ය. මෙය පරීක්ෂා කිරීම සඳහා පහසු වේ. එය ඕනෑම සර්වර් ගණනක පොකුරු ආකාරයෙන්ද ක්රියා කළ හැක. අපට යන්ත්‍ර 100 ක පොකුරක් තිබේ නම්, එය යන්ත්‍ර 100 ක වැඩ කිරීම අවශ්ය නොවේ. ඔබට ZooKeeper ධාවනය කළ හැකි යන්ත්‍ර කිහිපයක් තෝරා ගැනීම ප්‍රමාණවත් වේ. තවද එය ඉහළ ලබා ගැනීමේ මූලධර්මය ප්‍රකාශ කරයි. ධාවනය වන සෑම අවස්ථාවකදීම, ZooKeeper දත්තවල සම්පූර්ණ පිටපතක් ගබඩා කරයි. ඔහු එය කරන්නේ කෙසේදැයි පසුව මම ඔබට කියමි. එය දත්ත කොටස් කිරීම හෝ කොටස් කිරීම සිදු නොකරයි. එක අතකින් අපිට ගොඩක් ගබඩා කරන්න බැරි වීම අවාසියක්, අනිත් පැත්තෙන් මේක කරන්න අවශ්ය නැහැ. එය නිර්මාණය කර ඇත්තේ එය නොවේ, එය දත්ත ගබඩාවක් නොවේ.
සේවාදායකයා පැත්තෙන් දත්ත හැඹිලිගත කළ හැක. මෙය සම්මත මූලධර්මයක් වන අතර එමඟින් අපි සේවාවට බාධා නොකරන අතර එකම ඉල්ලීම් සමඟ එය පටවන්නේ නැත. දක්ෂ සේවාදායකයෙක් සාමාන්යයෙන් මේ ගැන දන්නා අතර එය හැඹිලි කරයි.
උදාහරණයක් ලෙස, මෙහි යමක් වෙනස් වී ඇත. යම් ආකාරයක යෙදුමක් තිබේ. නව නායකයෙකු තේරී පත් විය, ඔහු වගකිව යුතුය, උදාහරණයක් ලෙස, ලිවීමේ මෙහෙයුම් සැකසීම සඳහා. තවද අපට දත්ත අනුකරණය කිරීමට අවශ්යයි. එක් විසඳුමක් වන්නේ එය ලූපයකට දැමීමයි. අපි නිරන්තරයෙන් අපගේ සේවාව ප්‍රශ්න කරමු - යමක් වෙනස් වී තිබේද? දෙවන විකල්පය වඩාත් ප්රශස්ත වේ. මෙය යම් දෙයක් වෙනස් වී ඇති බව සේවාදායකයින්ට දැනුම් දීමට ඔබට ඉඩ සලසන ඔරලෝසු යාන්ත්‍රණයකි. මෙය සම්පත් අතින් මිල අඩු ක්රමයක් වන අතර ගනුදෙනුකරුවන්ට වඩාත් පහසු වේ.
සේවාදායකයා යනු ZooKeeper භාවිතා කරන පරිශීලකයා වේ.
Server යනු ZooKeeper ක්‍රියාවලියම වේ.
ZooKeeper හි ප්රධාන දෙය Znode වේ. සියලුම znodes ZooKeeper විසින් මතකයේ ගබඩා කර ඇති අතර ධූරාවලි රූප සටහනක් ආකාරයෙන්, ගසක ආකාරයෙන් සංවිධානය කර ඇත.
මෙහෙයුම් වර්ග දෙකක් තිබේ. පළමුවැන්න යාවත්කාලීන කිරීම/ලිවීම, යම් මෙහෙයුමක් අපගේ ගසේ තත්වය වෙනස් කරන විට. ගස පොදු ය.
තවද සේවාදායකයා එක් ඉල්ලීමක් සම්පූර්ණ කර නැති අතර විසන්ධි වී ඇත, නමුත් එය ZooKeeper සමඟ අන්තර් ක්රියා කරන සැසියක් ස්ථාපිත කළ හැකිය.
ZooKeeper හි දත්ත ආකෘතිය ගොනු පද්ධතියකට සමාන වේ. සම්මත මූලයක් ඇති අතර පසුව අපි මූලයෙන් යන නාමාවලි හරහා ගියෙමු. ඉන්පසු පළමු මට්ටමේ, දෙවන මට්ටමේ නාමාවලිය. මේ සියල්ල znodes වේ.
එක් එක් znode සමහර දත්ත ගබඩා කළ හැක, සාමාන්යයෙන් ඉතා විශාල නොවේ, උදාහරණයක් ලෙස, කිලෝබයිට් 10 ක්. තවද සෑම znode එකකටම නිශ්චිත දරුවන් සංඛ්‍යාවක් සිටිය හැක.
Znodes වර්ග කිහිපයකින් පැමිණේ. ඒවා නිර්මාණය කළ හැකිය. තවද znode නිර්මාණය කිරීමේදී, එය අයත් විය යුතු වර්ගය අපි සඳහන් කරමු.
වර්ග දෙකක් තිබේ. පළමුවැන්න අකාලික කොඩියයි. Znode සැසියක් තුළ ජීවත් වේ. උදාහරණයක් ලෙස, සේවාදායකයා සැසියක් පිහිටුවා ඇත. තවද මෙම සැසිය ජීවමානව පවතින තාක් කල් එය පවතිනු ඇත. අනවශ්ය දෙයක් නිෂ්පාදනය නොකිරීමට මෙය අවශ්ය වේ. සැසියක් තුළ දත්ත ප්රාථමික ගබඩා කිරීම අපට වැදගත් වන අවස්ථා සඳහාද මෙය සුදුසු වේ.
දෙවන වර්ගය අනුක්‍රමික ධජයයි. එය znode වෙත යන මාර්ගයේ කවුන්ටරය වැඩි කරයි. උදාහරණයක් ලෙස, අපට යෙදුම් 1_5 සමඟ නාමාවලියක් තිබුණි. අපි පළමු නෝඩය නිර්මාණය කළ විට, එය p_1, දෙවන - p_2 ලැබුණි. තවද අපි මෙම ක්රමය සෑම අවස්ථාවකම ඇමතූ විට, අපි සම්පූර්ණ මාර්ගය පසුකර, මාර්ගයේ කොටසක් පමණක් දක්වන අතර, අපි නෝඩ් වර්ගය - අනුක්‍රමික ලෙස දක්වන නිසා මෙම අංකය ස්වයංක්‍රීයව වැඩි වේ.
නිතිපතා znode. ඇය සැමවිටම ජීවත් වන අතර අප ඇයට පවසන නම ඇත.
තවත් ප්රයෝජනවත් දෙයක් වන්නේ ඔරලෝසු කොඩියයි. අපි එය ස්ථාපනය කරන්නේ නම්, සේවාදායකයාට නිශ්චිත නෝඩයක් සඳහා සමහර සිදුවීම් සඳහා දායක විය හැකිය. මෙය සිදු කරන්නේ කෙසේදැයි මම ඔබට පසුව උදාහරණයක් සමඟ පෙන්වන්නම්. ZooKeeper විසින්ම නෝඩයේ දත්ත වෙනස් වී ඇති බව සේවාදායකයාට දැනුම් දෙයි. කෙසේ වෙතත්, සමහර නව දත්ත පැමිණ ඇති බවට දැනුම්දීම් සහතික නොවේ. ඔවුන් සරලව පවසන්නේ යමක් වෙනස් වී ඇති බවයි, එබැවින් ඔබට පසුව වෙනම ඇමතුම් සමඟ දත්ත සැසඳිය යුතුය.
මම දැනටමත් පවසා ඇති පරිදි, දත්තවල අනුපිළිවෙල කිලෝබයිට් මගින් තීරණය වේ. විශාල පෙළ දත්ත එහි ගබඩා කිරීමට අවශ්ය නැත, මන්ද එය දත්ත සමුදායක් නොවන බැවින් එය ක්රියාකාරී සම්බන්ධීකරණ සේවාදායකයකි.
මම සැසි ගැන ටිකක් කියන්නම්. අපට බහු සේවාදායක තිබේ නම්, එවිට අපට සැසි හැඳුනුම්කාරකය භාවිතයෙන් විනිවිදභාවයෙන් සේවාදායකයෙන් සේවාදායකයට යා හැකිය. එය තරමක් පහසු ය.
සෑම සැසියකටම යම් ආකාරයක කල් ඉකුත්වීමක් ඇත. සැසියක් නිර්වචනය කරනු ලබන්නේ සේවාදායකයා එම සැසියේදී සේවාදායකයට යමක් යවන්නේද යන්න මගිනි. කල් ඉකුත් වූ කාලය තුළ ඔහු කිසිවක් සම්ප්රේෂණය නොකළේ නම්, සැසිය කඩා වැටේ, නැතහොත් සේවාදායකයාට එය වසා දැමිය හැකිය.
එහි එතරම් විශේෂාංග නොමැත, නමුත් ඔබට මෙම API සමඟ විවිධ දේ කළ හැකිය. අපි create දැකපු call එක znode එකක් හදලා parameters තුනක් ගන්නවා. මෙය znode වෙත යන මාර්ගය වන අතර, එය මුල සිට සම්පූර්ණයෙන් සඳහන් කළ යුතුය. තවද මෙය අපට එහි මාරු කිරීමට අවශ්ය දත්ත කිහිපයක් වේ. සහ කොඩි වර්ගය. නිර්මාණය කිරීමෙන් පසු එය znode වෙත මාර්ගය නැවත ලබා දෙයි.
දෙවනුව, ඔබට එය මකා දැමිය හැකිය. මෙහි ඇති උපක්‍රමය නම්, දෙවන පරාමිතිය, znode වෙත යන මාර්ගයට අමතරව, අනුවාදය නියම කළ හැකිය. ඒ අනුව, අප විසින් මාරු කරන ලද එහි අනුවාදය සත්‍ය වශයෙන්ම පවතින අනුවාදයට සමාන නම් එම znode මකා දැමෙනු ඇත.
අපට මෙම අනුවාදය පරීක්ෂා කිරීමට අවශ්ය නැතිනම්, අපි සරලව "-1" තර්කය සම්මත කරමු.
තෙවනුව, එය znode වල පැවැත්ම පරීක්ෂා කරයි. නෝඩය තිබේ නම් සත්‍ය ලබා දෙයි, එසේ නොමැති නම් අසත්‍යය.
ඉන්පසු ධජ ඔරලෝසුව දිස්වේ, එමඟින් ඔබට මෙම නෝඩය නිරීක්ෂණය කිරීමට ඉඩ සලසයි.
ඔබට මෙම ධජය නොපවතින නෝඩයක පවා සැකසිය හැකි අතර එය දිස් වූ විට දැනුම් දීමක් ලබා ගත හැක. මෙය ද ප්රයෝජනවත් විය හැකිය.
තවත් අභියෝග කිහිපයක් තිබේ දත්ත ලබා ගන්න. අපට znode හරහා දත්ත ලබාගත හැකි බව පැහැදිලිය. ඔබට ධජ ඔරලෝසුව ද භාවිතා කළ හැකිය. මෙම අවස්ථාවේදී, නෝඩයක් නොමැති නම් එය ස්ථාපනය නොවේ. එමනිසා, එය පවතින බව ඔබ තේරුම් ගත යුතු අතර, පසුව දත්ත ලබා ගන්න.
ද ඇත දත්ත සකසන්න. මෙන්න අපි අනුවාදය සම්මත කරමු. තවද අපි මෙය ලබා දුන්නොත්, යම් අනුවාදයක znode මත දත්ත යාවත්කාලීන වේ.
මෙම චෙක්පත බැහැර කිරීමට ඔබට "-1" ද නියම කළ හැක.
තවත් ප්රයෝජනවත් ක්රමයකි ළමයි ලබාගන්න. අපට එයට අයත් සියලුම znodes ලැයිස්තුවක් ද ලබා ගත හැකිය. ධජ ඔරලෝසුව සැකසීමෙන් අපට මෙය නිරීක්ෂණය කළ හැකිය.
සහ ක්රමය සමමුහුර්ත කරන්න සියලුම වෙනස්කම් එකවර යැවීමට ඉඩ සලසයි, එමගින් ඒවා සුරැකී ඇති බව සහතික කර ඇති අතර සියලු දත්ත සම්පූර්ණයෙන්ම වෙනස් කර ඇත.
අපි සාම්ප්‍රදායික ක්‍රමලේඛනය සමඟ සාදෘශ්‍ය අඳින්නේ නම්, ඔබ ලිවීම වැනි ක්‍රම භාවිතා කරන විට, තැටියට යමක් ලියන විට සහ එය ඔබට ප්‍රතිචාරයක් ලබා දුන් පසු, ඔබ දත්ත තැටියට ලියා ඇති බවට සහතිකයක් නොමැත. තවද මෙහෙයුම් පද්ධතිය සෑම දෙයක්ම ලියා ඇති බව විශ්වාස කරන විට පවා, ක්රියාවලිය බෆර ස්ථර හරහා ගමන් කරන යාන්ත්‍රණයන් තැටියේම ඇති අතර, දත්ත තැටියේ තැබෙන්නේ ඉන් පසුවය.
බොහෝ විට අසමමුහුර්ත ඇමතුම් භාවිතා වේ. මෙය සේවාදායකයාට විවිධ ඉල්ලීම් සමඟ සමාන්තරව වැඩ කිරීමට ඉඩ සලසයි. ඔබට සමමුහුර්ත ප්රවේශය භාවිතා කළ හැකිය, නමුත් එය අඩු ඵලදායී වේ.
අපි කතා කරපු මෙහෙයුම් දෙක තමයි දත්ත වෙනස් කරන update/write. ඒ තමයි create, setData, sync, delete. සහ කියවීම පවතී, getData, getChildren.
බෙදා හරින ලද පද්ධතියක වැඩ කිරීම සඳහා ඔබට ප්රාථමික සෑදිය හැකි ආකාරය පිළිබඳ උදාහරණ කිහිපයක් දැන්. උදාහරණයක් ලෙස, යම් දෙයක වින්‍යාසය හා සම්බන්ධ. නව සේවකයෙක් පෙනී සිටියේය. අපි යන්ත්රය එකතු කර ක්රියාවලිය ආරම්භ කළා. තවද පහත ප්‍රශ්න තුන ඇත. එය වින්‍යාස කිරීම සඳහා ZooKeeper වෙතින් විමසන්නේ කෙසේද? තවද අපට වින්‍යාසය වෙනස් කිරීමට අවශ්ය නම්, අපි එය වෙනස් කරන්නේ කෙසේද? අපි එය වෙනස් කළ පසු, අප සතුව තිබූ එම සේවකයින් එය ලබා ගන්නේ කෙසේද?
ZooKeeper මෙය සාපේක්ෂව පහසු කරයි. උදාහරණයක් ලෙස, අපගේ znode ගස ඇත. අපගේ යෙදුම සඳහා නෝඩයක් මෙහි ඇත, අපි එහි අතිරේක නෝඩයක් සාදන්නෙමු, එහි වින්‍යාසයෙන් දත්ත අඩංගු වේ. මේවා වෙනම පරාමිතීන් විය හැකිය හෝ නොවිය හැකිය. ප්‍රමාණය කුඩා බැවින්, වින්‍යාස ප්‍රමාණය සාමාන්යයෙන් කුඩා වන බැවින් එය මෙහි ගබඩා කිරීමට තරමක් හැකි ය.
ඔබ ක්රමය භාවිතා කරයි දත්ත ලබා ගන්න නෝඩයෙන් සේවකයා සඳහා වින්‍යාසය ලබා ගැනීමට. සත්‍ය ලෙස සකසන්න. කිසියම් හේතුවක් නිසා මෙම නෝඩය නොපවතියි නම්, එය දිස්වන විට හෝ එය වෙනස් වන විට අපි ඒ ගැන දැනුම් දෙනු ඇත. යමක් වෙනස් වී ඇති බව අපට දැන ගැනීමට අවශ්ය නම්, අපි එය සත්‍ය බවට පත් කරමු. තවද මෙම නෝඩයේ දත්ත වෙනස් වුවහොත්, අපි ඒ ගැන දැන ගනිමු.
දත්ත සකසන්න. අපි දත්ත සකසන්න, "-1" සකසන්න, එනම් අපි අනුවාදය පරීක්ෂා නොකරමු, අපි සෑම විටම එක් වින්යාසයක් ඇති බව උපකල්පනය කරමු, අපට බොහෝ වින්යාසයන් ගබඩා කිරීමට අවශ්ය නොවේ. ඔබට ගොඩක් ගබඩා කිරීමට අවශ්ය නම්, ඔබට තවත් මට්ටමක් එකතු කිරීමට අවශ්ය වනු ඇත. මෙහි ඇත්තේ එකක් පමණක් බව අපි විශ්වාස කරමු, එබැවින් අපි නවතම එක පමණක් යාවත්කාලීන කරන්නෙමු, එබැවින් අපි අනුවාදය පරීක්ෂා නොකරමු. මේ මොහොතේ, කලින් දායක වූ සියලුම සේවාදායකයින්ට මෙම නෝඩයේ යමක් වෙනස් වී ඇති බවට දැනුම්දීමක් ලැබේ. ඔවුන්ට එය ලැබුණු පසු, ඔවුන් නැවත දත්ත ඉල්ලා සිටිය යුතුය. දැනුම්දීම නම් ඔවුන්ට දත්ත නොලැබෙන නමුත් වෙනස්කම් දැනුම්දීම පමණි. මෙයින් පසු ඔවුන් නව දත්ත ඉල්ලා සිටිය යුතුය.
ප්රාථමික භාවිතා කිරීම සඳහා දෙවන විකල්පය වේ කණ්ඩායම් සාමාජිකත්වය. අප සතුව බෙදා හරින ලද අයදුම්පතක් ඇත, කම්කරුවන් පිරිසක් සිටින අතර ඔවුන් සියල්ලන්ම සිටින බව අපට තේරුම් ගැනීමට අවශ්‍යය. එමනිසා, ඔවුන් අපගේ අයදුම්පතෙහි වැඩ කරන බව ඔවුන් විසින්ම ලියාපදිංචි කළ යුතුය. එමෙන්ම දැනට අප සතුව ඇති සියලුම ක්රියාකාරී සේවකයින් පිළිබඳව මාස්ටර් ක්රියාවලියෙන් හෝ වෙනත් ස්ථානයක සිට සොයා ගැනීමටද අපට අවශ්‍යය.
අපි මෙය කරන්නේ කෙසේද? යෙදුම සඳහා, අපි කම්කරු නෝඩයක් සාදන අතර නිර්මාණය කිරීමේ ක්රමය භාවිතා කර එහි උප මට්ටමක් එක් කරන්නෙමු. මට ස්ලයිඩයේ දෝෂයක් ඇත. මෙන්න ඔබට අවශ්යයි අනුක්‍රමික සඳහන් කරන්න, එවිට සියලුම කම්කරුවන් එකින් එක නිර්මාණය වනු ඇත. තවද මෙම නෝඩයේ දරුවන් පිළිබඳ සියලු දත්ත ඉල්ලා සිටින යෙදුම, පවතින සියලුම ක්රියාකාරී සේවකයින් ලබා ගනී.
මෙය ජාවා කේතයෙන් මෙය කළ හැකි ආකාරය පිළිබඳ භයානක ක්රියාත්මක කිරීමකි. ප්රධාන ක්රමය සමඟ අවසානයේ සිට ආරම්භ කරමු. මෙය අපගේ පන්තියයි, අපි එහි ක්රමය නිර්මාණය කරමු. අපි ධාරකය භාවිතා කරන පළමු තර්කය ලෙස, අපි සම්බන්ධ වන ස්ථානය, එනම් අපි එය තර්කයක් ලෙස සකස් කරමු. දෙවන තර්කය වන්නේ කණ්ඩායමේ නමයි.
සම්බන්ධතාවය සිදුවන්නේ කෙසේද? මෙය භාවිතා කරන API සඳහා සරල උදාහරණයකි. මෙහි සෑම දෙයක්ම සාපේක්ෂව සරල ය. සම්මත පන්තියේ ZooKeeper ඇත. අපි එයට සත්කාරකයින් පාස් කරමු. සහ කල් ඉකුත්වීම, උදාහරණයක් ලෙස, තත්පර 5 දක්වා සකසන්න. ඒවගේම අපිට connectSignal කියලා සාමාජිකයෙක් ඉන්නවා. අත්යවශ්යයෙන්ම, අපි සම්ප්රේෂණය කරන ලද මාර්ගය ඔස්සේ කණ්ඩායමක් නිර්මාණය කරමු. යමක් ලිවිය හැකි වුවද අපි එහි දත්ත ලියන්නේ නැත. තවද මෙහි නෝඩය ස්ථීර වර්ගයකි. අත්යවශ්යයෙන්ම, මෙය සාමාන්ය නිත්‍ය නෝඩයක් වන අතර එය සැමවිටම පවතිනු ඇත. සැසිය නිර්මාණය වන්නේ මෙහිදීය. මෙය සේවාදායකයා විසින්ම ක්රියාත්මක කිරීමයි. අපගේ සේවාදායකයා සැසිය සජීවී බව පෙන්නුම් කරමින් වරින් වර පණිවිඩ එවනු ඇත. අපි සැසිය අවසන් කරන විට, අපි සමීපව අමතන්නෙමු, එය එයයි, සැසිය වැටේ. මෙය සිදු වන්නේ අපට යමක් වැරදුනහොත්, ZooKeeper ඒ ගැන සොයා බලා සැසිය කපා හැරීමටයි.
සම්පතක් අගුළු දමන්නේ කෙසේද? මෙන්න හැම දෙයක්ම ටිකක් සංකීර්ණයි. අපිට වැඩකාරයෝ සෙට් එකක් ඉන්නවා, අපිට ලොක් කරන්න ඕන සම්පතක් තියෙනවා. මෙය සිදු කිරීම සඳහා, අපි වෙනම නෝඩයක් සාදන්නෙමු, උදාහරණයක් ලෙස, lock1 ලෙස හැඳින්වේ. අපට එය නිර්මාණය කිරීමට හැකි වූයේ නම්, අපට මෙහි අගුලක් ලැබුණි. තවද අපට එය නිර්මාණය කිරීමට නොහැකි වූවා නම්, සේවකයා මෙතැනින් getData ලබා ගැනීමට උත්සාහ කරයි, සහ නෝඩය දැනටමත් නිර්මාණය කර ඇති බැවින්, අපි මෙහි නිරීක්ෂකයෙකු දමා මෙම නෝඩයේ තත්වය වෙනස් වූ මොහොතේ, අපි ඒ ගැන දැන ගනිමු. ඒ වගේම අපට එය නැවත නිර්මාණය කිරීමට කාලය ලබා ගැනීමට උත්සාහ කළ හැකියි. අපි මෙම නෝඩය ගත්තා නම්, මෙම අගුල ගත්තා නම්, අපට තවදුරටත් අගුල අවශ්ය නොවූ පසු, අපි එය අත්හරිමු, මන්ද නෝඩය පවතින්නේ සැසිය තුළ පමණි. ඒ අනුව, එය අතුරුදහන් වනු ඇත. තවත් සේවාදායකයෙකුට, වෙනත් සැසියක රාමුව තුළ, මෙම නෝඩයේ අගුල ගැනීමට හැකි වනු ඇත, නැතහොත්, යමක් වෙනස් වී ඇති බවට ඔහුට දැනුම් දීමක් ලැබෙනු ඇති අතර ඔහුට එය නියමිත වේලාවට කිරීමට උත්සාහ කළ හැකිය.
ඔබට ප්රධාන නායකයා තෝරා ගත හැකි ආකාරය පිළිබඳ තවත් උදාහරණයක්. මෙය ටිකක් සංකීර්ණයි, නමුත් සාපේක්ෂව සරලයි. මොකද මෙතන වෙන්නෙ? සියලුම කම්කරුවන් එකතු කරන ප්රධාන නෝඩයක් ඇත. අපි නායකයා ගැන දත්ත ලබා ගැනීමට උත්සාහ කරනවා. මෙය සාර්ථකව සිදු වූයේ නම්, එනම් අපට යම් දත්තයක් ලැබුණි නම්, අපගේ සේවකයා මෙම නායකයා අනුගමනය කිරීමට පටන් ගනී. දැනටමත් නායකයෙකු සිටින බව ඔහු විශ්වාස කරයි.
කිසියම් හේතුවක් නිසා නායකයා මිය ගියහොත්, උදාහරණයක් ලෙස, වැටුණොත්, අපි නව නායකයෙකු නිර්මාණය කිරීමට උත්සාහ කරමු. අපි සාර්ථක වුවහොත් අපගේ සේවකයා නායකයා බවට පත්වේ. මේ මොහොතේ යමෙකු නව නායකයෙකු නිර්මාණය කිරීමට සමත් වූවා නම්, අපි ඒ කවුද යන්න තේරුම් ගෙන ඔහු අනුගමනය කිරීමට උත්සාහ කරමු.
මෙහිදී ඊනියා රංචු ප්‍රයෝගය, එනම් රංචු ප්‍රයෝගය හටගන්නේ නායකයකු මිය ගිය විට, කාලයේ පළමුවැන්නා නායකයා වන බැවිනි.
සම්පතක් අල්ලා ගැනීමේදී, ඔබට තරමක් වෙනස් ප්රවේශයක් භාවිතා කිරීමට උත්සාහ කළ හැකිය, එය පහත පරිදි වේ. උදාහරණයක් ලෙස, අපට අගුලක් ලබා ගැනීමට අවශ්යයි, නමුත් හර්ට් ආචරණය නොමැතිව. අපගේ යෙදුම අගුලක් සහිත දැනටමත් පවතින නෝඩයක් සඳහා සියලුම නෝඩ් හැඳුනුම්පත් ලැයිස්තුවක් ඉල්ලා සිටින බව එය සමන්විත වේ. ඊට පෙර අපි අගුලක් නිර්මාණය කළ නෝඩය අපට ලැබුණු කට්ටලයෙන් කුඩාම නම්, මෙයින් අදහස් කරන්නේ අපි අගුල අල්ලාගෙන ඇති බවයි. අපට අගුලක් ලැබී ඇත්දැයි අපි පරීක්ෂා කරමු. චෙක් එකක් විදියට අලුත් ලොක් එකක් හදනකොට අපිට ලැබුණු හැඳුනුම්පත අවමයි කියලා කොන්දේසියක් එනවා. අපට එය ලැබුනේ නම්, අපි තවදුරටත් වැඩ කරන්නෙමු.
අපගේ අගුලට වඩා කුඩා නිශ්චිත හැඳුනුම්පතක් තිබේ නම්, අපි මෙම සිදුවීමට මුරකරුවෙකු තබා යමක් වෙනස් වන තෙක් දැනුම් දෙන තෙක් බලා සිටිමු. එනම්, අපට මෙම අගුල ලැබුණි. එය වැටෙන තුරු, අපි අවම හැඳුනුම්පත බවට පත් නොවන අතර අවම අගුල නොලැබෙනු ඇත, එබැවින් අපට ලොග් වීමට හැකි වනු ඇත. මෙම කොන්දේසිය සපුරා නොමැති නම්, අපි වහාම මෙහි ගොස් මෙම අගුල නැවත ලබා ගැනීමට උත්සාහ කරමු, මන්ද මෙම කාලය තුළ යමක් වෙනස් වී තිබිය හැකි බැවිනි.
ZooKeeper සමන්විත වන්නේ කුමක් ද? ප්රධාන කරුණු 4ක් තියෙනවා. මෙය සැකසුම් ක්‍රියාවලි වේ - ඉල්ලීම. ඒ වගේම ZooKeeper Atomic Broadcast. සියලුම මෙහෙයුම් සටහන් කර ඇති කැපුම් ලොගයක් ඇත. සහ In-memory Replicated DB ම, එනම් මෙම සම්පූර්ණ ගස ගබඩා කර ඇති දත්ත ගබඩාව ම ය.
සියලුම ලිවීමේ මෙහෙයුම් ඉල්ලීම් ප්‍රොසෙසරය හරහා සිදුවන බව සඳහන් කිරීම වටී. තවද කියවීමේ මෙහෙයුම් සෘජුවම මතකයේ දත්ත ගබඩාවට යයි.
දත්ත සමුදාය සම්පූර්ණයෙන්ම අනුකරණය කර ඇත. ZooKeeper හි සියලුම අවස්ථා දත්තවල සම්පූර්ණ පිටපතක් ගබඩා කරයි.
බිඳවැටීමකින් පසු දත්ත සමුදාය ප්‍රතිසාධනය කිරීම සඳහා, කැපවීම් ලොගයක් ඇත. සම්මත පරිචය නම්, දත්ත මතකයට ඇතුළු වීමට පෙර, එය එහි ලියා ඇති අතර එමඟින් එය බිඳ වැටුණහොත්, මෙම ලොගය නැවත ධාවනය කළ හැකි අතර පද්ධති තත්ත්වය ප්‍රතිසාධනය කළ හැකිය. තවද දත්ත සමුදායේ ආවර්තිතා ඡායාරූප ද භාවිතා වේ.
ZooKeeper Atomic Broadcast යනු ප්‍රතිනිර්මාණය කරන ලද දත්ත පවත්වා ගැනීමට භාවිතා කරන දෙයකි.
ZAB අභ්‍යන්තරව ZooKeeper node හි දෘෂ්ටි කෝණයෙන් නායකයෙකු තෝරා ගනී. අනෙකුත් නෝඩ් ඇගේ අනුගාමිකයින් බවට පත් වන අතර ඇයගෙන් යම් ක්රියා බලාපොරොත්තු වේ. ඔවුන්ට ඇතුළත් කිරීම් ලැබුණහොත්, ඔවුන් සියල්ල නායකයා වෙත යොමු කරයි. ඔහු මුලින්ම ලිවීමේ මෙහෙයුමක් සිදු කරන අතර පසුව ඔහුගේ අනුගාමිකයින්ට වෙනස් වී ඇති දේ ගැන පණිවිඩයක් යවයි. මෙය ඇත්ත වශයෙන්ම පරමාණුකව සිදු කළ යුතුය, එනම් සමස්ත දෙයෙහි පටිගත කිරීම සහ විකාශනය කිරීමේ මෙහෙයුම පරමාණුකව සිදු කළ යුතු අතර එමඟින් දත්ත අනුකූලතාව සහතික කෙරේ.
එය ක්‍රියාවලි කරන්නේ ලිවීමේ ඉල්ලීම් පමණි. එහි ප්රධාන කාර්යය වන්නේ මෙහෙයුම ගනුදෙනු යාවත්කාලීන කිරීමක් බවට පරිවර්තනය කිරීමයි. මෙය විශේෂයෙන් ජනනය කරන ලද ඉල්ලීමකි.
තවද එකම මෙහෙයුම සඳහා යාවත්කාලීනවල අසමර්ථතාවය සහතික කර ඇති බව සඳහන් කිරීම වටී. එය කුමක්ද? මෙම දෙය, දෙවරක් ක්රියාත්මක කළහොත්, එකම තත්වය ඇත, එනම් ඉල්ලීමම වෙනස් නොවේ. මෙය සිදු කළ යුතු අතර එමඟින් බිඳවැටීමකදී, ඔබට මෙහෙයුම නැවත ආරම්භ කළ හැකි අතර එමඟින් මේ මොහොතේ වැටී ඇති වෙනස්කම් ආපසු හැරවිය හැකිය. මෙම අවස්ථාවෙහිදී, පද්ධතියේ තත්වය සමාන වනු ඇත, එනම් එකම මාලාවක්, උදාහරණයක් ලෙස, යාවත්කාලීන ක්‍රියාවලීන්, පද්ධතියේ විවිධ අවසාන තත්වයන්ට තුඩු දුන් බව නොවිය යුතුය.
මූලාශ්රය: www.habr.com