സന്ദേശ ബ്രോക്കർമാരെ മനസ്സിലാക്കുന്നു. ActiveMQ, Kafka എന്നിവ ഉപയോഗിച്ച് സന്ദേശമയയ്‌ക്കുന്നതിനുള്ള മെക്കാനിക്‌സ് പഠിക്കുന്നു. അധ്യായം 3. കാഫ്ക

ഒരു ചെറിയ പുസ്തകത്തിന്റെ വിവർത്തനത്തിന്റെ തുടർച്ച:
സന്ദേശ ബ്രോക്കർമാരെ മനസ്സിലാക്കുന്നു
രചയിതാവ്: Jakub Korab, പ്രസാധകൻ: O'Reilly Media, Inc., പ്രസിദ്ധീകരിച്ച തീയതി: ജൂൺ 2017, ISBN: 9781492049296.

മുമ്പ് വിവർത്തനം ചെയ്ത ഭാഗം: സന്ദേശ ബ്രോക്കർമാരെ മനസ്സിലാക്കുന്നു. ActiveMQ, Kafka എന്നിവ ഉപയോഗിച്ച് സന്ദേശമയയ്‌ക്കുന്നതിനുള്ള മെക്കാനിക്‌സ് പഠിക്കുന്നു. അധ്യായം 1 ആമുഖം

അധ്യായം 3

കാഫ്ക

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

ഈ ആത്യന്തിക ലക്ഷ്യം കണക്കിലെടുക്കുമ്പോൾ, മറ്റ് ആവശ്യകതകൾ സ്വാഭാവികമായും ഉയർന്നു. കാഫ്ക ചെയ്യണം:

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

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

ഏകീകൃത ഡെസ്റ്റിനേഷൻ മോഡൽ

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

ഈ അധ്യായത്തിന്റെ ബാക്കി ഭാഗങ്ങളിൽ, ഞങ്ങൾ വ്യക്തമായി പറയുന്നില്ലെങ്കിൽ, "വിഷയം" എന്ന പദം ഒരു കാഫ്ക വിഷയത്തെ സൂചിപ്പിക്കും.

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

"ലോഗ്", "പോയിന്റർ" എന്നീ പദങ്ങൾ ദൃശ്യമാകില്ല കാഫ്ക ഡോക്യുമെന്റേഷൻ. മനസ്സിലാക്കാൻ സഹായിക്കുന്നതിന് ഈ അറിയപ്പെടുന്ന പദങ്ങൾ ഇവിടെ ഉപയോഗിക്കുന്നു.

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

ചിത്രം 3-1. കാഫ്ക പാർട്ടീഷനുകൾ

ഒരു നിർമ്മാതാവ് ഒരു കാഫ്ക വിഷയത്തിലേക്ക് ഒരു സന്ദേശം അയയ്ക്കുമ്പോൾ, ഏത് പാർട്ടീഷനിലേക്കാണ് സന്ദേശം അയക്കേണ്ടതെന്ന് അത് തീരുമാനിക്കുന്നു. ഞങ്ങൾ ഇത് കൂടുതൽ വിശദമായി പിന്നീട് നോക്കും.

സന്ദേശങ്ങൾ വായിക്കുന്നു

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

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

വായനയുടെ പ്രശ്നം ഇനിപ്പറയുന്ന രീതിയിൽ പ്രതിനിധീകരിക്കാം:

• വിഷയത്തിന് ഒന്നിലധികം പാർട്ടീഷനുകൾ ഉണ്ട്
• ഉപഭോക്താക്കളുടെ ഒന്നിലധികം ഗ്രൂപ്പുകൾക്ക് ഒരേ സമയം ഒരു വിഷയം ഉപയോഗിക്കാൻ കഴിയും
• ഒരു കൂട്ടം ഉപഭോക്താക്കൾക്ക് ഒന്നിലധികം വ്യത്യസ്ത സംഭവങ്ങൾ ഉണ്ടാകാം

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

ഉപഭോക്താക്കളും ഉപഭോക്തൃ ഗ്രൂപ്പുകളും

ഒരു പാർട്ടീഷൻ ഉള്ള ഒരു വിഷയം നമുക്ക് ആരംഭ പോയിന്റായി എടുക്കാം (ചിത്രം 3-2).

ചിത്രം 3-2. വിഭജനത്തിൽ നിന്ന് ഉപഭോക്താവ് വായിക്കുന്നു

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

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

ചിത്രം 3-3. വ്യത്യസ്ത ഉപഭോക്തൃ ഗ്രൂപ്പുകളിലെ രണ്ട് ഉപഭോക്താക്കൾ ഒരേ പാർട്ടീഷനിൽ നിന്ന് വായിക്കുന്നു

ഒരു ഉപഭോക്തൃ ഗ്രൂപ്പിലെ ഉപഭോക്താക്കൾ

ഒരു ഉപഭോക്തൃ ഉദാഹരണം ഒരു പാർട്ടീഷനിൽ നിന്നുള്ള ഡാറ്റ വായിക്കുമ്പോൾ, അതിന് പോയിന്ററിന്റെ പൂർണ്ണ നിയന്ത്രണം ഉണ്ടായിരിക്കുകയും മുൻ വിഭാഗത്തിൽ വിവരിച്ചിരിക്കുന്നതുപോലെ സന്ദേശങ്ങൾ പ്രോസസ്സ് ചെയ്യുകയും ചെയ്യുന്നു.
ഉപഭോക്താക്കളുടെ നിരവധി സംഭവങ്ങൾ ഒരേ ഗ്രൂപ്പ്_ഐഡി ഉപയോഗിച്ച് ഒരു പാർട്ടീഷനുള്ള ഒരു വിഷയവുമായി ബന്ധിപ്പിച്ചിട്ടുണ്ടെങ്കിൽ, അവസാനം കണക്റ്റുചെയ്‌ത സന്ദർഭത്തിന് പോയിന്ററിന്മേൽ നിയന്ത്രണം നൽകുകയും ആ നിമിഷം മുതൽ അതിന് എല്ലാ സന്ദേശങ്ങളും ലഭിക്കുകയും ചെയ്യും (ചിത്രം 3-4).

ചിത്രം 3-4. ഒരേ ഉപഭോക്തൃ ഗ്രൂപ്പിലെ രണ്ട് ഉപഭോക്താക്കൾ ഒരേ പാർട്ടീഷനിൽ നിന്ന് വായിക്കുന്നു

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

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

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

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

കാഫ്കയിലെ ഈ പ്രശ്നം പരിഹരിക്കാനുള്ള കാനോനിക്കൽ മാർഗം ബിОകൂടുതൽ പാർട്ടീഷനുകൾ.

വിഭജനം

ഒരൊറ്റ ബ്രോക്കർ ഉദാഹരണത്തിന്റെ ബാൻഡ്‌വിഡ്‌ത്തിനപ്പുറം ഒരു വിഷയം വായിക്കുന്നതിനും സ്കെയിൽ ചെയ്യുന്നതിനുമുള്ള പ്രധാന സംവിധാനമാണ് പാർട്ടീഷനുകൾ. ഇത് നന്നായി മനസ്സിലാക്കാൻ, രണ്ട് പാർട്ടീഷനുകളുള്ള ഒരു വിഷയവും ഒരു ഉപഭോക്താവ് ഈ വിഷയത്തിലേക്ക് സബ്‌സ്‌ക്രൈബുചെയ്യുന്നതുമായ ഒരു സാഹചര്യം നമുക്ക് പരിഗണിക്കാം (ചിത്രം 3-5).

ചിത്രം 3-5. ഒരു ഉപഭോക്താവ് ഒന്നിലധികം പാർട്ടീഷനുകളിൽ നിന്ന് വായിക്കുന്നു

ഈ സാഹചര്യത്തിൽ, ഉപഭോക്താവിന് രണ്ട് പാർട്ടീഷനുകളിലും അതിന്റെ ഗ്രൂപ്പ്_ഐഡിയുമായി ബന്ധപ്പെട്ട പോയിന്ററുകളുടെ നിയന്ത്രണം നൽകുകയും രണ്ട് പാർട്ടീഷനുകളിൽ നിന്നും സന്ദേശങ്ങൾ വായിക്കാൻ തുടങ്ങുകയും ചെയ്യുന്നു.
ഈ വിഷയത്തിലേക്ക് അതേ group_id-യ്‌ക്ക് ഒരു അധിക ഉപഭോക്താവിനെ ചേർക്കുമ്പോൾ, കാഫ്ക ആദ്യത്തേതിൽ നിന്ന് രണ്ടാമത്തെ ഉപഭോക്താവിലേക്ക് പാർട്ടീഷനുകളിലൊന്ന് വീണ്ടും അനുവദിക്കും. അതിനുശേഷം, ഉപഭോക്താവിന്റെ ഓരോ സംഭവവും വിഷയത്തിന്റെ ഒരു വിഭജനത്തിൽ നിന്ന് വായിക്കും (ചിത്രം 3-6).

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

ചിത്രം 3-6. ഒരേ ഉപഭോക്തൃ ഗ്രൂപ്പിലെ രണ്ട് ഉപഭോക്താക്കൾ വ്യത്യസ്ത പാർട്ടീഷനുകളിൽ നിന്ന് വായിക്കുന്നു

JMS ക്യൂ നിലനിർത്തുന്നതിന് ആവശ്യമായ സന്ദേശ വിതരണവുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ ഈ സ്കീം കാഫ്ക ബ്രോക്കറുടെ സങ്കീർണ്ണതയെ വളരെയധികം കുറയ്ക്കുന്നു. ഇവിടെ നിങ്ങൾ ഇനിപ്പറയുന്ന പോയിന്റുകളെക്കുറിച്ച് വിഷമിക്കേണ്ടതില്ല:

• റൗണ്ട് റോബിൻ അലോക്കേഷൻ, പ്രീഫെച്ച് ബഫറുകളുടെ നിലവിലെ ശേഷി അല്ലെങ്കിൽ മുൻ സന്ദേശങ്ങൾ (ജെഎംഎസ് സന്ദേശ ഗ്രൂപ്പുകൾ പോലെ) എന്നിവയെ അടിസ്ഥാനമാക്കി ഏത് ഉപഭോക്താവിനാണ് അടുത്ത സന്ദേശം ലഭിക്കേണ്ടത്.
• ഏതൊക്കെ ഉപഭോക്താക്കൾക്ക് ഏതൊക്കെ സന്ദേശങ്ങളാണ് അയയ്‌ക്കുന്നത്, പരാജയപ്പെടുകയാണെങ്കിൽ അവ വീണ്ടും ഡെലിവർ ചെയ്യണോ.

കാഫ്ക ബ്രോക്കർ ചെയ്യേണ്ടത്, ഉപഭോക്താവ് ആവശ്യപ്പെടുമ്പോൾ തുടർച്ചയായി സന്ദേശങ്ങൾ അയയ്ക്കുക എന്നതാണ്.

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

സന്ദേശങ്ങൾ അയയ്ക്കുന്നു

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

JMS-ൽ നമ്മൾ മെറ്റാഡാറ്റയും (ഹെഡറുകളും പ്രോപ്പർട്ടികളും) പേലോഡ് (പേലോഡ്) അടങ്ങിയ ബോഡിയും ഉള്ള ഒരു സന്ദേശ ഘടന ഉപയോഗിക്കുന്നു, കാഫ്കയിൽ സന്ദേശം ഇതാണ് ജോടി "കീ-മൂല്യം". സന്ദേശ പേലോഡ് ഒരു മൂല്യമായി അയച്ചു. മറുവശത്ത്, കീ പ്രധാനമായും പാർട്ടീഷനിംഗിനായി ഉപയോഗിക്കുന്നു, അതിൽ അടങ്ങിയിരിക്കണം ബിസിനസ് ലോജിക് നിർദ്ദിഷ്ട കീഅതേ പാർട്ടീഷനിൽ ബന്ധപ്പെട്ട സന്ദേശങ്ങൾ ഇടാൻ.

അദ്ധ്യായം 2-ൽ, ഒരൊറ്റ ഉപഭോക്താവ് ക്രമത്തിൽ ബന്ധപ്പെട്ട ഇവന്റുകൾ പ്രോസസ്സ് ചെയ്യേണ്ട ഓൺലൈൻ വാതുവെപ്പ് സാഹചര്യം ഞങ്ങൾ ചർച്ച ചെയ്തു:

1. ഉപയോക്തൃ അക്കൗണ്ട് ക്രമീകരിച്ചു.
2. അക്കൗണ്ടിലേക്ക് പണം ക്രെഡിറ്റ് ചെയ്യപ്പെടുന്നു.
3. അക്കൗണ്ടിൽ നിന്ന് പണം പിൻവലിക്കാൻ ഒരു പന്തയം നടത്തുന്നു.

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

ഈ ഇന്റർഫേസ് ഇതുപോലെ കാണപ്പെടുന്നു:

interface Partitioner {
    int partition(String topic,
        Object key, byte[] keyBytes, Object value, byte[] valueBytes, Cluster cluster);
}

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

നിങ്ങളുടെ സ്വന്തം വിഭജന തന്ത്രം എഴുതുന്നു

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

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

{
  "signature": "541661622185851c248b41bf0cea7ad0",
  "accountId": "10007865234"
}

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

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

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

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

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

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

ക്ലസ്റ്ററുകൾക്കിടയിൽ പകർത്തുമ്പോൾ സന്ദേശങ്ങൾക്കിടയിൽ ആപേക്ഷിക ക്രമം നിലനിർത്താൻ മിറർ മേക്കർ, ആ വിഷയത്തിന്റെ കീകൾ മനസ്സിലാക്കണം, കാരണം ആ വിഷയത്തിനായുള്ള പാർട്ടീഷനുകളുടെ എണ്ണം രണ്ട് ക്ലസ്റ്ററുകളിൽ തുല്യമായിരിക്കില്ല.

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

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

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

പ്രൊഡ്യൂസർ ഉടമ്പടികൾ

സന്ദേശങ്ങൾ അയയ്ക്കുമ്പോൾ പാർട്ടീഷനിംഗ് മാത്രമല്ല പരിഗണിക്കേണ്ടത്. ജാവ എപിഐയിലെ പ്രൊഡ്യൂസർ ക്ലാസിന്റെ അയക്കുന്ന () രീതികൾ നോക്കാം:

Future < RecordMetadata > send(ProducerRecord < K, V > record);
Future < RecordMetadata > send(ProducerRecord < K, V > record, Callback callback);

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

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

RecordMetadata metadata = producer.send(record).get();

സന്ദേശങ്ങൾ വായിക്കുന്നതിനെക്കുറിച്ച് കൂടുതൽ

സന്ദേശങ്ങൾ വായിക്കുന്നതിന് കൂടുതൽ സങ്കീർണതകൾ ഉണ്ട്, അത് ഊഹിക്കേണ്ടതുണ്ട്. ഒരു സന്ദേശത്തിന് പ്രതികരണമായി ഒരു സന്ദേശ ശ്രോതാവിനെ പ്രവർത്തിപ്പിക്കാൻ കഴിയുന്ന JMS API-യിൽ നിന്ന് വ്യത്യസ്തമായി, ദി ഉപഭോക്തൃ കാഫ്ക വോട്ടെടുപ്പ് മാത്രം. നമുക്ക് രീതി കൂടുതൽ വിശദമായി പരിശോധിക്കാം വോട്ടെടുപ്പ്()ഈ ആവശ്യത്തിനായി ഉപയോഗിക്കുന്നു:

ConsumerRecords < K, V > poll(long timeout);

ഒന്നിലധികം വസ്തുക്കൾ അടങ്ങുന്ന ഒരു കണ്ടെയ്നർ ഘടനയാണ് രീതിയുടെ റിട്ടേൺ മൂല്യം ഉപഭോക്തൃ റെക്കോർഡ് സാധ്യതയുള്ള നിരവധി പാർട്ടീഷനുകളിൽ നിന്ന്. ഉപഭോക്തൃ റെക്കോർഡ് അത് ഉരുത്തിരിഞ്ഞ പാർട്ടീഷൻ പോലെയുള്ള അനുബന്ധ മെറ്റാഡാറ്റയോടുകൂടിയ ഒരു കീ-വാല്യൂ ജോഡിക്കുള്ള ഹോൾഡർ ഒബ്‌ജക്റ്റാണ്.

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

ഞങ്ങൾ പറഞ്ഞതുപോലെ, ഉപഭോക്തൃ ഗ്രൂപ്പ് ലോഗിലെ ഓഫ്സെറ്റുമായി ബന്ധപ്പെട്ടിരിക്കുന്നു. ഈ ഓഫ്‌സെറ്റുമായി ബന്ധപ്പെട്ട ലോഗ് സ്ഥാനം പ്രതികരണമായി നൽകേണ്ട അടുത്ത സന്ദേശവുമായി പൊരുത്തപ്പെടുന്നു വോട്ടെടുപ്പ്(). ഈ ഓഫ്‌സെറ്റ് വർദ്ധിക്കുന്ന കാലഘട്ടം വായനയ്ക്ക് നിർണായകമാണ്.

മുമ്പ് ചർച്ച ചെയ്ത വായനാ മാതൃകയിലേക്ക് മടങ്ങുമ്പോൾ, സന്ദേശ പ്രോസസ്സിംഗ് മൂന്ന് ഘട്ടങ്ങൾ ഉൾക്കൊള്ളുന്നു:

1. വായനയ്ക്കായി ഒരു സന്ദേശം വീണ്ടെടുക്കുക.
2. സന്ദേശം പ്രോസസ്സ് ചെയ്യുക.
3. സന്ദേശം സ്ഥിരീകരിക്കുക.

കാഫ്ക ഉപഭോക്താവ് ഒരു കോൺഫിഗറേഷൻ ഓപ്ഷനുമായാണ് വരുന്നത് enable.auto.commit. "ഓട്ടോ" എന്ന വാക്ക് അടങ്ങുന്ന സജ്ജീകരണങ്ങളിൽ സാധാരണയായി ഉപയോഗിക്കുന്ന ഒരു സ്ഥിരസ്ഥിതി ക്രമീകരണമാണിത്.

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

കാഫ്ക 0.10-ൽ, ക്ലയന്റ് കോഡ് മാറ്റിയതിനാൽ കോൺഫിഗർ ചെയ്തതുപോലെ, ക്ലയന്റ് ലൈബ്രറി ഇടയ്‌ക്കിടെ കമ്മിറ്റ് പ്രവർത്തനക്ഷമമാക്കും. auto.commit.interval.ms. ഈ സ്വഭാവം JMS AUTO_ACKNOWLEDGE, DUPS_OK_ACKNOWLEDGE എന്നീ മോഡുകൾക്ക് ഇടയിലാണ്. ഓട്ടോകമ്മിറ്റ് ഉപയോഗിക്കുമ്പോൾ, സന്ദേശങ്ങൾ യഥാർത്ഥത്തിൽ പ്രോസസ്സ് ചെയ്തിട്ടുണ്ടോ എന്നത് പരിഗണിക്കാതെ തന്നെ പ്രതിജ്ഞാബദ്ധമാക്കാം - ഇത് വേഗത കുറഞ്ഞ ഉപഭോക്താവിന്റെ കാര്യത്തിൽ സംഭവിക്കാം. ഒരു ഉപഭോക്താവ് നിർത്തലാക്കുകയാണെങ്കിൽ, അടുത്ത ഉപഭോക്താവിന് സന്ദേശങ്ങൾ ലഭിക്കും, അത് പ്രതിജ്ഞാബദ്ധമായ സ്ഥാനത്ത് നിന്ന് ആരംഭിക്കും, ഇത് ഒരു മിസ്ഡ് മെസേജിലേക്ക് നയിച്ചേക്കാം. ഈ സാഹചര്യത്തിൽ, കാഫ്കയ്ക്ക് സന്ദേശങ്ങൾ നഷ്‌ടമായില്ല, റീഡിംഗ് കോഡ് അവ പ്രോസസ്സ് ചെയ്തില്ല.

ഈ മോഡ് പതിപ്പ് 0.9-ലെ അതേ വാഗ്ദാനമുണ്ട്: സന്ദേശങ്ങൾ പ്രോസസ്സ് ചെയ്യാൻ കഴിയും, പക്ഷേ അത് പരാജയപ്പെടുകയാണെങ്കിൽ, ഓഫ്‌സെറ്റ് പ്രതിജ്ഞാബദ്ധമായേക്കില്ല, ഇത് ഡെലിവറി ഇരട്ടിയാക്കാൻ സാധ്യതയുണ്ട്. എക്സിക്യൂട്ട് ചെയ്യുമ്പോൾ നിങ്ങൾക്ക് ലഭിക്കുന്ന കൂടുതൽ സന്ദേശങ്ങൾ വോട്ടെടുപ്പ്(), ഈ പ്രശ്നം കൂടുതൽ.

പേജ് 21-ലെ "ഒരു ക്യൂവിൽ നിന്നുള്ള സന്ദേശങ്ങൾ വായിക്കുന്നു" എന്നതിൽ ചർച്ച ചെയ്തതുപോലെ, പരാജയ മോഡുകൾ കണക്കിലെടുക്കുമ്പോൾ ഒരു സന്ദേശമയയ്‌ക്കൽ സിസ്റ്റത്തിൽ ഒരു സന്ദേശം ഒറ്റത്തവണ ഡെലിവറി ചെയ്യുന്നതായി ഒന്നുമില്ല.

കാഫ്കയിൽ, ഒരു ഓഫ്‌സെറ്റ് (ഓഫ്‌സെറ്റ്) ചെയ്യാൻ (കമ്മിറ്റ്) രണ്ട് വഴികളുണ്ട്: സ്വയമേവയും സ്വമേധയാ. രണ്ട് സാഹചര്യങ്ങളിലും, സന്ദേശം പ്രോസസ്സ് ചെയ്‌തെങ്കിലും കമ്മിറ്റിന് മുമ്പ് പരാജയപ്പെട്ടാൽ സന്ദേശങ്ങൾ ഒന്നിലധികം തവണ പ്രോസസ്സ് ചെയ്യാൻ കഴിയും. പ്രതിബദ്ധത പശ്ചാത്തലത്തിൽ സംഭവിക്കുകയും നിങ്ങളുടെ കോഡ് പ്രോസസ്സ് ചെയ്യുന്നതിന് മുമ്പായി പൂർത്തിയാക്കുകയും ചെയ്താൽ (ഒരുപക്ഷേ കാഫ്ക 0.9-ലും അതിനുമുമ്പും) സന്ദേശം പ്രോസസ്സ് ചെയ്യരുതെന്നും നിങ്ങൾക്ക് തിരഞ്ഞെടുക്കാം.

പരാമീറ്റർ സജ്ജീകരിക്കുന്നതിലൂടെ നിങ്ങൾക്ക് കാഫ്ക കൺസ്യൂമർ API-ൽ മാനുവൽ ഓഫ്‌സെറ്റ് കമ്മിറ്റ് പ്രോസസ്സ് നിയന്ത്രിക്കാനാകും enable.auto.commit ഇനിപ്പറയുന്ന രീതികളിലൊന്ന് തെറ്റായതും വ്യക്തമായും വിളിക്കാൻ:

void commitSync();
void commitAsync();

നിങ്ങൾക്ക് "ഒരിക്കലെങ്കിലും" സന്ദേശം പ്രോസസ്സ് ചെയ്യണമെങ്കിൽ, നിങ്ങൾ ഓഫ്സെറ്റ് സ്വമേധയാ ചെയ്യേണ്ടതുണ്ട് സമന്വയം()സന്ദേശങ്ങൾ പ്രോസസ്സ് ചെയ്ത ഉടൻ തന്നെ ഈ കമാൻഡ് എക്സിക്യൂട്ട് ചെയ്യുന്നതിലൂടെ.

ഈ രീതികൾ സന്ദേശങ്ങൾ പ്രോസസ്സ് ചെയ്യുന്നതിനുമുമ്പ് അംഗീകരിക്കാൻ അനുവദിക്കുന്നില്ല, എന്നാൽ ഇടപാട് നടത്തുന്നതിന് സാധ്യതയുള്ള പ്രോസസ്സിംഗ് കാലതാമസം ഇല്ലാതാക്കാൻ അവ ഒന്നും ചെയ്യുന്നില്ല. കാഫ്കയിൽ ഇടപാടുകളൊന്നുമില്ല. ഉപഭോക്താവിന് ഇനിപ്പറയുന്നവ ചെയ്യാനുള്ള കഴിവില്ല:

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

നമുക്ക് ഇടപാടുകളെ ആശ്രയിക്കാൻ കഴിയുന്നില്ലെങ്കിൽ, പരമ്പരാഗത സന്ദേശമയയ്‌ക്കൽ സംവിധാനങ്ങൾ നൽകുന്നവയോട് അടുത്ത് നമുക്ക് എങ്ങനെ അർത്ഥശാസ്‌ത്രം നൽകാനാകും?

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

void seek(TopicPartition partition, long offset);
void seekToBeginning(Collection < TopicPartition > partitions);

രീതി അന്വേഷിക്കുക() രീതി ഉപയോഗിച്ച് ഉപയോഗിക്കാം
ഓഫ്സെറ്റുകൾ ഫോർ ടൈംസ്(മാപ്പ് തിരയാനുള്ള സമയമുദ്രകൾ) ഭൂതകാലത്തിലെ ചില പ്രത്യേക ഘട്ടത്തിൽ ഒരു അവസ്ഥയിലേക്ക് റിവൈൻഡ് ചെയ്യാൻ.

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

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

സന്ദേശങ്ങളുടെ തീവ്രത കൂടുന്നതിനനുസരിച്ച് ഓരോ വ്യക്തിഗത സന്ദേശത്തിന്റെയും മൂല്യം കുറയുന്നതായി വ്യക്തിഗത നിരീക്ഷണങ്ങൾ കാണിക്കുന്നു. ഒരു സമാഹരിച്ച രൂപത്തിൽ കാണുമ്പോൾ വലിയ സന്ദേശങ്ങൾ വിലപ്പെട്ടതാണ്.

ഉയർന്ന ലഭ്യത

ഉയർന്ന ലഭ്യതയോടുള്ള കാഫ്കയുടെ സമീപനം ActiveMQ-ന്റെ സമീപനത്തിൽ നിന്ന് വളരെ വ്യത്യസ്തമാണ്. എല്ലാ ബ്രോക്കർ സംഭവങ്ങളും ഒരേ സമയം സന്ദേശങ്ങൾ സ്വീകരിക്കുകയും വിതരണം ചെയ്യുകയും ചെയ്യുന്ന സ്കെയിൽ-ഔട്ട് ക്ലസ്റ്ററുകളെ ചുറ്റിപ്പറ്റിയാണ് കാഫ്ക രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്.

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

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

ഒരു സെർവർ ക്ലസ്റ്ററുമായി ബന്ധിപ്പിച്ചിരിക്കുന്ന ബ്രോക്കർമാർ മൃഗശാല സൂക്ഷിപ്പുകാരൻ, ഇത് ഒരു കോൺഫിഗറേഷൻ ഡാറ്റ രജിസ്ട്രിയായി പ്രവർത്തിക്കുകയും ഓരോ ബ്രോക്കറുടെയും റോളുകൾ ഏകോപിപ്പിക്കാൻ ഉപയോഗിക്കുകയും ചെയ്യുന്നു. ZooKeeper തന്നെ ഒരു വിതരണ സംവിധാനമാണ്, അത് സ്ഥാപിക്കുന്നതിലൂടെ വിവരങ്ങളുടെ പകർപ്പിലൂടെ ഉയർന്ന ലഭ്യത നൽകുന്നു കോറം.

അടിസ്ഥാന സാഹചര്യത്തിൽ, ഇനിപ്പറയുന്ന ഗുണങ്ങളുള്ള ഒരു കാഫ്ക ക്ലസ്റ്ററിൽ ഒരു വിഷയം സൃഷ്ടിക്കപ്പെടുന്നു:

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

ഏകോപനത്തിനായി ZooKeepers ഉപയോഗിച്ച്, ക്ലസ്റ്ററിലെ ബ്രോക്കർമാർക്കിടയിൽ പുതിയ പാർട്ടീഷനുകൾ ന്യായമായി വിതരണം ചെയ്യാൻ കാഫ്ക ശ്രമിക്കുന്നു. ഒരു കൺട്രോളറായി പ്രവർത്തിക്കുന്ന ഒരൊറ്റ ഉദാഹരണത്തിലൂടെയാണ് ഇത് ചെയ്യുന്നത്.

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

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

പ്രൊഡ്യൂസർ കോൺഫിഗറേഷന്റെ ഭാഗമാണ് പരാമീറ്റർ അക്കുകൾ, ആപ്ലിക്കേഷൻ ത്രെഡ് അയയ്‌ക്കുന്നത് തുടരുന്നതിന് മുമ്പ് ഒരു സന്ദേശത്തിന്റെ രസീത് എത്ര പകർപ്പുകൾ അംഗീകരിക്കണം (അംഗീകരിക്കണം) എന്ന് ഇത് നിർണ്ണയിക്കുന്നു: 0, 1, അല്ലെങ്കിൽ എല്ലാം. സജ്ജമാക്കിയാൽ എല്ലാം, പിന്നീട് ഒരു സന്ദേശം ലഭിക്കുമ്പോൾ, വിഷയ ക്രമീകരണം നിർവചിച്ചിരിക്കുന്ന നിരവധി സൂചകങ്ങളിൽ നിന്ന് (സ്വയം ഉൾപ്പെടെ) റെക്കോർഡിന്റെ സ്ഥിരീകരണങ്ങൾ (അംഗീകാരങ്ങൾ) ലഭിച്ചാലുടൻ നേതാവ് ഒരു സ്ഥിരീകരണം നിർമ്മാതാവിന് തിരികെ അയയ്ക്കും. min.insync.replicas (സ്ഥിരസ്ഥിതി 1). സന്ദേശം വിജയകരമായി പകർത്താൻ കഴിയുന്നില്ലെങ്കിൽ, നിർമ്മാതാവ് ഒരു ആപ്ലിക്കേഷൻ ഒഴിവാക്കും (NotEnoughReplicas അഥവാ NotEnoughReplicasAfterAppend).

ഒരു സാധാരണ കോൺഫിഗറേഷൻ 3 (1 ലീഡർ, ഓരോ പാർട്ടീഷനും 2 ഫോളോവേഴ്‌സ്) പാരാമീറ്ററിന്റെ പകർപ്പെടുക്കൽ ഘടകം ഉള്ള ഒരു വിഷയം സൃഷ്ടിക്കുന്നു. min.insync.replicas 2 ആയി സജ്ജീകരിച്ചിരിക്കുന്നു. ഈ സാഹചര്യത്തിൽ, ക്ലയന്റ് ആപ്ലിക്കേഷനുകളെ ബാധിക്കാതെ ടോപ്പിക്ക് പാർട്ടീഷൻ നിയന്ത്രിക്കുന്ന ബ്രോക്കർമാരിൽ ഒരാളെ ക്ലസ്റ്റർ അനുവദിക്കും.

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

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

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

ഒരൊറ്റ കാഫ്ക ബ്രോക്കറിനേക്കാൾ മികച്ച പ്രകടനം കാഫ്ക ക്ലസ്റ്ററിൽ സാധ്യമാണ്, കാരണം വിഷയ പാർട്ടീഷനുകൾ പല വ്യത്യസ്ത മെഷീനുകളിൽ സ്കെയിൽ ചെയ്യാൻ കഴിയും.

ഫലങ്ങൾ

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

മുമ്പ് വിവർത്തനം ചെയ്ത ഭാഗം: സന്ദേശ ബ്രോക്കർമാരെ മനസ്സിലാക്കുന്നു. ActiveMQ, Kafka എന്നിവ ഉപയോഗിച്ച് സന്ദേശമയയ്‌ക്കുന്നതിനുള്ള മെക്കാനിക്‌സ് പഠിക്കുന്നു. അധ്യായം 1

വിവർത്തനം ചെയ്തു: tele.gg/middle_java

തുടരേണ്ടത് ...

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

നിങ്ങളുടെ സ്ഥാപനത്തിൽ കാഫ്ക ഉപയോഗിക്കുന്നുണ്ടോ?

• ആ

• ഇല്ല

• മുമ്പ് ഉപയോഗിച്ചിരുന്നു, ഇപ്പോൾ ഇല്ല

• ഉപയോഗിക്കാൻ ഞങ്ങൾ പദ്ധതിയിടുന്നു

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

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