മൾട്ടി-റീജിയൻ എഴുത്ത്: കമ്മിറ്റ് യഥാർത്ഥത്തിൽ എവിടെ എത്തുന്നു?
റൂട്ടിംഗ് ഒരു അഭ്യർത്ഥനയെ ഒരു റീജിയനിലേക്ക് എത്തിക്കുന്നു; എഴുത്തിനെ ആറ്റോമിക് ആക്കുന്നത് ട്രാൻസാക്ഷൻ അതിർത്തി മാത്രമാണ്. ഇൻവേരിയന്റ് പേരിടുക, ഉടമയെ തിരഞ്ഞെടുക്കുക, പിന്നെ അതിനു ചുറ്റും വീണ്ടും ശ്രമം രൂപകല്പന ചെയ്യുക.
രണ്ട് റീജിയനുകളിൽ രണ്ട് ആപ്ലിക്കേഷൻ സെർവറുകൾ, VPN വഴി എഴുതുന്ന ഒരു ക്ലയന്റ്, ആരും എഴുതിവയ്ക്കാത്ത ഒരു ചോദ്യം: എഴുത്ത് സംഭവിച്ചു എന്ന് ഏത് ഘടകമാണ് തീരുമാനിക്കുന്നത്? റൂട്ടിംഗ് അഭ്യർത്ഥനയെ ഒരു പ്രോസസ്സിലേക്ക് എത്തിക്കുന്നു. ട്രാൻസാക്ഷൻ അതിർത്തി മാറ്റം എപ്പോൾ സ്ഥിരവും ദൃശ്യവുമാകുന്നു എന്ന് തീരുമാനിക്കുന്നു. ഇവ വ്യത്യസ്ത സിസ്റ്റങ്ങൾ ചെയ്യുന്ന വ്യത്യസ്ത ജോലികളാണ്, അവയ്ക്കിടയിലുള്ള വിടവാണ് മിക്ക മൾട്ടി-റീജിയൻ എഴുത്ത് ബഗ്ഗുകളും കഴിയുന്നിടം.
ഭൂപടത്തിൽ നിന്നല്ല, ബിസിനസ് നിയമത്തിൽ നിന്ന് തുടങ്ങുക
ഭൂമിശാസ്ത്രത്തെക്കുറിച്ചല്ല, ബിസിനസ് നിയമത്തെക്കുറിച്ചുള്ള ഒരു വാക്യത്തിൽ തുടങ്ങുക: ഏത് വായനകളും എഴുത്തുകളും ഒരുമിച്ച് വിജയിക്കണം, അത് നടക്കുമ്പോൾ ഏത് ഏകകാലിക മാറ്റങ്ങൾ അസാധ്യമായിരിക്കണം. ഇൻവെന്ററി റിസർവേഷനിൽ അതിന്റെ അർത്ഥം സ്റ്റോക്ക് പരിശോധനയും റിസർവേഷനും ഒരുമിച്ച് പ്രാബല്യത്തിൽ വരുന്നു അല്ലെങ്കിൽ ഒന്നും വരുന്നില്ല, ഇടയ്ക്ക് മറ്റൊരു ഓർഡറിനും അതേ യൂണിറ്റ് ഉപയോഗിക്കാൻ പാടില്ല എന്നാണ്.
| Requirement | What satisfies it | What does not |
|---|---|---|
| All-or-nothing application | A transaction inside one owning system | A VPN path between regions |
| No double spend | Isolation strong enough to exclude the conflict | Atomicity alone |
| Survive a region loss | Replication the database itself documents | Two independent databases behind one client |
ടീമുകൾ ഒഴിവാക്കുന്നത് അതേ മധ്യവരിയാണ്. മതിയായ ഐസൊലേഷൻ ഇല്ലാത്ത ആറ്റോമിസിറ്റി രണ്ട് ട്രാൻസാക്ഷനുകൾക്ക് ഓരോന്നും ശരിയായി കമ്മിറ്റ് ചെയ്യാൻ അനുവദിക്കുന്നു, എന്നിട്ടും ബിസിനസ് അസാധ്യമെന്ന് കരുതുന്ന ഒരു അവസ്ഥ സൃഷ്ടിക്കുന്നു, പിന്നീട് ഏത് വീണ്ടും ശ്രമ യുക്തിയും അത് ശരിയാക്കുന്നില്ല.
ഒരു അധികാര അതിർത്തി രണ്ട് പ്രാദേശിക സെർവറുകളെ തോൽപ്പിക്കുന്നു
പ്രാദേശിക ആപ്ലിക്കേഷൻ സെർവറുകൾക്ക് അവയുള്ളിടത്ത് തന്നെ തുടരാം, പക്ഷേ പ്രവർത്തനം ഒരു പിന്തുണയുള്ള ട്രാൻസാക്ഷൻ അതിർത്തിക്കുള്ളിൽ നിർവഹിക്കുന്ന ഒരു സേവനത്തിന് സമർപ്പിക്കണം. ആപ്ലിക്കേഷൻ പാളി ഉദ്ദേശ്യത്തിന്റെ റൂട്ടറാകുന്നു; ഡാറ്റാ പാളി സത്യം കൈവശം വയ്ക്കുന്നു.
ആ അതിർത്തി ചെറുതായി, അത് തൊടുന്ന ഡാറ്റയ്ക്ക് അടുത്തായി നിലനിർത്തുക. ഒരു മനുഷ്യൻ സൂചനയ്ക്ക് മറുപടി നൽകുമ്പോൾ, അല്ലെങ്കിൽ ഒരു കോൾ രണ്ട് റീജിയനുകളെ മുറിച്ചുകടക്കുമ്പോൾ, തുറന്നിരിക്കുന്ന ട്രാൻസാക്ഷൻ അതിന്റെ സമയം ലോക്കുകൾ പിടിച്ചുനിർത്തുന്നതിൽ ചെലവഴിക്കുന്നു, അതിനു പിന്നിൽ മറ്റെന്തെങ്കിലും സമയപരിധി കഴിയാനുള്ള സാധ്യത വർദ്ധിപ്പിക്കുന്നു. ആ പരാജയം ഒരു ഡാറ്റാബേസ് പ്രശ്നമായി തോന്നുന്നു, യഥാർത്ഥത്തിൽ അങ്ങനെ വേഷമിട്ട ഒരു ഡിസൈൻ പ്രശ്നമാണ്. തീരുമാനം ഡാറ്റാ പാളിയിലേക്ക് മാറ്റുന്നത് സാധാരണയായി അതിനെ പൂർണ്ണമായി ഇല്ലാതാക്കുന്നു.
BEGIN;
UPDATE inventory SET reserved = reserved + 1
WHERE sku = 'A-100' AND available >= 1;
INSERT INTO reservation (sku, order_id) VALUES ('A-100', 'ord-9f');
COMMIT;ആ രേഖാചിത്രം ഒരു അതിർത്തിയായി വായിക്കുക, പ്രകടന ശുപാർശയായി അല്ല. കാര്യം, പരിശോധനയും ചേർക്കലും ഒരു കമ്മിറ്റ് പങ്കിടുന്നു എന്നതാണ്, അതിനാൽ ഏകകാലിക ഓർഡർ സ്റ്റോക്ക് ഉപയോഗിച്ചതായി കാണുന്നു അല്ലെങ്കിൽ ഒട്ടും കാണുന്നില്ല.
റെപ്ലിക്കേറ്റ് ചെയ്ത ഡാറ്റാബേസ് എന്ത് നൽകുന്നു, എന്ത് നൽകുന്നില്ല
അതിന്റെ സ്വന്തം ട്രാൻസാക്ഷൻ മാതൃക പിന്തുണയ്ക്കുമ്പോൾ റെപ്ലിക്കേറ്റ് ചെയ്ത ഡാറ്റാബേസിന് വിശാലമായ അതിർത്തി നൽകാനാകും. Spanner ഒരു ഡാറ്റാബേസിനുള്ളിൽ പട്ടികകളിലായി ആറ്റോമിക് വായന-എഴുത്ത് ട്രാൻസാക്ഷനുകൾ, നിർവചിക്കപ്പെട്ട ഐസൊലേഷനും വീണ്ടും ശ്രമ സ്വഭാവവും സഹിതം രേഖപ്പെടുത്തുന്നു. അത് നിങ്ങൾ വായിക്കുകയും പരീക്ഷിക്കുകയും ബോധപൂർവം ആശ്രയിക്കുകയും ചെയ്യുന്ന ഒരു ഉറപ്പാണ്.
അത് ഉൽപ്പന്നത്തിൽ നിന്ന് വരുന്ന ഉറപ്പുമാണ്, പാതയിൽ നിന്നല്ല. റീജിയനുകൾക്കിടയിലുള്ള VPN പാക്കറ്റുകൾ എങ്ങനെ സഞ്ചരിക്കുന്നു, പരാജയങ്ങൾ എങ്ങനെ പ്രത്യക്ഷപ്പെടുന്നു എന്നത് മാറ്റുന്നു. ടണൽ എത്ര ആരോഗ്യമുള്ളതായി തോന്നിയാലും അത് ട്രാൻസാക്ഷൻ അതിർത്തി ഒരു വരി പോലും വിപുലീകരിക്കുന്നില്ല. രണ്ടും കൂട്ടിക്കുഴയ്ക്കുന്നത് ഓരോ ഘടകവും സ്വന്തം പരിശോധന പാസാകുന്ന, എന്നിട്ടും ഡാറ്റ ഒത്തുപോകാത്ത ആർക്കിടെക്ചറുകൾ സൃഷ്ടിക്കുന്നു.
രണ്ട് ഡാറ്റാബേസുകൾ ഒരു സിസ്റ്റമാകുന്നില്ല
സ്വതന്ത്രമായി കൈകാര്യം ചെയ്യുന്ന രണ്ട് ഡാറ്റാബേസുകൾ ക്ലയന്റുകൾക്ക് രണ്ടിലേക്കും എത്താം എന്ന കാരണം കൊണ്ട് പങ്കിട്ട ട്രാൻസാക്ഷൻ മാനേജർ നേടുന്നില്ല. ബിസിനസിന് യഥാർത്ഥത്തിൽ ആ ജോടിക്ക് കുറുകെ ആറ്റോമിക് പ്രതിബദ്ധത വേണമെങ്കിൽ, ഏകോപന സംവിധാനവും പങ്കാളികളും വീണ്ടെടുപ്പ് പ്രക്രിയയും ഊഹിക്കാതെ തിരഞ്ഞെടുത്ത് യോഗ്യമാക്കണം.
ജോലി തയ്യാറാക്കിയതിന് ശേഷം ഒരു പങ്കാളിയോ ലിങ്കോ അപ്രത്യക്ഷമാകുന്ന നിമിഷം ചിന്തിക്കുക. പിന്തുണയുള്ള വിതരണ കമ്മിറ്റ് വീണ്ടെടുപ്പ് നടപടിക്രമവും മനുഷ്യ തീരുമാനവും ആവശ്യമുള്ള ഒരു അനിശ്ചിതാവസ്ഥ അവശേഷിപ്പിക്കാം, ഓരോ വിഭജനത്തിലും ഓരോ റീജിയനും എഴുതാവുന്നതായി തുടരുമെന്ന വാഗ്ദാനം അതിനൊപ്പം വരുന്നില്ല.
പകരം അസമകാലിക ഏകോപനം സ്വീകാര്യമെങ്കിൽ, അത് വ്യക്തമായി പറഞ്ഞ് ഇടക്കാല ബിസിനസ് അവസ്ഥകളും പൊരുത്തപ്പെടുത്തൽ നിയമങ്ങളും എഴുതിവയ്ക്കുക. നഷ്ടപരിഹാരത്തോടെ പ്രാദേശികമായി കമ്മിറ്റ് ചെയ്ത ഘട്ടങ്ങളുടെ ശൃംഖല സാധുവായ രൂപകല്പനയാണ്; അത് മറ്റൊരു പേരിലുള്ള ഒരു ആറ്റോമിക് ട്രാൻസാക്ഷൻ മാത്രമല്ല.
ആദ്യ തകരാറിന് മുമ്പേ വീണ്ടും ശ്രമം രൂപകല്പന ചെയ്യുക
പ്രവർത്തനം കമ്മിറ്റ് ചെയ്തതിന് ശേഷം ക്ലയന്റിന് പ്രതികരണം നഷ്ടപ്പെടാം, അതിനാൽ വിളിക്കുന്നയാൾക്ക് സമയപരിധി പരാജയമായി കാണാനാവില്ല. ദീർഘകാല അഭ്യർത്ഥന ഐഡന്റിറ്റി സംരക്ഷിക്കുക, മാറ്റം വീണ്ടും ശ്രമിക്കുന്നതിന് മുമ്പ് സേവന ഫലമോ ഐഡംപൊട്ടൻസി സംവിധാനമോ ഉപയോഗിക്കുക, അല്ലെങ്കിൽ വീണ്ടും ശ്രമം രണ്ടാമത്തെ എഴുത്തായി മാറും.
സ്വയമേവയുള്ള ട്രാൻസാക്ഷൻ കോൾബാക്കുകൾ വീണ്ടും ശ്രമിക്കാവുന്ന റദ്ദാക്കലിന് ശേഷം ഒരു തവണയിൽ കൂടുതൽ പ്രവർത്തിച്ചേക്കാം, ഇത് മാറ്റാനാവാത്ത ബാഹ്യ ഫലങ്ങൾക്ക് അവയെ മോശം വീടാക്കുന്നു. വർക്ക്ഫ്ലോ അവയ്ക്ക് വ്യക്തമായ സുരക്ഷിത പ്രോട്ടോക്കോൾ നിർവചിക്കാത്ത പക്ഷം അവ കോൾബാക്കിന് പുറത്ത് നിർത്തുക. പണം ചെലവാക്കുന്നതോ സന്ദേശം അയയ്ക്കുന്നതോ ആയ എല്ലാത്തിനും അതേ മുൻകരുതൽ ബാധകമാണ്. ഇരട്ട നിരക്ക് ഇരട്ട ലോഗ് വരിയെക്കാൾ ഏറെ ബുദ്ധിമുട്ടുള്ള സംഭാഷണമാണ്.
സ്വീകാര്യത നാല് സാഹചര്യങ്ങൾ വീണ്ടും പ്രവർത്തിപ്പിക്കണം: ഒരേ വരിക്കായി മത്സരിക്കുന്ന രണ്ട് ക്ലയന്റുകൾ, സേവനം വീണ്ടും ശ്രമിക്കാവുന്നതെന്ന് പറയുന്ന റദ്ദാക്കൽ, ഉത്തരം ഒരിക്കലും എത്താത്ത കമ്മിറ്റ്, ഒരു റീജിയനോ അവയ്ക്കിടയിലുള്ള ലിങ്കോ നഷ്ടപ്പെടുന്നത്. കമ്മിറ്റ് ചെയ്ത ബിസിനസ് ഫലവും പരിഹരിക്കാത്ത അവസ്ഥകളും റൂട്ടിംഗ് രൂപകല്പനയ്ക്കൊപ്പം രേഖപ്പെടുത്തുക, ആരും നെറ്റ്വർക്കിനെ ഉറപ്പ് നൽകുന്ന ഘടകമായി തെറ്റിദ്ധരിക്കാതിരിക്കാൻ.