సందేశ బ్రోకర్లను అర్థం చేసుకోవడం. ActiveMQ మరియు కాఫ్కాతో మెసేజింగ్ మెకానిక్‌లను నేర్చుకోవడం. అధ్యాయం 3. కాఫ్కా

ఒక చిన్న పుస్తకం యొక్క అనువాదం యొక్క కొనసాగింపు:
సందేశ బ్రోకర్లను అర్థం చేసుకోవడం
రచయిత: జాకుబ్ కోరాబ్, ప్రచురణకర్త: ఓ'రైల్లీ మీడియా, ఇంక్., ప్రచురణ తేదీ: జూన్ 2017, ISBN: 9781492049296.

మునుపటి అనువదించబడిన భాగం: సందేశ బ్రోకర్లను అర్థం చేసుకోవడం. ActiveMQ మరియు కాఫ్కాతో మెసేజింగ్ మెకానిక్‌లను నేర్చుకోవడం. చాప్టర్ 1 పరిచయం

3 వ అధ్యాయము

కాఫ్కా

సాంప్రదాయ సందేశ బ్రోకర్ల యొక్క కొన్ని పరిమితులను అధిగమించడానికి మరియు విభిన్న పాయింట్-టు-పాయింట్ ఇంటరాక్షన్‌ల కోసం బహుళ సందేశ బ్రోకర్‌లను సెటప్ చేయకుండా ఉండటానికి లింక్డ్‌ఇన్ ద్వారా కాఫ్కా అభివృద్ధి చేయబడింది, ఇది ఈ పుస్తకంలో పేజీ 28లోని "స్కేలింగ్ అప్ అండ్ అవుట్" క్రింద వివరించబడింది. ఉత్పత్తిదారులు లేదా ఇతర వినియోగదారుల ఉత్పాదకతపై ప్రభావం చూపకుండా బహుళ సిస్టమ్‌ల ద్వారా ఆ డేటాను ఉపయోగించేందుకు ఇప్పటికీ అనుమతిస్తూనే, పేజీ క్లిక్‌లు మరియు యాక్సెస్ లాగ్‌ల వంటి అతి పెద్ద మొత్తంలో డేటాను వన్-వే ఇన్‌జెషన్‌పై ఆధారపడిన సందర్భాలను ఉపయోగించండి. వాస్తవానికి, యూనివర్సల్ డేటా పైప్‌లైన్ వివరించే రకమైన మెసేజింగ్ ఆర్కిటెక్చర్‌ని పొందడం కోసం కాఫ్కా ఉనికిలో ఉంది.

ఈ అంతిమ లక్ష్యం కారణంగా, ఇతర అవసరాలు సహజంగా తలెత్తాయి. కాఫ్కా చేయాలి:

• చాలా వేగంగా ఉండండి
• సందేశాలతో పని చేస్తున్నప్పుడు మరింత బ్యాండ్‌విడ్త్‌ను అందించండి
• పబ్లిషర్-సబ్స్క్రయిబర్ మరియు పాయింట్-టు-పాయింట్ మోడల్‌లకు మద్దతు ఇవ్వండి
• వినియోగదారులను జోడించడంలో నెమ్మదించవద్దు. ఉదాహరణకు, గమ్యస్థానంలో వినియోగదారుల సంఖ్య పెరిగే కొద్దీ ActiveMQలోని క్యూ మరియు టాపిక్ రెండింటి పనితీరు క్షీణిస్తుంది.
• క్షితిజ సమాంతరంగా కొలవగలగా ఉండండి; మెసేజ్‌లను కొనసాగించే ఒక బ్రోకర్ గరిష్ట డిస్క్ వేగంతో మాత్రమే చేయగలిగితే, పనితీరును పెంచడానికి ఒకే బ్రోకర్ ఉదాహరణకి మించి వెళ్లడం అర్ధమే.
• సందేశాలను నిల్వ చేయడానికి మరియు తిరిగి పొందేందుకు ప్రాప్యతను పరిమితం చేయండి

వీటన్నింటిని సాధించడానికి, కాఫ్కా క్లయింట్‌లు మరియు మెసేజింగ్ బ్రోకర్ల పాత్రలు మరియు బాధ్యతలను పునర్నిర్వచించే నిర్మాణాన్ని అవలంబించారు. JMS మోడల్ చాలా బ్రోకర్ ఆధారితమైనది, ఇక్కడ సందేశాలను పంపిణీ చేయడానికి బ్రోకర్ బాధ్యత వహిస్తాడు మరియు క్లయింట్‌లు సందేశాలను పంపడం మరియు స్వీకరించడం గురించి మాత్రమే ఆందోళన చెందాలి. కాఫ్కా, మరోవైపు, క్లయింట్-కేంద్రీకృతమైనది, క్లయింట్ చాలా వేగవంతమైన మరియు స్కేలబుల్ బ్రోకర్‌కు బదులుగా వినియోగదారులకు సంబంధిత సందేశాల న్యాయమైన పంపిణీ వంటి సాంప్రదాయ బ్రోకర్ యొక్క అనేక లక్షణాలను తీసుకుంటుంది. సాంప్రదాయ మెసేజింగ్ సిస్టమ్‌లతో పనిచేసిన వ్యక్తుల కోసం, కాఫ్కాతో పనిచేయడానికి ప్రాథమికంగా మనస్సులో మార్పు అవసరం.
ఈ ఇంజనీరింగ్ దిశ సంప్రదాయ బ్రోకర్‌తో పోలిస్తే అనేక ఆర్డర్‌ల మాగ్నిట్యూడ్ ద్వారా నిర్గమాంశను పెంచే సామర్థ్యం గల మెసేజింగ్ ఇన్‌ఫ్రాస్ట్రక్చర్‌ను రూపొందించడానికి దారితీసింది. మనం చూడబోతున్నట్లుగా, ఈ విధానం ట్రేడ్-ఆఫ్‌లతో వస్తుంది, అంటే కొన్ని రకాల పనిభారం మరియు ఇన్‌స్టాల్ చేయబడిన సాఫ్ట్‌వేర్‌లకు కాఫ్కా తగినది కాదు.

ఏకీకృత డెస్టినేషన్ మోడల్

పైన వివరించిన అవసరాలను నెరవేర్చడానికి, కాఫ్కా ఒక రకమైన గమ్యస్థానం కింద పబ్లిష్-సబ్‌స్క్రైబ్ మరియు పాయింట్-టు-పాయింట్ మెసేజింగ్‌లను మిళితం చేసింది - అంశం. మెసేజింగ్ సిస్టమ్‌లతో పనిచేసిన వ్యక్తులకు ఇది గందరగోళంగా ఉంది, ఇక్కడ "టాపిక్" అనే పదం ప్రసార యంత్రాంగాన్ని సూచిస్తుంది, దీని నుండి (అంశం నుండి) చదవడం మన్నికైనది కాదు. ఈ పుస్తక పరిచయంలో నిర్వచించినట్లుగా, కాఫ్కా అంశాలను హైబ్రిడ్ గమ్యస్థాన రకంగా పరిగణించాలి.

ఈ అధ్యాయంలోని మిగిలిన భాగంలో, మేము స్పష్టంగా చెప్పకపోతే, "టాపిక్" అనే పదం కాఫ్కా అంశాన్ని సూచిస్తుంది.

టాపిక్‌లు ఎలా ప్రవర్తిస్తాయో మరియు అవి ఏ హామీలను అందిస్తాయో పూర్తిగా అర్థం చేసుకోవడానికి, కాఫ్కాలో అవి ఎలా అమలు చేయబడతాయో మనం మొదట చూడాలి.
కాఫ్కాలోని ప్రతి అంశానికి దాని స్వంత లాగ్ ఉంటుంది.
కాఫ్కాకు సందేశాలను పంపే నిర్మాతలు ఈ లాగ్‌కు వ్రాస్తారు మరియు వినియోగదారులు నిరంతరం ముందుకు సాగే పాయింటర్‌లను ఉపయోగించి లాగ్ నుండి చదువుతారు. కాలానుగుణంగా, కాఫ్కా లాగ్‌లోని పురాతన భాగాలను తొలగిస్తుంది, ఆ భాగాలలోని సందేశాలు చదవబడినా లేదా చదవకపోయినా. కాఫ్కా రూపకల్పనలో ప్రధాన భాగం ఏమిటంటే, మెసేజ్‌లు చదవబడినా లేదా చదవకపోయినా బ్రోకర్ పట్టించుకోడు - అది క్లయింట్ యొక్క బాధ్యత.

"లాగ్" మరియు "పాయింటర్" అనే పదాలు కనిపించవు కాఫ్కా డాక్యుమెంటేషన్. ఈ ప్రసిద్ధ పదాలు అవగాహనకు సహాయపడటానికి ఇక్కడ ఉపయోగించబడ్డాయి.

ఈ మోడల్ ActiveMQ నుండి పూర్తిగా భిన్నంగా ఉంటుంది, ఇక్కడ అన్ని క్యూల నుండి సందేశాలు ఒకే లాగ్‌లో నిల్వ చేయబడతాయి మరియు బ్రోకర్ సందేశాలను చదివిన తర్వాత తొలగించబడినట్లు గుర్తు పెడుతుంది.
ఇప్పుడు కొంచెం లోతుగా త్రవ్వి, టాపిక్ లాగ్‌ను మరింత వివరంగా చూద్దాం.
కాఫ్కా లాగ్ అనేక విభజనలను కలిగి ఉంటుంది (మూర్తి 3-1) కాఫ్కా ప్రతి విభజనలో కఠినమైన క్రమాన్ని హామీ ఇస్తుంది. విభజనకు ఒక నిర్దిష్ట క్రమంలో వ్రాసిన సందేశాలు అదే క్రమంలో చదవబడతాయి. ప్రతి విభజన రోలింగ్ లాగ్ ఫైల్‌గా అమలు చేయబడుతుంది ఒక ఉపసమితి దాని నిర్మాతలు టాపిక్‌కి పంపిన అన్ని సందేశాల (ఉపసమితి). సృష్టించబడిన అంశం డిఫాల్ట్‌గా ఒక విభజనను కలిగి ఉంటుంది. విభజనల ఆలోచన క్షితిజ సమాంతర స్కేలింగ్ కోసం కాఫ్కా యొక్క కేంద్ర ఆలోచన.

మూర్తి 3-1. కాఫ్కా విభజనలు

నిర్మాత కాఫ్కా టాపిక్‌కి సందేశం పంపినప్పుడు, ఆ సందేశాన్ని ఏ విభజనకు పంపాలో అది నిర్ణయిస్తుంది. మేము దీనిని మరింత వివరంగా తరువాత పరిశీలిస్తాము.

సందేశాలను చదవడం

సందేశాలను చదవాలనుకునే క్లయింట్ పేరు పెట్టబడిన పాయింటర్‌ను నిర్వహిస్తుంది వినియోగదారు సమూహం, ఇది సూచిస్తుంది ఆఫ్సెట్ విభజనలో సందేశాలు. ఆఫ్‌సెట్ అనేది విభజన ప్రారంభంలో 0 వద్ద ప్రారంభమయ్యే ఇంక్రిమెంటల్ స్థానం. వినియోగదారు నిర్వచించిన group_id ద్వారా APIలో సూచించబడిన ఈ వినియోగదారు సమూహం దీనికి అనుగుణంగా ఉంటుంది ఒక తార్కిక వినియోగదారు లేదా వ్యవస్థ.

చాలా మెసేజింగ్ సిస్టమ్‌లు సందేశాలను సమాంతరంగా ప్రాసెస్ చేయడానికి బహుళ సందర్భాలు మరియు థ్రెడ్‌లను ఉపయోగించి గమ్యం నుండి డేటాను రీడ్ చేస్తాయి. అందువల్ల, ఒకే వినియోగదారు సమూహాన్ని పంచుకునే అనేక వినియోగదారు సందర్భాలు సాధారణంగా ఉంటాయి.

పఠనం యొక్క సమస్యను ఈ క్రింది విధంగా సూచించవచ్చు:

• అంశం బహుళ విభజనలను కలిగి ఉంది
• వినియోగదారుల యొక్క బహుళ సమూహాలు ఒకే సమయంలో ఒక అంశాన్ని ఉపయోగించవచ్చు
• వినియోగదారుల సమూహం బహుళ ప్రత్యేక సందర్భాలను కలిగి ఉండవచ్చు

ఇది సామాన్యమైనది కాని అనేక నుండి అనేక సమస్య. వినియోగదారు సమూహాలు, వినియోగదారు సందర్భాలు మరియు విభజనల మధ్య సంబంధాలను కాఫ్కా ఎలా నిర్వహిస్తుందో అర్థం చేసుకోవడానికి, క్రమంగా మరింత క్లిష్టమైన పఠన దృశ్యాల శ్రేణిని చూద్దాం.

వినియోగదారులు మరియు వినియోగదారుల సమూహాలు

ఒక విభజనతో ఒక అంశాన్ని ప్రారంభ బిందువుగా తీసుకుందాం (మూర్తి 3-2).

మూర్తి 3-2. విభజన నుండి వినియోగదారు చదివారు

వినియోగదారు ఉదాహరణ ఈ అంశానికి దాని స్వంత group_idతో కనెక్ట్ అయినప్పుడు, దానికి రీడ్ విభజన మరియు ఆ విభజనలో ఆఫ్‌సెట్ కేటాయించబడుతుంది. ఈ ఆఫ్‌సెట్ యొక్క స్థానం క్లయింట్‌లో అత్యంత ఇటీవలి స్థానం (సరికొత్త సందేశం) లేదా ప్రారంభ స్థానానికి (పాత సందేశం) పాయింటర్‌గా కాన్ఫిగర్ చేయబడింది. వినియోగదారు టాపిక్ నుండి సందేశాలను అభ్యర్థిస్తుంది (పోల్స్), ఇది వాటిని లాగ్ నుండి వరుసగా చదవడానికి కారణమవుతుంది.
ఆఫ్‌సెట్ స్థానం క్రమం తప్పకుండా కాఫ్కాకు కట్టుబడి ఉంటుంది మరియు అంతర్గత అంశంలో సందేశాలుగా నిల్వ చేయబడుతుంది _వినియోగదారు_ఆఫ్‌సెట్‌లు. సాధారణ బ్రోకర్ వలె కాకుండా చదివిన సందేశాలు ఇప్పటికీ తొలగించబడలేదు మరియు క్లయింట్ ఇప్పటికే వీక్షించిన సందేశాలను మళ్లీ ప్రాసెస్ చేయడానికి ఆఫ్‌సెట్‌ను రివైండ్ చేయవచ్చు.

రెండవ తార్కిక వినియోగదారుడు వేరొక group_idని ఉపయోగించి కనెక్ట్ చేసినప్పుడు, ఇది మొదటిదానితో సంబంధం లేకుండా రెండవ పాయింటర్‌ను నిర్వహిస్తుంది (మూర్తి 3-3) అందువల్ల, కాఫ్కా అంశం ఒక వినియోగదారు ఉన్న క్యూ లాగా మరియు బహుళ వినియోగదారులు సబ్‌స్క్రైబ్ చేసే సాధారణ ప్రచురణ-చందా (పబ్-సబ్) అంశం వలె పనిచేస్తుంది, అన్ని సందేశాలు నిల్వ చేయబడతాయి మరియు అనేకసార్లు ప్రాసెస్ చేయబడతాయి అనే అదనపు ప్రయోజనం ఉంటుంది.

మూర్తి 3-3. వేర్వేరు వినియోగదారు సమూహాలలో ఇద్దరు వినియోగదారులు ఒకే విభజన నుండి చదువుతారు

వినియోగదారు సమూహంలో వినియోగదారులు

ఒక వినియోగదారు ఉదాహరణ విభజన నుండి డేటాను చదివినప్పుడు, అది పాయింటర్‌పై పూర్తి నియంత్రణను కలిగి ఉంటుంది మరియు మునుపటి విభాగంలో వివరించిన విధంగా సందేశాలను ప్రాసెస్ చేస్తుంది.
వినియోగదారుల యొక్క అనేక సందర్భాలు ఒకే గ్రూప్_ఐడితో ఒక విభజనతో ఒక అంశానికి కనెక్ట్ చేయబడితే, చివరిగా కనెక్ట్ చేయబడిన సందర్భానికి పాయింటర్‌పై నియంత్రణ ఇవ్వబడుతుంది మరియు ఆ క్షణం నుండి అది అన్ని సందేశాలను అందుకుంటుంది (మూర్తి 3-4).

మూర్తి 3-4. ఒకే వినియోగదారు సమూహంలోని ఇద్దరు వినియోగదారులు ఒకే విభజన నుండి చదివారు

ఈ ప్రాసెసింగ్ మోడ్, దీనిలో వినియోగదారు ఉదాహరణల సంఖ్య విభజనల సంఖ్యను మించిపోయింది, ఇది ఒక రకమైన ప్రత్యేకమైన వినియోగదారుగా పరిగణించబడుతుంది. బహుళ వినియోగదారులను సమాంతరంగా ("యాక్టివ్-యాక్టివ్" లేదా "హాట్-హాట్") అమలు చేయడం చాలా విలక్షణమైనప్పటికీ, మీకు మీ వినియోగదారు సందర్భాల క్లస్టరింగ్ "యాక్టివ్-పాసివ్" (లేదా "హాట్-వార్మ్") అవసరమైతే ఇది ఉపయోగకరంగా ఉంటుంది. వినియోగదారులు సిద్ధంగా ఉన్నారు.

సాధారణ JMS క్యూ ఎలా ప్రవర్తిస్తుందో దానితో పోలిస్తే పైన వివరించిన ఈ సందేశ పంపిణీ ప్రవర్తన ఆశ్చర్యకరంగా ఉంటుంది. ఈ మోడల్‌లో, క్యూలో పంపబడిన సందేశాలు ఇద్దరు వినియోగదారుల మధ్య సమానంగా పంపిణీ చేయబడతాయి.

చాలా తరచుగా, మేము వినియోగదారుల యొక్క బహుళ సందర్భాలను సృష్టించినప్పుడు, మేము సందేశాలను సమాంతరంగా ప్రాసెస్ చేయడానికి లేదా చదివే వేగాన్ని పెంచడానికి లేదా పఠన ప్రక్రియ యొక్క స్థిరత్వాన్ని పెంచడానికి దీన్ని చేస్తాము. ఒక సమయంలో ఒక వినియోగదారు ఉదాహరణ మాత్రమే విభజన నుండి డేటాను చదవగలదు కాబట్టి, కాఫ్కాలో ఇది ఎలా సాధించబడుతుంది?

దీన్ని చేయడానికి ఒక మార్గం ఏమిటంటే, అన్ని సందేశాలను చదవడానికి మరియు వాటిని థ్రెడ్ పూల్‌కు పంపడానికి ఒకే వినియోగదారు ఉదాహరణను ఉపయోగించడం. ఈ విధానం ప్రాసెసింగ్ నిర్గమాంశను పెంచుతుంది, ఇది వినియోగదారు తర్కం యొక్క సంక్లిష్టతను పెంచుతుంది మరియు పఠన వ్యవస్థ యొక్క పటిష్టతను పెంచడానికి ఏమీ చేయదు. విద్యుత్ వైఫల్యం లేదా ఇలాంటి సంఘటన కారణంగా వినియోగదారు యొక్క ఒక కాపీ తగ్గినట్లయితే, వ్యవకలనం ఆగిపోతుంది.

కాఫ్కాలో ఈ సమస్యను పరిష్కరించడానికి కానానికల్ మార్గం బిОమరిన్ని విభజనలు.

విభజన చేయడం

ఒకే బ్రోకర్ ఉదాహరణ యొక్క బ్యాండ్‌విడ్త్‌కు మించి ఒక అంశాన్ని చదవడం మరియు స్కేలింగ్ చేయడం కోసం విభజనలు ప్రధాన మెకానిజం. దీన్ని బాగా అర్థం చేసుకోవడానికి, రెండు విభజనలతో ఒక అంశం ఉన్న పరిస్థితిని పరిశీలిద్దాం మరియు ఒక వినియోగదారు ఈ అంశానికి సభ్యత్వాన్ని పొందారు (మూర్తి 3-5).

మూర్తి 3-5. ఒక వినియోగదారు బహుళ విభజనల నుండి చదువుతారు

ఈ దృష్టాంతంలో, వినియోగదారుకు రెండు విభజనలలో దాని group_idకి సంబంధించిన పాయింటర్‌లపై నియంత్రణ ఇవ్వబడుతుంది మరియు రెండు విభజనల నుండి సందేశాలను చదవడం ప్రారంభిస్తుంది.
అదే group_id కోసం అదనపు వినియోగదారుని ఈ అంశానికి జోడించినప్పుడు, కాఫ్కా మొదటి నుండి రెండవ వినియోగదారుకి విభజనలలో ఒకదానిని తిరిగి కేటాయించింది. ఆ తరువాత, వినియోగదారు యొక్క ప్రతి ఉదాహరణ అంశం యొక్క ఒక విభజన నుండి చదవబడుతుంది (మూర్తి 3-6).

సందేశాలు 20 థ్రెడ్‌లలో సమాంతరంగా ప్రాసెస్ చేయబడతాయని నిర్ధారించుకోవడానికి, మీకు కనీసం 20 విభజనలు అవసరం. తక్కువ విభజనలు ఉన్నట్లయితే, ప్రత్యేకమైన వినియోగదారుల చర్చలో ముందుగా వివరించిన విధంగా మీరు పని చేయడానికి ఏమీ లేని వినియోగదారులతో మిగిలిపోతారు.

మూర్తి 3-6. ఒకే వినియోగదారు సమూహంలోని ఇద్దరు వినియోగదారులు వేర్వేరు విభజనల నుండి చదివారు

JMS క్యూను నిర్వహించడానికి అవసరమైన సందేశ పంపిణీతో పోలిస్తే ఈ పథకం కాఫ్కా బ్రోకర్ యొక్క సంక్లిష్టతను బాగా తగ్గిస్తుంది. ఇక్కడ మీరు ఈ క్రింది అంశాల గురించి చింతించాల్సిన అవసరం లేదు:

• రౌండ్-రాబిన్ కేటాయింపు, ప్రీఫెచ్ బఫర్‌ల ప్రస్తుత సామర్థ్యం లేదా మునుపటి సందేశాల ఆధారంగా (JMS సందేశ సమూహాల కోసం) ఏ వినియోగదారు తదుపరి సందేశాన్ని స్వీకరించాలి.
• ఏ వినియోగదారులకు ఏ సందేశాలు పంపబడ్డాయి మరియు విఫలమైతే వాటిని మళ్లీ బట్వాడా చేయాలా.

కాఫ్కా బ్రోకర్ చేయాల్సిందల్లా వినియోగదారుని అభ్యర్థించినప్పుడు వరుసగా సందేశాలను పంపడం.

అయితే, ప్రూఫ్ రీడింగ్‌ను సమాంతరంగా చేయడం మరియు విఫలమైన సందేశాలను మళ్లీ పంపడం వంటి అవసరాలు దూరంగా ఉండవు - వాటి బాధ్యత కేవలం బ్రోకర్ నుండి క్లయింట్‌కు వెళుతుంది. అంటే వాటిని మీ కోడ్‌లో తప్పనిసరిగా పరిగణనలోకి తీసుకోవాలి.

సందేశాలు పంపుతోంది

ఏ విభజనకు సందేశం పంపాలో నిర్ణయించడం ఆ సందేశ నిర్మాత యొక్క బాధ్యత. దీన్ని చేసే మెకానిజమ్‌ను అర్థం చేసుకోవడానికి, ముందుగా మనం సరిగ్గా ఏమి పంపుతున్నామో పరిశీలించాలి.

JMSలో మనం మెటాడేటా (హెడర్‌లు మరియు ప్రాపర్టీస్) మరియు పేలోడ్ (పేలోడ్) ఉన్న బాడీతో కూడిన మెసేజ్ స్ట్రక్చర్‌ని ఉపయోగిస్తాము, కాఫ్కాలో సందేశం జత "కీ-విలువ". సందేశం పేలోడ్ విలువగా పంపబడుతుంది. కీ, మరోవైపు, విభజన కోసం ప్రధానంగా ఉపయోగించబడుతుంది మరియు తప్పనిసరిగా కలిగి ఉండాలి వ్యాపార తర్కం నిర్దిష్ట కీసంబంధిత సందేశాలను ఒకే విభజనలో ఉంచడానికి.

అధ్యాయం 2లో, ఒకే వినియోగదారు ద్వారా సంబంధిత ఈవెంట్‌లను ప్రాసెస్ చేయాల్సిన ఆన్‌లైన్ బెట్టింగ్ దృశ్యాన్ని మేము చర్చించాము:

1. వినియోగదారు ఖాతా కాన్ఫిగర్ చేయబడింది.
2. ఖాతాలో డబ్బు జమ అవుతుంది.
3. ఖాతా నుండి డబ్బును ఉపసంహరించుకునే పందెం వేయబడుతుంది.

ప్రతి ఈవెంట్ ఒక అంశానికి పోస్ట్ చేయబడిన సందేశం అయితే, సహజ కీ ఖాతా ID అవుతుంది.
కాఫ్కా ప్రొడ్యూసర్ APIని ఉపయోగించి సందేశం పంపబడినప్పుడు, అది ఒక విభజన ఫంక్షన్‌కు పంపబడుతుంది, ఇది సందేశం మరియు కాఫ్కా క్లస్టర్ యొక్క ప్రస్తుత స్థితిని బట్టి, సందేశం పంపవలసిన విభజన యొక్క IDని అందిస్తుంది. ఈ ఫీచర్ జావాలో పార్టిషనర్ ఇంటర్‌ఫేస్ ద్వారా అమలు చేయబడుతుంది.

ఈ ఇంటర్ఫేస్ ఇలా కనిపిస్తుంది:

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

పార్టిషనర్ అమలు విభజనను నిర్ణయించడానికి కీపై డిఫాల్ట్ జనరల్-పర్పస్ హ్యాషింగ్ అల్గారిథమ్‌ను ఉపయోగిస్తుంది లేదా కీ పేర్కొనకపోతే రౌండ్-రాబిన్. ఈ డిఫాల్ట్ విలువ చాలా సందర్భాలలో బాగా పని చేస్తుంది. అయితే, భవిష్యత్తులో మీరు మీ స్వంతంగా రాయాలనుకుంటున్నారు.

మీ స్వంత విభజన వ్యూహాన్ని వ్రాయడం

మీరు మెసేజ్ పేలోడ్‌తో పాటు మెటాడేటాను పంపాలనుకుంటున్న ఉదాహరణను చూద్దాం. మా ఉదాహరణలో పేలోడ్ గేమ్ ఖాతాకు డిపాజిట్ చేయడానికి సూచన. సూచన అనేది ట్రాన్స్‌మిషన్‌లో సవరించబడదని మేము హామీ ఇవ్వాలనుకుంటున్నాము మరియు విశ్వసనీయమైన అప్‌స్ట్రీమ్ సిస్టమ్ మాత్రమే ఆ సూచనను ప్రారంభించగలదని నిర్ధారించుకోవాలి. ఈ సందర్భంలో, పంపే మరియు స్వీకరించే వ్యవస్థలు సందేశాన్ని ప్రమాణీకరించడానికి సంతకాన్ని ఉపయోగించడాన్ని అంగీకరిస్తాయి.
సాధారణ JMSలో, మేము కేవలం "మెసేజ్ సిగ్నేచర్" ప్రాపర్టీని నిర్వచించి, దానిని సందేశానికి జోడిస్తాము. అయినప్పటికీ, కాఫ్కా మాకు మెటాడేటాను పాస్ చేసే మెకానిజమ్‌ను అందించదు, కేవలం ఒక కీ మరియు విలువ మాత్రమే.

విలువ అనేది బ్యాంక్ బదిలీ పేలోడ్ అయినందున, దీని సమగ్రతను మనం కాపాడుకోవాలనుకుంటున్నాము, కీలో ఉపయోగించాల్సిన డేటా నిర్మాణాన్ని నిర్వచించడం మినహా మాకు వేరే మార్గం లేదు. విభజన కోసం మనకు ఖాతా ID అవసరమని భావించి, ఖాతాకు సంబంధించిన అన్ని సందేశాలు తప్పనిసరిగా క్రమంలో ప్రాసెస్ చేయబడాలి కాబట్టి, మేము ఈ క్రింది JSON నిర్మాణాన్ని అందిస్తాము:

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

పేలోడ్‌పై ఆధారపడి సంతకం విలువ మారుతుంది కాబట్టి, పార్టిషనర్ ఇంటర్‌ఫేస్ యొక్క డిఫాల్ట్ హ్యాషింగ్ వ్యూహం సంబంధిత సందేశాలను విశ్వసనీయంగా సమూహపరచదు. కాబట్టి, మేము ఈ కీని అన్వయించే మరియు accountId విలువను విభజించే మా స్వంత వ్యూహాన్ని వ్రాయవలసి ఉంటుంది.

స్టోర్‌లోని సందేశాల అవినీతిని గుర్తించడానికి కాఫ్కా చెక్‌సమ్‌లను కలిగి ఉంది మరియు పూర్తి భద్రతా లక్షణాలను కలిగి ఉంది. అయినప్పటికీ, పైన పేర్కొన్నది వంటి పరిశ్రమ-నిర్దిష్ట అవసరాలు కొన్నిసార్లు కనిపిస్తాయి.

వినియోగదారు యొక్క విభజన వ్యూహం తప్పనిసరిగా అన్ని సంబంధిత సందేశాలు ఒకే విభజనలో ముగుస్తుందని నిర్ధారించుకోవాలి. ఇది సరళంగా అనిపించినప్పటికీ, సంబంధిత సందేశాలను ఆర్డర్ చేయడం యొక్క ప్రాముఖ్యత మరియు అంశంలోని విభజనల సంఖ్య ఎంత స్థిరంగా ఉంటుంది అనే దానితో అవసరం సంక్లిష్టంగా ఉంటుంది.

ఒక అంశంలోని విభజనల సంఖ్య కాలక్రమేణా మారవచ్చు, ట్రాఫిక్ ప్రారంభ అంచనాలకు మించి ఉంటే వాటిని జోడించవచ్చు. అందువల్ల, సందేశ కీలు అవి మొదట పంపబడిన విభజనతో అనుబంధించబడతాయి, నిర్మాత సందర్భాల మధ్య భాగస్వామ్యం చేయవలసిన రాష్ట్ర భాగాన్ని సూచిస్తుంది.

విభజనల అంతటా సందేశాల సమాన పంపిణీని పరిగణించవలసిన మరొక అంశం. సాధారణంగా, కీలు సందేశాల అంతటా సమానంగా పంపిణీ చేయబడవు మరియు హ్యాష్ ఫంక్షన్‌లు చిన్న సెట్ కీల కోసం సందేశాల సరసమైన పంపిణీకి హామీ ఇవ్వవు.
మీరు మెసేజ్‌లను విభజించడానికి ఎంచుకున్నప్పటికీ, సెపరేటర్‌నే మళ్లీ ఉపయోగించాల్సి రావచ్చని గమనించడం ముఖ్యం.

వివిధ భౌగోళిక స్థానాల్లో కాఫ్కా క్లస్టర్‌ల మధ్య డేటాను పునరావృతం చేయవలసిన అవసరాన్ని పరిగణించండి. ఈ ప్రయోజనం కోసం, కాఫ్కా MirrorMaker అనే కమాండ్ లైన్ సాధనంతో వస్తుంది, ఇది ఒక క్లస్టర్ నుండి సందేశాలను చదవడానికి మరియు వాటిని మరొక క్లస్టర్‌కు బదిలీ చేయడానికి ఉపయోగించబడుతుంది.

మిర్రర్‌మేకర్ క్లస్టర్‌ల మధ్య ప్రతిరూపం చేసేటప్పుడు సందేశాల మధ్య సాపేక్ష క్రమాన్ని నిర్వహించడానికి ప్రతిరూపం చేయబడిన టాపిక్ యొక్క కీలను తప్పనిసరిగా అర్థం చేసుకోవాలి, ఎందుకంటే ఆ టాపిక్ కోసం విభజనల సంఖ్య రెండు క్లస్టర్‌లలో ఒకేలా ఉండకపోవచ్చు.

కస్టమ్ విభజన వ్యూహాలు చాలా అరుదుగా ఉంటాయి, ఎందుకంటే డిఫాల్ట్ హ్యాషింగ్ లేదా రౌండ్ రాబిన్ చాలా సందర్భాలలో బాగా పనిచేస్తుంది. అయితే, మీకు బలమైన ఆర్డరింగ్ గ్యారెంటీలు అవసరమైతే లేదా పేలోడ్‌ల నుండి మెటాడేటాను సంగ్రహించవలసి వస్తే, విభజన చేయడం అనేది మీరు నిశితంగా పరిశీలించాల్సిన విషయం.

సాంప్రదాయ బ్రోకర్ యొక్క కొన్ని బాధ్యతలను క్లయింట్‌కు బదిలీ చేయడం ద్వారా కాఫ్కా యొక్క స్కేలబిలిటీ మరియు పనితీరు ప్రయోజనాలు వస్తాయి. ఈ సందర్భంలో, సమాంతరంగా పనిచేసే అనేక మంది వినియోగదారుల మధ్య సంభావ్య సంబంధిత సందేశాలను పంపిణీ చేయడానికి నిర్ణయం తీసుకోబడుతుంది.

JMS బ్రోకర్లు కూడా అలాంటి అవసరాలతో వ్యవహరించాలి. ఆసక్తికరంగా, JMS మెసేజ్ గ్రూప్స్ (స్టిక్కీ లోడ్ బ్యాలెన్సింగ్ (SLB) స్ట్రాటజీపై ఒక వైవిధ్యం) ద్వారా అమలు చేయబడిన అదే వినియోగదారునికి సంబంధిత సందేశాలను పంపే మెకానిజం కూడా పంపినవారు సందేశాలను సంబంధితంగా గుర్తించాల్సిన అవసరం ఉంది. JMS విషయానికొస్తే, బ్రోకర్ ఈ సమూహానికి సంబంధించిన సందేశాలను చాలా మందిలో ఒకరికి పంపడానికి మరియు వినియోగదారు పడిపోయినట్లయితే సమూహం యొక్క యాజమాన్యాన్ని బదిలీ చేయడానికి బాధ్యత వహిస్తాడు.

నిర్మాత ఒప్పందాలు

సందేశాలను పంపేటప్పుడు విభజన మాత్రమే పరిగణించాల్సిన విషయం కాదు. జావా APIలో ప్రొడ్యూసర్ క్లాస్ పంపే() పద్ధతులను పరిశీలిద్దాం:

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 మరియు కాఫ్కాతో మెసేజింగ్ మెకానిక్‌లను నేర్చుకోవడం. 1 వ అధ్యాయము

అనువాదం పూర్తయింది: tele.gg/middle_java

కొనసాగించాలి…

నమోదు చేసుకున్న వినియోగదారులు మాత్రమే సర్వేలో పాల్గొనగలరు. సైన్ ఇన్ చేయండిదయచేసి.

మీ సంస్థలో కాఫ్కా ఉపయోగించబడుతుందా?

• అవును

• ఏ

• గతంలో ఉపయోగించారు, ఇప్పుడు కాదు

• మేము ఉపయోగించడానికి ప్లాన్ చేస్తున్నాము

38 మంది వినియోగదారులు ఓటు వేశారు. 8 మంది వినియోగదారులు దూరంగా ఉన్నారు.

మూలం: www.habr.com