കാഫ്കയിൽ ഒരു അസിൻക്രണസ് API ഉപയോഗിച്ച് റീഫണ്ട് ടൂൾ സേവനം വികസിപ്പിക്കുന്നതിൽ അനുഭവപരിചയം

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

എന്നാൽ നിങ്ങൾക്ക് അധിക ആനുകൂല്യങ്ങൾ കണക്കാക്കാൻ കഴിയില്ലെന്ന് ഇതിനർത്ഥമില്ല. കാഫ്കയിൽ ഇവന്റുകൾ അടിസ്ഥാനമാക്കിയുള്ള API നടപ്പിലാക്കിയാൽ നിങ്ങൾക്ക് കൃത്യമായി എന്താണ് വിജയിക്കാനാകുക എന്ന് സെർജി സൈക്ക നിങ്ങളോട് പറയും (കുറച്ച്). വലിയ ഷോട്ടുകളെക്കുറിച്ചും രസകരമായ കണ്ടെത്തലുകളെക്കുറിച്ചും തീർച്ചയായും സംസാരിക്കും - അവയില്ലാതെ പരീക്ഷണം ചെയ്യാൻ കഴിയില്ല.

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

പ്രക്രിയയെക്കുറിച്ച്

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

ഇവന്റുകൾ അടിസ്ഥാനമാക്കിയുള്ള API ഉള്ള റീഫണ്ട് ടൂൾ

സംഭവങ്ങളാൽ നയിക്കപ്പെടുന്ന വാക്ക് തികച്ചും ഹാക്ക്നിഡ് ആണ്; കുറച്ചുകൂടി മുന്നോട്ട്, ഇത് എന്താണ് അർത്ഥമാക്കുന്നത് എന്ന് ഞങ്ങൾ കൂടുതൽ വിശദമായി നിർവചിക്കും. കാഫ്കയിൽ ഇവന്റുകൾ അടിസ്ഥാനമാക്കിയുള്ള API സമീപനം പരീക്ഷിക്കാൻ ഞങ്ങൾ തീരുമാനിച്ച സന്ദർഭത്തിൽ നിന്നാണ് ഞാൻ ആരംഭിക്കുന്നത്.

ഏത് സ്റ്റോറിലും, ഉപഭോക്താക്കൾ അടയ്ക്കുന്ന ഓർഡറുകൾക്ക് പുറമേ, ഉൽപ്പന്നം ഉപഭോക്താവിന് അനുയോജ്യമല്ലാത്തതിനാൽ പണം തിരികെ നൽകേണ്ട സമയങ്ങളുണ്ട്. ഇത് താരതമ്യേന ചെറിയ പ്രക്രിയയാണ്: ആവശ്യമെങ്കിൽ ഞങ്ങൾ വിവരങ്ങൾ വ്യക്തമാക്കുകയും പണം കൈമാറുകയും ചെയ്യുന്നു.

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

ഞങ്ങളുടെ പ്രചോദനം:

1. നിയമം FZ-54 - ചുരുക്കത്തിൽ, ഓരോ പണ ഇടപാടുകളെക്കുറിച്ചും, അത് റിട്ടേണായാലും രസീതായാലും, കുറച്ച് മിനിറ്റുകൾക്കുള്ളിൽ വളരെ ചുരുങ്ങിയ എസ്എൽഎയ്ക്കുള്ളിൽ നികുതി ഓഫീസിൽ റിപ്പോർട്ട് ചെയ്യണമെന്ന് നിയമം ആവശ്യപ്പെടുന്നു. ഞങ്ങൾ, ഒരു ഇ-കൊമേഴ്‌സ് കമ്പനി എന്ന നിലയിൽ, ധാരാളം പ്രവർത്തനങ്ങൾ നടത്തുന്നു. സാങ്കേതികമായി, ഇതിനർത്ഥം പുതിയ ഉത്തരവാദിത്തവും (അതിനാൽ ഒരു പുതിയ സേവനവും) ഉൾപ്പെട്ടിരിക്കുന്ന എല്ലാ സിസ്റ്റങ്ങളിലെയും മെച്ചപ്പെടുത്തലുകളും.
2. BOB വിഭജനം വലിയ തോതിലുള്ള നോൺ-കോർ ഉത്തരവാദിത്തങ്ങളിൽ നിന്ന് BOB-യെ ഒഴിവാക്കുന്നതിനും അതിന്റെ മൊത്തത്തിലുള്ള സങ്കീർണ്ണത കുറയ്ക്കുന്നതിനുമുള്ള കമ്പനിയുടെ ഒരു ആന്തരിക പ്രോജക്ടാണ്.

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

BOB-ക്ക് ധാരാളം എക്സ്ചേഞ്ചുകളുണ്ട്: പേയ്‌മെന്റ് സംവിധാനങ്ങൾ, ഡെലിവറി സംവിധാനങ്ങൾ, അറിയിപ്പ് സംവിധാനങ്ങൾ മുതലായവ.

സാങ്കേതികമായി BOB ഇതാണ്:

• കോഡിന്റെ ~150k ലൈനുകൾ + ~100k ലൈനുകൾ ടെസ്റ്റുകൾ;
• php7.2 + Zend 1 & Symfony ഘടകങ്ങൾ 3;
• >100 API-കൾ & ~50 ഔട്ട്ബൗണ്ട് സംയോജനങ്ങൾ;
• സ്വന്തം ബിസിനസ്സ് യുക്തിയുള്ള 4 രാജ്യങ്ങൾ.

BOB വിന്യസിക്കുന്നത് ചെലവേറിയതും വേദനാജനകവുമാണ്, അത് പരിഹരിക്കുന്ന കോഡിന്റെ അളവും പ്രശ്‌നങ്ങളും ആർക്കും അവരുടെ തലയിൽ വയ്ക്കാൻ കഴിയാത്തതാണ്. പൊതുവേ, ഇത് ലളിതമാക്കാൻ നിരവധി കാരണങ്ങളുണ്ട്.

റിട്ടേൺ പ്രോസസ്

തുടക്കത്തിൽ, രണ്ട് സിസ്റ്റങ്ങൾ ഈ പ്രക്രിയയിൽ ഉൾപ്പെടുന്നു: BOB, പേയ്മെന്റ്. ഇപ്പോൾ രണ്ടെണ്ണം കൂടി പ്രത്യക്ഷപ്പെടുന്നു:

• ധനവൽക്കരണ സേവനം, ധനവൽക്കരണത്തിലെ പ്രശ്നങ്ങൾക്കും ബാഹ്യ സേവനങ്ങളുമായുള്ള ആശയവിനിമയത്തിനും ഇത് ശ്രദ്ധ നൽകും.
• റീഫണ്ട് ടൂൾ, BOB വർദ്ധിപ്പിക്കാതിരിക്കാൻ പുതിയ എക്സ്ചേഞ്ചുകൾ അടങ്ങിയിരിക്കുന്നു.

ഇപ്പോൾ പ്രക്രിയ ഇതുപോലെ കാണപ്പെടുന്നു:

1. റീഫണ്ടിനുള്ള അഭ്യർത്ഥന BOB-ന് ലഭിക്കുന്നു.
2. BOB ഈ റീഫണ്ട് ടൂളിനെക്കുറിച്ച് സംസാരിക്കുന്നു.
3. റീഫണ്ട് ടൂൾ പേയ്‌മെന്റിനോട് പറയുന്നു: "പണം തിരികെ നൽകുക."
4. പേയ്മെന്റ് പണം തിരികെ നൽകുന്നു.
5. റീഫണ്ട് ടൂളും BOB-ഉം സ്റ്റാറ്റസുകൾ പരസ്പരം സമന്വയിപ്പിക്കുന്നു, കാരണം ഇപ്പോൾ അവ രണ്ടിനും അത് ആവശ്യമാണ്. റീഫണ്ട് ടൂളിലേക്ക് പൂർണ്ണമായും മാറാൻ ഞങ്ങൾ ഇതുവരെ തയ്യാറായിട്ടില്ല, കാരണം BOB-ന് ഒരു UI, അക്കൌണ്ടിംഗിനുള്ള റിപ്പോർട്ടുകൾ, പൊതുവെ അത്ര എളുപ്പത്തിൽ കൈമാറാൻ കഴിയാത്ത ധാരാളം ഡാറ്റ എന്നിവയുണ്ട്. നിങ്ങൾ രണ്ട് കസേരകളിൽ ഇരിക്കണം.
6. ധനവൽക്കരണത്തിനുള്ള അഭ്യർത്ഥന നീങ്ങുന്നു.

തൽഫലമായി, ഞങ്ങൾ കാഫ്കയിൽ ഒരുതരം ഇവന്റ് ബസ് ഉണ്ടാക്കി - ഇവന്റ്-ബസ്, അതിൽ എല്ലാം ആരംഭിച്ചു. ഹുറേ, ഇപ്പോൾ ഞങ്ങൾക്ക് പരാജയത്തിന്റെ ഒരൊറ്റ പോയിന്റ് ഉണ്ട് (പരിഹാസം).

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

എന്താണ് ഇവന്റുകൾ അടിസ്ഥാനമാക്കിയുള്ള API

ഈ ചോദ്യത്തിനുള്ള നല്ലൊരു ഉത്തരം മാർട്ടിൻ ഫൗളറുടെ (GOTO 2017) റിപ്പോർട്ടിലുണ്ട്. "ഇവന്റ്-ഡ്രൈവൻ ആർക്കിടെക്ചറിന്റെ പല അർത്ഥങ്ങളും".

ഞങ്ങൾ എന്താണ് ചെയ്തതെന്ന് ചുരുക്കത്തിൽ:

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

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

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

അസിൻക് എക്സ്ചേഞ്ച് AS IS

അസിൻക്രണസ് എക്സ്ചേഞ്ചുകൾക്കായി, PHP വകുപ്പ് സാധാരണയായി RabbitMQ ഉപയോഗിക്കുന്നു. ഞങ്ങൾ അഭ്യർത്ഥനയ്ക്കായി ഡാറ്റ ശേഖരിച്ചു, ഒരു ക്യൂവിൽ ഇട്ടു, അതേ സേവനത്തിന്റെ ഉപഭോക്താവ് അത് വായിച്ച് അയച്ചു (അല്ലെങ്കിൽ അയച്ചില്ല). API-ക്ക് വേണ്ടി തന്നെ, Lamoda സജീവമായി സ്വാഗർ ഉപയോഗിക്കുന്നു. ഞങ്ങൾ ഒരു API രൂപകൽപ്പന ചെയ്യുകയും സ്വാഗറിൽ വിവരിക്കുകയും ക്ലയന്റും സെർവർ കോഡും സൃഷ്ടിക്കുകയും ചെയ്യുന്നു. ഞങ്ങൾ അല്പം മെച്ചപ്പെടുത്തിയ JSON RPC 2.0 ഉപയോഗിക്കുന്നു.

ചില സ്ഥലങ്ങളിൽ ESB ബസുകൾ ഉപയോഗിക്കുന്നു, ചിലത് ActiveMQ-ൽ ജീവിക്കുന്നു, പക്ഷേ, പൊതുവേ, RabbitMQ - സ്റ്റാൻഡേർഡ്.

അസിൻക് എക്‌സ്‌ചേഞ്ച്

ഇവന്റുകൾ-ബസ് വഴി എക്സ്ചേഞ്ച് രൂപകൽപ്പന ചെയ്യുമ്പോൾ, ഒരു സാമ്യം കണ്ടെത്താനാകും. ഇവന്റ് ഘടന വിവരണങ്ങളിലൂടെ ഭാവിയിലെ ഡാറ്റാ കൈമാറ്റം ഞങ്ങൾ സമാനമായി വിവരിക്കുന്നു. yaml ഫോർമാറ്റ്, ഞങ്ങൾ തന്നെ കോഡ് ജനറേഷൻ ചെയ്യേണ്ടതുണ്ട്, ജനറേറ്റർ സ്പെസിഫിക്കേഷൻ അനുസരിച്ച് DTO-കൾ സൃഷ്ടിക്കുകയും ക്ലയന്റുകളേയും സെർവറുകളേയും അവരോടൊപ്പം പ്രവർത്തിക്കാൻ പഠിപ്പിക്കുകയും ചെയ്യുന്നു. തലമുറ രണ്ട് ഭാഷകളിലേക്ക് പോകുന്നു - golang ഒപ്പം php. ഇത് ലൈബ്രറികളെ സ്ഥിരമായി നിലനിർത്താൻ സഹായിക്കുന്നു. ജനറേറ്റർ ഗോലാങ്ങിൽ എഴുതിയിരിക്കുന്നു, അതിനാലാണ് ഇതിന് ഗോഗി എന്ന പേര് ലഭിച്ചത്.

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

അത്തരമൊരു സന്തോഷകരമായ സാഹചര്യത്തിൽ പോലും, ഏകദേശം സമാനമായ ഒരു പരിഹാരം ഉണ്ടാക്കിയ സാലാൻഡോ എന്ന ഏതാണ്ട് സമാനമായ ബിസിനസ്സ് ഉള്ളപ്പോൾ, നമുക്ക് അത് ഫലപ്രദമായി ഉപയോഗിക്കാൻ കഴിയുന്നില്ല എന്നത് വിരോധാഭാസമാണ്.

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

ഇവന്റുകൾ-ബസ്

അല്ലെങ്കിൽ ഒരു ഇവന്റ് ബസ്. ഇത് കേവലം ഒരു സ്‌റ്റേറ്റ്‌ലെസ് http ഗേറ്റ്‌വേ ആണ്, ഇത് നിരവധി പ്രധാന റോളുകൾ ഏറ്റെടുക്കുന്നു:

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

എന്തുകൊണ്ട്

ഞങ്ങൾ ഒരു വലിയ കമ്പനിയിൽ കാര്യക്ഷമമായ പ്രക്രിയയിൽ ജോലി ചെയ്യുന്നു. എന്തിനാണ് എന്തെങ്കിലും മാറ്റുന്നത്? ഇതൊരു പരീക്ഷണമാണ്, കൂടാതെ നിരവധി നേട്ടങ്ങൾ കൊയ്യാൻ ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു.

1:n+1 എക്സ്ചേഞ്ചുകൾ (ഒന്ന് മുതൽ പലത് വരെ)

പുതിയ ഉപഭോക്താക്കളെ API-ലേക്ക് ബന്ധിപ്പിക്കുന്നത് കാഫ്ക വളരെ എളുപ്പമാക്കുന്നു.

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

BOB-യുടെ ഒരു ഭാഗമായ റീഫണ്ട്-ടൂളിന്റെ കാര്യത്തിൽ, അവ കാഫ്കയിലൂടെ സമന്വയിപ്പിച്ച് നിലനിർത്തുന്നത് ഞങ്ങൾക്ക് സൗകര്യപ്രദമാണ്. പണം തിരികെ ലഭിച്ചുവെന്ന് പേയ്‌മെന്റ് പറയുന്നു: BOB, RT ഇതിനെക്കുറിച്ച് കണ്ടെത്തി, അവരുടെ സ്റ്റാറ്റസുകൾ മാറ്റി, ഫിസ്കലൈസേഷൻ സർവീസ് ഇതിനെക്കുറിച്ച് കണ്ടെത്തി ഒരു ചെക്ക് നൽകി.

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

ഡാറ്റാധിഷ്ടിതമാണ്

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

റെപ്ലിക്കേഷൻ ലോഗ്

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

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

അടുത്തതായി, കാഫ്കയെ പരിചയമില്ലാത്തവർക്കായി ഡോക്യുമെന്റേഷന്റെ ഒരു ചെറിയ പുനരാഖ്യാനം (ചിത്രവും ഡോക്യുമെന്റേഷനിൽ നിന്നുള്ളതാണ്)

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

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

അതനുസരിച്ച്, വ്യത്യസ്ത യുക്തികൾ നടപ്പിലാക്കാൻ കഴിയും. ഉദാഹരണത്തിന്, ഞങ്ങൾക്ക് വിവിധ രാജ്യങ്ങൾക്കായി 4 സന്ദർഭങ്ങളിൽ BOB ഉണ്ട് - റഷ്യ, കസാക്കിസ്ഥാൻ, ഉക്രെയ്ൻ, ബെലാറസ് എന്നിവിടങ്ങളിലാണ് ലമോഡ. അവ വെവ്വേറെ വിന്യസിച്ചിരിക്കുന്നതിനാൽ, അവയ്ക്ക് അല്പം വ്യത്യസ്തമായ കോൺഫിഗുകളും അവരുടെ സ്വന്തം ബിസിനസ്സ് ലോജിക്കും ഉണ്ട്. അത് ഏത് രാജ്യത്തെയാണ് സൂചിപ്പിക്കുന്നതെന്ന് ഞങ്ങൾ സന്ദേശത്തിൽ സൂചിപ്പിക്കുന്നു. ഓരോ രാജ്യത്തെയും ഓരോ BOB ഉപഭോക്താവും വ്യത്യസ്ത ഗ്രൂപ്പ് ഐഡി ഉപയോഗിച്ച് വായിക്കുന്നു, സന്ദേശം അവർക്ക് ബാധകമല്ലെങ്കിൽ, അവർ അത് ഒഴിവാക്കുന്നു, അതായത്. ഉടൻ ഓഫ്‌സെറ്റ് +1 ചെയ്യുന്നു. ഞങ്ങളുടെ പേയ്‌മെന്റ് സേവനം ഒരേ വിഷയം വായിക്കുകയാണെങ്കിൽ, അത് ഒരു പ്രത്യേക ഗ്രൂപ്പിലാണ് ചെയ്യുന്നത്, അതിനാൽ ഓഫ്‌സെറ്റുകൾ വിഭജിക്കില്ല.

ഇവന്റ് ആവശ്യകതകൾ:

• ഡാറ്റ സമ്പൂർണ്ണത. ഇവന്റിന് ആവശ്യമായ ഡാറ്റ ഉണ്ടായിരിക്കണമെന്ന് ഞാൻ ആഗ്രഹിക്കുന്നു, അതുവഴി അത് പ്രോസസ്സ് ചെയ്യാൻ കഴിയും.

• സമഗ്രത. ഇവന്റ് സ്ഥിരതയുള്ളതാണെന്നും അത് പ്രോസസ്സ് ചെയ്യാമെന്നും പരിശോധിച്ചുറപ്പിക്കൽ ഞങ്ങൾ Events-bus-ന് നിയോഗിക്കുന്നു.
• ക്രമം പ്രധാനമാണ്. തിരിച്ചുവരവിന്റെ കാര്യത്തിൽ, ചരിത്രവുമായി പ്രവർത്തിക്കാൻ ഞങ്ങൾ നിർബന്ധിതരാകുന്നു. അറിയിപ്പുകൾക്കൊപ്പം, ഓർഡർ പ്രധാനമല്ല, അവ ഏകതാനമായ അറിയിപ്പുകളാണെങ്കിൽ, ഏത് ഓർഡർ ആദ്യം വന്നാലും ഇമെയിൽ സമാനമായിരിക്കും. റീഫണ്ടിന്റെ കാര്യത്തിൽ, വ്യക്തമായ ഒരു പ്രക്രിയയുണ്ട്; ഞങ്ങൾ ഓർഡർ മാറ്റുകയാണെങ്കിൽ, ഒഴിവാക്കലുകൾ ഉണ്ടാകാം, റീഫണ്ട് സൃഷ്ടിക്കുകയോ പ്രോസസ്സ് ചെയ്യുകയോ ചെയ്യില്ല - ഞങ്ങൾ മറ്റൊരു അവസ്ഥയിൽ അവസാനിക്കും.
• സ്ഥിരത. ഞങ്ങൾക്ക് ഒരു സ്റ്റോർ ഉണ്ട്, ഇപ്പോൾ ഞങ്ങൾ ഒരു API-ക്ക് പകരം ഇവന്റുകൾ സൃഷ്ടിക്കുന്നു. പുതിയ ഇവന്റുകളെക്കുറിച്ചും നിലവിലുള്ളവയിൽ വരുത്തുന്ന മാറ്റങ്ങളെക്കുറിച്ചും ഞങ്ങളുടെ സേവനങ്ങളിലേക്ക് വേഗത്തിലും വിലകുറഞ്ഞും വിവരങ്ങൾ കൈമാറാൻ ഞങ്ങൾക്ക് ഒരു മാർഗം ആവശ്യമാണ്. ഒരു പ്രത്യേക ജിറ്റ് റിപ്പോസിറ്ററിയിലെയും കോഡ് ജനറേറ്ററുകളിലെയും പൊതുവായ സ്പെസിഫിക്കേഷനിലൂടെയാണ് ഇത് നേടുന്നത്. അതിനാൽ, വിവിധ സേവനങ്ങളിലെ ക്ലയന്റുകളും സെർവറുകളും ഏകോപിപ്പിക്കപ്പെടുന്നു.

ലമോഡയിലെ കാഫ്ക

ഞങ്ങൾക്ക് മൂന്ന് കാഫ്ക ഇൻസ്റ്റാളേഷനുകളുണ്ട്:

1. രേഖകൾ;
2. R&D;
3. ഇവന്റുകൾ-ബസ്.

ഇന്ന് നമ്മൾ അവസാന പോയിന്റിനെക്കുറിച്ച് മാത്രമാണ് സംസാരിക്കുന്നത്. ഇവന്റുകൾ-ബസിൽ, ഞങ്ങൾക്ക് വളരെ വലിയ ഇൻസ്റ്റാളേഷനുകളില്ല - 3 ബ്രോക്കർമാർ (സെർവറുകൾ) കൂടാതെ 27 വിഷയങ്ങൾ മാത്രം. ചട്ടം പോലെ, ഒരു വിഷയം ഒരു പ്രക്രിയയാണ്. എന്നാൽ ഇതൊരു സൂക്ഷ്മമായ പോയിന്റാണ്, ഞങ്ങൾ ഇപ്പോൾ അതിൽ സ്പർശിക്കും.

മുകളിൽ rps ഗ്രാഫ് ആണ്. റീഫണ്ട് പ്രോസസ് ഒരു ടർക്കോയ്സ് ലൈൻ ഉപയോഗിച്ച് അടയാളപ്പെടുത്തിയിരിക്കുന്നു (അതെ, X അക്ഷത്തിലുള്ളത്), പിങ്ക് ലൈൻ ഉള്ളടക്കം അപ്ഡേറ്റ് പ്രക്രിയയാണ്.

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

പിങ്ക് പീക്കുകൾ ഉൽപ്പന്ന അപ്‌ഡേറ്റുകളാണ്, അതായത് ഉൽപ്പന്നങ്ങളിലെ മാറ്റങ്ങൾ. ആൺകുട്ടികൾ ചിത്രമെടുത്തു, ചിത്രമെടുത്തു, പിന്നെയും കാണാം! - ഇവന്റുകളുടെ ഒരു പായ്ക്ക് ലോഡ് ചെയ്തു.

ലമോഡ ഇവന്റുകൾ കേസുകൾ ഉപയോഗിക്കുന്നു

ഇനിപ്പറയുന്ന പ്രവർത്തനങ്ങൾക്കായി ഞങ്ങൾ നിർമ്മിച്ച വാസ്തുവിദ്യ ഉപയോഗിക്കുന്നു:

• റിട്ടേൺ സ്റ്റാറ്റസ് ട്രാക്കിംഗ്: ഉൾപ്പെട്ടിരിക്കുന്ന എല്ലാ സിസ്റ്റങ്ങളിൽ നിന്നും കോൾ-ടു-ആക്ഷൻ, സ്റ്റാറ്റസ് ട്രാക്കിംഗ്. പേയ്‌മെന്റ്, സ്റ്റാറ്റസുകൾ, ധനവൽക്കരണം, അറിയിപ്പുകൾ. ഇവിടെ ഞങ്ങൾ സമീപനം പരീക്ഷിച്ചു, ഉപകരണങ്ങൾ ഉണ്ടാക്കി, എല്ലാ ബഗുകളും ശേഖരിച്ചു, ഡോക്യുമെന്റേഷൻ എഴുതി, അത് എങ്ങനെ ഉപയോഗിക്കണമെന്ന് ഞങ്ങളുടെ സഹപ്രവർത്തകരോട് പറഞ്ഞു.
• ഉൽപ്പന്ന കാർഡുകൾ അപ്ഡേറ്റ് ചെയ്യുന്നു: കോൺഫിഗറേഷൻ, മെറ്റാ-ഡാറ്റ, സവിശേഷതകൾ. ഒരു സിസ്റ്റം റീഡുചെയ്യുന്നു (അത് പ്രദർശിപ്പിക്കുന്നു), നിരവധി എഴുതുന്നു.
• ഇമെയിൽ, പുഷ്, എസ്എംഎസ്: ഓർഡർ ശേഖരിച്ചു, ഓർഡർ എത്തി, റിട്ടേൺ സ്വീകരിച്ചു തുടങ്ങി, അവയിൽ ധാരാളം ഉണ്ട്.
• സ്റ്റോക്ക്, വെയർഹൗസ് പുതുക്കൽ - ഇനങ്ങളുടെ അളവ് അപ്ഡേറ്റ്, വെറും അക്കങ്ങൾ: വെയർഹൗസിലെ വരവ്, മടക്കം. സാധനങ്ങൾ റിസർവ് ചെയ്യുന്നതുമായി ബന്ധപ്പെട്ട എല്ലാ സിസ്റ്റങ്ങളും ഏറ്റവും നിലവിലെ ഡാറ്റ ഉപയോഗിച്ച് പ്രവർത്തിക്കേണ്ടത് ആവശ്യമാണ്. നിലവിൽ, സ്റ്റോക്ക് അപ്ഡേറ്റ് സിസ്റ്റം വളരെ സങ്കീർണ്ണമാണ്; കാഫ്ക അത് ലളിതമാക്കും.
• ഡാറ്റ വിശകലനം (R&D വകുപ്പ്), ML ടൂളുകൾ, അനലിറ്റിക്സ്, സ്റ്റാറ്റിസ്റ്റിക്സ്. വിവരങ്ങൾ സുതാര്യമാകണമെന്ന് ഞങ്ങൾ ആഗ്രഹിക്കുന്നു - കാഫ്ക ഇതിന് അനുയോജ്യമാണ്.

കഴിഞ്ഞ ആറ് മാസത്തിനിടെ ഉണ്ടായ വലിയ കുതിച്ചുചാട്ടങ്ങളെക്കുറിച്ചും രസകരമായ കണ്ടെത്തലുകളെക്കുറിച്ചും ഇപ്പോൾ കൂടുതൽ രസകരമായ ഭാഗം.

ഡിസൈൻ പ്രശ്നങ്ങൾ

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

ഇവ സമാന മേഖലകളാണെന്ന് തോന്നുന്നു, എന്നാൽ BOB-ലെ ഓർഡർ പ്രോസസ്സിംഗിനും ഷിപ്പിംഗ് സിസ്റ്റത്തിനും വ്യത്യസ്ത നിലകളുണ്ട്. ഉദാഹരണത്തിന്, ചില കൊറിയർ സേവനങ്ങൾ ഇന്റർമീഡിയറ്റ് സ്റ്റാറ്റസുകൾ അയയ്‌ക്കുന്നില്ല, പക്ഷേ അവസാനത്തേത് മാത്രം: “ഡെലിവർ ചെയ്‌തു” അല്ലെങ്കിൽ “നഷ്ടപ്പെട്ടു”. മറ്റുള്ളവർ, നേരെമറിച്ച്, ചരക്കുകളുടെ ചലനത്തെക്കുറിച്ച് വളരെ വിശദമായി റിപ്പോർട്ട് ചെയ്യുന്നു. ഓരോരുത്തർക്കും അവരവരുടെ മൂല്യനിർണ്ണയ നിയമങ്ങളുണ്ട്: ചിലർക്ക് ഇമെയിൽ സാധുതയുള്ളതാണ്, അതായത് അത് പ്രോസസ്സ് ചെയ്യപ്പെടും; മറ്റുള്ളവർക്ക് ഇത് സാധുതയുള്ളതല്ല, പക്ഷേ കോൺടാക്റ്റിനായി ഒരു ഫോൺ നമ്പർ ഉള്ളതിനാൽ ഓർഡർ തുടർന്നും പ്രോസസ്സ് ചെയ്യും, അത്തരമൊരു ഓർഡർ പ്രോസസ്സ് ചെയ്യില്ലെന്ന് ആരെങ്കിലും പറയും.

ഡാറ്റ സ്ട്രീം

കാഫ്കയുടെ കാര്യത്തിൽ, ഡാറ്റാ ഫ്ലോ സംഘടിപ്പിക്കുന്നതിനുള്ള ചോദ്യം ഉയർന്നുവരുന്നു. ഈ ടാസ്‌ക്കിൽ നിരവധി പോയിന്റുകളെ അടിസ്ഥാനമാക്കി ഒരു തന്ത്രം തിരഞ്ഞെടുക്കുന്നത് ഉൾപ്പെടുന്നു; നമുക്ക് അവയെല്ലാം നോക്കാം.

ഒരു വിഷയത്തിലോ വ്യത്യസ്ത വിഷയത്തിലോ?

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

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

പുതിയ ഫീൽഡ് അല്ലെങ്കിൽ പുതിയ ഇവന്റ്?

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

ഇവന്റ്-ബസിന് ഈ ഫീൽഡ് ആവശ്യമാണെന്ന് ഞങ്ങൾ ഒരു നിയമം അവതരിപ്പിക്കുകയാണെങ്കിൽ, BOB-ലോ സ്റ്റാർട്ട് ഇവന്റ് ഹാൻഡ്‌ലറിലോ അധിക മൂല്യനിർണ്ണയ നിയമങ്ങൾ സജ്ജീകരിക്കാൻ ഞങ്ങൾ നിർബന്ധിതരാകും. മൂല്യനിർണ്ണയം സേവനത്തിലുടനീളം വ്യാപിക്കാൻ തുടങ്ങുന്നു - ഇത് വളരെ സൗകര്യപ്രദമല്ല.

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

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

ഇവന്റ് പതിപ്പിംഗ്

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

പാർട്ടീഷനുകളുടെ വായനാ ക്രമം ഉറപ്പ്

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

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

എങ്ങനെയാണ് കാഫ്ക അവരെ വിഭജിക്കുന്നത്? ഓരോ സന്ദേശത്തിനും ഒരു ബോഡിയും (അതിൽ ഞങ്ങൾ JSON സംഭരിക്കുന്നു) ഒരു കീയും ഉണ്ട്. ഈ കീയിലേക്ക് നിങ്ങൾക്ക് ഒരു ഹാഷ് ഫംഗ്ഷൻ അറ്റാച്ചുചെയ്യാം, സന്ദേശം ഏത് പാർട്ടീഷനിലേക്കാണ് പോകേണ്ടതെന്ന് ഇത് നിർണ്ണയിക്കും.

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

ഇവന്റുകൾ vs കമാൻഡുകൾ

ഞങ്ങൾ നേരിട്ട മറ്റൊരു പ്രശ്നമാണിത്. ഇവന്റ് ഒരു നിശ്ചിത സംഭവമാണ്: എവിടെയോ എന്തെങ്കിലും സംഭവിച്ചുവെന്ന് ഞങ്ങൾ പറയുന്നു (എന്തോ_സംഭവിച്ചു), ഉദാഹരണത്തിന്, ഒരു ഇനം റദ്ദാക്കി അല്ലെങ്കിൽ റീഫണ്ട് സംഭവിച്ചു. ആരെങ്കിലും ഈ ഇവന്റുകൾ ശ്രദ്ധിക്കുകയാണെങ്കിൽ, "ഇനം റദ്ദാക്കി" എന്നതനുസരിച്ച്, റീഫണ്ട് എന്റിറ്റി സൃഷ്ടിക്കപ്പെടും, കൂടാതെ സജ്ജീകരണങ്ങളിൽ എവിടെയെങ്കിലും "റീഫണ്ട് സംഭവിച്ചു" എന്ന് എഴുതപ്പെടും.

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

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

RabbitMQ-ലെ അസിൻക്രണസ് എക്സ്ചേഞ്ചിൽ, നിങ്ങൾ സന്ദേശം വായിക്കുമ്പോൾ, http എന്നതിലേക്ക് പോകുക, നിങ്ങൾക്ക് ഒരു പ്രതികരണമുണ്ട് - കുറഞ്ഞത് സന്ദേശം ലഭിച്ചുവെന്ന്. നിങ്ങൾ കാഫ്കയ്ക്ക് എഴുതുമ്പോൾ, നിങ്ങൾ കാഫ്കയ്ക്ക് എഴുതിയ ഒരു സന്ദേശമുണ്ട്, പക്ഷേ അത് എങ്ങനെ പ്രോസസ്സ് ചെയ്തു എന്നതിനെക്കുറിച്ച് നിങ്ങൾക്ക് ഒന്നും അറിയില്ല.

അതിനാൽ, ഞങ്ങളുടെ കാര്യത്തിൽ, ഞങ്ങൾക്ക് ഒരു പ്രതികരണ പരിപാടി അവതരിപ്പിക്കുകയും നിരീക്ഷണം സജ്ജീകരിക്കുകയും ചെയ്യേണ്ടതുണ്ട്, അങ്ങനെ നിരവധി ഇവന്റുകൾ അയച്ചിട്ടുണ്ടെങ്കിൽ, അത്തരം സമയത്തിന് ശേഷം അത്രയും പ്രതികരണ ഇവന്റുകൾ എത്തിച്ചേരും. ഇത് സംഭവിച്ചില്ലെങ്കിൽ, എന്തോ കുഴപ്പം സംഭവിച്ചതായി തോന്നുന്നു. ഉദാഹരണത്തിന്, ഞങ്ങൾ “item_ready_to_refund” ഇവന്റ് അയച്ചാൽ, ഒരു റീഫണ്ട് സൃഷ്‌ടിക്കുമെന്നും പണം ക്ലയന്റിലേക്ക് തിരികെ നൽകുമെന്നും “money_refunded” ഇവന്റ് ഞങ്ങൾക്ക് അയയ്‌ക്കുമെന്നും ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു. എന്നാൽ ഇത് ഉറപ്പില്ലാത്തതിനാൽ നിരീക്ഷണം ആവശ്യമാണ്.

സൂക്ഷ്മത

വളരെ വ്യക്തമായ ഒരു പ്രശ്‌നമുണ്ട്: നിങ്ങൾ ഒരു വിഷയത്തിൽ നിന്ന് തുടർച്ചയായി വായിക്കുകയും നിങ്ങൾക്ക് എന്തെങ്കിലും മോശം സന്ദേശമുണ്ടെങ്കിൽ, ഉപഭോക്താവ് വീഴും, നിങ്ങൾ കൂടുതൽ മുന്നോട്ട് പോകില്ല. നിങ്ങൾക്ക് വേണം എല്ലാ ഉപഭോക്താക്കളെയും നിർത്തുക, വായന തുടരാൻ കൂടുതൽ ഓഫ്സെറ്റ് സമർപ്പിക്കുക.

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

സേവനം കുറച്ച് സമയത്തേക്ക് കിടന്നു - ഭാഗ്യവശാൽ, കാഫ്കയിൽ ഇത് അത്ര മോശമല്ല, കാരണം സന്ദേശങ്ങൾ അവശേഷിക്കുന്നു. ജോലി പുനഃസ്ഥാപിക്കുമ്പോൾ, നിങ്ങൾക്ക് അവ വായിക്കാൻ കഴിയും. ഇത് സുഖകരമാണ്.

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

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

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

നിരീക്ഷിക്കുന്നു

നിലവിലുള്ള സമീപനത്തിൽ എന്തൊക്കെ പ്രശ്‌നങ്ങളുണ്ടെന്ന് ഞങ്ങൾ നിരീക്ഷിക്കുന്ന രീതി കൂടുതൽ വ്യക്തമാകുമെന്ന് ഞാൻ കരുതുന്നു.

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

കൂടാതെ, നിർമ്മാതാവ് എങ്ങനെ പ്രവർത്തിക്കുന്നു, ഇവന്റുകൾ-ബസിന് സന്ദേശങ്ങൾ ലഭിച്ചിട്ടുണ്ടോ, ഉപഭോക്താവ് എങ്ങനെ പ്രവർത്തിക്കുന്നു എന്നിവ നിങ്ങൾ നിരീക്ഷിക്കേണ്ടതുണ്ട്. ഉദാഹരണത്തിന്, ചുവടെയുള്ള ചാർട്ടുകളിൽ, റീഫണ്ട് ടൂൾ നന്നായി പ്രവർത്തിക്കുന്നു, എന്നാൽ BOB-ന് വ്യക്തമായും ചില പ്രശ്നങ്ങളുണ്ട് (നീല കൊടുമുടികൾ).

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

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

API പ്രതികരണം ഇങ്ങനെയാണ് കാണപ്പെടുന്നത്. ഗ്രൂപ്പ് bob-live-fifa, പാർട്ടീഷൻ refund.update.v1, സ്റ്റാറ്റസ് ശരി, ലാഗ് 0 - അവസാനത്തെ ഫൈനൽ ഓഫ്‌സെറ്റ് അത്തരത്തിലുള്ളവ ഇതാ.

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

ചുരുക്കത്തിൽ, ഇവന്റുകൾ ഉപയോഗിക്കുന്നത് സൗകര്യപ്രദമാണ്:

• നിരവധി സിസ്റ്റങ്ങൾക്ക് വിവരങ്ങൾ ആവശ്യമാണ്;
• പ്രോസസ്സിംഗിന്റെ ഫലം പ്രധാനമല്ല;
• കുറച്ച് സംഭവങ്ങളോ ചെറിയ സംഭവങ്ങളോ ഉണ്ട്.

ലേഖനത്തിന് വളരെ നിർദ്ദിഷ്ട വിഷയമുണ്ടെന്ന് തോന്നുന്നു - കാഫ്കയിലെ അസിൻക്രണസ് എപിഐ, എന്നാൽ ഇതുമായി ബന്ധപ്പെട്ട് ഒരേസമയം ധാരാളം കാര്യങ്ങൾ ശുപാർശ ചെയ്യാൻ ഞാൻ ആഗ്രഹിക്കുന്നു.
ആദ്യം, അടുത്തത് ഹൈലോഡ്++ ഞങ്ങൾ നവംബർ വരെ കാത്തിരിക്കേണ്ടതുണ്ട്; ഏപ്രിലിൽ ഒരു സെന്റ് പീറ്റേഴ്‌സ്ബർഗ് പതിപ്പ് ഉണ്ടാകും, ജൂണിൽ ഞങ്ങൾ നോവോസിബിർസ്കിലെ ഉയർന്ന ലോഡുകളെക്കുറിച്ച് സംസാരിക്കും.
രണ്ടാമതായി, റിപ്പോർട്ടിന്റെ രചയിതാവ് സെർജി സൈക്ക, വിജ്ഞാന മാനേജ്മെന്റിനെക്കുറിച്ചുള്ള ഞങ്ങളുടെ പുതിയ കോൺഫറൻസിന്റെ പ്രോഗ്രാം കമ്മിറ്റി അംഗമാണ്. നോളജ് കോൺഫ്. കോൺഫറൻസ് ഒരു ദിവസമാണ്, ഏപ്രിൽ 26 ന് നടക്കും, എന്നാൽ അതിന്റെ പ്രോഗ്രാം വളരെ തീവ്രമാണ്.
അത് മെയ് മാസത്തിലായിരിക്കും PHP റഷ്യ и RIT++ (DevOpsConf ഉൾപ്പെടുത്തി) - നിങ്ങൾക്ക് അവിടെ നിങ്ങളുടെ വിഷയം നിർദ്ദേശിക്കാനും നിങ്ങളുടെ അനുഭവത്തെക്കുറിച്ച് സംസാരിക്കാനും നിങ്ങളുടെ സ്റ്റഫ് ചെയ്ത കോണുകളെ കുറിച്ച് പരാതിപ്പെടാനും കഴിയും.

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