വിതരണം ചെയ്ത ആപ്ലിക്കേഷനുകളുടെ നിർമ്മാണ ബ്ലോക്കുകൾ. രണ്ടാമത്തെ ഏകദേശ കണക്ക്

പ്രഖ്യാപനം

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

Erlang/Elixir-ൽ വിതരണം ചെയ്ത റിയാക്ടീവ് ആപ്ലിക്കേഷനുകളെക്കുറിച്ചുള്ള പരമ്പരയിലെ അവസാന ലേഖനമാണിത്. IN ആദ്യ ലേഖനം റിയാക്ടീവ് ആർക്കിടെക്ചറിന്റെ സൈദ്ധാന്തിക അടിത്തറ നിങ്ങൾക്ക് കണ്ടെത്താനാകും. രണ്ടാമത്തെ ലേഖനം അത്തരം സംവിധാനങ്ങൾ നിർമ്മിക്കുന്നതിനുള്ള അടിസ്ഥാന പാറ്റേണുകളും മെക്കാനിസങ്ങളും ചിത്രീകരിക്കുന്നു.

ഇന്ന് ഞങ്ങൾ കോഡ് ബേസിന്റെ വികസനത്തിന്റെ പ്രശ്നങ്ങളും പൊതുവെ പദ്ധതികളും ഉന്നയിക്കും.

സേവനങ്ങളുടെ ഓർഗനൈസേഷൻ

യഥാർത്ഥ ജീവിതത്തിൽ, ഒരു സേവനം വികസിപ്പിക്കുമ്പോൾ, നിങ്ങൾ പലപ്പോഴും ഒരു കൺട്രോളറിൽ നിരവധി പാറ്റേണുകൾ സംയോജിപ്പിക്കേണ്ടതുണ്ട്. ഉദാഹരണത്തിന്, പ്രോജക്റ്റ് ഉപയോക്തൃ പ്രൊഫൈലുകൾ കൈകാര്യം ചെയ്യുന്നതിലെ പ്രശ്നം പരിഹരിക്കുന്ന ഉപയോക്തൃ സേവനം, req-resp അഭ്യർത്ഥനകളോട് പ്രതികരിക്കുകയും പബ്-സബ് വഴി പ്രൊഫൈൽ അപ്‌ഡേറ്റുകൾ റിപ്പോർട്ട് ചെയ്യുകയും വേണം. ഈ കേസ് വളരെ ലളിതമാണ്: സന്ദേശമയയ്‌ക്കുന്നതിന് പിന്നിൽ സേവന ലോജിക് നടപ്പിലാക്കുകയും അപ്‌ഡേറ്റുകൾ പ്രസിദ്ധീകരിക്കുകയും ചെയ്യുന്ന ഒരു കൺട്രോളർ ഉണ്ട്.

ഒരു തെറ്റ്-സഹിഷ്ണുതയുള്ള വിതരണ സേവനം നടപ്പിലാക്കേണ്ടിവരുമ്പോൾ സ്ഥിതി കൂടുതൽ സങ്കീർണമാകുന്നു. ഉപയോക്താക്കൾക്കുള്ള ആവശ്യകതകൾ മാറിയെന്ന് നമുക്ക് സങ്കൽപ്പിക്കുക:

1. ഇപ്പോൾ സേവനം 5 ക്ലസ്റ്റർ നോഡുകളിൽ അഭ്യർത്ഥനകൾ പ്രോസസ്സ് ചെയ്യണം,
2. പശ്ചാത്തല പ്രോസസ്സിംഗ് ജോലികൾ ചെയ്യാൻ കഴിയും,
3. കൂടാതെ പ്രൊഫൈൽ അപ്‌ഡേറ്റുകൾക്കായുള്ള സബ്‌സ്‌ക്രിപ്‌ഷൻ ലിസ്റ്റുകൾ ഡൈനാമിക്കായി മാനേജ് ചെയ്യാനും കഴിയും.

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

ഉപയോക്തൃ സേവനത്തിന്റെ ഔപചാരിക വിവരണം കൂടുതൽ സങ്കീർണ്ണമായിരിക്കുന്നു. ഒരു പ്രോഗ്രാമറുടെ വീക്ഷണകോണിൽ, സന്ദേശമയയ്‌ക്കൽ ഉപയോഗം കാരണം മാറ്റങ്ങൾ വളരെ കുറവാണ്. ആദ്യ ആവശ്യകത നിറവേറ്റുന്നതിന്, ഞങ്ങൾ req-resp എക്സ്ചേഞ്ച് പോയിന്റിൽ ബാലൻസിംഗ് കോൺഫിഗർ ചെയ്യേണ്ടതുണ്ട്.

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

പോയിന്റ് 3-ന് പബ്-സബ് ടെംപ്ലേറ്റ് വിപുലീകരണം ആവശ്യമാണ്. നടപ്പിലാക്കുന്നതിനായി, ഒരു പബ്-സബ് എക്‌സ്‌ചേഞ്ച് പോയിന്റ് സൃഷ്‌ടിച്ചതിന് ശേഷം, ഞങ്ങളുടെ സേവനത്തിനുള്ളിൽ ഈ പോയിന്റിന്റെ കൺട്രോളർ കൂടി ലോഞ്ച് ചെയ്യേണ്ടതുണ്ട്. അതിനാൽ, സബ്‌സ്‌ക്രിപ്‌ഷനുകൾ പ്രോസസ്സ് ചെയ്യുന്നതിനും മെസേജിംഗ് ലെയറിൽ നിന്ന് അൺസബ്‌സ്‌ക്രൈബ് ചെയ്യുന്നതിനുമുള്ള യുക്തി ഞങ്ങൾ ഉപയോക്താക്കളുടെ നടപ്പാക്കലിലേക്ക് മാറ്റുന്നത് പോലെയാണ് ഇത്.

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

നേതാവിന്റെ തിരഞ്ഞെടുപ്പ്

ഡിസ്ട്രിബ്യൂഡ് സിസ്റ്റങ്ങളിൽ, ചില ലോഡുകളുടെ വിതരണം ചെയ്ത പ്രോസസ്സിംഗ് ഷെഡ്യൂൾ ചെയ്യുന്നതിന് ഉത്തരവാദിത്തമുള്ള ഒരൊറ്റ പ്രക്രിയയെ നിയമിക്കുന്നതിനുള്ള നടപടിക്രമമാണ് ലീഡർ തിരഞ്ഞെടുപ്പ്.

കേന്ദ്രീകരണത്തിന് സാധ്യതയില്ലാത്ത സിസ്റ്റങ്ങളിൽ, പാക്സോസ് അല്ലെങ്കിൽ റാഫ്റ്റ് പോലെയുള്ള സാർവത്രികവും സമവായ അടിസ്ഥാനത്തിലുള്ളതുമായ അൽഗോരിതങ്ങൾ ഉപയോഗിക്കുന്നു.
സന്ദേശമയയ്‌ക്കൽ ഒരു ബ്രോക്കറും കേന്ദ്ര ഘടകവുമായതിനാൽ, എല്ലാ സേവന കൺട്രോളറുകളെയും - സ്ഥാനാർത്ഥി നേതാക്കളെ കുറിച്ച് അതിന് അറിയാം. സന്ദേശമയയ്‌ക്കലിന് വോട്ട് ചെയ്യാതെ തന്നെ ഒരു നേതാവിനെ നിയമിക്കാം.

എക്സ്ചേഞ്ച് പോയിന്റിലേക്ക് ആരംഭിച്ച് കണക്റ്റുചെയ്‌തതിന് ശേഷം, എല്ലാ സേവനങ്ങൾക്കും ഒരു സിസ്റ്റം സന്ദേശം ലഭിക്കും #'$leader'{exchange = ?EXCHANGE, pid = LeaderPid, servers = Servers}. എങ്കിൽ LeaderPid യോജിക്കുന്നു pid നിലവിലെ പ്രക്രിയ, അത് നേതാവായി നിയമിക്കപ്പെട്ടു, പട്ടിക Servers എല്ലാ നോഡുകളും അവയുടെ പാരാമീറ്ററുകളും ഉൾപ്പെടുന്നു.
പുതിയൊരെണ്ണം പ്രത്യക്ഷപ്പെടുകയും ഒരു വർക്കിംഗ് ക്ലസ്റ്റർ നോഡ് വിച്ഛേദിക്കുകയും ചെയ്ത നിമിഷത്തിൽ, എല്ലാ സേവന കൺട്രോളറുകൾക്കും ലഭിക്കും #'$slave_up'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} и #'$slave_down'{exchange = ?EXCHANGE, pid = SlavePid, options = SlaveOpts} യഥാക്രമം

ഈ രീതിയിൽ, എല്ലാ ഘടകങ്ങളും എല്ലാ മാറ്റങ്ങളെക്കുറിച്ചും ബോധവാന്മാരാണ്, കൂടാതെ ക്ലസ്റ്ററിന് ഏത് സമയത്തും ഒരു ലീഡർ ഉണ്ടെന്ന് ഉറപ്പുനൽകുന്നു.

മധ്യസ്ഥർ

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

പബ്-സബ് ഒപ്റ്റിമൈസേഷന്റെ ഒരു മികച്ച ഉദാഹരണം, മാർക്കറ്റിലെ വില മാറ്റങ്ങൾ, വെബ് ക്ലയന്റുകൾക്ക് വെബ്‌സോക്കറ്റ് API നൽകുന്ന N സെർവറുകൾ എന്നിവ പോലുള്ള അപ്‌ഡേറ്റ് ഇവന്റുകൾ സൃഷ്ടിക്കുന്ന ഒരു ബിസിനസ്സ് കോർ ഉള്ള ഒരു വിതരണം ചെയ്ത ആപ്ലിക്കേഷനാണ്.
നിങ്ങൾ നേരിട്ട് തീരുമാനിക്കുകയാണെങ്കിൽ, ഉപഭോക്തൃ സേവനം ഇതുപോലെ കാണപ്പെടുന്നു:

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

"വാർത്ത" വിഷയത്തിൽ ഞങ്ങൾക്ക് 50000 വരിക്കാരുണ്ടെന്ന് സങ്കൽപ്പിക്കുക. വരിക്കാരെ 5 സെർവറുകളിലുടനീളം തുല്യമായി വിതരണം ചെയ്യുന്നു. തൽഫലമായി, എക്‌സ്‌ചേഞ്ച് പോയിന്റിൽ എത്തുന്ന ഓരോ അപ്‌ഡേറ്റും 50000 തവണ ആവർത്തിക്കും: ഓരോ സെർവറിലും 10000 തവണ, അതിലെ സബ്‌സ്‌ക്രൈബർമാരുടെ എണ്ണം അനുസരിച്ച്. വളരെ ഫലപ്രദമായ ഒരു പദ്ധതിയല്ല, അല്ലേ?
സാഹചര്യം മെച്ചപ്പെടുത്തുന്നതിന്, എക്സ്ചേഞ്ച് പോയിന്റിന്റെ അതേ പേരുള്ള ഒരു പ്രോക്സി അവതരിപ്പിക്കാം. ഗ്ലോബൽ നെയിം രജിസ്ട്രാർക്ക് പേരിനനുസരിച്ച് ഏറ്റവും അടുത്തുള്ള പ്രക്രിയ തിരികെ നൽകാൻ കഴിയണം, ഇത് പ്രധാനമാണ്.

ആക്‌സസ് ലെയർ സെർവറുകളിൽ ഈ പ്രോക്‌സി സമാരംഭിക്കാം, വെബ്‌സോക്കറ്റ് എപിഐ സേവിക്കുന്ന ഞങ്ങളുടെ എല്ലാ പ്രക്രിയകളും ഇത് സബ്‌സ്‌ക്രൈബ് ചെയ്യും, അല്ലാതെ കേർണലിലെ യഥാർത്ഥ പബ്-സബ് എക്‌സ്‌ചേഞ്ച് പോയിന്റിലേക്കല്ല. ഒരു അദ്വിതീയ സബ്‌സ്‌ക്രിപ്‌ഷന്റെ കാര്യത്തിൽ മാത്രം പ്രോക്‌സി കോറിലേക്ക് സബ്‌സ്‌ക്രൈബുചെയ്യുകയും അതിന്റെ എല്ലാ വരിക്കാർക്കും ഇൻകമിംഗ് സന്ദേശം പകർത്തുകയും ചെയ്യുന്നു.
തൽഫലമായി, കേർണലിനും ആക്സസ് സെർവറിനുമിടയിൽ 5 സന്ദേശങ്ങൾക്ക് പകരം 50000 സന്ദേശങ്ങൾ അയയ്ക്കും.

റൂട്ടിംഗും ബാലൻസും

Req-Resp

നിലവിലെ സന്ദേശമയയ്‌ക്കൽ നടപ്പാക്കലിൽ, 7 അഭ്യർത്ഥന വിതരണ തന്ത്രങ്ങളുണ്ട്:

• default. അഭ്യർത്ഥന എല്ലാ കൺട്രോളർമാർക്കും അയച്ചു.
• round-robin. അഭ്യർത്ഥനകൾ കണക്കാക്കുകയും കൺട്രോളറുകൾക്കിടയിൽ ചാക്രികമായി വിതരണം ചെയ്യുകയും ചെയ്യുന്നു.
• consensus. സേവനത്തെ സേവിക്കുന്ന കൺട്രോളർമാരെ നേതാക്കൾ, അടിമകൾ എന്നിങ്ങനെ തിരിച്ചിരിക്കുന്നു. അഭ്യർത്ഥനകൾ നേതാവിന് മാത്രമേ അയയ്ക്കൂ.
• consensus & round-robin. ഗ്രൂപ്പിന് ഒരു നേതാവുണ്ട്, എന്നാൽ അഭ്യർത്ഥനകൾ എല്ലാ അംഗങ്ങൾക്കും വിതരണം ചെയ്യുന്നു.
• sticky. ഹാഷ് ഫംഗ്‌ഷൻ കണക്കാക്കുകയും ഒരു പ്രത്യേക ഹാൻഡ്‌ലറിന് നൽകുകയും ചെയ്യുന്നു. ഈ ഒപ്പുള്ള തുടർന്നുള്ള അഭ്യർത്ഥനകൾ ഒരേ ഹാൻഡ്‌ലറിലേക്ക് പോകുന്നു.
• sticky-fun. എക്സ്ചേഞ്ച് പോയിന്റ് ആരംഭിക്കുമ്പോൾ, ഹാഷ് കണക്കുകൂട്ടൽ പ്രവർത്തനം sticky ബാലൻസിങ്.
• fun. സ്റ്റിക്കി-ഫൺ പോലെ, നിങ്ങൾക്ക് മാത്രമേ ഇത് റീഡയറക്‌ട് ചെയ്യാനോ നിരസിക്കാനോ മുൻകൂട്ടി പ്രോസസ്സ് ചെയ്യാനോ കഴിയൂ.

എക്സ്ചേഞ്ച് പോയിന്റ് ആരംഭിക്കുമ്പോൾ വിതരണ തന്ത്രം സജ്ജീകരിച്ചിരിക്കുന്നു.

ബാലൻസിംഗ് കൂടാതെ, മെസേജിംഗ് നിങ്ങളെ എന്റിറ്റികളെ ടാഗ് ചെയ്യാൻ അനുവദിക്കുന്നു. സിസ്റ്റത്തിലെ ടാഗുകളുടെ തരങ്ങൾ നോക്കാം:

• കണക്ഷൻ ടാഗ്. ഏത് കണക്ഷനിലൂടെയാണ് ഇവന്റുകൾ വന്നതെന്ന് മനസിലാക്കാൻ നിങ്ങളെ അനുവദിക്കുന്നു. ഒരു കൺട്രോളർ പ്രോസസ്സ് ഒരേ എക്സ്ചേഞ്ച് പോയിന്റിലേക്ക് കണക്റ്റുചെയ്യുമ്പോൾ ഉപയോഗിക്കുന്നു, എന്നാൽ വ്യത്യസ്ത റൂട്ടിംഗ് കീകൾ.
• സേവന ടാഗ്. ഒരു സേവനത്തിനായി ഹാൻഡ്‌ലർമാരെ ഗ്രൂപ്പുകളായി സംയോജിപ്പിക്കാനും റൂട്ടിംഗ്, ബാലൻസിംഗ് കഴിവുകൾ വികസിപ്പിക്കാനും നിങ്ങളെ അനുവദിക്കുന്നു. req-resp പാറ്റേണിന്, റൂട്ടിംഗ് രേഖീയമാണ്. എക്സ്ചേഞ്ച് പോയിന്റിലേക്ക് ഞങ്ങൾ ഒരു അഭ്യർത്ഥന അയയ്‌ക്കുന്നു, അത് അത് സേവനത്തിലേക്ക് കൈമാറുന്നു. എന്നാൽ നമുക്ക് ഹാൻഡ്‌ലറുകളെ ലോജിക്കൽ ഗ്രൂപ്പുകളായി വിഭജിക്കണമെങ്കിൽ, ടാഗുകൾ ഉപയോഗിച്ചാണ് വിഭജനം നടത്തുന്നത്. ഒരു ടാഗ് വ്യക്തമാക്കുമ്പോൾ, ഒരു നിർദ്ദിഷ്‌ട കൺട്രോളറുകളിലേക്ക് അഭ്യർത്ഥന അയയ്‌ക്കും.
• അഭ്യർത്ഥന ടാഗ്. ഉത്തരങ്ങൾ തമ്മിൽ വേർതിരിച്ചറിയാൻ നിങ്ങളെ അനുവദിക്കുന്നു. ഞങ്ങളുടെ സിസ്റ്റം അസമന്വിതമായതിനാൽ, സേവന പ്രതികരണങ്ങൾ പ്രോസസ്സ് ചെയ്യുന്നതിന് ഒരു അഭ്യർത്ഥന അയയ്‌ക്കുമ്പോൾ ഞങ്ങൾക്ക് ഒരു അഭ്യർത്ഥന ടാഗ് വ്യക്തമാക്കേണ്ടതുണ്ട്. ഏത് അഭ്യർത്ഥനയാണ് ഞങ്ങൾക്ക് വന്നതെന്ന് അതിൽ നിന്ന് നമുക്ക് മനസിലാക്കാൻ കഴിയും.

പബ്-സബ്

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

സ്കേലബിളിറ്റിയും തെറ്റ് സഹിഷ്ണുതയും

സിസ്റ്റത്തിന്റെ മൊത്തത്തിലുള്ള സ്കേലബിളിറ്റി സിസ്റ്റത്തിന്റെ പാളികളുടെയും ഘടകങ്ങളുടെയും സ്കേലബിളിറ്റിയുടെ അളവിനെ ആശ്രയിച്ചിരിക്കുന്നു:

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

ഒരു പദ്ധതിയുടെ വിജയം പലപ്പോഴും സ്കെയിലിംഗിന്റെ ലാളിത്യത്തെയും വേഗതയെയും ആശ്രയിച്ചിരിക്കുന്നു. അതിന്റെ നിലവിലെ പതിപ്പിൽ സന്ദേശമയയ്‌ക്കൽ അപ്ലിക്കേഷനോടൊപ്പം വളരുന്നു. 50-60 മെഷീനുകളുടെ ഒരു ക്ലസ്റ്റർ ഇല്ലെങ്കിലും, നമുക്ക് ഫെഡറേഷനെ ആശ്രയിക്കാം. നിർഭാഗ്യവശാൽ, ഫെഡറേഷന്റെ വിഷയം ഈ ലേഖനത്തിന്റെ പരിധിക്കപ്പുറമാണ്.

സംവരണം

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

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

ഉത്പാദനക്ഷമത

rabbitmq-ന്റെ പ്രകടനവും ഞങ്ങളുടെ ഇഷ്‌ടാനുസൃത സന്ദേശമയയ്‌ക്കലും ഏകദേശം താരതമ്യം ചെയ്യാൻ ശ്രമിക്കാം.
ഞാന് കണ്ടെത്തി ഔദ്യോഗിക ഫലങ്ങൾ ഓപ്പൺസ്റ്റാക്ക് ടീമിൽ നിന്നുള്ള rabbitmq പരിശോധന.

ഖണ്ഡിക 6.14.1.2.1.2.2 ൽ. യഥാർത്ഥ പ്രമാണം RPC CAST-ന്റെ ഫലം കാണിക്കുന്നു:

OS കേർണലിലോ erlang VM-ലോ ഞങ്ങൾ മുൻകൂറായി അധിക ക്രമീകരണങ്ങളൊന്നും ഉണ്ടാക്കില്ല. പരിശോധനയ്ക്കുള്ള വ്യവസ്ഥകൾ:

• erl opts: +A1 +sbtu.
• ഒരൊറ്റ എർലാംഗ് നോഡിനുള്ളിലെ പരിശോധന മൊബൈൽ പതിപ്പിൽ പഴയ i7 ഉള്ള ഒരു ലാപ്‌ടോപ്പിലാണ് പ്രവർത്തിക്കുന്നത്.
• 10G നെറ്റ്‌വർക്ക് ഉള്ള സെർവറുകളിൽ ക്ലസ്റ്റർ ടെസ്റ്റുകൾ നടത്തുന്നു.
• ഡോക്കർ കണ്ടെയ്‌നറുകളിൽ കോഡ് പ്രവർത്തിക്കുന്നു. NAT മോഡിൽ നെറ്റ്‌വർക്ക്.

ടെസ്റ്റ് കോഡ്:

req_resp_bench(_) ->
  W = perftest:comprehensive(10000,
    fun() ->
      messaging:request(?EXCHANGE, default, ping, self()),
      receive
        #'$msg'{message = pong} -> ok
      after 5000 ->
        throw(timeout)
      end
    end
  ),
  true = lists:any(fun(E) -> E >= 30000 end, W),
  ok.

രംഗം 1: പഴയ i7 മൊബൈൽ പതിപ്പുള്ള ലാപ്‌ടോപ്പിലാണ് ടെസ്റ്റ് പ്രവർത്തിക്കുന്നത്. ടെസ്റ്റ്, സന്ദേശമയയ്‌ക്കൽ, സേവനം എന്നിവ ഒരു ഡോക്കർ കണ്ടെയ്‌നറിൽ ഒരു നോഡിൽ നടപ്പിലാക്കുന്നു:

Sequential 10000 cycles in ~0 seconds (26987 cycles/s)
Sequential 20000 cycles in ~1 seconds (26915 cycles/s)
Sequential 100000 cycles in ~4 seconds (26957 cycles/s)
Parallel 2 100000 cycles in ~2 seconds (44240 cycles/s)
Parallel 4 100000 cycles in ~2 seconds (53459 cycles/s)
Parallel 10 100000 cycles in ~2 seconds (52283 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (49317 cycles/s)

രംഗം 2: ഡോക്കറിന് (NAT) കീഴിലുള്ള വ്യത്യസ്ത മെഷീനുകളിൽ പ്രവർത്തിക്കുന്ന 3 നോഡുകൾ.

Sequential 10000 cycles in ~1 seconds (8684 cycles/s)
Sequential 20000 cycles in ~2 seconds (8424 cycles/s)
Sequential 100000 cycles in ~12 seconds (8655 cycles/s)
Parallel 2 100000 cycles in ~7 seconds (15160 cycles/s)
Parallel 4 100000 cycles in ~5 seconds (19133 cycles/s)
Parallel 10 100000 cycles in ~4 seconds (24399 cycles/s)
Parallel 100 100000 cycles in ~3 seconds (34517 cycles/s)

എല്ലാ സാഹചര്യങ്ങളിലും, CPU ഉപയോഗം 250% കവിയുന്നില്ല

ഫലങ്ങൾ

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

ഫോട്ടോ @ചട്ടർസ്നാപ്പ്

രജിസ്റ്റർ ചെയ്ത ഉപയോക്താക്കൾക്ക് മാത്രമേ സർവേയിൽ പങ്കെടുക്കാൻ കഴിയൂ. സൈൻ ഇൻദയവായി.

VTrade പരീക്ഷണ പരമ്പരയുടെ ഭാഗമായി ഞാൻ ഏതൊക്കെ വിഷയങ്ങളാണ് കൂടുതൽ വിശദമായി ഉൾപ്പെടുത്തേണ്ടത്?

• സിദ്ധാന്തം: മാർക്കറ്റുകളും ഓർഡറുകളും അവയുടെ സമയവും: DAY, GTD, GTC, IOC, FOK, MOO, MOC, LOO, LOC

• ഉത്തരവുകളുടെ പുസ്തകം. ഗ്രൂപ്പിംഗുകൾ ഉപയോഗിച്ച് ഒരു പുസ്തകം നടപ്പിലാക്കുന്നതിനുള്ള സിദ്ധാന്തവും പ്രയോഗവും

• ട്രേഡിംഗിന്റെ ദൃശ്യവൽക്കരണം: ടിക്കുകൾ, ബാറുകൾ, റെസല്യൂഷനുകൾ. എങ്ങനെ സംഭരിക്കാം, എങ്ങനെ പശ ചെയ്യാം

• ബാക്ക് ഓഫീസ്. ആസൂത്രണവും വികസനവും. ജീവനക്കാരുടെ നിരീക്ഷണവും സംഭവ അന്വേഷണവും

• API. എന്തൊക്കെ ഇന്റർഫേസുകളാണ് ആവശ്യമെന്നും അവ എങ്ങനെ നടപ്പിലാക്കണമെന്നും നമുക്ക് നോക്കാം

• വിവര സംഭരണം: PostgreSQL, ടൈംസ്‌കെയിൽ, ട്രേഡിംഗ് സിസ്റ്റങ്ങളിൽ Tarantool

• വ്യാപാര സംവിധാനങ്ങളിലെ പ്രതിപ്രവർത്തനം

• മറ്റുള്ളവ. ഞാൻ അഭിപ്രായങ്ങളിൽ എഴുതാം

6 ഉപയോക്താക്കൾ വോട്ട് ചെയ്തു. 4 ഉപയോക്താക്കൾ വിട്ടുനിന്നു.

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