തെറ്റ് സഹിഷ്ണുതയും ഉയർന്ന ലഭ്യതയും വലിയ വിഷയങ്ങളാണ്, അതിനാൽ ഞങ്ങൾ RabbitMQ, Kafka എന്നിവയ്ക്കായി പ്രത്യേക ലേഖനങ്ങൾ സമർപ്പിക്കും. ഈ ലേഖനം RabbitMQ നെക്കുറിച്ചാണ്, അടുത്തത് RabbitMQ-യുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ കാഫ്കയെക്കുറിച്ചാണ്. ഇതൊരു നീണ്ട ലേഖനമാണ്, അതിനാൽ സ്വയം സുഖകരമാക്കുക.

ഓരോ തന്ത്രവും ഉണ്ടാക്കുന്ന തെറ്റ് സഹിഷ്ണുത, സ്ഥിരത, ഉയർന്ന ലഭ്യത (HA) തന്ത്രങ്ങളും ട്രേഡ്ഓഫുകളും നോക്കാം. RabbitMQ നോഡുകളുടെ ഒരു ക്ലസ്റ്ററിൽ പ്രവർത്തിക്കാൻ കഴിയും - തുടർന്ന് ഒരു വിതരണ സംവിധാനമായി തരംതിരിക്കാം. വിതരണ സംവിധാനങ്ങളുടെ കാര്യം വരുമ്പോൾ, സ്ഥിരതയെയും ലഭ്യതയെയും കുറിച്ച് നമ്മൾ പലപ്പോഴും സംസാരിക്കാറുണ്ട്.

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

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

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

സിംഗിൾ നോഡ് റെസിലിയൻസ് പ്രിമിറ്റീവ്സ്

റെസിലന്റ് ക്യൂയിംഗ്/റൂട്ടിംഗ്

RabbitMQ-ൽ രണ്ട് തരം ക്യൂകളുണ്ട്: ഡ്യൂറബിൾ, നോൺ-ഡ്യൂറബിൾ. എല്ലാ ക്യൂകളും Mnesia ഡാറ്റാബേസിൽ സംരക്ഷിച്ചിരിക്കുന്നു. നോഡ് സ്റ്റാർട്ടപ്പിൽ ഡ്യൂറബിൾ ക്യൂകൾ വീണ്ടും പരസ്യപ്പെടുത്തുകയും അങ്ങനെ പുനരാരംഭിക്കലുകൾ, സിസ്റ്റം ക്രാഷുകൾ അല്ലെങ്കിൽ സെർവർ ക്രാഷുകൾ (ഡാറ്റ നിലനിൽക്കുന്നിടത്തോളം) അതിജീവിക്കുകയും ചെയ്യുന്നു. ഇതിനർത്ഥം നിങ്ങൾ റൂട്ടിംഗും (എക്‌സ്‌ചേഞ്ചും) ക്യൂവും പ്രതിരോധശേഷിയുള്ളതാണെന്ന് പ്രഖ്യാപിക്കുന്നിടത്തോളം, ക്യൂയിംഗ്/റൂട്ടിംഗ് ഇൻഫ്രാസ്ട്രക്ചർ ഓൺലൈനിൽ തിരിച്ചെത്തും.

നോഡ് പുനരാരംഭിക്കുമ്പോൾ അസ്ഥിരമായ ക്യൂകളും റൂട്ടിംഗും നീക്കം ചെയ്യപ്പെടും.

സ്ഥിരമായ സന്ദേശങ്ങൾ

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

അരി. 1. സുസ്ഥിരത മാട്രിക്സ്

ക്യൂ മിററിംഗ് ഉള്ള ക്ലസ്റ്ററിംഗ്

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

ക്യൂ മിററിംഗ്:

• എല്ലാ റൈറ്റ്, റീഡ് കമാൻഡുകളും സ്വീകരിക്കുന്ന ഒരു പ്രധാന ക്യൂ (മാസ്റ്റർ).
• പ്രധാന ക്യൂവിൽ നിന്ന് എല്ലാ സന്ദേശങ്ങളും മെറ്റാഡാറ്റയും സ്വീകരിക്കുന്ന ഒന്നോ അതിലധികമോ മിററുകൾ. ഈ കണ്ണാടികൾ സ്കെയിലിംഗിനുള്ളതല്ല, മറിച്ച് ആവർത്തനത്തിന് വേണ്ടിയുള്ളതാണ്.

അരി. 2. ക്യൂ മിററിംഗ്

മിററിംഗ് ഉചിതമായ നയമനുസരിച്ച് സജ്ജീകരിച്ചിരിക്കുന്നു. അതിൽ നിങ്ങൾക്ക് റെപ്ലിക്കേഷൻ കോഫിഫിഷ്യന്റും ക്യൂ സ്ഥിതിചെയ്യേണ്ട നോഡുകളും പോലും തിരഞ്ഞെടുക്കാം. ഉദാഹരണങ്ങൾ:

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (ഒരു യജമാനനും ഒരു കണ്ണാടിയും)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

പ്രസാധകന്റെ സ്ഥിരീകരണം

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

പരാജയ ക്യൂ

ഒരു ബ്രോക്കർ ജോലി ഉപേക്ഷിക്കുകയോ ക്രാഷ് ആകുകയോ ചെയ്യുമ്പോൾ, ആ നോഡിലെ എല്ലാ ക്യൂ ലീഡർമാരും (മാസ്റ്റർമാർ) അതോടൊപ്പം ക്രാഷ് ചെയ്യുന്നു. ക്ലസ്റ്റർ ഓരോ മാസ്റ്ററുടെയും ഏറ്റവും പഴയ മിറർ തിരഞ്ഞെടുത്ത് പുതിയ മാസ്റ്ററായി പ്രമോട്ട് ചെയ്യുന്നു.

അരി. 3. ഒന്നിലധികം മിറർ ചെയ്ത ക്യൂകളും അവയുടെ നയങ്ങളും

ബ്രോക്കർ 3 കുറയുന്നു. ബ്രോക്കർ 2-ലെ ക്യൂ സി മിറർ മാസ്റ്ററായി പ്രമോട്ടുചെയ്യുന്നു എന്നത് ശ്രദ്ധിക്കുക. ബ്രോക്കർ 1-ൽ ക്യൂ C-യ്‌ക്കായി ഒരു പുതിയ മിറർ സൃഷ്‌ടിച്ചിരിക്കുന്നു എന്നതും ശ്രദ്ധിക്കുക. RabbitMQ എപ്പോഴും നിങ്ങളുടെ നയങ്ങളിൽ വ്യക്തമാക്കിയിട്ടുള്ള പകർപ്പെടുക്കൽ ഘടകം നിലനിർത്താൻ ശ്രമിക്കുന്നു.

അരി. 4. ബ്രോക്കർ 3 പരാജയപ്പെടുന്നു, ക്യൂ സി പരാജയപ്പെടുന്നതിന് കാരണമാകുന്നു

അടുത്ത ബ്രോക്കർ 1 വീഴുന്നു! ഞങ്ങൾക്ക് ഒരു ബ്രോക്കർ മാത്രമേ അവശേഷിക്കുന്നുള്ളൂ. ക്യൂ ബി മിറർ മാസ്റ്ററായി പ്രമോട്ട് ചെയ്യുന്നു.

ചിത്രം. 5

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

ഈ സാഹചര്യത്തിൽ, ഡാറ്റ പോലെ ബ്രോക്കർ 1 ന്റെ നഷ്ടം പൂർത്തിയായി, അതിനാൽ മിറർ ചെയ്യാത്ത ക്യൂ ബി പൂർണ്ണമായും നഷ്ടപ്പെട്ടു.

അരി. 6. ബ്രോക്കർ 1 സേവനത്തിലേക്ക് മടങ്ങുന്നു

ബ്രോക്കർ 3 വീണ്ടും ഓൺലൈനായി, അതിനാൽ A, B ക്യൂകൾ അവരുടെ HA നയങ്ങൾ തൃപ്തിപ്പെടുത്താൻ അതിൽ സൃഷ്‌ടിച്ച മിററുകൾ തിരികെ ലഭിക്കും. എന്നാൽ ഇപ്പോൾ എല്ലാ പ്രധാന ക്യൂകളും ഒരു നോഡിലാണ്! ഇത് അനുയോജ്യമല്ല, നോഡുകൾക്കിടയിൽ തുല്യമായ വിതരണമാണ് നല്ലത്. നിർഭാഗ്യവശാൽ, മാസ്റ്റേഴ്സിനെ പുനഃസന്തുലിതമാക്കുന്നതിന് ഇവിടെ കൂടുതൽ ഓപ്ഷനുകൾ ഇല്ല. ക്യൂ സിൻക്രൊണൈസേഷൻ ആദ്യം നോക്കേണ്ടതിനാൽ ഞങ്ങൾ പിന്നീട് ഈ പ്രശ്നത്തിലേക്ക് മടങ്ങിവരും.

അരി. 7. ബ്രോക്കർ 3 സേവനത്തിലേക്ക് മടങ്ങുന്നു. എല്ലാ പ്രധാന ക്യൂകളും ഒരു നോഡിൽ!

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

സമന്വയിപ്പിക്കുക

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

ഈ സമന്വയം സ്വയമേവയോ സ്വമേധയായോ നിർവ്വഹിക്കുന്നു കൂടാതെ ഒരു ക്യൂ നയം ഉപയോഗിച്ചാണ് ഇത് കൈകാര്യം ചെയ്യുന്നത്. നമുക്ക് ഒരു ഉദാഹരണം നോക്കാം.

ഞങ്ങൾക്ക് രണ്ട് മിറർ ക്യൂകളുണ്ട്. ക്യൂ എ സ്വയമേ സമന്വയിപ്പിക്കപ്പെടുന്നു, ക്യൂ ബി സ്വമേധയാ സമന്വയിപ്പിക്കുന്നു. രണ്ട് ക്യൂകളിലും പത്ത് സന്ദേശങ്ങൾ അടങ്ങിയിരിക്കുന്നു.

അരി. 8. വ്യത്യസ്ത സിൻക്രൊണൈസേഷൻ മോഡുകളുള്ള രണ്ട് ക്യൂകൾ

ഇപ്പോൾ നമുക്ക് ബ്രോക്കർ 3 നഷ്ടപ്പെടുന്നു.

അരി. 9. ബ്രോക്കർ 3 വീണു

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

അരി. 10. ക്യൂ എയുടെ പുതിയ മിററിന് നിലവിലുള്ള എല്ലാ സന്ദേശങ്ങളും ലഭിക്കുന്നു, എന്നാൽ ക്യൂ ബിയുടെ പുതിയ മിററിന് ലഭിക്കുന്നില്ല.

രണ്ട് ക്യൂവിലും പത്ത് സന്ദേശങ്ങൾ കൂടി വരുന്നു. തുടർന്ന് ബ്രോക്കർ 2 ക്രാഷാകുകയും ക്യൂ എ ബ്രോക്കർ 1-ൽ ഉള്ള ഏറ്റവും പഴയ മിററിലേക്ക് മടങ്ങുകയും ചെയ്യുന്നു. പരാജയപ്പെടുമ്പോൾ ഡാറ്റ നഷ്‌ടമാകില്ല. ബി ക്യൂവിൽ, മാസ്റ്ററിൽ ഇരുപത് സന്ദേശങ്ങളും കണ്ണാടിയിൽ പത്ത് സന്ദേശങ്ങളും മാത്രമാണുള്ളത്, കാരണം ഈ ക്യൂ യഥാർത്ഥ പത്ത് സന്ദേശങ്ങൾ പകർത്തിയിട്ടില്ല.

അരി. 11. സന്ദേശങ്ങൾ നഷ്‌ടപ്പെടാതെ ക്യൂ എ ബ്രോക്കർ 1-ലേക്ക് തിരികെ പോകുന്നു

രണ്ട് ക്യൂവിലും പത്ത് സന്ദേശങ്ങൾ കൂടി വരുന്നു. ഇപ്പോൾ ബ്രോക്കർ 1 ക്രാഷാകുന്നു. സന്ദേശങ്ങൾ നഷ്‌ടപ്പെടാതെ ക്യൂ എ എളുപ്പത്തിൽ മിററിലേക്ക് മാറുന്നു. എന്നിരുന്നാലും, ബി ക്യൂവിൽ പ്രശ്നങ്ങൾ ഉണ്ട്. ഈ ഘട്ടത്തിൽ നമുക്ക് ലഭ്യതയോ സ്ഥിരതയോ ഒപ്റ്റിമൈസ് ചെയ്യാം.

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

അരി. 12. സന്ദേശങ്ങൾ നഷ്‌ടപ്പെടാതെ തന്നെ ക്യൂ എ ബ്രോക്കർ 3-ലേക്ക് തിരികെ കൊണ്ടുവരുന്നു. പത്ത് സന്ദേശങ്ങൾ നഷ്‌ടപ്പെട്ടതോടെ ക്യൂ ബി ബ്രോക്കർ 3-ലേക്ക് തിരികെ വരുന്നു

നമുക്കും ഇൻസ്റ്റാൾ ചെയ്യാം ha-promote-on-failure അർത്ഥത്തിലേക്ക് when-synced. ഈ സാഹചര്യത്തിൽ, മിററിലേക്ക് തിരികെ പോകുന്നതിനുപകരം, ബ്രോക്കർ 1 അതിന്റെ ഡാറ്റയുമായി ഓൺലൈൻ മോഡിലേക്ക് മടങ്ങുന്നത് വരെ ക്യൂ കാത്തിരിക്കും. അത് തിരിച്ചെത്തിയ ശേഷം, ഡാറ്റ നഷ്‌ടപ്പെടാതെ പ്രധാന ക്യൂ ബ്രോക്കർ 1-ൽ തിരിച്ചെത്തി. ഡാറ്റ സുരക്ഷയ്ക്കായി ലഭ്യത ബലികഴിക്കപ്പെടുന്നു. എന്നാൽ ഇത് അപകടസാധ്യതയുള്ള ഒരു മോഡാണ്, ഇത് പൂർണ്ണമായ ഡാറ്റ നഷ്‌ടത്തിലേക്ക് നയിച്ചേക്കാം, അത് ഞങ്ങൾ ഉടൻ നോക്കും.

അരി. 13. ബ്രോക്കർ 1 നഷ്‌ടപ്പെട്ടതിന് ശേഷം ക്യൂ ബി ലഭ്യമല്ല

"ഒരിക്കലും ഓട്ടോമാറ്റിക് സിൻക്രൊണൈസേഷൻ ഉപയോഗിക്കാതിരിക്കുന്നതാണോ നല്ലത്?" എന്ന് നിങ്ങൾ ചോദിച്ചേക്കാം. സമന്വയം ഒരു തടയൽ പ്രവർത്തനമാണ് എന്നതാണ് ഉത്തരം. സിൻക്രൊണൈസേഷൻ സമയത്ത്, പ്രധാന ക്യൂവിന് വായിക്കാനോ എഴുതാനോ ഉള്ള പ്രവർത്തനങ്ങളൊന്നും നടത്താൻ കഴിയില്ല!

നമുക്ക് ഒരു ഉദാഹരണം നോക്കാം. ഇപ്പോൾ ഞങ്ങൾക്ക് വളരെ നീണ്ട ക്യൂകളുണ്ട്. അവയ്‌ക്ക് എങ്ങനെ ഇത്രയും വലുപ്പത്തിൽ വളരാൻ കഴിയും? പല കാരണങ്ങളാൽ:

• ക്യൂകൾ സജീവമായി ഉപയോഗിക്കുന്നില്ല
• ഇവ ഹൈ-സ്പീഡ് ക്യൂകളാണ്, ഇപ്പോൾ ഉപഭോക്താക്കൾ മന്ദഗതിയിലാണ്
• ഇത് അതിവേഗ ക്യൂകളാണ്, ഒരു തകരാർ സംഭവിച്ചു, ഉപഭോക്താക്കൾ പിടിക്കുന്നു

അരി. 14. വ്യത്യസ്ത സിൻക്രൊണൈസേഷൻ മോഡുകളുള്ള രണ്ട് വലിയ ക്യൂകൾ

ഇപ്പോൾ ബ്രോക്കർ 3 വീഴുന്നു.

അരി. 15. ബ്രോക്കർ 3 വീഴുന്നു, ഓരോ ക്യൂവിലും ഒരു മാസ്റ്ററും കണ്ണാടിയും അവശേഷിക്കുന്നു

ബ്രോക്കർ 3 ഓൺലൈനിൽ തിരിച്ചെത്തുകയും പുതിയ മിററുകൾ സൃഷ്ടിക്കപ്പെടുകയും ചെയ്യുന്നു. പ്രധാന ക്യൂ A, നിലവിലുള്ള സന്ദേശങ്ങൾ പുതിയ മിററിലേക്ക് പകർത്താൻ തുടങ്ങുന്നു, ഈ സമയത്ത് ക്യൂ ലഭ്യമല്ല. ഡാറ്റ ആവർത്തിക്കാൻ രണ്ട് മണിക്കൂർ എടുക്കും, ഈ ക്യൂവിൽ രണ്ട് മണിക്കൂർ പ്രവർത്തനരഹിതമാകും!

എന്നിരുന്നാലും, ക്യൂ ബി മുഴുവൻ കാലയളവിലും ലഭ്യമാണ്. പ്രവേശനക്ഷമതയ്ക്കായി അവൾ ചില ആവർത്തനങ്ങൾ ത്യജിച്ചു.

അരി. 16. സിൻക്രൊണൈസേഷൻ സമയത്ത് ക്യൂ ലഭ്യമല്ല

രണ്ട് മണിക്കൂറിന് ശേഷം, ക്യൂ എയും ലഭ്യമാകും, കൂടാതെ വീണ്ടും വായനയും എഴുത്തും സ്വീകരിക്കാൻ തുടങ്ങാം.

അപ്ഡേറ്റുകൾ

സിൻക്രൊണൈസേഷൻ സമയത്ത് ഈ തടയൽ സ്വഭാവം വളരെ വലിയ ക്യൂകളുള്ള ക്ലസ്റ്ററുകൾ അപ്ഡേറ്റ് ചെയ്യുന്നത് ബുദ്ധിമുട്ടാക്കുന്നു. ചില ഘട്ടങ്ങളിൽ, മാസ്റ്റർ നോഡ് പുനരാരംഭിക്കേണ്ടതുണ്ട്, അതായത് ഒന്നുകിൽ മിററിലേക്ക് മാറുകയോ സെർവർ നവീകരിക്കുമ്പോൾ ക്യൂ പ്രവർത്തനരഹിതമാക്കുകയോ ചെയ്യുക. ഞങ്ങൾ സംക്രമണം തിരഞ്ഞെടുക്കുകയാണെങ്കിൽ, മിററുകൾ സമന്വയിപ്പിച്ചില്ലെങ്കിൽ ഞങ്ങൾക്ക് സന്ദേശങ്ങൾ നഷ്‌ടമാകും. ഡിഫോൾട്ടായി, ഒരു ബ്രോക്കർ ഔട്ടേജ് സമയത്ത്, ഒരു സമന്വയിപ്പിക്കാത്ത മിററിലേക്കുള്ള ഒരു പരാജയം നടപ്പിലാക്കില്ല. ഇതിനർത്ഥം, ബ്രോക്കർ തിരിച്ചെത്തിയാലുടൻ, ഞങ്ങൾക്ക് സന്ദേശങ്ങളൊന്നും നഷ്‌ടപ്പെടില്ല, കേടുപാടുകൾ ഒരു ലളിതമായ ക്യൂ മാത്രമായിരുന്നു. ഒരു ബ്രോക്കർ വിച്ഛേദിക്കപ്പെടുമ്പോൾ പെരുമാറ്റ നിയമങ്ങൾ നയമനുസരിച്ച് സജ്ജീകരിച്ചിരിക്കുന്നു ha-promote-on-shutdown. നിങ്ങൾക്ക് രണ്ട് മൂല്യങ്ങളിൽ ഒന്ന് സജ്ജമാക്കാൻ കഴിയും:

• always= സമന്വയിപ്പിക്കാത്ത മിററുകളിലേക്കുള്ള മാറ്റം പ്രവർത്തനക്ഷമമാക്കി
• when-synced= ഒരു സമന്വയിപ്പിച്ച മിററിലേക്ക് മാത്രം മാറുക, അല്ലാത്തപക്ഷം ക്യൂ വായിക്കാനാവാത്തതും എഴുതാൻ കഴിയാത്തതുമാണ്. ബ്രോക്കർ തിരിച്ചെത്തിയാലുടൻ ക്യൂ സേവനത്തിലേക്ക് മടങ്ങുന്നു

ഒരു തരത്തിൽ അല്ലെങ്കിൽ മറ്റൊന്ന്, വലിയ ക്യൂവിൽ നിങ്ങൾ ഡാറ്റ നഷ്‌ടത്തിനും ലഭ്യതയ്ക്കും ഇടയിൽ തിരഞ്ഞെടുക്കേണ്ടതുണ്ട്.

ലഭ്യത ഡാറ്റ സുരക്ഷ മെച്ചപ്പെടുത്തുമ്പോൾ

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

ഇവിടെ നിങ്ങൾ ഇനിപ്പറയുന്നവ പരിഗണിക്കേണ്ടതുണ്ട്:

• പ്രസാധകന് ഒരു പിശക് വരുത്തി അപ്‌സ്ട്രീം സേവനമോ ഉപയോക്താവോ പിന്നീട് വീണ്ടും ശ്രമിക്കാമോ?
• പിന്നീട് വീണ്ടും ശ്രമിക്കുന്നതിനായി പ്രസാധകന് സന്ദേശം പ്രാദേശികമായോ ഡാറ്റാബേസിലോ സംരക്ഷിക്കാനാകുമോ?

പ്രസാധകന് സന്ദേശം നിരസിക്കാൻ മാത്രമേ കഴിയൂ എങ്കിൽ, വാസ്തവത്തിൽ, പ്രവേശനക്ഷമത മെച്ചപ്പെടുത്തുന്നത് ഡാറ്റ സുരക്ഷയും മെച്ചപ്പെടുത്തുന്നു.

അതിനാൽ, ഒരു ബാലൻസ് തേടേണ്ടതുണ്ട്, കൂടാതെ പരിഹാരം നിർദ്ദിഷ്ട സാഹചര്യത്തെ ആശ്രയിച്ചിരിക്കുന്നു.

ha-promote-on-failure=when-synced എന്നതിലെ പ്രശ്നങ്ങൾ

ഐഡിയ ha-promote-on-failure= എപ്പോൾ-സമന്വയിപ്പിക്കുന്നു സമന്വയിപ്പിക്കാത്ത മിററിലേക്ക് മാറുന്നത് ഞങ്ങൾ തടയുകയും അതുവഴി ഡാറ്റാ നഷ്ടം ഒഴിവാക്കുകയും ചെയ്യുക എന്നതാണ്. ക്യൂ വായിക്കാനോ എഴുതാനോ കഴിയില്ല. പകരം, ക്രാഷ് ആയ ബ്രോക്കറെ അതിന്റെ ഡാറ്റ കേടുകൂടാതെ വീണ്ടെടുക്കാൻ ഞങ്ങൾ ശ്രമിക്കുന്നു, അതുവഴി ഡാറ്റ നഷ്‌ടപ്പെടാതെ തന്നെ അതിന് ഒരു മാസ്റ്ററായി പ്രവർത്തിക്കാൻ കഴിയും.

എന്നാൽ (ഇതൊരു വലിയ കാര്യമാണ്, പക്ഷേ) ബ്രോക്കറിന് അവന്റെ ഡാറ്റ നഷ്ടപ്പെട്ടാൽ, ഞങ്ങൾക്ക് ഒരു വലിയ പ്രശ്നമുണ്ട്: ക്യൂ നഷ്ടപ്പെട്ടു! എല്ലാ ഡാറ്റയും പോയി! പ്രധാന ക്യൂവിൽ കൂടുതലായി പിടിക്കുന്ന കണ്ണാടികൾ നിങ്ങളുടെ പക്കലുണ്ടെങ്കിൽപ്പോലും, ആ കണ്ണാടികളും ഉപേക്ഷിക്കപ്പെടും.

അതേ പേരിൽ ഒരു നോഡ് വീണ്ടും ചേർക്കുന്നതിന്, നഷ്ടപ്പെട്ട നോഡ് മറക്കാൻ ഞങ്ങൾ ക്ലസ്റ്ററിനോട് പറയുന്നു (കമാൻഡ് ഉപയോഗിച്ച് rabbitmqctl forget_cluster_node) കൂടാതെ അതേ ഹോസ്റ്റ് നാമത്തിൽ ഒരു പുതിയ ബ്രോക്കർ ആരംഭിക്കുക. ക്ലസ്റ്റർ നഷ്ടപ്പെട്ട നോഡ് ഓർക്കുമ്പോൾ, പഴയ ക്യൂവും സമന്വയിപ്പിക്കാത്ത മിററുകളും അത് ഓർക്കുന്നു. അനാഥമായ ഒരു നോഡ് മറക്കാൻ ഒരു ക്ലസ്റ്ററിനോട് പറയുമ്പോൾ, ആ ക്യൂവും മറക്കുന്നു. ഇപ്പോൾ നമുക്ക് അത് വീണ്ടും പ്രഖ്യാപിക്കേണ്ടതുണ്ട്. ഞങ്ങൾക്ക് ഒരു ഭാഗിക ഡാറ്റയുള്ള മിററുകൾ ഉണ്ടായിരുന്നെങ്കിലും ഞങ്ങൾക്ക് എല്ലാ ഡാറ്റയും നഷ്ടപ്പെട്ടു. സമന്വയിപ്പിക്കാത്ത കണ്ണാടിയിലേക്ക് മാറുന്നതാണ് നല്ലത്!

അതിനാൽ, മാനുവൽ സിൻക്രൊണൈസേഷൻ (ഒപ്പം സമന്വയിപ്പിക്കുന്നതിൽ പരാജയം) സംയുക്തമായി ha-promote-on-failure=when-synced, എന്റെ അഭിപ്രായത്തിൽ, തികച്ചും അപകടകരമാണ്. ഡാറ്റ സുരക്ഷയ്ക്കായി ഈ ഓപ്ഷൻ നിലവിലുണ്ടെന്ന് ഡോക്‌സ് പറയുന്നു, എന്നാൽ ഇത് ഇരുതല മൂർച്ചയുള്ള കത്തിയാണ്.

മാസ്റ്റർ റീബാലൻസിങ്

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

രണ്ട് കാരണങ്ങളാൽ മാസ്റ്റേഴ്സ് റീബാലൻസ് ചെയ്യുന്നത് പ്രശ്നമാകാം:

• റീബാലൻസിങ് നടത്താൻ നല്ല ടൂളുകളൊന്നുമില്ല
• ക്യൂ സിൻക്രൊണൈസേഷൻ

പുനഃസന്തുലിതമാക്കുന്നതിന് ഒരു മൂന്നാം കക്ഷിയുണ്ട് പ്ലഗിൻ, ഇത് ഔദ്യോഗികമായി പിന്തുണയ്ക്കുന്നില്ല. RabbitMQ മാനുവലിലെ മൂന്നാം കക്ഷി പ്ലഗിന്നുകളെക്കുറിച്ച് പറഞ്ഞു: “പ്ലഗിൻ ചില അധിക കോൺഫിഗറേഷനും റിപ്പോർട്ടിംഗ് ടൂളുകളും നൽകുന്നു, പക്ഷേ RabbitMQ ടീം പിന്തുണയ്ക്കുകയോ സ്ഥിരീകരിക്കുകയോ ചെയ്യുന്നില്ല. നിങ്ങളുടെ സ്വന്തം ഉത്തരവാദിത്തത്തിൽ ഉപയോഗിക്കുക."

HA പോളിസികളിലൂടെ പ്രധാന ക്യൂ നീക്കാൻ മറ്റൊരു തന്ത്രമുണ്ട്. മാനുവലിൽ പരാമർശിക്കുന്നു സ്ക്രിപ്റ്റ് ഇതിനായി. ഇത് ഇതുപോലെ പ്രവർത്തിക്കുന്നു:

• നിലവിലുള്ള എച്ച്എ നയത്തേക്കാൾ ഉയർന്ന മുൻഗണനയുള്ള ഒരു താൽക്കാലിക പോളിസി ഉപയോഗിച്ച് എല്ലാ മിററുകളും നീക്കംചെയ്യുന്നു.
• നോഡ് മോഡ് ഉപയോഗിക്കുന്നതിന് HA താൽക്കാലിക നയം മാറ്റുന്നു, മാസ്റ്റർ ക്യൂ ട്രാൻസ്ഫർ ചെയ്യേണ്ട നോഡ് വ്യക്തമാക്കുന്നു.
• പുഷ് മൈഗ്രേഷനുള്ള ക്യൂ സമന്വയിപ്പിക്കുന്നു.
• മൈഗ്രേഷൻ പൂർത്തിയായ ശേഷം, താൽക്കാലിക നയം ഇല്ലാതാക്കുന്നു. പ്രാരംഭ എച്ച്എ നയം പ്രാബല്യത്തിൽ വരികയും ആവശ്യമായ മിററുകൾ സൃഷ്ടിക്കപ്പെടുകയും ചെയ്യുന്നു.

നിങ്ങൾക്ക് വലിയ ക്യൂകളോ കർശനമായ ആവർത്തന ആവശ്യകതകളോ ഉണ്ടെങ്കിൽ ഈ സമീപനം പ്രവർത്തിക്കില്ല എന്നതാണ് ദോഷം.

നെറ്റ്‌വർക്ക് പാർട്ടീഷനുകളിൽ RabbitMQ ക്ലസ്റ്ററുകൾ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് ഇപ്പോൾ നോക്കാം.

കണക്റ്റിവിറ്റി നഷ്ടം

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

RabbitMQ ഉപയോഗിച്ച് ഞങ്ങൾക്ക് രണ്ട് പ്രധാന ഓപ്ഷനുകൾ ഉണ്ട്:

• ലോജിക്കൽ ഡിവിഷൻ (സ്പ്ലിറ്റ് ബ്രെയിൻ) അനുവദിക്കുക. ഇത് ലഭ്യത ഉറപ്പാക്കുന്നു, പക്ഷേ ഡാറ്റ നഷ്‌ടത്തിന് കാരണമായേക്കാം.
• ലോജിക്കൽ വേർതിരിക്കൽ പ്രവർത്തനരഹിതമാക്കുക. ക്ലസ്റ്ററിലേക്ക് ക്ലയന്റുകളെ എങ്ങനെ ബന്ധിപ്പിക്കുന്നു എന്നതിനെ ആശ്രയിച്ച്, ഹ്രസ്വകാല ലഭ്യത നഷ്ടപ്പെടാൻ ഇടയാക്കിയേക്കാം. രണ്ട്-നോഡ് ക്ലസ്റ്ററിൽ പൂർണ്ണമായ അസാന്നിധ്യത്തിനും കാരണമാകും.

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

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

പ്രസാധകർ രണ്ട് മാസ്റ്റർമാർക്കും ഡാറ്റ അയയ്‌ക്കുകയാണെങ്കിൽ, ക്യൂവിന്റെ രണ്ട് വ്യത്യസ്ത പകർപ്പുകൾ ഞങ്ങൾക്ക് ലഭിക്കും.

RabbitMQ-ന്റെ വ്യത്യസ്ത മോഡുകൾ ലഭ്യതയോ സ്ഥിരതയോ നൽകുന്നു.

മോഡ് അവഗണിക്കുക (സ്ഥിരസ്ഥിതി)

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

അരി. 18. മൂന്ന് പ്രസാധകർ മൂന്ന് ബ്രോക്കർമാരുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു. ആന്തരികമായി, ക്ലസ്റ്റർ എല്ലാ അഭ്യർത്ഥനകളും ബ്രോക്കർ 2 ലെ പ്രധാന ക്യൂവിലേക്ക് നയിക്കുന്നു.

ഇപ്പോൾ നമുക്ക് ബ്രോക്കർ 3 നഷ്‌ടപ്പെടുകയാണ്. മറ്റ് ബ്രോക്കർമാർ വീണുപോയതായി അവൻ കാണുകയും തന്റെ കണ്ണാടിയെ മാസ്റ്ററിലേക്ക് പ്രമോട്ട് ചെയ്യുകയും ചെയ്യുന്നു. ഒരു ലോജിക്കൽ വേർതിരിവ് സംഭവിക്കുന്നത് ഇങ്ങനെയാണ്.

അരി. 19. ലോജിക്കൽ ഡിവിഷൻ (പിളർപ്പ്-മസ്തിഷ്കം). രേഖകൾ രണ്ട് പ്രധാന ക്യൂകളിലേക്ക് പോകുന്നു, രണ്ട് പകർപ്പുകളും വ്യതിചലിക്കുന്നു.

കണക്റ്റിവിറ്റി പുനഃസ്ഥാപിച്ചു, പക്ഷേ ലോജിക്കൽ വേർതിരിവ് അവശേഷിക്കുന്നു. അഡ്‌മിനിസ്‌ട്രേറ്റർ നഷ്‌ടപ്പെടുന്ന വശം സ്വമേധയാ തിരഞ്ഞെടുക്കണം. ചുവടെയുള്ള സാഹചര്യത്തിൽ, അഡ്‌മിനിസ്‌ട്രേറ്റർ ബ്രോക്കർ 3 റീബൂട്ട് ചെയ്യുന്നു. അദ്ദേഹത്തിന് കൈമാറാൻ കഴിയാത്ത എല്ലാ സന്ദേശങ്ങളും നഷ്‌ടമായി.

അരി. 20. അഡ്മിനിസ്ട്രേറ്റർ ബ്രോക്കർ 3 പ്രവർത്തനരഹിതമാക്കുന്നു.

അരി. 21. അഡ്മിനിസ്ട്രേറ്റർ ബ്രോക്കർ 3 ആരംഭിക്കുന്നു, അത് ക്ലസ്റ്ററിൽ ചേരുന്നു, അവിടെ അവശേഷിക്കുന്ന എല്ലാ സന്ദേശങ്ങളും നഷ്‌ടപ്പെടും.

കണക്റ്റിവിറ്റി നഷ്‌ടമായ സമയത്തും അത് പുനഃസ്ഥാപിച്ചതിന് ശേഷവും, ക്ലസ്റ്ററും ഈ ക്യൂവും വായിക്കാനും എഴുതാനും ലഭ്യമായിരുന്നു.

ഓട്ടോഹീൽ മോഡ്

ഇഗ്നോർ മോഡിന് സമാനമായി പ്രവർത്തിക്കുന്നു, കണക്റ്റിവിറ്റി വിഭജിച്ച് പുനഃസ്ഥാപിച്ചതിന് ശേഷം ക്ലസ്റ്റർ സ്വയം നഷ്ടപ്പെടുന്ന വശം തിരഞ്ഞെടുക്കുന്നു എന്നതൊഴിച്ചാൽ. നഷ്‌ടപ്പെടുന്ന വശം ശൂന്യമായി ക്ലസ്റ്ററിലേക്ക് മടങ്ങുന്നു, ആ ഭാഗത്തേക്ക് മാത്രം അയച്ച എല്ലാ സന്ദേശങ്ങളും ക്യൂവിന് നഷ്‌ടമാകും.

ന്യൂനപക്ഷ മോഡ് താൽക്കാലികമായി നിർത്തുക

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

അരി. 22. മൂന്ന് പ്രസാധകർ മൂന്ന് ബ്രോക്കർമാരുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു. ആന്തരികമായി, ക്ലസ്റ്റർ എല്ലാ അഭ്യർത്ഥനകളും ബ്രോക്കർ 2 ലെ പ്രധാന ക്യൂവിലേക്ക് നയിക്കുന്നു.

ബ്രോക്കർമാർ 1 ഉം 2 ഉം പിന്നീട് ബ്രോക്കർ 3 ൽ നിന്ന് വേർപിരിഞ്ഞു. അവരുടെ മിറർ മാസ്റ്ററായി പ്രമോട്ട് ചെയ്യുന്നതിനുപകരം, ബ്രോക്കർ 3 താൽക്കാലികമായി നിർത്തി, ലഭ്യമല്ലാതാകുന്നു.

അരി. 23. ബ്രോക്കർ 3 താൽക്കാലികമായി നിർത്തുന്നു, എല്ലാ ക്ലയന്റുകളേയും വിച്ഛേദിക്കുന്നു, കണക്ഷൻ അഭ്യർത്ഥനകൾ നിരസിക്കുന്നു.

കണക്റ്റിവിറ്റി പുനഃസ്ഥാപിച്ചുകഴിഞ്ഞാൽ, അത് ക്ലസ്റ്ററിലേക്ക് മടങ്ങുന്നു.

പ്രധാന ക്യൂ ബ്രോക്കർ 3-ൽ ഉള്ള മറ്റൊരു ഉദാഹരണം നോക്കാം.

അരി. 24. ബ്രോക്കർ 3-ലെ പ്രധാന ക്യൂ.

അപ്പോൾ കണക്ടിവിറ്റിയുടെ അതേ നഷ്ടം സംഭവിക്കുന്നു. ബ്രോക്കർ 3 താൽക്കാലികമായി നിർത്തുന്നു, കാരണം അത് ചെറിയ ഭാഗത്താണ്. മറുവശത്ത്, ബ്രോക്കർ 3 വീണുപോയതായി നോഡുകൾ കാണുന്നു, അതിനാൽ ബ്രോക്കർമാരുടെ 1, 2 എന്നിവയിൽ നിന്നുള്ള പഴയ മിറർ മാസ്റ്ററായി പ്രമോട്ടുചെയ്യപ്പെടുന്നു.

അരി. 25. ബ്രോക്കർ 2 ലഭ്യമല്ലെങ്കിൽ ബ്രോക്കർ 3 ലേക്കുള്ള മാറ്റം.

കണക്റ്റിവിറ്റി പുനഃസ്ഥാപിക്കുമ്പോൾ, ബ്രോക്കർ 3 ക്ലസ്റ്ററിൽ ചേരും.

അരി. 26. ക്ലസ്റ്റർ സാധാരണ പ്രവർത്തനത്തിലേക്ക് മടങ്ങി.

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

ലഭ്യത ഉറപ്പാക്കാൻ, ക്ലയന്റുകൾ ഹോസ്റ്റിലേക്ക് വിജയകരമായി കണക്റ്റുചെയ്യുന്നുവെന്ന് ഉറപ്പാക്കേണ്ടത് പ്രധാനമാണ്. നമ്മുടെ ഓപ്ഷനുകൾ നോക്കാം.

കസ്റ്റമർ കണക്റ്റിവിറ്റി ഉറപ്പാക്കുന്നു

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

ഞങ്ങളുടെ ഓപ്ഷനുകൾ:

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

കണ്ടെത്തലുകൾ

RabbitMQ ക്ലസ്റ്ററിംഗിന് അതിന്റെ ഗുണങ്ങളും ദോഷങ്ങളുമുണ്ട്. ഏറ്റവും ഗുരുതരമായ പോരായ്മകൾ ഇവയാണ്:

• ഒരു ക്ലസ്റ്ററിൽ ചേരുമ്പോൾ, നോഡുകൾ അവയുടെ ഡാറ്റ ഉപേക്ഷിക്കുന്നു;
• സമന്വയം തടയുന്നത് ക്യൂ ലഭ്യമല്ലാതാക്കുന്നു.

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

• വിശ്വസനീയമല്ലാത്ത നെറ്റ്‌വർക്ക്.
• വിശ്വസനീയമല്ലാത്ത സംഭരണം.
• വളരെ നീണ്ട ക്യൂകൾ.

ഉയർന്ന ലഭ്യത ക്രമീകരണങ്ങൾ വരുമ്പോൾ, ഇനിപ്പറയുന്നവ പരിഗണിക്കുക:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (അല്ലെങ്കിൽ autoheal)
• സ്ഥിരമായ സന്ദേശങ്ങൾ
• ചില നോഡ് പരാജയപ്പെടുമ്പോൾ ക്ലയന്റുകൾ സജീവ നോഡിലേക്ക് കണക്റ്റുചെയ്യുന്നുവെന്ന് ഉറപ്പാക്കുക

സ്ഥിരതയ്ക്കായി (ഡാറ്റ സുരക്ഷ), ഇനിപ്പറയുന്ന ക്രമീകരണങ്ങൾ പരിഗണിക്കുക:

• പ്രസാധകൻ സ്ഥിരീകരിക്കുകയും ഉപഭോക്തൃ വശത്ത് മാനുവൽ അംഗീകാരം നൽകുകയും ചെയ്യുന്നു
• ha-promote-on-failure=when-synced, പ്രസാധകർക്ക് പിന്നീട് വീണ്ടും ശ്രമിക്കാനാകുമെങ്കിൽ, നിങ്ങൾക്ക് വളരെ വിശ്വസനീയമായ സ്റ്റോറേജ് ഉണ്ടെങ്കിൽ! അല്ലെങ്കിൽ ഇടുക =always.
• ha-sync-mode=automatic (പക്ഷേ, വലിയ നിഷ്ക്രിയ ക്യൂകൾക്ക്, മാനുവൽ മോഡ് ആവശ്യമായി വന്നേക്കാം; കൂടാതെ, ലഭ്യതയില്ലായ്മ സന്ദേശങ്ങൾ നഷ്‌ടപ്പെടാൻ ഇടയാക്കുമോ എന്ന് പരിഗണിക്കുക)
• ന്യൂനപക്ഷ മോഡ് താൽക്കാലികമായി നിർത്തുക
• സ്ഥിരമായ സന്ദേശങ്ങൾ

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

എനിക്ക് മറ്റെന്തെങ്കിലും നഷ്‌ടമായിട്ടുണ്ടെങ്കിൽ, ദയവായി എന്നെ അറിയിക്കുക.

എന്റെയും കാണുക ഒരു പോസ്റ്റ്, ഈ ലേഖനത്തിൽ വിവരിച്ചിരിക്കുന്ന ചില സന്ദേശ നഷ്‌ട സാഹചര്യങ്ങൾ പരിശോധിക്കുന്നതിന് ഡോക്കറും ബ്ലോക്ക്‌ഡേഡും ഉപയോഗിച്ച് ഞാൻ റാബിറ്റ്എംക്യു ക്ലസ്റ്ററിൽ ഒരു നാശം വരുത്തുന്നു.

പരമ്പരയിലെ മുൻ ലേഖനങ്ങൾ:
നമ്പർ 1 - habr.com/ru/company/itsumma/blog/416629
നമ്പർ 2 - habr.com/ru/company/itsumma/blog/418389
നമ്പർ 3 - habr.com/ru/company/itsumma/blog/437446

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