ടാരന്റൂൾ കാട്രിഡ്ജ്: മൂന്ന് വരികളിലായി ഒരു ലുവാ ബാക്ക്എൻഡ് പങ്കിടുന്നു

Mail.ru ഗ്രൂപ്പിൽ ഞങ്ങൾക്ക് Tarantool ഉണ്ട് - ഇത് ലുവയിലെ ഒരു ആപ്ലിക്കേഷൻ സെർവറാണ്, ഇത് ഒരു ഡാറ്റാബേസായി ഇരട്ടിയാകുന്നു (അല്ലെങ്കിൽ തിരിച്ചും?). ഇത് വേഗതയേറിയതും രസകരവുമാണ്, എന്നാൽ ഒരു സെർവറിന്റെ കഴിവുകൾ ഇപ്പോഴും പരിമിതമല്ല. വെർട്ടിക്കൽ സ്കെയിലിംഗും ഒരു പരിഭ്രാന്തി അല്ല, അതിനാൽ ടാരന്റൂളിന് തിരശ്ചീന സ്കെയിലിംഗിനുള്ള ഉപകരണങ്ങൾ ഉണ്ട് - vshard മൊഡ്യൂൾ [1]. നിരവധി സെർവറുകളിലുടനീളം ഡാറ്റ ഷാർഡ് ചെയ്യാൻ ഇത് നിങ്ങളെ അനുവദിക്കുന്നു, എന്നാൽ അത് സജ്ജീകരിക്കുന്നതിനും ബിസിനസ്സ് ലോജിക് അറ്റാച്ചുചെയ്യുന്നതിനും നിങ്ങൾ അത് ടിങ്കർ ചെയ്യേണ്ടതുണ്ട്.

നല്ല വാർത്ത: ഞങ്ങൾ ചില വലിയ ഷോട്ടുകൾ ശേഖരിച്ചു (ഉദാ [2], [3]) കൂടാതെ ഈ പ്രശ്നത്തിനുള്ള പരിഹാരം ഗണ്യമായി ലളിതമാക്കുന്ന മറ്റൊരു ചട്ടക്കൂട് സൃഷ്ടിച്ചു.

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

കൃത്യമായി എന്താണ് പ്രശ്നം?

ഞങ്ങൾക്ക് ഒരു ടരാന്റുലയുണ്ട്, ഞങ്ങൾക്ക് vshard ഉണ്ട് - നിങ്ങൾക്ക് ഇതിൽ കൂടുതൽ എന്താണ് വേണ്ടത്?

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

കാട്രിഡ്ജ് തന്നെ vshard കോൺഫിഗറേഷൻ കൈകാര്യം ചെയ്യുന്നു, അത് അതിന്റെ അടിസ്ഥാനത്തിലാണ് ഇത് ചെയ്യുന്നത് സ്വന്തം വിതരണം ചെയ്ത കോൺഫിഗറേഷൻ. ഇത് അടിസ്ഥാനപരമായി ഒരു ലളിതമായ YAML ഫയലാണ്, അതിന്റെ ഒരു പകർപ്പ് ഓരോ Tarantool സന്ദർഭത്തിലും സംഭരിച്ചിരിക്കുന്നു. ചട്ടക്കൂട് തന്നെ അതിന്റെ കോൺഫിഗറേഷൻ നിരീക്ഷിക്കുകയും എല്ലായിടത്തും ഒരേപോലെയാണെന്ന് ഉറപ്പാക്കുകയും ചെയ്യുന്നു എന്നതാണ് ലളിതവൽക്കരണം.

രണ്ടാമതായി, ഇത് വീണ്ടും സൗകര്യത്തിന്റെ കാര്യമാണ്. vshard കോൺഫിഗറേഷന് ബിസിനസ് ലോജിക്കിന്റെ വികസനവുമായി ഒരു ബന്ധവുമില്ല, മാത്രമല്ല പ്രോഗ്രാമറെ അവന്റെ ജോലിയിൽ നിന്ന് വ്യതിചലിപ്പിക്കുകയും ചെയ്യുന്നു. ഒരു പ്രോജക്റ്റിന്റെ വാസ്തുവിദ്യയെക്കുറിച്ച് ഞങ്ങൾ ചർച്ച ചെയ്യുമ്പോൾ, ഞങ്ങൾ മിക്കപ്പോഴും സംസാരിക്കുന്നത് വ്യക്തിഗത ഘടകങ്ങളെക്കുറിച്ചും അവയുടെ ഇടപെടലുകളെക്കുറിച്ചും ആണ്. 3 ഡാറ്റാ സെന്ററുകളിലേക്ക് ഒരു ക്ലസ്റ്റർ പുറത്തിറക്കുന്നതിനെക്കുറിച്ച് ചിന്തിക്കുന്നത് വളരെ നേരത്തെ തന്നെ.

ഞങ്ങൾ ഈ പ്രശ്നങ്ങൾ വീണ്ടും വീണ്ടും പരിഹരിച്ചു, ചില ഘട്ടങ്ങളിൽ ആപ്ലിക്കേഷനുമായി അതിന്റെ മുഴുവൻ ജീവിത ചക്രത്തിലുടനീളം പ്രവർത്തിക്കുന്നത് ലളിതമാക്കുന്ന ഒരു സമീപനം വികസിപ്പിക്കാൻ ഞങ്ങൾക്ക് കഴിഞ്ഞു: സൃഷ്ടിക്കൽ, വികസനം, പരിശോധന, CI/CD, പരിപാലനം.

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

ടാരന്റൂൾ കാട്രിഡ്ജിന്റെ പ്രധാന സവിശേഷതകൾ:

• ഓട്ടോമേറ്റഡ് ക്ലസ്റ്റർ ഓർക്കസ്ട്രേഷൻ;
• പുതിയ റോളുകൾ ഉപയോഗിച്ച് ആപ്ലിക്കേഷന്റെ പ്രവർത്തനം വിപുലീകരിക്കുന്നു;
• വികസനത്തിനും വിന്യാസത്തിനുമുള്ള ആപ്ലിക്കേഷൻ ടെംപ്ലേറ്റ്;
• ബിൽറ്റ്-ഇൻ ഓട്ടോമാറ്റിക് ഷാർഡിംഗ്;
• Luatest ടെസ്റ്റിംഗ് ചട്ടക്കൂടുമായുള്ള സംയോജനം;
• WebUI, API എന്നിവ ഉപയോഗിച്ച് ക്ലസ്റ്റർ മാനേജ്മെന്റ്;
• പാക്കേജിംഗ്, വിന്യാസ ഉപകരണങ്ങൾ.

ഹലോ വേൾഡ്!

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

$ tarantoolctl rocks install cartridge-cli
$ export PATH=$PWD/.rocks/bin/:$PATH

ഈ രണ്ട് കമാൻഡുകൾ കമാൻഡ് ലൈൻ യൂട്ടിലിറ്റികൾ ഇൻസ്റ്റാൾ ചെയ്യുകയും ടെംപ്ലേറ്റിൽ നിന്ന് നിങ്ങളുടെ ആദ്യ ആപ്ലിക്കേഷൻ സൃഷ്ടിക്കാൻ നിങ്ങളെ അനുവദിക്കുകയും ചെയ്യും:

$ cartridge create --name myapp

നമുക്ക് ലഭിക്കുന്നത് ഇതാണ്:

myapp/
├── .git/
├── .gitignore
├── app/roles/custom.lua
├── deps.sh
├── init.lua
├── myapp-scm-1.rockspec
├── test
│   ├── helper
│   │   ├── integration.lua
│   │   └── unit.lua
│   ├── helper.lua
│   ├── integration/api_test.lua
│   └── unit/sample_test.lua
└── tmp/

റെഡിമെയ്ഡ് “ഹലോ, വേൾഡ്!” ഉള്ള ഒരു ജിറ്റ് ശേഖരമാണിത്. അപേക്ഷ. മുമ്പ് ഡിപൻഡൻസികൾ ഇൻസ്റ്റാൾ ചെയ്ത ശേഷം (ഫ്രെയിംവർക്ക് ഉൾപ്പെടെ) ഇത് ഉടൻ പ്രവർത്തിപ്പിക്കാൻ ശ്രമിക്കാം:

$ tarantoolctl rocks make
$ ./init.lua --http-port 8080

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

ആപ്ലിക്കേഷൻ വികസനം

സങ്കൽപ്പിക്കുക, ഞങ്ങൾ ഒരു പ്രോജക്റ്റ് രൂപകൽപന ചെയ്യുന്നു, അത് ഡാറ്റ സ്വീകരിക്കുകയും അത് സംരക്ഷിക്കുകയും ഒരു ദിവസത്തിൽ ഒരിക്കൽ ഒരു റിപ്പോർട്ട് നിർമ്മിക്കുകയും വേണം.

ഞങ്ങൾ ഒരു ഡയഗ്രം വരയ്ക്കാൻ തുടങ്ങുകയും അതിൽ മൂന്ന് ഘടകങ്ങൾ സ്ഥാപിക്കുകയും ചെയ്യുന്നു: ഗേറ്റ്വേ, സ്റ്റോറേജ്, ഷെഡ്യൂളർ. ഞങ്ങൾ വാസ്തുവിദ്യയിൽ കൂടുതൽ പ്രവർത്തിക്കുന്നു. ഞങ്ങൾ vshard സംഭരണമായി ഉപയോഗിക്കുന്നതിനാൽ, ഞങ്ങൾ സ്കീമിലേക്ക് vshard-router, vshard-storage എന്നിവ ചേർക്കുന്നു. ഗേറ്റ്‌വേയോ ഷെഡ്യൂളറോ നേരിട്ട് സ്‌റ്റോറേജിലേക്ക് പ്രവേശിക്കില്ല; അതിനാണ് റൂട്ടർ, അതിനായി സൃഷ്‌ടിച്ചത്.

ഈ ഡയഗ്രം ഇപ്പോഴും പ്രോജക്റ്റിൽ ഞങ്ങൾ നിർമ്മിക്കുന്നതിനെ കൃത്യമായി പ്രതിനിധീകരിക്കുന്നില്ല, കാരണം ഘടകങ്ങൾ അമൂർത്തമായി കാണപ്പെടുന്നു. യഥാർത്ഥ ടാരന്റൂളിലേക്ക് ഇത് എങ്ങനെ പ്രൊജക്റ്റ് ചെയ്യപ്പെടുമെന്ന് നമുക്ക് ഇപ്പോഴും കാണേണ്ടതുണ്ട് - പ്രോസസ് പ്രകാരം നമുക്ക് നമ്മുടെ ഘടകങ്ങളെ ഗ്രൂപ്പുചെയ്യാം.

vshard-router ഉം ഗേറ്റ്‌വേയും പ്രത്യേക സന്ദർഭങ്ങളിൽ സൂക്ഷിക്കുന്നതിൽ കാര്യമില്ല. ഇത് ഇതിനകം തന്നെ റൂട്ടറിന്റെ ഉത്തരവാദിത്തമാണെങ്കിൽ ഞങ്ങൾ നെറ്റ്‌വർക്കിൽ ഒരിക്കൽ കൂടി സർഫ് ചെയ്യേണ്ടത് എന്തുകൊണ്ട്? അവ ഒരേ പ്രക്രിയയിൽ പ്രവർത്തിക്കണം. അതായത്, ഗേറ്റ്‌വേയും vshard.router.cfg ഉം ഒരു പ്രക്രിയയിൽ ആരംഭിക്കുകയും അവയെ പ്രാദേശികമായി സംവദിക്കാൻ അനുവദിക്കുകയും ചെയ്യുന്നു.

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

സ്റ്റേജിംഗിലേക്കോ പ്രൊഡക്ഷനിലേക്കോ വിന്യാസത്തിന്റെ കാര്യം വരുമ്പോൾ, ഹാർഡ്‌വെയർ കഴിവുകളെ ആശ്രയിച്ച് ഓരോ ടാരന്റൂളിനും അതിന്റേതായ റോളുകൾ ഞങ്ങൾ നൽകും:

ടോപ്പോളജി മാനേജ്മെന്റ്

ഏത് റോളുകളാണ് പ്രവർത്തിക്കുന്നത് എന്നതിനെക്കുറിച്ചുള്ള വിവരങ്ങൾ എവിടെയെങ്കിലും സൂക്ഷിക്കണം. ഇത് "എവിടെയോ" എന്നത് വിതരണം ചെയ്ത കോൺഫിഗറേഷനാണ്, ഞാൻ ഇതിനകം മുകളിൽ സൂചിപ്പിച്ചതാണ്. അതിൽ ഏറ്റവും പ്രധാനം ക്ലസ്റ്റർ ടോപ്പോളജിയാണ്. 3 ടാരന്റൂൾ പ്രക്രിയകളുടെ 5 റെപ്ലിക്കേഷൻ ഗ്രൂപ്പുകൾ ഇതാ:

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

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

വേഷങ്ങളുടെ ജീവിതം

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

function init()
function validate_config()
function apply_config()
function stop()

ഓരോ റോളിനും ഒരു ധർമ്മമുണ്ട് init. റോൾ പ്രവർത്തനക്ഷമമാക്കുമ്പോഴോ ടാരന്റൂൾ പുനരാരംഭിക്കുമ്പോഴോ ഇത് ഒരിക്കൽ വിളിക്കപ്പെടും. ഉദാഹരണത്തിന്, box.space.create സമാരംഭിക്കുന്നത് അവിടെ സൗകര്യപ്രദമാണ്, അല്ലെങ്കിൽ നിശ്ചിത സമയ ഇടവേളകളിൽ ജോലി നിർവഹിക്കുന്ന ചില പശ്ചാത്തല ഫൈബർ ഷെഡ്യൂളറിന് സമാരംഭിക്കാൻ കഴിയും.

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

ക്ലസ്റ്റർ കോളുകൾ validate_config и apply_config ഓരോ തവണയും വിതരണം ചെയ്ത കോൺഫിഗറേഷൻ മാറുന്നു. ഒരു കോൺഫിഗറേഷൻ രണ്ട്-ഘട്ട കമ്മിറ്റ് ഉപയോഗിച്ച് പ്രയോഗിക്കുമ്പോൾ, ഓരോ റോളും ഈ പുതിയ കോൺഫിഗറേഷൻ സ്വീകരിക്കാൻ തയ്യാറാണോ എന്ന് ക്ലസ്റ്റർ പരിശോധിക്കുന്നു, ആവശ്യമെങ്കിൽ ഉപയോക്താവിന് ഒരു പിശക് റിപ്പോർട്ട് ചെയ്യുന്നു. കോൺഫിഗറേഷൻ സാധാരണമാണെന്ന് എല്ലാവരും സമ്മതിക്കുമ്പോൾ, പിന്നെ apply_config.

റോളുകൾക്കും ഒരു രീതിയുണ്ട് stop, റോളിന്റെ ഔട്ട്പുട്ട് വൃത്തിയാക്കാൻ ഇത് ആവശ്യമാണ്. ഈ സെർവറിൽ ഇനി ഷെഡ്യൂളർ ആവശ്യമില്ലെന്ന് ഞങ്ങൾ പറഞ്ഞാൽ, അത് ആരംഭിച്ച ആ ഫൈബറുകളെ അതിന് നിർത്താനാകും init.

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

മറ്റൊരു പ്രധാന കാര്യം തെറ്റ് സഹിഷ്ണുത ഉറപ്പാക്കുക എന്നതാണ്. ആരോഗ്യം നിരീക്ഷിക്കാൻ കാട്രിഡ്ജ് SWIM പ്രോട്ടോക്കോൾ ഉപയോഗിക്കുന്നു [4]. ചുരുക്കത്തിൽ, UDP-യിലൂടെ പ്രക്രിയകൾ പരസ്പരം "കിംവദന്തികൾ" കൈമാറുന്നു-ഓരോ പ്രക്രിയയും അതിന്റെ അയൽക്കാരോട് ഏറ്റവും പുതിയ വാർത്തകൾ പറയുകയും അവർ പ്രതികരിക്കുകയും ചെയ്യുന്നു. പെട്ടെന്ന് ഉത്തരം ലഭിച്ചില്ലെങ്കിൽ, ടാരന്തൂൾ എന്തോ കുഴപ്പമുണ്ടെന്ന് സംശയിക്കാൻ തുടങ്ങുന്നു, കുറച്ച് സമയത്തിന് ശേഷം അത് മരണം പാരായണം ചെയ്യുകയും ചുറ്റുമുള്ള എല്ലാവരോടും ഈ വാർത്ത പറയാൻ തുടങ്ങുകയും ചെയ്യുന്നു.

ഈ പ്രോട്ടോക്കോൾ അടിസ്ഥാനമാക്കി, കാട്രിഡ്ജ് ഓട്ടോമാറ്റിക് പരാജയ പ്രോസസ്സിംഗ് സംഘടിപ്പിക്കുന്നു. ഓരോ പ്രക്രിയയും അതിന്റെ പരിതസ്ഥിതി നിരീക്ഷിക്കുന്നു, നേതാവ് പെട്ടെന്ന് പ്രതികരിക്കുന്നത് നിർത്തുകയാണെങ്കിൽ, പകർപ്പിന് അതിന്റെ പങ്ക് ഏറ്റെടുക്കാൻ കഴിയും, കൂടാതെ കാട്രിഡ്ജ് അതിനനുസരിച്ച് റണ്ണിംഗ് റോളുകൾ ക്രമീകരിക്കുകയും ചെയ്യുന്നു.

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

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

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

വിന്യാസ ഉപകരണങ്ങൾ

ആപ്ലിക്കേഷനുകൾ വിന്യസിക്കാൻ കാട്രിഡ്ജ് എങ്ങനെ സഹായിക്കുന്നുവെന്ന് കാണിക്കുമെന്ന് ഞാൻ വാഗ്ദാനം ചെയ്തു. മറ്റുള്ളവർക്ക് ജീവിതം എളുപ്പമാക്കുന്നതിന്, ഫ്രെയിംവർക്ക് പാക്കേജുകൾ RPM പാക്കേജുകൾ:

$ cartridge pack rpm myapp -- упакует для нас ./myapp-0.1.0-1.rpm
$ sudo yum install ./myapp-0.1.0-1.rpm

ഇൻസ്റ്റോൾ ചെയ്ത പാക്കേജിൽ നിങ്ങൾക്ക് ആവശ്യമുള്ള മിക്കവാറും എല്ലാം അടങ്ങിയിരിക്കുന്നു: ആപ്ലിക്കേഷനും ഇൻസ്റ്റാൾ ചെയ്ത ഡിപൻഡൻസികളും. RPM പാക്കേജിന്റെ ആശ്രിതത്വമായി Tarantool സെർവറിൽ എത്തും, ഞങ്ങളുടെ സേവനം സമാരംഭിക്കാൻ തയ്യാറാണ്. ഇത് systemd വഴിയാണ് ചെയ്യുന്നത്, എന്നാൽ ആദ്യം നിങ്ങൾ ഒരു ചെറിയ കോൺഫിഗറേഷൻ എഴുതേണ്ടതുണ്ട്. കുറഞ്ഞത്, ഓരോ പ്രക്രിയയുടെയും URI വ്യക്തമാക്കുക. ഉദാഹരണത്തിന് മൂന്ന് മതി.

$ sudo tee /etc/tarantool/conf.d/demo.yml <<CONFIG
myapp.router: {"advertise_uri": "localhost:3301", "http_port": 8080}
myapp.storage_A: {"advertise_uri": "localhost:3302", "http_enabled": False}
myapp.storage_B: {"advertise_uri": "localhost:3303", "http_enabled": False}
CONFIG

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

ഇപ്പോൾ കോൺഫിഗറേഷൻ തയ്യാറാണ്, നിങ്ങൾക്ക് പ്രക്രിയകൾ ആരംഭിക്കാം. ഒരു സാധാരണ systemd യൂണിറ്റ് ഒന്നിൽ കൂടുതൽ പ്രക്രിയകൾ ആരംഭിക്കാൻ അനുവദിക്കാത്തതിനാൽ, കാട്രിഡ്ജിലെ ആപ്ലിക്കേഷനുകൾ എന്ന് വിളിക്കപ്പെടുന്നവ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ഇതുപോലെ പ്രവർത്തിക്കുന്ന തൽക്ഷണ യൂണിറ്റുകൾ:

$ sudo systemctl start myapp@router
$ sudo systemctl start myapp@storage_A
$ sudo systemctl start myapp@storage_B

കോൺഫിഗറേഷനിൽ, കാട്രിഡ്ജ് വെബ് ഇന്റർഫേസ് നൽകുന്ന HTTP പോർട്ട് ഞങ്ങൾ വ്യക്തമാക്കി - 8080. നമുക്ക് അതിലേക്ക് പോയി നോക്കാം:

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

നിങ്ങളുടെ പ്രിയപ്പെട്ട പാനീയം ഒരു ഗ്ലാസ് ഒഴിച്ച് ഒരു നീണ്ട പ്രവൃത്തി ആഴ്ചയ്ക്ക് ശേഷം വിശ്രമിക്കാം. ആപ്ലിക്കേഷൻ ഉപയോഗിക്കാം.

ഫലങ്ങൾ

ഫലങ്ങൾ എന്തൊക്കെയാണ്? ഇത് പരീക്ഷിക്കുക, ഉപയോഗിക്കുക, ഫീഡ്‌ബാക്ക് നൽകുക, Github-ൽ ടിക്കറ്റുകൾ സൃഷ്‌ടിക്കുക.

റെഫറൻസുകൾ

[1] Tarantool » 2.2 » റഫറൻസ് » Rocks reference » Module vshard

[2] Tarantool അടിസ്ഥാനമാക്കിയുള്ള Alfa-Bank-ന്റെ നിക്ഷേപ ബിസിനസിന്റെ കാതൽ ഞങ്ങൾ എങ്ങനെയാണ് നടപ്പിലാക്കിയത്

[3] ന്യൂ ജനറേഷൻ ബില്ലിംഗ് ആർക്കിടെക്ചർ: ടാരന്റൂളിലേക്കുള്ള പരിവർത്തനം

[4] SWIM - ക്ലസ്റ്റർ നിർമ്മാണ പ്രോട്ടോക്കോൾ

[5] GitHub - tarantool/cartridge-cli

[6] GitHub - ടാരന്റൂൾ/കാട്രിഡ്ജ്

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