"ഹദൂപ്. ZooKeeper" Mail.Ru ഗ്രൂപ്പ് ടെക്‌നോസ്ട്രീം സീരീസിൽ നിന്നുള്ള "Hadoop-ൽ വലിയ അളവിലുള്ള ഡാറ്റ വിതരണം ചെയ്യുന്നതിനുള്ള രീതികൾ"

"ഹഡൂപ്പിലെ വലിയ അളവിലുള്ള ഡാറ്റ വിതരണം ചെയ്യുന്നതിനുള്ള രീതികൾ" എന്ന പരമ്പരയിൽ നിന്നുള്ള "ഹഡൂപ്പ്. സൂ കീപ്പർ" എന്ന പ്രഭാഷണത്തിന്റെ ട്രാൻസ്ക്രിപ്റ്റ് വായിക്കാൻ ഞാൻ നിർദ്ദേശിക്കുന്നു.

എന്താണ് ZooKeeper, Hadoop ഇക്കോസിസ്റ്റത്തിൽ അതിന്റെ സ്ഥാനം. വിതരണം ചെയ്ത കമ്പ്യൂട്ടിംഗിനെക്കുറിച്ചുള്ള അസത്യങ്ങൾ. ഒരു സാധാരണ വിതരണ സംവിധാനത്തിന്റെ ഡയഗ്രം. വിതരണ സംവിധാനങ്ങൾ ഏകോപിപ്പിക്കുന്നതിൽ ബുദ്ധിമുട്ട്. സാധാരണ ഏകോപന പ്രശ്നങ്ങൾ. ZooKeeper-ന്റെ രൂപകൽപ്പനയ്ക്ക് പിന്നിലെ തത്വങ്ങൾ. ZooKeeper ഡാറ്റ മോഡൽ. znode പതാകകൾ. സെഷനുകൾ. ക്ലയന്റ് API. പ്രിമിറ്റീവ്സ് (കോൺഫിഗറേഷൻ, ഗ്രൂപ്പ് അംഗത്വം, ലളിതമായ ലോക്കുകൾ, ലീഡർ തിരഞ്ഞെടുപ്പ്, കന്നുകാലി പ്രഭാവം ഇല്ലാതെ ലോക്കിംഗ്). ZooKeeper വാസ്തുവിദ്യ. മൃഗശാലാ സൂക്ഷിപ്പുകാരൻ ഡി.ബി. ZAB. ഹാൻഡ്ലർ അഭ്യർത്ഥിക്കുക.

ഇന്ന് നമ്മൾ ZooKeeper നെക്കുറിച്ച് സംസാരിക്കും. ഈ കാര്യം വളരെ ഉപയോഗപ്രദമാണ്. ഏതൊരു അപ്പാച്ചെ ഹഡൂപ്പ് ഉൽപ്പന്നത്തെയും പോലെ ഇതിന് ഒരു ലോഗോ ഉണ്ട്. ഇത് ഒരു മനുഷ്യനെ ചിത്രീകരിക്കുന്നു.

ഇതിന് മുമ്പ്, അവിടെ ഡാറ്റ എങ്ങനെ പ്രോസസ്സ് ചെയ്യാം, അത് എങ്ങനെ സംഭരിക്കാം, അതായത് എങ്ങനെയെങ്കിലും എങ്ങനെ ഉപയോഗിക്കാം, എങ്ങനെയെങ്കിലും എങ്ങനെ പ്രവർത്തിക്കാം എന്നതിനെക്കുറിച്ചാണ് ഞങ്ങൾ പ്രധാനമായും സംസാരിച്ചത്. വിതരണം ചെയ്ത ആപ്ലിക്കേഷനുകൾ നിർമ്മിക്കുന്നതിനെക്കുറിച്ച് ഇന്ന് ഞാൻ കുറച്ച് സംസാരിക്കാൻ ആഗ്രഹിക്കുന്നു. ഈ കാര്യം ലളിതമാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന കാര്യങ്ങളിൽ ഒന്നാണ് ZooKeeper. വിതരണം ചെയ്ത സിസ്റ്റങ്ങളിൽ, വിതരണം ചെയ്ത ആപ്ലിക്കേഷനുകളിൽ പ്രക്രിയകളുടെ പരസ്പര പ്രവർത്തനത്തിന്റെ ഏതെങ്കിലും തരത്തിലുള്ള ഏകോപനത്തിനായി ഉദ്ദേശിച്ചിട്ടുള്ള ഒരു തരത്തിലുള്ള സേവനമാണിത്.

ഇത്തരം ആപ്ലിക്കേഷനുകളുടെ ആവശ്യം അനുദിനം വർദ്ധിച്ചുവരികയാണ്, അതാണ് ഞങ്ങളുടെ കോഴ്സ്. ഒരു വശത്ത്, MapReduce ഉം ഈ റെഡിമെയ്ഡ് ചട്ടക്കൂടും ഈ സങ്കീർണ്ണതയെ സമനിലയിലാക്കാനും പ്രക്രിയകളുടെ പരസ്പര പ്രവർത്തനവും ഏകോപനവും പോലുള്ള പ്രാകൃതങ്ങൾ എഴുതുന്നതിൽ നിന്ന് പ്രോഗ്രാമറെ മോചിപ്പിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു. എന്നാൽ മറുവശത്ത്, ഇത് എന്തായാലും ചെയ്യേണ്ടതില്ലെന്ന് ആരും ഉറപ്പുനൽകുന്നില്ല. MapReduce അല്ലെങ്കിൽ മറ്റ് റെഡിമെയ്ഡ് ചട്ടക്കൂടുകൾ ഇത് ഉപയോഗിച്ച് നടപ്പിലാക്കാൻ കഴിയാത്ത ചില കേസുകൾ എല്ലായ്പ്പോഴും പൂർണ്ണമായും മാറ്റിസ്ഥാപിക്കുന്നില്ല. MapReduce-ഉം മറ്റ് അപ്പാച്ചെ പ്രോജക്റ്റുകളുടെ ഒരു കൂട്ടവും ഉൾപ്പെടെ; വാസ്തവത്തിൽ അവയും വിതരണം ചെയ്ത ആപ്ലിക്കേഷനുകളാണ്. എഴുത്ത് എളുപ്പമാക്കാൻ, അവർ ZooKeeper എഴുതി.

ഹഡൂപ്പുമായി ബന്ധപ്പെട്ട എല്ലാ ആപ്ലിക്കേഷനുകളെയും പോലെ, ഇത് വികസിപ്പിച്ചെടുത്തത് Yahoo! ഇത് ഇപ്പോൾ ഒരു ഔദ്യോഗിക അപ്പാച്ചെ ആപ്ലിക്കേഷൻ കൂടിയാണ്. ഇത് HBase പോലെ സജീവമായി വികസിപ്പിച്ചിട്ടില്ല. നിങ്ങൾ JIRA HBase-ലേക്ക് പോകുകയാണെങ്കിൽ, എല്ലാ ദിവസവും ഒരു കൂട്ടം ബഗ് റിപ്പോർട്ടുകൾ ഉണ്ട്, എന്തെങ്കിലും ഒപ്റ്റിമൈസ് ചെയ്യാനുള്ള ഒരു കൂട്ടം നിർദ്ദേശങ്ങൾ, അതായത് പ്രോജക്റ്റിലെ ജീവിതം നിരന്തരം നടക്കുന്നു. ZooKeeper, ഒരു വശത്ത്, താരതമ്യേന ലളിതമായ ഒരു ഉൽപ്പന്നമാണ്, മറുവശത്ത്, ഇത് അതിന്റെ വിശ്വാസ്യത ഉറപ്പാക്കുന്നു. ഇത് ഉപയോഗിക്കാൻ വളരെ എളുപ്പമാണ്, അതിനാലാണ് ഹഡൂപ്പ് ആവാസവ്യവസ്ഥയ്ക്കുള്ളിലെ ആപ്ലിക്കേഷനുകളിൽ ഇത് ഒരു മാനദണ്ഡമായി മാറിയത്. അതിനാൽ, ഇത് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നും എങ്ങനെ ഉപയോഗിക്കാമെന്നും മനസിലാക്കാൻ ഇത് അവലോകനം ചെയ്യുന്നത് ഉപയോഗപ്രദമാകുമെന്ന് ഞാൻ കരുതി.

ഞങ്ങൾ നടത്തിയ ചില പ്രഭാഷണങ്ങളിൽ നിന്നുള്ള ചിത്രമാണിത്. നമ്മൾ ഇതുവരെ പരിഗണിച്ച എല്ലാ കാര്യങ്ങളിലും ഇത് ഓർത്തോഗണൽ ആണെന്ന് നമുക്ക് പറയാം. ഇവിടെ സൂചിപ്പിച്ചിരിക്കുന്നതെല്ലാം, ഒരു പരിധിവരെ അല്ലെങ്കിൽ മറ്റൊന്ന്, ZooKeeper-ൽ പ്രവർത്തിക്കുന്നു, അതായത്, ഈ ഉൽപ്പന്നങ്ങളെല്ലാം ഉപയോഗിക്കുന്ന ഒരു സേവനമാണിത്. HDFS അല്ലെങ്കിൽ MapReduce എന്നിവയ്‌ക്ക് പ്രത്യേകമായി പ്രവർത്തിക്കുന്ന സമാന സേവനങ്ങൾ എഴുതുന്നില്ല. അതനുസരിച്ച്, ZooKeeper ഉപയോഗിക്കുന്നു. ഇത് വികസനവും പിശകുകളുമായി ബന്ധപ്പെട്ട ചില കാര്യങ്ങളും ലളിതമാക്കുന്നു.

ഇതെല്ലാം എവിടെ നിന്ന് വരുന്നു? വ്യത്യസ്ത കമ്പ്യൂട്ടറുകളിൽ സമാന്തരമായി ഞങ്ങൾ രണ്ട് ആപ്ലിക്കേഷനുകൾ സമാരംഭിച്ചതായി തോന്നുന്നു, അവയെ ഒരു സ്ട്രിംഗിലോ മെഷിലോ ബന്ധിപ്പിച്ചിരിക്കുന്നു, എല്ലാം പ്രവർത്തിക്കുന്നു. എന്നാൽ നെറ്റ്‌വർക്ക് വിശ്വസനീയമല്ല എന്നതാണ് പ്രശ്‌നം, നിങ്ങൾ ട്രാഫിക്കിനെ മണക്കുകയോ അവിടെ എന്താണ് സംഭവിക്കുന്നതെന്ന് നോക്കുകയോ ചെയ്‌താൽ, നെറ്റ്‌വർക്കിൽ ക്ലയന്റുകൾ എങ്ങനെ ഇടപെടുന്നുവെന്ന് നോക്കുകയാണെങ്കിൽ, ചില പാക്കറ്റുകൾ നഷ്‌ടപ്പെടുകയോ വീണ്ടും അയയ്‌ക്കുകയോ ചെയ്യുന്നത് നിങ്ങൾക്ക് പലപ്പോഴും കാണാൻ കഴിയും. ടിസിപി പ്രോട്ടോക്കോളുകൾ കണ്ടുപിടിച്ചത് വെറുതെയല്ല, ഇത് ഒരു നിശ്ചിത സെഷൻ സ്ഥാപിക്കാനും സന്ദേശങ്ങളുടെ ഡെലിവറി ഉറപ്പ് നൽകാനും നിങ്ങളെ അനുവദിക്കുന്നു. എന്നാൽ ഏത് സാഹചര്യത്തിലും, ടിസിപിക്ക് പോലും നിങ്ങളെ എപ്പോഴും രക്ഷിക്കാൻ കഴിയില്ല. എല്ലാത്തിനും സമയപരിധിയുണ്ട്. കുറച്ച് സമയത്തേക്ക് നെറ്റ്‌വർക്ക് തകരാറിലായേക്കാം. അത് വെറുതെ മിന്നിമറഞ്ഞേക്കാം. നെറ്റ്‌വർക്ക് വിശ്വസനീയമായതിൽ നിങ്ങൾക്ക് ആശ്രയിക്കാൻ കഴിയില്ല എന്ന വസ്തുതയിലേക്ക് ഇതെല്ലാം നയിക്കുന്നു. മെമ്മറിയിൽ കൂടുതൽ വിശ്വസനീയമായ ഡാറ്റാ എക്സ്ചേഞ്ച് ബസ് ഉള്ള നെറ്റ്‌വർക്ക് ഇല്ലാത്ത ഒരു കമ്പ്യൂട്ടറിലോ ഒരു സൂപ്പർ കമ്പ്യൂട്ടറിലോ പ്രവർത്തിക്കുന്ന സമാന്തര ആപ്ലിക്കേഷനുകൾ എഴുതുന്നതിൽ നിന്നുള്ള പ്രധാന വ്യത്യാസം ഇതാണ്. കൂടാതെ ഇത് അടിസ്ഥാനപരമായ വ്യത്യാസമാണ്.

മറ്റ് കാര്യങ്ങളിൽ, നെറ്റ്‌വർക്ക് ഉപയോഗിക്കുമ്പോൾ, എല്ലായ്പ്പോഴും ഒരു നിശ്ചിത ലേറ്റൻസി ഉണ്ടാകും. ഡിസ്കിലും ഇത് ഉണ്ട്, പക്ഷേ നെറ്റ്‌വർക്കിൽ അതിൽ കൂടുതൽ ഉണ്ട്. ലേറ്റൻസി എന്നത് കുറച്ച് കാലതാമസ സമയമാണ്, അത് ചെറുതോ പ്രാധാന്യമുള്ളതോ ആകാം.

നെറ്റ്‌വർക്ക് ടോപ്പോളജി മാറുകയാണ്. എന്താണ് ടോപ്പോളജി - ഇതാണ് ഞങ്ങളുടെ നെറ്റ്‌വർക്ക് ഉപകരണങ്ങളുടെ സ്ഥാനം. ഡാറ്റാ സെന്ററുകളുണ്ട്, അവിടെ നിൽക്കുന്ന റാക്കുകൾ ഉണ്ട്, മെഴുകുതിരികളുണ്ട്. ഇതെല്ലാം വീണ്ടും ബന്ധിപ്പിക്കാനും നീക്കാനും കഴിയും. ഇതെല്ലാം കൂടി കണക്കിലെടുക്കേണ്ടതുണ്ട്. IP പേരുകൾ മാറുന്നു, നമ്മുടെ ട്രാഫിക്കിന്റെ റൂട്ടിംഗ് മാറുന്നു. ഇതും കണക്കിലെടുക്കേണ്ടതുണ്ട്.

ഉപകരണങ്ങളുടെ കാര്യത്തിലും നെറ്റ്‌വർക്ക് മാറിയേക്കാം. പരിശീലനത്തിൽ നിന്ന്, ഞങ്ങളുടെ നെറ്റ്‌വർക്ക് എഞ്ചിനീയർമാർ മെഴുകുതിരികളിൽ ഇടയ്ക്കിടെ എന്തെങ്കിലും അപ്‌ഡേറ്റ് ചെയ്യാൻ ഇഷ്ടപ്പെടുന്നുവെന്ന് എനിക്ക് പറയാൻ കഴിയും. പെട്ടെന്ന് ഒരു പുതിയ ഫേംവെയർ പുറത്തുവന്നു, അവർക്ക് ചില ഹഡൂപ്പ് ക്ലസ്റ്ററുകളിൽ പ്രത്യേക താൽപ്പര്യമില്ലായിരുന്നു. അവർക്ക് സ്വന്തമായി ജോലിയുണ്ട്. അവരെ സംബന്ധിച്ചിടത്തോളം, പ്രധാന കാര്യം നെറ്റ്‌വർക്ക് പ്രവർത്തിക്കുന്നു എന്നതാണ്. അതനുസരിച്ച്, അവർ അവിടെ എന്തെങ്കിലും വീണ്ടും അപ്‌ലോഡ് ചെയ്യാനും അവരുടെ ഹാർഡ്‌വെയറിൽ ഒരു മിന്നൽ നടത്താനും ആഗ്രഹിക്കുന്നു, കൂടാതെ ഹാർഡ്‌വെയറും ഇടയ്‌ക്കിടെ മാറുന്നു. ഇതെല്ലാം എങ്ങനെയെങ്കിലും കണക്കിലെടുക്കേണ്ടതുണ്ട്. ഇതെല്ലാം ഞങ്ങളുടെ വിതരണം ചെയ്ത ആപ്ലിക്കേഷനെ ബാധിക്കുന്നു.

സാധാരണയായി ചില കാരണങ്ങളാൽ വലിയ അളവിലുള്ള ഡാറ്റ ഉപയോഗിച്ച് പ്രവർത്തിക്കാൻ തുടങ്ങുന്ന ആളുകൾ ഇന്റർനെറ്റ് പരിധിയില്ലാത്തതാണെന്ന് വിശ്വസിക്കുന്നു. നിരവധി ടെറാബൈറ്റുകളുടെ ഒരു ഫയൽ അവിടെ ഉണ്ടെങ്കിൽ, നിങ്ങൾക്ക് അത് നിങ്ങളുടെ സെർവറിലേക്കോ കമ്പ്യൂട്ടറിലേക്കോ കൊണ്ടുപോയി ഉപയോഗിച്ച് തുറക്കാവുന്നതാണ്. പൂച്ച ഒപ്പം വാച്ച്. മറ്റൊരു പിശക് ഉണ്ട് വിമ് രേഖകൾ നോക്കുക. ഇത് ഒരിക്കലും ചെയ്യരുത് കാരണം ഇത് മോശമാണ്. Vim എല്ലാം ബഫർ ചെയ്യാൻ ശ്രമിക്കുന്നതിനാൽ, എല്ലാം മെമ്മറിയിലേക്ക് ലോഡ് ചെയ്യാൻ ശ്രമിക്കുന്നു, പ്രത്യേകിച്ചും നമ്മൾ ഈ ലോഗിലൂടെ നീങ്ങുകയും എന്തെങ്കിലും തിരയുകയും ചെയ്യുമ്പോൾ. ഇതൊക്കെ മറന്നുപോയ, എന്നാൽ പരിഗണിക്കേണ്ട കാര്യങ്ങളാണ്.

ഒരു കമ്പ്യൂട്ടറിൽ ഒരു പ്രോസസർ ഉപയോഗിച്ച് പ്രവർത്തിക്കുന്ന ഒരു പ്രോഗ്രാം എഴുതുന്നത് എളുപ്പമാണ്.

ഞങ്ങളുടെ സിസ്റ്റം വളരുമ്പോൾ, എല്ലാം സമാന്തരമാക്കാനും കമ്പ്യൂട്ടറിൽ മാത്രമല്ല, ഒരു ക്ലസ്റ്ററിലും സമാന്തരമാക്കാനും ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ചോദ്യം ഉയർന്നുവരുന്നു: ഈ കാര്യം എങ്ങനെ ഏകോപിപ്പിക്കാം? ഞങ്ങളുടെ ആപ്ലിക്കേഷനുകൾ പരസ്‌പരം സംവദിക്കുക പോലും ചെയ്‌തേക്കില്ല, പക്ഷേ ഞങ്ങൾ നിരവധി സെർവറുകളിൽ സമാന്തരമായി നിരവധി പ്രക്രിയകൾ നടത്തി. അവർക്ക് എല്ലാം നന്നായി നടക്കുന്നുണ്ടെന്ന് എങ്ങനെ നിരീക്ഷിക്കാം? ഉദാഹരണത്തിന്, അവർ ഇന്റർനെറ്റിലൂടെ എന്തെങ്കിലും അയയ്ക്കുന്നു. അവർ അവരുടെ അവസ്ഥയെക്കുറിച്ച് എവിടെയെങ്കിലും എഴുതണം, ഉദാഹരണത്തിന്, ഏതെങ്കിലും തരത്തിലുള്ള ഡാറ്റാബേസിലോ ലോഗിലോ, തുടർന്ന് ഈ ലോഗ് സമാഹരിച്ച് എവിടെയെങ്കിലും വിശകലനം ചെയ്യുക. കൂടാതെ, പ്രക്രിയ പ്രവർത്തിക്കുന്നുണ്ടെന്നും പ്രവർത്തിക്കുന്നുവെന്നും ഞങ്ങൾ കണക്കിലെടുക്കേണ്ടതുണ്ട്, പെട്ടെന്ന് അതിൽ ചില പിശക് പ്രത്യക്ഷപ്പെട്ടു അല്ലെങ്കിൽ അത് തകർന്നു, അപ്പോൾ എത്ര വേഗത്തിൽ ഞങ്ങൾ അതിനെക്കുറിച്ച് കണ്ടെത്തും?

ഇതെല്ലാം പെട്ടെന്ന് നിരീക്ഷിക്കാൻ കഴിയുമെന്ന് വ്യക്തമാണ്. ഇതും നല്ലതാണ്, എന്നാൽ ചില കാര്യങ്ങൾ ഉയർന്ന തലത്തിൽ നിരീക്ഷിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന പരിമിതമായ കാര്യമാണ് നിരീക്ഷണം.

ഞങ്ങളുടെ പ്രക്രിയകൾ പരസ്പരം ഇടപഴകാൻ തുടങ്ങണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുമ്പോൾ, ഉദാഹരണത്തിന്, പരസ്പരം കുറച്ച് ഡാറ്റ അയയ്ക്കാൻ, അപ്പോൾ ചോദ്യവും ഉയർന്നുവരുന്നു - ഇത് എങ്ങനെ സംഭവിക്കും? എന്തെങ്കിലും തരത്തിലുള്ള റേസ് അവസ്ഥ ഉണ്ടാകുമോ, അവർ പരസ്പരം തിരുത്തിയെഴുതുമോ, ഡാറ്റ കൃത്യമായി എത്തുമോ, വഴിയിൽ എന്തെങ്കിലും നഷ്ടപ്പെടുമോ? നമുക്ക് ഒരുതരം പ്രോട്ടോക്കോൾ മുതലായവ വികസിപ്പിക്കേണ്ടതുണ്ട്.

ഈ പ്രക്രിയകളെല്ലാം ഏകോപിപ്പിക്കുക എന്നത് നിസ്സാര കാര്യമല്ല. ഇത് ഡവലപ്പറെ ഇതിലും താഴ്ന്ന നിലയിലേക്ക് പോകാൻ പ്രേരിപ്പിക്കുന്നു, കൂടാതെ ആദ്യം മുതൽ അല്ലെങ്കിൽ ആദ്യം മുതൽ സിസ്റ്റങ്ങൾ എഴുതുക, പക്ഷേ ഇത് അത്ര ലളിതമല്ല.

നിങ്ങൾ ഒരു ക്രിപ്‌റ്റോഗ്രാഫിക് അൽഗോരിതം കൊണ്ടുവരികയോ അല്ലെങ്കിൽ അത് നടപ്പിലാക്കുകയോ ചെയ്‌താൽ, അത് ഉടനടി വലിച്ചെറിയുക, കാരണം മിക്കവാറും ഇത് നിങ്ങൾക്കായി പ്രവർത്തിക്കില്ല. നിങ്ങൾ നൽകാൻ മറന്നുപോയ ഒരു കൂട്ടം പിശകുകൾ ഇതിൽ അടങ്ങിയിരിക്കാം. ഗുരുതരമായ ഒന്നിനും ഇത് ഉപയോഗിക്കരുത്, കാരണം ഇത് മിക്കവാറും അസ്ഥിരമായിരിക്കും. കാരണം, നിലവിലുള്ള എല്ലാ അൽഗോരിതങ്ങളും വളരെക്കാലമായി സമയം പരീക്ഷിച്ചതാണ്. ഇത് സമൂഹം വഴി തെറ്റിക്കുന്നു. ഇതൊരു പ്രത്യേക വിഷയമാണ്. ഇവിടെയും അങ്ങനെ തന്നെ. ഏതെങ്കിലും തരത്തിലുള്ള പ്രോസസ്സ് സിൻക്രൊണൈസേഷൻ സ്വയം നടപ്പിലാക്കാതിരിക്കാൻ കഴിയുമെങ്കിൽ, ഇത് ചെയ്യാതിരിക്കുന്നതാണ് നല്ലത്, കാരണം ഇത് വളരെ സങ്കീർണ്ണവും പിശകുകൾക്കായി നിരന്തരം തിരയുന്നതിനുള്ള ഇളകിയ പാതയിലേക്ക് നിങ്ങളെ നയിക്കുന്നതുമാണ്.

ഇന്ന് നമ്മൾ സംസാരിക്കുന്നത് ZooKeeper നെക്കുറിച്ചാണ്. ഒരു വശത്ത്, ഇത് ഒരു ചട്ടക്കൂടാണ്, മറുവശത്ത്, ഇത് ഡെവലപ്പർക്ക് ജീവിതം എളുപ്പമാക്കുന്ന ഒരു സേവനമാണ്, കൂടാതെ യുക്തിയുടെ നടപ്പാക്കലും ഞങ്ങളുടെ പ്രക്രിയകളുടെ ഏകോപനവും കഴിയുന്നത്ര ലളിതമാക്കുന്നു.

ഒരു സാധാരണ വിതരണ സംവിധാനം എങ്ങനെയായിരിക്കുമെന്ന് നമുക്ക് ഓർക്കാം. ഞങ്ങൾ സംസാരിച്ചത് ഇതാണ് - HDFS, HBase. തൊഴിലാളികളെയും അടിമ പ്രക്രിയകളെയും നിയന്ത്രിക്കുന്ന ഒരു മാസ്റ്റർ പ്രക്രിയയുണ്ട്. ജോലികൾ ഏകോപിപ്പിക്കുന്നതിനും വിതരണം ചെയ്യുന്നതിനും, തൊഴിലാളികളെ പുനരാരംഭിക്കുന്നതിനും, പുതിയവ സമാരംഭിക്കുന്നതിനും, ലോഡ് വിതരണം ചെയ്യുന്നതിനും അദ്ദേഹം ഉത്തരവാദിയാണ്.

കൂടുതൽ വിപുലമായ ഒരു കാര്യം കോർഡിനേഷൻ സേവനമാണ്, അതായത്, ഏകോപന ചുമതല തന്നെ ഒരു പ്രത്യേക പ്രക്രിയയിലേക്ക് മാറ്റുക, കൂടാതെ സമാന്തരമായി ഏതെങ്കിലും തരത്തിലുള്ള ബാക്കപ്പ് അല്ലെങ്കിൽ സ്റ്റാൻബൈ മാസ്റ്റർ പ്രവർത്തിപ്പിക്കുക, കാരണം മാസ്റ്റർ പരാജയപ്പെടാം. മാസ്റ്റർ വീണാൽ, നമ്മുടെ സിസ്റ്റം പ്രവർത്തിക്കില്ല. ഞങ്ങൾ ബാക്കപ്പ് പ്രവർത്തിപ്പിക്കുന്നു. ബാക്കപ്പിലേക്ക് മാസ്റ്റർ പകർത്തേണ്ടതുണ്ടെന്ന് ചില പ്രസ്താവിക്കുന്നു. ഇതും കോർഡിനേഷൻ സർവീസിനെ ഏൽപ്പിക്കാവുന്നതാണ്. എന്നാൽ ഈ ഡയഗ്രാമിൽ, തൊഴിലാളികളെ ഏകോപിപ്പിക്കുന്നതിന് മാസ്റ്റർ തന്നെ ഉത്തരവാദിയാണ്; ഇവിടെ സേവനം ഡാറ്റ റെപ്ലിക്കേഷൻ പ്രവർത്തനങ്ങൾ ഏകോപിപ്പിക്കുന്നു.

സാധാരണ ചെയ്യുന്നത് പോലെ, എല്ലാ ഏകോപനവും ഞങ്ങളുടെ സേവനം കൈകാര്യം ചെയ്യുമ്പോഴാണ് കൂടുതൽ വിപുലമായ ഓപ്ഷൻ. എല്ലാം പ്രവർത്തിക്കുന്നുവെന്ന് ഉറപ്പാക്കാനുള്ള ഉത്തരവാദിത്തം അവൻ ഏറ്റെടുക്കുന്നു. എന്തെങ്കിലും പ്രവർത്തിക്കുന്നില്ലെങ്കിൽ, ഞങ്ങൾ അതിനെക്കുറിച്ച് കണ്ടെത്തുകയും ഈ സാഹചര്യത്തെ മറികടക്കാൻ ശ്രമിക്കുകയും ചെയ്യും. ഏതായാലും, അടിമകളുമായി എങ്ങനെയെങ്കിലും ഇടപഴകുകയും ചില സേവനങ്ങളിലൂടെ ഡാറ്റ, വിവരങ്ങൾ, സന്ദേശങ്ങൾ മുതലായവ അയയ്‌ക്കുകയും ചെയ്യുന്ന ഒരു യജമാനനാണ് നമുക്ക് അവശേഷിക്കുന്നത്.

അതിലും വിപുലമായ ഒരു സ്കീം ഉണ്ട്, ഞങ്ങൾക്ക് ഒരു മാസ്റ്റർ ഇല്ലെങ്കിൽ, എല്ലാ നോഡുകളും മാസ്റ്റർ സ്ലേവുകളാണ്, അവരുടെ പെരുമാറ്റത്തിൽ വ്യത്യസ്തമാണ്. എന്നാൽ അവർ ഇപ്പോഴും പരസ്പരം ഇടപഴകേണ്ടതുണ്ട്, അതിനാൽ ഈ പ്രവർത്തനങ്ങൾ ഏകോപിപ്പിക്കുന്നതിന് ഇനിയും ചില സേവനം അവശേഷിക്കുന്നു. ഒരുപക്ഷേ, ഈ തത്വത്തിൽ പ്രവർത്തിക്കുന്ന കസാന്ദ്ര, ഈ സ്കീമിന് അനുയോജ്യമാണ്.

ഈ സ്കീമുകളിൽ ഏതാണ് മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നതെന്ന് പറയാൻ പ്രയാസമാണ്. ഓരോന്നിനും അതിന്റേതായ ഗുണങ്ങളും ദോഷങ്ങളുമുണ്ട്.

കൂടാതെ, മാസ്റ്ററുമായി ചില കാര്യങ്ങളിൽ ഭയപ്പെടേണ്ടതില്ല, കാരണം, പ്രാക്ടീസ് കാണിക്കുന്നതുപോലെ, അവൻ നിരന്തരം സേവിക്കാൻ അത്ര എളുപ്പമല്ല. ഈ സേവനം ഒരു പ്രത്യേക ശക്തമായ നോഡിൽ ഹോസ്റ്റുചെയ്യുന്നതിനുള്ള ശരിയായ പരിഹാരം തിരഞ്ഞെടുക്കുക എന്നതാണ് ഇവിടെ പ്രധാന കാര്യം, അതുവഴി ആവശ്യത്തിന് ഉറവിടങ്ങളുണ്ട്, അതിനാൽ സാധ്യമെങ്കിൽ, ഉപയോക്താക്കൾക്ക് അവിടെ പ്രവേശനമില്ല, അതിനാൽ അവർ ഈ പ്രക്രിയയെ ആകസ്മികമായി നശിപ്പിക്കില്ല. എന്നാൽ അതേ സമയം, അത്തരമൊരു സ്കീമിൽ മാസ്റ്റർ പ്രക്രിയയിൽ നിന്ന് തൊഴിലാളികളെ നിയന്ത്രിക്കുന്നത് വളരെ എളുപ്പമാണ്, അതായത്, ഈ പദ്ധതി നടപ്പിലാക്കുന്നതിന്റെ കാഴ്ചപ്പാടിൽ നിന്ന് ലളിതമാണ്.

ഈ സ്കീം (മുകളിൽ) ഒരുപക്ഷേ കൂടുതൽ സങ്കീർണ്ണവും എന്നാൽ കൂടുതൽ വിശ്വസനീയവുമാണ്.

ഭാഗിക പരാജയമാണ് പ്രധാന പ്രശ്നം. ഉദാഹരണത്തിന്, നമ്മൾ നെറ്റ്‌വർക്കിലൂടെ ഒരു സന്ദേശം അയയ്‌ക്കുമ്പോൾ, ഒരുതരം അപകടം സംഭവിക്കുന്നു, സന്ദേശം അയച്ചയാൾക്ക് തന്റെ സന്ദേശം ലഭിച്ചോ എന്നും സ്വീകർത്താവിന്റെ ഭാഗത്ത് എന്താണ് സംഭവിച്ചതെന്നും അറിയില്ല, സന്ദേശം ശരിയായി പ്രോസസ്സ് ചെയ്തിട്ടുണ്ടോ എന്ന് അറിയില്ല. , അതായത് അയാൾക്ക് ഒരു സ്ഥിരീകരണവും ലഭിക്കില്ല.

അതനുസരിച്ച്, ഞങ്ങൾ ഈ സാഹചര്യം പ്രോസസ്സ് ചെയ്യണം. ഏറ്റവും ലളിതമായ കാര്യം ഈ സന്ദേശം വീണ്ടും അയച്ച് ഒരു പ്രതികരണം ലഭിക്കുന്നതുവരെ കാത്തിരിക്കുക എന്നതാണ്. ഈ സാഹചര്യത്തിൽ, റിസീവറിന്റെ അവസ്ഥ മാറിയിട്ടുണ്ടോ എന്നത് കണക്കിലെടുക്കുന്നില്ല. ഞങ്ങൾക്ക് ഒരു സന്ദേശം അയച്ച് ഒരേ ഡാറ്റ രണ്ടുതവണ ചേർക്കാം.

ZooKeeper ഇത്തരം വിസമ്മതങ്ങളെ നേരിടാനുള്ള വഴികൾ വാഗ്ദാനം ചെയ്യുന്നു, അത് നമ്മുടെ ജീവിതവും എളുപ്പമാക്കുന്നു.

കുറച്ച് നേരത്തെ സൂചിപ്പിച്ചതുപോലെ, ഇത് മൾട്ടി-ത്രെഡഡ് പ്രോഗ്രാമുകൾ എഴുതുന്നതിന് സമാനമാണ്, എന്നാൽ പ്രധാന വ്യത്യാസം ഞങ്ങൾ വ്യത്യസ്ത മെഷീനുകളിൽ നിർമ്മിക്കുന്ന ഡിസ്ട്രിബ്യൂട്ടഡ് ആപ്ലിക്കേഷനുകളിൽ, ആശയവിനിമയത്തിനുള്ള ഏക മാർഗം നെറ്റ്‌വർക്ക് മാത്രമാണ്. അടിസ്ഥാനപരമായി, ഇത് പങ്കിടാത്ത വാസ്തുവിദ്യയാണ്. ഒരു മെഷീനിൽ പ്രവർത്തിക്കുന്ന ഓരോ പ്രോസസ്സിനും സേവനത്തിനും അതിന്റേതായ മെമ്മറി, സ്വന്തം ഡിസ്ക്, സ്വന്തം പ്രോസസ്സർ എന്നിവയുണ്ട്, അത് ആരുമായും പങ്കിടില്ല.

നമ്മൾ ഒരു കമ്പ്യൂട്ടറിൽ ഒരു മൾട്ടി-ത്രെഡഡ് പ്രോഗ്രാം എഴുതുകയാണെങ്കിൽ, ഡാറ്റ കൈമാറാൻ നമുക്ക് പങ്കിട്ട മെമ്മറി ഉപയോഗിക്കാം. ഞങ്ങൾക്ക് അവിടെ ഒരു സന്ദർഭ സ്വിച്ച് ഉണ്ട്, പ്രക്രിയകൾക്ക് മാറാൻ കഴിയും. ഇത് പ്രകടനത്തെ ബാധിക്കുന്നു. ഒരു വശത്ത്, ഒരു ക്ലസ്റ്ററിലെ പ്രോഗ്രാമിൽ അങ്ങനെയൊന്നുമില്ല, പക്ഷേ നെറ്റ്‌വർക്കിൽ പ്രശ്‌നങ്ങളുണ്ട്.

അതനുസരിച്ച്, വിതരണം ചെയ്ത സിസ്റ്റങ്ങൾ എഴുതുമ്പോൾ ഉണ്ടാകുന്ന പ്രധാന പ്രശ്നങ്ങൾ കോൺഫിഗറേഷനാണ്. ഞങ്ങൾ ഒരു തരത്തിലുള്ള അപേക്ഷ എഴുതുകയാണ്. ഇത് ലളിതമാണെങ്കിൽ, ഞങ്ങൾ കോഡിലെ എല്ലാത്തരം നമ്പറുകളും ഹാർഡ്‌കോഡ് ചെയ്യുന്നു, പക്ഷേ ഇത് അസൗകര്യമാണ്, കാരണം അര സെക്കൻഡിന്റെ സമയപരിധിക്ക് പകരം ഒരു സെക്കൻഡ് സമയപരിധി വേണമെന്ന് ഞങ്ങൾ തീരുമാനിക്കുകയാണെങ്കിൽ, ഞങ്ങൾ ആപ്ലിക്കേഷൻ വീണ്ടും കംപൈൽ ചെയ്യേണ്ടതുണ്ട്. എല്ലാം വീണ്ടും ഉരുട്ടുക. ഇത് ഒരു മെഷീനിലായിരിക്കുമ്പോൾ, നിങ്ങൾക്ക് അത് പുനരാരംഭിക്കാൻ കഴിയുമ്പോൾ ഇത് ഒരു കാര്യമാണ്, എന്നാൽ ഞങ്ങൾക്ക് ധാരാളം മെഷീനുകൾ ഉള്ളപ്പോൾ, ഞങ്ങൾ എല്ലാം നിരന്തരം പകർത്തേണ്ടതുണ്ട്. ആപ്ലിക്കേഷൻ കോൺഫിഗർ ചെയ്യുവാൻ ഞങ്ങൾ ശ്രമിക്കണം.

സിസ്റ്റം പ്രക്രിയകൾക്കായുള്ള സ്റ്റാറ്റിക് കോൺഫിഗറേഷനെക്കുറിച്ചാണ് നമ്മൾ ഇവിടെ സംസാരിക്കുന്നത്. ഇത് പൂർണ്ണമായും അല്ല, ഒരുപക്ഷേ ഓപ്പറേറ്റിംഗ് സിസ്റ്റം വീക്ഷണകോണിൽ നിന്ന്, ഇത് ഞങ്ങളുടെ പ്രക്രിയകൾക്കായുള്ള ഒരു സ്റ്റാറ്റിക് കോൺഫിഗറേഷനായിരിക്കാം, അതായത്, ഇത് ലളിതമായി എടുക്കാനും അപ്‌ഡേറ്റ് ചെയ്യാനും കഴിയാത്ത ഒരു കോൺഫിഗറേഷനാണ്.

ഒരു ഡൈനാമിക് കോൺഫിഗറേഷനും ഉണ്ട്. ഞങ്ങൾ പറക്കുമ്പോൾ മാറ്റാൻ ആഗ്രഹിക്കുന്ന പാരാമീറ്ററുകൾ ഇവയാണ്, അതിനാൽ അവ അവിടെ നിന്ന് തിരഞ്ഞെടുക്കപ്പെടും.

ഇവിടെ എന്താണ് പ്രശ്നം? ഞങ്ങൾ കോൺഫിഗറേഷൻ അപ്‌ഡേറ്റ് ചെയ്‌തു, അത് പുറത്തിറക്കി, അപ്പോൾ എന്താണ്? ഒരു വശത്ത് ഞങ്ങൾ കോൺഫിഗറേഷൻ പുറത്തിറക്കിയതായിരിക്കാം പ്രശ്നം, പക്ഷേ പുതിയ കാര്യത്തെക്കുറിച്ച് മറന്നു, കോൺഫിഗേഷൻ അവിടെ തന്നെ തുടർന്നു. രണ്ടാമതായി, ഞങ്ങൾ പുറത്തുവിടുമ്പോൾ, ചില സ്ഥലങ്ങളിൽ കോൺഫിഗറേഷൻ അപ്ഡേറ്റ് ചെയ്തു, എന്നാൽ മറ്റുള്ളവയിൽ അല്ല. ഒരു മെഷീനിൽ പ്രവർത്തിക്കുന്ന ഞങ്ങളുടെ ആപ്ലിക്കേഷന്റെ ചില പ്രോസസ്സുകൾ ഒരു പുതിയ കോൺഫിഗറിലൂടെയും എവിടെയോ പഴയത് ഉപയോഗിച്ചും പുനരാരംഭിച്ചു. ഇത് ഒരു കോൺഫിഗറേഷൻ വീക്ഷണകോണിൽ നിന്ന് ഞങ്ങളുടെ വിതരണം ചെയ്ത ആപ്ലിക്കേഷൻ പൊരുത്തമില്ലാത്തതായിരിക്കാൻ ഇടയാക്കും. ഈ പ്രശ്നം സാധാരണമാണ്. ഒരു ഡൈനാമിക് കോൺഫിഗറേഷനായി, ഇത് കൂടുതൽ പ്രസക്തമാണ്, കാരണം അത് ഈച്ചയിൽ മാറ്റാൻ കഴിയുമെന്ന് സൂചിപ്പിക്കുന്നു.

ഗ്രൂപ്പ് അംഗത്വമാണ് മറ്റൊരു പ്രശ്നം. ഞങ്ങൾക്ക് എപ്പോഴും ചില തൊഴിലാളികൾ ഉണ്ട്, അവരിൽ ആരാണ് ജീവിച്ചിരിക്കുന്നതെന്നും അവരിൽ ആരാണ് മരിച്ചതെന്നും അറിയാൻ ഞങ്ങൾ എപ്പോഴും ആഗ്രഹിക്കുന്നു. ഒരു മാസ്റ്റർ ഉണ്ടെങ്കിൽ, ഏതൊക്കെ തൊഴിലാളികളെ ക്ലയന്റുകളിലേക്ക് റീഡയറക്‌ട് ചെയ്യാമെന്ന് അദ്ദേഹം മനസ്സിലാക്കണം, അതുവഴി അവർ കണക്കുകൂട്ടലുകൾ നടത്തുകയോ ഡാറ്റ ഉപയോഗിച്ച് പ്രവർത്തിക്കുകയോ ചെയ്യരുത്. നമ്മുടെ ക്ലസ്റ്ററിൽ ആരാണ് ജോലി ചെയ്യുന്നതെന്ന് അറിയേണ്ടതുണ്ട് എന്നതാണ് നിരന്തരം ഉയർന്നുവരുന്ന ഒരു പ്രശ്നം.

മറ്റൊരു സാധാരണ പ്രശ്നം ലീഡർ തിരഞ്ഞെടുപ്പാണ്, ആരാണ് ചുമതലയുള്ളതെന്ന് അറിയാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. റൈറ്റ് ഓപ്പറേഷനുകൾ സ്വീകരിക്കുകയും മറ്റ് പ്രോസസ്സുകൾക്കിടയിൽ അവ ആവർത്തിക്കുകയും ചെയ്യുന്ന ചില പ്രോസസ്സുകൾ ഉള്ളപ്പോൾ, ഒരു ഉദാഹരണമാണ് പകർപ്പെടുക്കൽ. അവൻ നേതാവായിരിക്കും, മറ്റെല്ലാവരും അവനെ അനുസരിക്കും, അവനെ അനുഗമിക്കും. ഒരു പ്രക്രിയ തിരഞ്ഞെടുക്കേണ്ടത് ആവശ്യമാണ്, അതുവഴി എല്ലാവർക്കും അത് അവ്യക്തമാണ്, അതിനാൽ രണ്ട് നേതാക്കളെ തിരഞ്ഞെടുത്തതായി മാറില്ല.

പരസ്പര വിരുദ്ധമായ പ്രവേശനവും ഉണ്ട്. ഇവിടെ പ്രശ്നം കൂടുതൽ സങ്കീർണ്ണമാണ്. നിങ്ങൾ മൾട്ടി-ത്രെഡഡ് പ്രോഗ്രാമുകൾ എഴുതുകയും ചില റിസോഴ്‌സിലേക്ക് ആക്‌സസ്സ് ആവശ്യപ്പെടുകയും ചെയ്യുമ്പോൾ, ഉദാഹരണത്തിന്, ഒരു മെമ്മറി സെൽ, പരിമിതപ്പെടുത്തുകയും ഒരു ത്രെഡ് മാത്രം നടപ്പിലാക്കുകയും ചെയ്യുമ്പോൾ മ്യൂട്ടക്സ് പോലെയുള്ള ഒരു സംഗതിയുണ്ട്. ഇവിടെ വിഭവം കൂടുതൽ അമൂർത്തമായ ഒന്നായിരിക്കാം. ഞങ്ങളുടെ നെറ്റ്‌വർക്കിന്റെ വ്യത്യസ്‌ത നോഡുകളിൽ നിന്നുള്ള വ്യത്യസ്‌ത അപ്ലിക്കേഷനുകൾക്ക് നൽകിയിരിക്കുന്ന ഉറവിടത്തിലേക്ക് എക്‌സ്‌ക്ലൂസീവ് ആക്‌സസ് മാത്രമേ ലഭിക്കൂ, അല്ലാതെ എല്ലാവർക്കും അത് മാറ്റാനോ അവിടെ എന്തെങ്കിലും എഴുതാനോ കഴിയില്ല. ഇവയാണ് ലോക്കുകൾ എന്ന് വിളിക്കപ്പെടുന്നവ.

ഈ പ്രശ്‌നങ്ങളെല്ലാം ഒരു ഡിഗ്രി അല്ലെങ്കിൽ മറ്റൊന്നിലേക്ക് പരിഹരിക്കാൻ ZooKeeper നിങ്ങളെ അനുവദിക്കുന്നു. ഇത് എങ്ങനെ ചെയ്യാൻ നിങ്ങളെ അനുവദിക്കുന്നു എന്ന് ഞാൻ ഉദാഹരണങ്ങൾ സഹിതം കാണിക്കും.

തടയുന്ന പ്രാകൃതങ്ങളൊന്നുമില്ല. നമ്മൾ എന്തെങ്കിലും ഉപയോഗിക്കാൻ തുടങ്ങുമ്പോൾ, ഈ പ്രാകൃതം ഒരു സംഭവത്തിനും കാത്തിരിക്കില്ല. മിക്കവാറും, ഈ കാര്യം അസമന്വിതമായി പ്രവർത്തിക്കും, അതുവഴി എന്തെങ്കിലും കാത്തിരിക്കുമ്പോൾ പ്രക്രിയകൾ ഹാംഗ് ചെയ്യാതിരിക്കാൻ അനുവദിക്കുന്നു. ഇത് വളരെ ഉപകാരപ്രദമായ കാര്യമാണ്.

എല്ലാ ക്ലയന്റ് അഭ്യർത്ഥനകളും പൊതുവായ ക്യൂവിന്റെ ക്രമത്തിലാണ് പ്രോസസ്സ് ചെയ്യുന്നത്.

കൂടാതെ, ക്ലയന്റ് മാറിയ ഡാറ്റ കാണുന്നതിന് മുമ്പ്, ചില സംസ്ഥാനങ്ങളിലെ മാറ്റങ്ങളെക്കുറിച്ച്, ഡാറ്റയിലെ മാറ്റങ്ങളെക്കുറിച്ച് അറിയിപ്പ് സ്വീകരിക്കാൻ ക്ലയന്റുകൾക്ക് അവസരമുണ്ട്.

ZooKeeper രണ്ട് മോഡുകളിൽ പ്രവർത്തിക്കാൻ കഴിയും. ആദ്യത്തേത് ഒറ്റപ്പെട്ടതാണ്, ഒരു നോഡിൽ. ഇത് പരിശോധനയ്ക്ക് സൗകര്യപ്രദമാണ്. ഇതിന് എത്ര സെർവറുകളിലും ക്ലസ്റ്റർ മോഡിൽ പ്രവർത്തിക്കാനാകും. നമുക്ക് 100 മെഷീനുകളുടെ ഒരു ക്ലസ്റ്റർ ഉണ്ടെങ്കിൽ, അത് 100 മെഷീനുകളിൽ പ്രവർത്തിക്കേണ്ട ആവശ്യമില്ല. നിങ്ങൾക്ക് ZooKeeper പ്രവർത്തിപ്പിക്കാൻ കഴിയുന്ന നിരവധി മെഷീനുകൾ തിരഞ്ഞെടുത്താൽ മതി. ഉയർന്ന ലഭ്യതയുടെ തത്വം ഇത് അവകാശപ്പെടുന്നു. പ്രവർത്തിക്കുന്ന ഓരോ സന്ദർഭത്തിലും, ZooKeeper ഡാറ്റയുടെ മുഴുവൻ പകർപ്പും സംഭരിക്കുന്നു. അവൻ അത് എങ്ങനെ ചെയ്യുന്നുവെന്ന് പിന്നീട് ഞാൻ നിങ്ങളോട് പറയും. ഇത് ഡാറ്റ ഷാർഡ് ചെയ്യുകയോ പാർട്ടീഷൻ ചെയ്യുകയോ ചെയ്യുന്നില്ല. ഒരു വശത്ത്, നമുക്ക് വളരെയധികം സംഭരിക്കാൻ കഴിയാത്തത് ഒരു ന്യൂനതയാണ്, മറുവശത്ത്, ഇത് ചെയ്യേണ്ടതില്ല. അതിനായി രൂപകല്പന ചെയ്തതല്ല, ഒരു ഡാറ്റാബേസ് അല്ല.

ക്ലയന്റ് ഭാഗത്ത് ഡാറ്റ കാഷെ ചെയ്യാൻ കഴിയും. ഇത് ഒരു സ്റ്റാൻഡേർഡ് തത്വമാണ്, അതിനാൽ ഞങ്ങൾ സേവനത്തെ തടസ്സപ്പെടുത്താതിരിക്കാനും സമാന അഭ്യർത്ഥനകളാൽ അത് ലോഡ് ചെയ്യാതിരിക്കാനും കഴിയും. ഒരു സ്മാർട്ട് ക്ലയന്റ് സാധാരണയായി ഇതിനെക്കുറിച്ച് അറിയുകയും അത് കാഷെ ചെയ്യുകയും ചെയ്യുന്നു.

ഉദാഹരണത്തിന്, ഇവിടെ എന്തെങ്കിലും മാറിയിരിക്കുന്നു. ഒരുതരം അപേക്ഷയുണ്ട്. ഒരു പുതിയ നേതാവ് തിരഞ്ഞെടുക്കപ്പെട്ടു, അദ്ദേഹം ഉത്തരവാദിയാണ്, ഉദാഹരണത്തിന്, റൈറ്റ് പ്രവർത്തനങ്ങൾ പ്രോസസ്സ് ചെയ്യുന്നതിന്. ഞങ്ങൾ ഡാറ്റ ആവർത്തിക്കാൻ ആഗ്രഹിക്കുന്നു. ഒരു ലൂപ്പിൽ ഇടുക എന്നതാണ് ഒരു പരിഹാരം. ഞങ്ങളുടെ സേവനത്തെ ഞങ്ങൾ നിരന്തരം ചോദ്യം ചെയ്യുന്നു - എന്തെങ്കിലും മാറിയിട്ടുണ്ടോ? രണ്ടാമത്തെ ഓപ്ഷൻ കൂടുതൽ അനുയോജ്യമാണ്. എന്തെങ്കിലും മാറിയെന്ന് ക്ലയന്റുകളെ അറിയിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്ന ഒരു വാച്ച് മെക്കാനിസമാണിത്. വിഭവങ്ങളുടെ കാര്യത്തിൽ ഇത് ചെലവ് കുറഞ്ഞതും ഉപഭോക്താക്കൾക്ക് കൂടുതൽ സൗകര്യപ്രദവുമായ രീതിയാണ്.

സൂകീപ്പർ ഉപയോഗിക്കുന്ന ഉപയോക്താവാണ് ക്ലയന്റ്.

ZooKeeper പ്രക്രിയ തന്നെയാണ് സെർവർ.

ZooKeeper-ലെ പ്രധാന കാര്യം Znode ആണ്. എല്ലാ znodes-ഉം ZooKeeper മെമ്മറിയിൽ സൂക്ഷിക്കുന്നു, അവ ഒരു ശ്രേണിയുടെ രൂപത്തിൽ ഒരു വൃക്ഷത്തിന്റെ രൂപത്തിൽ ക്രമീകരിച്ചിരിക്കുന്നു.

രണ്ട് തരത്തിലുള്ള പ്രവർത്തനങ്ങളുണ്ട്. ആദ്യത്തേത് അപ്ഡേറ്റ് / റൈറ്റ് ആണ്, ചില പ്രവർത്തനങ്ങൾ നമ്മുടെ ട്രീയുടെ അവസ്ഥ മാറ്റുമ്പോൾ. മരം സാധാരണമാണ്.

കൂടാതെ, ക്ലയന്റ് ഒരു അഭ്യർത്ഥന പൂർത്തിയാക്കാതെയും വിച്ഛേദിക്കപ്പെട്ടിരിക്കാനും സാധ്യതയുണ്ട്, പക്ഷേ അത് ZooKeeper-മായി സംവദിക്കുന്ന ഒരു സെഷൻ സ്ഥാപിക്കാൻ കഴിയും.

ZooKeeper-ന്റെ ഡാറ്റ മോഡൽ ഒരു ഫയൽ സിസ്റ്റത്തോട് സാമ്യമുള്ളതാണ്. ഒരു സ്റ്റാൻഡേർഡ് റൂട്ട് ഉണ്ട്, തുടർന്ന് റൂട്ടിൽ നിന്ന് പോകുന്ന ഡയറക്ടറികളിലൂടെ ഞങ്ങൾ പോയി. പിന്നെ ഒന്നാം ലെവലിന്റെ കാറ്റലോഗ്, രണ്ടാം ലെവൽ. ഇതെല്ലാം znodes ആണ്.

ഓരോ znode-നും ചില ഡാറ്റ സംഭരിക്കാൻ കഴിയും, സാധാരണയായി വളരെ വലുതല്ല, ഉദാഹരണത്തിന്, 10 കിലോബൈറ്റുകൾ. ഓരോ znode-നും ഒരു നിശ്ചിത എണ്ണം കുട്ടികൾ ഉണ്ടായിരിക്കാം.

Znodes പല തരത്തിലാണ് വരുന്നത്. അവ സൃഷ്ടിക്കാൻ കഴിയും. ഒരു znode സൃഷ്ടിക്കുമ്പോൾ, അത് ഏത് തരത്തിലായിരിക്കണമെന്ന് ഞങ്ങൾ വ്യക്തമാക്കുന്നു.

രണ്ടു തരമുണ്ട്. ആദ്യത്തേത് ക്ഷണികമായ പതാകയാണ്. Znode ഒരു സെഷനിൽ ജീവിക്കുന്നു. ഉദാഹരണത്തിന്, ക്ലയന്റ് ഒരു സെഷൻ സ്ഥാപിച്ചു. ഈ സെഷൻ ജീവിച്ചിരിക്കുന്നിടത്തോളം കാലം അത് നിലനിൽക്കും. അനാവശ്യമായ എന്തെങ്കിലും ഉണ്ടാക്കാതിരിക്കാൻ ഇത് ആവശ്യമാണ്. ഒരു സെഷനിൽ ഡാറ്റ പ്രിമിറ്റീവുകൾ സംഭരിക്കുന്നത് ഞങ്ങൾക്ക് പ്രധാനമായ നിമിഷങ്ങൾക്കും ഇത് അനുയോജ്യമാണ്.

രണ്ടാമത്തെ തരം തുടർച്ചയായ പതാകയാണ്. ഇത് znode-ലേക്കുള്ള വഴിയിലുള്ള കൗണ്ടറിനെ വർദ്ധിപ്പിക്കുന്നു. ഉദാഹരണത്തിന്, ഞങ്ങൾക്ക് ആപ്ലിക്കേഷൻ 1_5 ഉള്ള ഒരു ഡയറക്ടറി ഉണ്ടായിരുന്നു. ഞങ്ങൾ ആദ്യ നോഡ് സൃഷ്ടിച്ചപ്പോൾ, അതിന് p_1 ലഭിച്ചു, രണ്ടാമത്തേത് - p_2. ഓരോ തവണയും ഞങ്ങൾ ഈ രീതിയെ വിളിക്കുമ്പോൾ, പാതയുടെ ഒരു ഭാഗം മാത്രം സൂചിപ്പിക്കുന്ന മുഴുവൻ പാതയും ഞങ്ങൾ കടന്നുപോകുന്നു, കൂടാതെ നോഡ് തരം - സീക്വൻഷ്യൽ ഞങ്ങൾ സൂചിപ്പിക്കുന്നതിനാൽ ഈ നമ്പർ യാന്ത്രികമായി വർദ്ധിപ്പിക്കും.

സാധാരണ znode. അവൾ എപ്പോഴും ജീവിക്കും, ഞങ്ങൾ അവളോട് പറയുന്ന പേരുണ്ടാകും.

മറ്റൊരു ഉപയോഗപ്രദമായ കാര്യം വാച്ച് ഫ്ലാഗ് ആണ്. ഞങ്ങൾ ഇത് ഇൻസ്റ്റാൾ ചെയ്യുകയാണെങ്കിൽ, ക്ലയന്റിന് ഒരു നിർദ്ദിഷ്ട നോഡിനായി ചില ഇവന്റുകൾ സബ്‌സ്‌ക്രൈബുചെയ്യാനാകും. ഇത് എങ്ങനെ ചെയ്യാമെന്ന് ഒരു ഉദാഹരണം ഉപയോഗിച്ച് ഞാൻ പിന്നീട് കാണിക്കും. നോഡിലെ ഡാറ്റ മാറിയെന്ന് സൂകീപ്പർ തന്നെ ക്ലയന്റിനെ അറിയിക്കുന്നു. എന്നിരുന്നാലും, ചില പുതിയ ഡാറ്റ വന്നതായി അറിയിപ്പുകൾ ഉറപ്പുനൽകുന്നില്ല. എന്തെങ്കിലും മാറിയെന്ന് അവർ പറയുന്നു, അതിനാൽ നിങ്ങൾ പിന്നീട് പ്രത്യേക കോളുകളുമായി ഡാറ്റ താരതമ്യം ചെയ്യേണ്ടതുണ്ട്.

ഞാൻ ഇതിനകം പറഞ്ഞതുപോലെ, ഡാറ്റയുടെ ക്രമം നിർണ്ണയിക്കുന്നത് കിലോബൈറ്റുകളാണ്. വലിയ ടെക്സ്റ്റ് ഡാറ്റ അവിടെ സംഭരിക്കേണ്ടതില്ല, കാരണം ഇത് ഒരു ഡാറ്റാബേസ് അല്ല, ഇതൊരു ആക്ഷൻ കോർഡിനേഷൻ സെർവറാണ്.

സെഷനുകളെക്കുറിച്ച് ഞാൻ നിങ്ങളോട് കുറച്ച് പറയും. ഞങ്ങൾക്ക് ഒന്നിലധികം സെർവറുകൾ ഉണ്ടെങ്കിൽ, സെഷൻ ഐഡന്റിഫയർ ഉപയോഗിച്ച് നമുക്ക് സെർവറിൽ നിന്ന് സെർവറിലേക്ക് സുതാര്യമായി നീങ്ങാൻ കഴിയും. ഇത് തികച്ചും സൗകര്യപ്രദമാണ്.

ഓരോ സെഷനും ഒരുതരം ടൈംഔട്ട് ഉണ്ട്. ആ സെഷനിൽ ക്ലയന്റ് സെർവറിലേക്ക് എന്തെങ്കിലും അയയ്ക്കുന്നുണ്ടോ എന്നതിനെ അടിസ്ഥാനമാക്കിയാണ് ഒരു സെഷൻ നിർവചിക്കുന്നത്. കാലഹരണപ്പെട്ട സമയത്ത് അവൻ ഒന്നും സംപ്രേഷണം ചെയ്തില്ലെങ്കിൽ, സെഷൻ വീഴും, അല്ലെങ്കിൽ ക്ലയന്റിന് അത് സ്വയം അടയ്ക്കാനാകും.

ഇതിന് ഇത്രയധികം സവിശേഷതകൾ ഇല്ല, എന്നാൽ ഈ API ഉപയോഗിച്ച് നിങ്ങൾക്ക് വ്യത്യസ്തമായ കാര്യങ്ങൾ ചെയ്യാൻ കഴിയും. ഞങ്ങൾ സൃഷ്ടിച്ച ആ കോൾ ഒരു znode സൃഷ്ടിക്കുകയും മൂന്ന് പാരാമീറ്ററുകൾ എടുക്കുകയും ചെയ്യുന്നു. ഇതാണ് znode-ലേക്കുള്ള പാത, ഇത് റൂട്ടിൽ നിന്ന് പൂർണ്ണമായി വ്യക്തമാക്കണം. ഞങ്ങൾ അവിടെ കൈമാറാൻ ആഗ്രഹിക്കുന്ന ചില ഡാറ്റയും ഇതാണ്. ഒപ്പം പതാകയുടെ തരം. സൃഷ്ടിച്ചതിനുശേഷം അത് znode-ലേക്കുള്ള പാത തിരികെ നൽകുന്നു.

രണ്ടാമതായി, നിങ്ങൾക്ക് അത് ഇല്ലാതാക്കാം. ഇവിടെയുള്ള തന്ത്രം, രണ്ടാമത്തെ പാരാമീറ്ററിന്, znode-ലേക്കുള്ള പാത കൂടാതെ, പതിപ്പ് വ്യക്തമാക്കാൻ കഴിയും. അതനുസരിച്ച്, ഞങ്ങൾ കൈമാറിയ പതിപ്പ് യഥാർത്ഥത്തിൽ നിലവിലുള്ളതിന് തുല്യമാണെങ്കിൽ ആ znode ഇല്ലാതാക്കപ്പെടും.

ഈ പതിപ്പ് പരിശോധിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നില്ലെങ്കിൽ, ഞങ്ങൾ "-1" ആർഗ്യുമെന്റ് പാസ്സാക്കുന്നു.

മൂന്നാമതായി, ഇത് ഒരു znode നിലവിലുണ്ടോ എന്ന് പരിശോധിക്കുന്നു. നോഡ് നിലവിലുണ്ടെങ്കിൽ true എന്ന് നൽകുന്നു, അല്ലാത്തപക്ഷം തെറ്റ്.

തുടർന്ന് ഫ്ലാഗ് വാച്ച് ദൃശ്യമാകുന്നു, ഇത് ഈ നോഡ് നിരീക്ഷിക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

നിലവിലില്ലാത്ത ഒരു നോഡിൽ പോലും നിങ്ങൾക്ക് ഈ ഫ്ലാഗ് സജ്ജീകരിക്കാനും അത് ദൃശ്യമാകുമ്പോൾ ഒരു അറിയിപ്പ് സ്വീകരിക്കാനും കഴിയും. ഇതും ഉപയോഗപ്രദമാകും.

ഒന്നുരണ്ടു വെല്ലുവിളികൾ കൂടിയുണ്ട് ഡാറ്റ നേടുക. znode വഴി നമുക്ക് ഡാറ്റ സ്വീകരിക്കാമെന്ന് വ്യക്തമാണ്. നിങ്ങൾക്ക് ഫ്ലാഗ് വാച്ചും ഉപയോഗിക്കാം. ഈ സാഹചര്യത്തിൽ, നോഡ് ഇല്ലെങ്കിൽ അത് ഇൻസ്റ്റാൾ ചെയ്യില്ല. അതിനാൽ, അത് നിലവിലുണ്ടെന്ന് നിങ്ങൾ മനസ്സിലാക്കേണ്ടതുണ്ട്, തുടർന്ന് ഡാറ്റ സ്വീകരിക്കുക.

അവിടെയും ഉണ്ട് സെറ്റ് ഡാറ്റ. ഇവിടെ ഞങ്ങൾ പതിപ്പ് കൈമാറുന്നു. ഞങ്ങൾ ഇത് കൈമാറുകയാണെങ്കിൽ, ഒരു നിശ്ചിത പതിപ്പിന്റെ znode-ലെ ഡാറ്റ അപ്ഡേറ്റ് ചെയ്യപ്പെടും.

ഈ പരിശോധന ഒഴിവാക്കുന്നതിന് നിങ്ങൾക്ക് "-1" വ്യക്തമാക്കാനും കഴിയും.

മറ്റൊരു ഉപയോഗപ്രദമായ രീതി കുട്ടികളെ നേടുക. അതിൽ ഉൾപ്പെടുന്ന എല്ലാ znodes-ന്റെയും ഒരു ലിസ്റ്റും നമുക്ക് ലഭിക്കും. ഫ്ലാഗ് വാച്ച് സജ്ജീകരിച്ച് നമുക്ക് ഇത് നിരീക്ഷിക്കാനാകും.

ഒപ്പം രീതിയും സമന്വയം എല്ലാ മാറ്റങ്ങളും ഒരേസമയം അയയ്ക്കാൻ അനുവദിക്കുന്നു, അതുവഴി അവ സംരക്ഷിക്കപ്പെട്ടിട്ടുണ്ടെന്നും എല്ലാ ഡാറ്റയും പൂർണ്ണമായും മാറ്റിയിട്ടുണ്ടെന്നും ഉറപ്പാക്കുന്നു.

ഞങ്ങൾ പരമ്പരാഗത പ്രോഗ്രാമിംഗുമായി സാമ്യതകൾ വരയ്ക്കുകയാണെങ്കിൽ, നിങ്ങൾ എഴുതുക, ഡിസ്കിലേക്ക് എന്തെങ്കിലും എഴുതുക തുടങ്ങിയ രീതികൾ ഉപയോഗിക്കുമ്പോൾ, അത് നിങ്ങൾക്ക് ഒരു പ്രതികരണം നൽകിയതിന് ശേഷം, നിങ്ങൾ ഡാറ്റ ഡിസ്കിലേക്ക് എഴുതി എന്നതിന് യാതൊരു ഉറപ്പുമില്ല. എല്ലാം എഴുതിയിട്ടുണ്ടെന്ന് ഓപ്പറേറ്റിംഗ് സിസ്റ്റത്തിന് ഉറപ്പുണ്ടെങ്കിൽപ്പോലും, പ്രക്രിയ ബഫറുകളുടെ പാളികളിലൂടെ കടന്നുപോകുന്ന മെക്കാനിസങ്ങൾ ഡിസ്കിൽ തന്നെയുണ്ട്, അതിനുശേഷം മാത്രമേ ഡാറ്റ ഡിസ്കിൽ സ്ഥാപിക്കുകയുള്ളൂ.

മിക്കവാറും അസിൻക്രണസ് കോളുകളാണ് ഉപയോഗിക്കുന്നത്. വ്യത്യസ്ത അഭ്യർത്ഥനകൾക്ക് സമാന്തരമായി പ്രവർത്തിക്കാൻ ഇത് ക്ലയന്റിനെ അനുവദിക്കുന്നു. നിങ്ങൾക്ക് സിൻക്രണസ് സമീപനം ഉപയോഗിക്കാം, പക്ഷേ അത് ഉൽപ്പാദനക്ഷമത കുറവാണ്.

ഞങ്ങൾ സംസാരിച്ച രണ്ട് ഓപ്പറേഷനുകൾ അപ്ഡേറ്റ് / റൈറ്റ് ആണ്, അത് ഡാറ്റ മാറ്റുന്നു. സൃഷ്ടിക്കുക, ഡാറ്റ സജ്ജമാക്കുക, സമന്വയിപ്പിക്കുക, ഇല്ലാതാക്കുക. കൂടാതെ റീഡ് ഈസ് ഉണ്ട്, getData, getChildren.

ഒരു വിതരണ സംവിധാനത്തിൽ പ്രവർത്തിക്കുന്നതിന് നിങ്ങൾക്ക് എങ്ങനെ പ്രാകൃതമാക്കാം എന്നതിന്റെ കുറച്ച് ഉദാഹരണങ്ങൾ ഇപ്പോൾ. ഉദാഹരണത്തിന്, എന്തെങ്കിലും കോൺഫിഗറേഷനുമായി ബന്ധപ്പെട്ടത്. ഒരു പുതിയ തൊഴിലാളി പ്രത്യക്ഷപ്പെട്ടു. ഞങ്ങൾ മെഷീൻ ചേർത്ത് പ്രക്രിയ ആരംഭിച്ചു. കൂടാതെ ഇനിപ്പറയുന്ന മൂന്ന് ചോദ്യങ്ങളുണ്ട്. കോൺഫിഗറേഷനായി ഇത് എങ്ങനെയാണ് ZooKeeper-നെ അന്വേഷിക്കുന്നത്? നമുക്ക് കോൺഫിഗറേഷൻ മാറ്റണമെങ്കിൽ, അത് എങ്ങനെ മാറ്റാം? ഞങ്ങൾ അത് മാറ്റിയ ശേഷം, ഞങ്ങളുടെ പക്കലുണ്ടായിരുന്ന തൊഴിലാളികൾക്ക് അത് എങ്ങനെ ലഭിക്കും?

ZooKeeper ഇത് താരതമ്യേന എളുപ്പമാക്കുന്നു. ഉദാഹരണത്തിന്, നമ്മുടെ znode ട്രീ ഉണ്ട്. ഞങ്ങളുടെ ആപ്ലിക്കേഷനായി ഇവിടെ ഒരു നോഡ് ഉണ്ട്, ഞങ്ങൾ അതിൽ ഒരു അധിക നോഡ് സൃഷ്ടിക്കുന്നു, അതിൽ കോൺഫിഗറേഷനിൽ നിന്നുള്ള ഡാറ്റ അടങ്ങിയിരിക്കുന്നു. ഇവ പ്രത്യേക പാരാമീറ്ററുകളായിരിക്കാം അല്ലെങ്കിൽ അല്ലായിരിക്കാം. വലിപ്പം ചെറുതായതിനാൽ, കോൺഫിഗറേഷൻ വലുപ്പവും സാധാരണയായി ചെറുതാണ്, അതിനാൽ ഇത് ഇവിടെ സംഭരിക്കുന്നത് തികച്ചും സാദ്ധ്യമാണ്.

നിങ്ങൾ രീതിയാണ് ഉപയോഗിക്കുന്നത് ഡാറ്റ നേടുക നോഡിൽ നിന്ന് തൊഴിലാളിക്കുള്ള കോൺഫിഗറേഷൻ ലഭിക്കാൻ. സത്യമായി സജ്ജമാക്കുക. ചില കാരണങ്ങളാൽ ഈ നോഡ് നിലവിലില്ലെങ്കിൽ, അത് ദൃശ്യമാകുമ്പോഴോ അല്ലെങ്കിൽ അത് മാറുമ്പോഴോ ഞങ്ങളെ അറിയിക്കും. എന്തെങ്കിലും മാറിയെന്ന് അറിയണമെങ്കിൽ, ഞങ്ങൾ അത് ശരിയാക്കി. ഈ നോഡിലെ ഡാറ്റ മാറുകയാണെങ്കിൽ, ഞങ്ങൾ അതിനെക്കുറിച്ച് അറിയും.

സെറ്റ് ഡാറ്റ. ഞങ്ങൾ ഡാറ്റ സജ്ജീകരിച്ചു, "-1" സജ്ജമാക്കി, അതായത് ഞങ്ങൾ പതിപ്പ് പരിശോധിക്കുന്നില്ല, ഞങ്ങൾക്ക് എല്ലായ്പ്പോഴും ഒരു കോൺഫിഗറേഷൻ ഉണ്ടെന്ന് ഞങ്ങൾ അനുമാനിക്കുന്നു, ഞങ്ങൾക്ക് നിരവധി കോൺഫിഗറേഷനുകൾ സംഭരിക്കേണ്ടതില്ല. നിങ്ങൾക്ക് ധാരാളം സംഭരിക്കേണ്ടതുണ്ടെങ്കിൽ, നിങ്ങൾ മറ്റൊരു ലെവൽ ചേർക്കേണ്ടതുണ്ട്. ഇവിടെ ഒരെണ്ണം മാത്രമേ ഉള്ളൂ എന്ന് ഞങ്ങൾ വിശ്വസിക്കുന്നു, അതിനാൽ ഞങ്ങൾ ഏറ്റവും പുതിയത് മാത്രം അപ്‌ഡേറ്റ് ചെയ്യുന്നു, അതിനാൽ ഞങ്ങൾ പതിപ്പ് പരിശോധിക്കുന്നില്ല. ഈ നിമിഷം, മുമ്പ് സബ്‌സ്‌ക്രൈബുചെയ്‌ത എല്ലാ ക്ലയന്റുകൾക്കും ഈ നോഡിൽ എന്തെങ്കിലും മാറ്റം വന്നതായി അറിയിപ്പ് ലഭിക്കും. അവർക്ക് അത് ലഭിച്ചതിന് ശേഷം, അവർ വീണ്ടും ഡാറ്റ അഭ്യർത്ഥിക്കണം. അവർക്ക് ഡാറ്റ തന്നെ ലഭിക്കുന്നില്ല, മാറ്റങ്ങളുടെ അറിയിപ്പ് മാത്രമാണ് അവർ സ്വീകരിക്കുന്നത് എന്നതാണ് അറിയിപ്പ്. ഇതിനുശേഷം അവർ പുതിയ ഡാറ്റ ആവശ്യപ്പെടണം.

പ്രാകൃതം ഉപയോഗിക്കുന്നതിനുള്ള രണ്ടാമത്തെ ഓപ്ഷൻ ഗ്രൂപ്പ് അംഗത്വം. ഞങ്ങൾക്ക് ഒരു വിതരണം ചെയ്ത അപേക്ഷയുണ്ട്, ഒരു കൂട്ടം തൊഴിലാളികളുണ്ട്, അവരെല്ലാം സ്ഥലത്തുണ്ടെന്ന് മനസ്സിലാക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. അതിനാൽ, അവർ ഞങ്ങളുടെ അപേക്ഷയിൽ പ്രവർത്തിക്കുന്നുണ്ടെന്ന് സ്വയം രജിസ്റ്റർ ചെയ്യണം. കൂടാതെ, മാസ്റ്റർ പ്രക്രിയയിൽ നിന്നോ മറ്റെവിടെയെങ്കിലുമോ, നിലവിൽ ഞങ്ങളുടെ പക്കലുള്ള എല്ലാ സജീവ തൊഴിലാളികളെക്കുറിച്ചും കണ്ടെത്താൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു.

ഞങ്ങൾ ഇത് എങ്ങനെ ചെയ്യും? ആപ്ലിക്കേഷനായി, ഞങ്ങൾ ഒരു തൊഴിലാളി നോഡ് സൃഷ്ടിക്കുകയും സൃഷ്ടിക്കൽ രീതി ഉപയോഗിച്ച് അവിടെ ഒരു സബ്ലെവൽ ചേർക്കുകയും ചെയ്യുന്നു. എനിക്ക് സ്ലൈഡിൽ ഒരു പിശകുണ്ട്. ഇവിടെ നിങ്ങൾക്ക് ആവശ്യമാണ് തുടർച്ചയായ വ്യക്തമാക്കുക, തുടർന്ന് എല്ലാ തൊഴിലാളികളും ഓരോന്നായി സൃഷ്ടിക്കപ്പെടും. ഈ നോഡിന്റെ കുട്ടികളെക്കുറിച്ചുള്ള എല്ലാ ഡാറ്റയും അഭ്യർത്ഥിക്കുന്ന ആപ്ലിക്കേഷൻ, നിലവിലുള്ള എല്ലാ സജീവ തൊഴിലാളികളെയും സ്വീകരിക്കുന്നു.

ജാവ കോഡിൽ ഇത് എങ്ങനെ ചെയ്യാം എന്നതിന്റെ ഭയാനകമായ നടപ്പാക്കലാണ് ഇത്. പ്രധാന രീതി ഉപയോഗിച്ച് നമുക്ക് അവസാനം മുതൽ ആരംഭിക്കാം. ഇതാണ് ഞങ്ങളുടെ ക്ലാസ്, നമുക്ക് അതിന്റെ രീതി സൃഷ്ടിക്കാം. ആദ്യത്തെ ആർഗ്യുമെന്റായി ഞങ്ങൾ ഹോസ്റ്റ് ഉപയോഗിക്കുന്നു, ഞങ്ങൾ എവിടെയാണ് ബന്ധിപ്പിക്കുന്നത്, അതായത് ഞങ്ങൾ അതിനെ ഒരു ആർഗ്യുമെന്റായി സജ്ജമാക്കുന്നു. രണ്ടാമത്തെ വാദം ഗ്രൂപ്പിന്റെ പേരാണ്.

കണക്ഷൻ എങ്ങനെയാണ് സംഭവിക്കുന്നത്? ഉപയോഗിക്കുന്ന API യുടെ ലളിതമായ ഉദാഹരണമാണിത്. ഇവിടെ എല്ലാം താരതമ്യേന ലളിതമാണ്. ഒരു സാധാരണ ക്ലാസ് ZooKeeper ഉണ്ട്. ഞങ്ങൾ അതിലേക്ക് ഹോസ്റ്റുകളെ കൈമാറുന്നു. കൂടാതെ ടൈംഔട്ട്, ഉദാഹരണത്തിന്, 5 സെക്കൻഡായി സജ്ജമാക്കുക. കണക്റ്റഡ് സിഗ്നൽ എന്നൊരു അംഗം ഞങ്ങൾക്കുണ്ട്. അടിസ്ഥാനപരമായി, പ്രക്ഷേപണം ചെയ്ത പാതയിലൂടെ ഞങ്ങൾ ഒരു ഗ്രൂപ്പ് സൃഷ്ടിക്കുന്നു. എന്തെങ്കിലും എഴുതാമായിരുന്നെങ്കിലും ഞങ്ങൾ അവിടെ ഡാറ്റ എഴുതുന്നില്ല. ഇവിടെയുള്ള നോഡ് സ്ഥിരതയുള്ള തരത്തിലുള്ളതാണ്. അടിസ്ഥാനപരമായി, ഇത് എല്ലായ്പ്പോഴും നിലനിൽക്കുന്ന ഒരു സാധാരണ നോഡാണ്. ഇവിടെയാണ് സെഷൻ സൃഷ്ടിക്കുന്നത്. ഇത് ഉപഭോക്താവിന്റെ തന്നെ നടപ്പാക്കലാണ്. സെഷൻ സജീവമാണെന്ന് സൂചിപ്പിക്കുന്ന ആനുകാലിക സന്ദേശങ്ങൾ ഞങ്ങളുടെ ക്ലയന്റ് അയയ്ക്കും. ഞങ്ങൾ സെഷൻ അവസാനിപ്പിക്കുമ്പോൾ, ഞങ്ങൾ അടുത്തതായി വിളിക്കുന്നു, അത്രയേയുള്ളൂ, സെഷൻ വീഴുന്നു. ഞങ്ങൾക്ക് എന്തെങ്കിലും വീഴ്ച സംഭവിച്ചാൽ, ZooKeeper അതിനെക്കുറിച്ച് കണ്ടെത്തുകയും സെഷൻ വിച്ഛേദിക്കുകയും ചെയ്യും.

ഒരു റിസോഴ്സ് എങ്ങനെ ലോക്ക് ചെയ്യാം? ഇവിടെ എല്ലാം കുറച്ചുകൂടി സങ്കീർണ്ണമാണ്. ഞങ്ങൾക്ക് ഒരു കൂട്ടം തൊഴിലാളികളുണ്ട്, ഞങ്ങൾ പൂട്ടാൻ ആഗ്രഹിക്കുന്ന ചില ഉറവിടങ്ങളുണ്ട്. ഇത് ചെയ്യുന്നതിന്, ഞങ്ങൾ ഒരു പ്രത്യേക നോഡ് സൃഷ്ടിക്കുന്നു, ഉദാഹരണത്തിന്, ലോക്ക് 1 എന്ന് വിളിക്കുന്നു. ഞങ്ങൾക്ക് ഇത് സൃഷ്ടിക്കാൻ കഴിയുമെങ്കിൽ, ഞങ്ങൾക്ക് ഇവിടെ ഒരു ലോക്ക് ലഭിച്ചു. ഞങ്ങൾക്ക് ഇത് സൃഷ്ടിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, തൊഴിലാളി ഇവിടെ നിന്ന് getData നേടാൻ ശ്രമിക്കുന്നു, കൂടാതെ നോഡ് ഇതിനകം തന്നെ സൃഷ്‌ടിച്ചതിനാൽ, ഞങ്ങൾ ഇവിടെ ഒരു വാച്ചറെ ഇടുകയും ഈ നോഡിന്റെ അവസ്ഥ മാറുന്ന നിമിഷം തന്നെ ഞങ്ങൾ അതിനെക്കുറിച്ച് അറിയുകയും ചെയ്യും. അത് പുനഃസൃഷ്‌ടിക്കാൻ സമയം കണ്ടെത്താനും ശ്രമിക്കാം. ഞങ്ങൾ ഈ നോഡ് എടുത്താൽ, ഈ ലോക്ക് എടുത്താൽ, നമുക്ക് ഇനി ലോക്ക് ആവശ്യമില്ലെങ്കിൽ, ഞങ്ങൾ അത് ഉപേക്ഷിക്കും, കാരണം നോഡ് സെഷനിൽ മാത്രമേ ഉള്ളൂ. അതനുസരിച്ച്, അത് അപ്രത്യക്ഷമാകും. മറ്റൊരു ക്ലയന്റ്, മറ്റൊരു സെഷന്റെ ചട്ടക്കൂടിനുള്ളിൽ, ഈ നോഡിലെ ലോക്ക് എടുക്കാൻ കഴിയും, അല്ലെങ്കിൽ, എന്തെങ്കിലും മാറിയെന്ന് അയാൾക്ക് ഒരു അറിയിപ്പ് ലഭിക്കും, അത് കൃത്യസമയത്ത് ചെയ്യാൻ ശ്രമിക്കാം.

പ്രധാന നേതാവിനെ എങ്ങനെ തിരഞ്ഞെടുക്കാം എന്നതിന്റെ മറ്റൊരു ഉദാഹരണം. ഇത് കുറച്ചുകൂടി സങ്കീർണ്ണമാണ്, മാത്രമല്ല താരതമ്യേന ലളിതവുമാണ്. എന്താണ് ഇവിടെ നടക്കുന്നത്? എല്ലാ തൊഴിലാളികളെയും കൂട്ടിച്ചേർക്കുന്ന ഒരു പ്രധാന നോഡ് ഉണ്ട്. നേതാവിനെ കുറിച്ചുള്ള വിവരങ്ങൾ ലഭിക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു. ഇത് വിജയകരമായി സംഭവിച്ചാൽ, അതായത് ഞങ്ങൾക്ക് കുറച്ച് ഡാറ്റ ലഭിച്ചുവെങ്കിൽ, ഞങ്ങളുടെ തൊഴിലാളി ഈ നേതാവിനെ പിന്തുടരാൻ തുടങ്ങുന്നു. ഇതിനകം ഒരു നേതാവ് ഉണ്ടെന്ന് അദ്ദേഹം വിശ്വസിക്കുന്നു.

ചില കാരണങ്ങളാൽ നേതാവ് മരിച്ചുവെങ്കിൽ, ഉദാഹരണത്തിന്, വീഴുകയാണെങ്കിൽ, ഞങ്ങൾ ഒരു പുതിയ നേതാവിനെ സൃഷ്ടിക്കാൻ ശ്രമിക്കുന്നു. നമ്മൾ വിജയിച്ചാൽ, നമ്മുടെ തൊഴിലാളി നേതാവാകും. ഈ നിമിഷം ഒരാൾക്ക് ഒരു പുതിയ നേതാവിനെ സൃഷ്ടിക്കാൻ കഴിഞ്ഞെങ്കിൽ, അത് ആരാണെന്ന് മനസിലാക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു, തുടർന്ന് അവനെ പിന്തുടരുക.

ഇവിടെ ഹെർഡ് ഇഫക്റ്റ് എന്ന് വിളിക്കപ്പെടുന്നവ ഉയർന്നുവരുന്നു, അതായത് കന്നുകാലി പ്രഭാവം, കാരണം ഒരു നേതാവ് മരിക്കുമ്പോൾ, സമയത്തിൽ ഒന്നാമനായവൻ നേതാവാകും.

ഒരു റിസോഴ്സ് ക്യാപ്ചർ ചെയ്യുമ്പോൾ, നിങ്ങൾക്ക് അല്പം വ്യത്യസ്തമായ ഒരു സമീപനം ഉപയോഗിക്കാൻ ശ്രമിക്കാം, അത് താഴെ പറയുന്നതാണ്. ഉദാഹരണത്തിന്, ഞങ്ങൾക്ക് ഒരു ലോക്ക് ലഭിക്കാൻ ആഗ്രഹമുണ്ട്, പക്ഷേ ഹെർട്ട് ഇഫക്റ്റ് ഇല്ലാതെ. ഇതിനകം നിലവിലുള്ള ഒരു ലോക്ക് ഉള്ള നോഡിനായി ഞങ്ങളുടെ ആപ്ലിക്കേഷൻ എല്ലാ നോഡ് ഐഡികളുടെയും ലിസ്റ്റുകൾ അഭ്യർത്ഥിക്കുന്നു എന്ന വസ്തുത ഇതിൽ അടങ്ങിയിരിക്കും. അതിനുമുമ്പ് ഞങ്ങൾ ഒരു ലോക്ക് സൃഷ്ടിച്ച നോഡ് ഞങ്ങൾക്ക് ലഭിച്ച സെറ്റിന്റെ ഏറ്റവും ചെറുതാണ് എങ്കിൽ, ഇതിനർത്ഥം ഞങ്ങൾ ലോക്ക് പിടിച്ചെടുത്തു എന്നാണ്. ഞങ്ങൾക്ക് ഒരു ലോക്ക് ലഭിച്ചിട്ടുണ്ടോയെന്ന് ഞങ്ങൾ പരിശോധിക്കുന്നു. ഒരു ചെക്ക് എന്ന നിലയിൽ, ഒരു പുതിയ ലോക്ക് സൃഷ്ടിക്കുമ്പോൾ ഞങ്ങൾക്ക് ലഭിച്ച ഐഡി വളരെ കുറവാണെന്ന ഒരു വ്യവസ്ഥ ഉണ്ടാകും. ഞങ്ങൾക്ക് അത് ലഭിച്ചാൽ, ഞങ്ങൾ കൂടുതൽ പ്രവർത്തിക്കുന്നു.

ഞങ്ങളുടെ ലോക്കിനേക്കാൾ ചെറുതായ ഒരു പ്രത്യേക ഐഡി ഉണ്ടെങ്കിൽ, ഞങ്ങൾ ഈ ഇവന്റിൽ ഒരു വാച്ചറെ ഇടുകയും എന്തെങ്കിലും മാറുന്നത് വരെ അറിയിപ്പിനായി കാത്തിരിക്കുകയും ചെയ്യും. അതായത്, ഞങ്ങൾക്ക് ഈ ലോക്ക് ലഭിച്ചു. അത് വീഴുന്നത് വരെ, ഞങ്ങൾ മിനിമം ഐഡി ആകില്ല, മിനിമം ലോക്ക് ലഭിക്കുകയുമില്ല, അങ്ങനെ നമുക്ക് ലോഗിൻ ചെയ്യാൻ കഴിയും. ഈ വ്യവസ്ഥ പാലിച്ചില്ലെങ്കിൽ, ഞങ്ങൾ ഉടൻ തന്നെ ഇവിടെ പോയി ഈ ലോക്ക് വീണ്ടും നേടാൻ ശ്രമിക്കുന്നു, കാരണം ഈ സമയത്ത് എന്തെങ്കിലും മാറിയിരിക്കാം.

ZooKeeper എന്താണ് ഉൾക്കൊള്ളുന്നത്? പ്രധാനമായും 4 കാര്യങ്ങളാണ് ഉള്ളത്. ഇത് പ്രോസസ്സിംഗ് പ്രക്രിയകളാണ് - അഭ്യർത്ഥന. കൂടാതെ ZooKeeper Atomic Broadcast. എല്ലാ പ്രവർത്തനങ്ങളും രേഖപ്പെടുത്തുന്ന ഒരു കമ്മിറ്റ് ലോഗ് ഉണ്ട്. കൂടാതെ ഇൻ-മെമ്മറി റെപ്ലിക്കേറ്റഡ് ഡിബി തന്നെ, അതായത് ഈ മുഴുവൻ ട്രീയും സംഭരിച്ചിരിക്കുന്ന ഡാറ്റാബേസ് തന്നെ.

എല്ലാ റൈറ്റ് പ്രവർത്തനങ്ങളും അഭ്യർത്ഥന പ്രോസസറിലൂടെയാണ് പോകുന്നത് എന്നത് ശ്രദ്ധിക്കേണ്ടതാണ്. കൂടാതെ റീഡ് ഓപ്പറേഷനുകൾ നേരിട്ട് ഇൻ-മെമ്മറി ഡാറ്റാബേസിലേക്ക് പോകുന്നു.

ഡാറ്റാബേസ് തന്നെ പൂർണ്ണമായും പകർത്തിയിരിക്കുന്നു. ZooKeeper-ന്റെ എല്ലാ സംഭവങ്ങളും ഡാറ്റയുടെ പൂർണ്ണമായ പകർപ്പ് സംഭരിക്കുന്നു.

ഒരു ക്രാഷിന് ശേഷം ഡാറ്റാബേസ് പുനഃസ്ഥാപിക്കുന്നതിന്, ഒരു കമ്മിറ്റ് ലോഗ് ഉണ്ട്. സ്റ്റാൻഡേർഡ് പ്രാക്ടീസ്, ഡാറ്റ മെമ്മറിയിൽ എത്തുന്നതിന് മുമ്പ്, അത് അവിടെ എഴുതുന്നു, അങ്ങനെ അത് ക്രാഷായാൽ, ഈ ലോഗ് വീണ്ടും പ്ലേ ചെയ്യാനും സിസ്റ്റം നില പുനഃസ്ഥാപിക്കാനും കഴിയും. ഡാറ്റാബേസിന്റെ ആനുകാലിക സ്നാപ്പ്ഷോട്ടുകളും ഉപയോഗിക്കുന്നു.

സൂകീപ്പർ ആറ്റോമിക് ബ്രോഡ്കാസ്റ്റ് എന്നത് പകർത്തിയ ഡാറ്റ നിലനിർത്താൻ ഉപയോഗിക്കുന്ന ഒരു വസ്തുവാണ്.

ZooKeeper നോഡിന്റെ വീക്ഷണകോണിൽ നിന്ന് ZAB ആന്തരികമായി ഒരു നേതാവിനെ തിരഞ്ഞെടുക്കുന്നു. മറ്റ് നോഡുകൾ അവളുടെ അനുയായികളായി മാറുകയും അവളിൽ നിന്ന് ചില പ്രവർത്തനങ്ങൾ പ്രതീക്ഷിക്കുകയും ചെയ്യുന്നു. അവർക്ക് എൻട്രികൾ ലഭിച്ചാൽ, അവയെല്ലാം നേതാവിന് കൈമാറും. അവൻ ആദ്യം ഒരു റൈറ്റിംഗ് ഓപ്പറേഷൻ നടത്തുന്നു, തുടർന്ന് തന്റെ അനുയായികൾക്ക് എന്താണ് മാറിയതെന്ന് ഒരു സന്ദേശം അയയ്ക്കുന്നു. വാസ്തവത്തിൽ, ഇത് ആറ്റോമികമായി നടത്തണം, അതായത് മുഴുവൻ കാര്യങ്ങളുടെയും റെക്കോർഡിംഗും പ്രക്ഷേപണ പ്രവർത്തനവും ആറ്റോമികമായി നടത്തണം, അതുവഴി ഡാറ്റ സ്ഥിരത ഉറപ്പ് നൽകുന്നു.

ഇത് റൈറ്റ് അഭ്യർത്ഥനകൾ മാത്രം പ്രോസസ്സ് ചെയ്യുന്നു. പ്രവർത്തനത്തെ ഒരു ഇടപാട് അപ്‌ഡേറ്റാക്കി മാറ്റുക എന്നതാണ് ഇതിന്റെ പ്രധാന ദൗത്യം. ഇത് പ്രത്യേകം സൃഷ്ടിച്ച അഭ്യർത്ഥനയാണ്.

അതേ പ്രവർത്തനത്തിനായുള്ള അപ്‌ഡേറ്റുകളുടെ ഇംപോട്ടൻസി ഉറപ്പുനൽകുന്നു എന്നത് ഇവിടെ ശ്രദ്ധിക്കേണ്ടതാണ്. അത് എന്താണ്? ഈ കാര്യം, രണ്ടുതവണ നിർവ്വഹിച്ചാൽ, അതേ അവസ്ഥ ഉണ്ടാകും, അതായത് അഭ്യർത്ഥന തന്നെ മാറില്ല. ഇത് ചെയ്യേണ്ടതുണ്ട്, അങ്ങനെ ഒരു ക്രാഷ് ഉണ്ടായാൽ, നിങ്ങൾക്ക് പ്രവർത്തനം പുനരാരംഭിക്കാൻ കഴിയും, അതുവഴി ഇപ്പോൾ സംഭവിച്ച മാറ്റങ്ങൾ തിരികെ കൊണ്ടുവരും. ഈ സാഹചര്യത്തിൽ, സിസ്റ്റത്തിന്റെ അവസ്ഥ ഒന്നുതന്നെയാകും, അതായത്, ഒരേ ഒരു ശ്രേണി, ഉദാഹരണത്തിന്, അപ്‌ഡേറ്റ് പ്രക്രിയകൾ, സിസ്റ്റത്തിന്റെ വിവിധ അന്തിമ അവസ്ഥകളിലേക്ക് നയിച്ചത് അങ്ങനെയാകരുത്.

അവലംബം: www.habr.com