В చివరి వ్యాసం మేము తప్పు సహనం మరియు అధిక లభ్యత కోసం RabbitMQ క్లస్టరింగ్‌ని చూశాము. ఇప్పుడు అపాచీ కాఫ్కాను లోతుగా త్రవ్వండి.

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

అన్నం. 1. మూడు బ్రోకర్ల మధ్య నాలుగు విభాగాలు పంపిణీ చేయబడ్డాయి

అన్ని చదవడం మరియు వ్రాయడం అభ్యర్థనలు నాయకుడికి వెళ్తాయి. తాజా సందేశాలను స్వీకరించడానికి అనుచరులు క్రమానుగతంగా నాయకుడికి అభ్యర్థనలను పంపుతారు. వినియోగదారులు ఎప్పుడూ అనుచరుల వైపు మొగ్గు చూపరు; రెండోది రిడెండెన్సీ మరియు తప్పు సహనం కోసం మాత్రమే ఉంటుంది.

విభజన వైఫల్యం

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

బ్రోకర్ 3 నెట్‌వర్క్ నుండి నిష్క్రమించాడు మరియు బ్రోకర్ 2 వద్ద సెక్షన్ 2 కోసం కొత్త నాయకుడు ఎన్నుకోబడతాడు.

అన్నం. 2. బ్రోకర్ 3 మరణిస్తాడు మరియు బ్రోకర్ 2లో అతని అనుచరుడు విభజన 2కి కొత్త నాయకుడిగా ఎన్నికయ్యాడు

అప్పుడు బ్రోకర్ 1 లీడర్‌లు మరియు సెక్షన్ 1 కూడా దాని నాయకుడిని కోల్పోతుంది, దీని పాత్ర బ్రోకర్ 2కి వెళుతుంది.

అన్నం. 3. ఒక బ్రోకర్ మిగిలి ఉన్నాడు. నాయకులందరూ సున్నా రిడెండెన్సీతో ఒకే బ్రోకర్‌పై ఉన్నారు

బ్రోకర్ 1 ఆన్‌లైన్‌కు తిరిగి వచ్చినప్పుడు, ఇది నలుగురు అనుచరులను జతచేస్తుంది, ప్రతి విభజనకు కొంత రిడెండెన్సీని అందిస్తుంది. కానీ నాయకులందరూ ఇప్పటికీ బ్రోకర్ 2లోనే ఉన్నారు.

అన్నం. 4. నాయకులు బ్రోకర్ 2లో ఉంటారు

బ్రోకర్ 3 వచ్చినప్పుడు, మేము ప్రతి విభజనకు మూడు ప్రతిరూపాలకు తిరిగి వస్తాము. కానీ నాయకులందరూ ఇప్పటికీ బ్రోకర్ 2లోనే ఉన్నారు.

అన్నం. 5. బ్రోకర్లు 1 మరియు 3 పునరుద్ధరణ తర్వాత నాయకుల అసమతుల్య స్థానం

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

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

దీన్ని పరిష్కరించడానికి, కాఫ్కా రెండు ఎంపికలను అందిస్తుంది:

• ఎంపిక auto.leader.rebalance.enable=true కంట్రోలర్ నోడ్ స్వయంచాలకంగా లీడర్‌లను ఇష్టపడే ప్రతిరూపాలకు తిరిగి కేటాయించడానికి మరియు తద్వారా ఏకరీతి పంపిణీని పునరుద్ధరించడానికి అనుమతిస్తుంది.
• నిర్వాహకుడు స్క్రిప్ట్‌ని అమలు చేయగలడు kafka-preferred-replica-election.sh మాన్యువల్ రీఅసైన్‌మెంట్ కోసం.

అన్నం. 6. రీబ్యాలెన్సింగ్ తర్వాత ప్రతిరూపాలు

ఇది వైఫల్యం యొక్క సరళీకృత సంస్కరణ, కానీ ఇక్కడ చాలా క్లిష్టంగా ఏమీ లేనప్పటికీ వాస్తవికత మరింత క్లిష్టంగా ఉంటుంది. ఇది సమకాలీకరించబడిన ప్రతిరూపాలకు (ఇన్-సింక్ రెప్లికాస్, ISR) వస్తుంది.

సమకాలీకరించబడిన ప్రతిరూపాలు (ISR)

ISR అనేది "సింక్రొనైజ్డ్" (ఇన్-సింక్)గా పరిగణించబడే విభజన యొక్క ప్రతిరూపాల సమితి. నాయకుడు ఉన్నాడు, కానీ అనుచరులు ఉండకపోవచ్చు. విరామం ముగిసేలోపు అన్ని నాయకుడి సందేశాల యొక్క ఖచ్చితమైన కాపీలను రూపొందించినట్లయితే, అనుచరుడు సమకాలీకరించబడినట్లు పరిగణించబడతారు replica.lag.time.max.ms.

ఒకవేళ ISR సెట్ నుండి ఒక అనుచరుడు తీసివేయబడతారు:

• విరామం కోసం ఎంచుకోవడానికి అభ్యర్థన చేయలేదు replica.lag.time.max.ms (చనిపోయి ఉండవచ్చు)
• విరామం సమయంలో అప్‌డేట్ చేయలేకపోయింది replica.lag.time.max.ms (నెమ్మదిగా పరిగణించబడుతుంది)

అనుచరులు విరామంలో నమూనా అభ్యర్థనలను చేస్తారు replica.fetch.wait.max.ms, ఇది డిఫాల్ట్‌గా 500ms.

ISR యొక్క ఉద్దేశ్యాన్ని స్పష్టంగా వివరించడానికి, మేము నిర్మాత నుండి నిర్ధారణలను మరియు కొన్ని వైఫల్య దృశ్యాలను చూడాలి. బ్రోకర్ నిర్ధారణను పంపినప్పుడు నిర్మాతలు ఎంచుకోవచ్చు:

• acks=0, నిర్ధారణ పంపబడలేదు
• acks=1, నాయకుడు తన స్థానిక లాగ్‌కు సందేశాన్ని వ్రాసిన తర్వాత నిర్ధారణ పంపబడుతుంది
• acks=అన్ని, ISRలోని అన్ని ప్రతిరూపాలు స్థానిక లాగ్‌లకు సందేశాన్ని వ్రాసిన తర్వాత నిర్ధారణ పంపబడుతుంది

కాఫ్కా పరిభాషలో, ISR సందేశాన్ని సేవ్ చేసినట్లయితే, అది “నిబద్ధత”. Acks=అన్నీ సురక్షితమైన ఎంపిక, కానీ అదనపు ఆలస్యాన్ని కూడా జోడిస్తుంది. వైఫల్యానికి సంబంధించిన రెండు ఉదాహరణలను చూద్దాం మరియు ISR కాన్సెప్ట్‌తో విభిన్న 'యాక్స్' ఎంపికలు ఎలా సంకర్షణ చెందుతాయి.

అక్స్=1 మరియు ISR

ఈ ఉదాహరణలో, అన్ని అనుచరుల నుండి ప్రతి సందేశం సేవ్ చేయబడటానికి నాయకుడు వేచి ఉండకపోతే, నాయకుడు విఫలమైతే డేటా నష్టం సాధ్యమవుతుందని మనం చూస్తాము. సమకాలీకరించబడని అనుచరుడికి నావిగేట్ చేయడం ద్వారా సెట్ చేయడం ద్వారా ప్రారంభించవచ్చు లేదా నిలిపివేయవచ్చు unclean.leader.election.enable.

ఈ ఉదాహరణలో, తయారీదారు విలువ acks=1ని కలిగి ఉంది. ఈ విభాగం మొత్తం ముగ్గురు బ్రోకర్లలో పంపిణీ చేయబడింది. బ్రోకర్ 3 వెనుకబడి ఉంది, ఇది ఎనిమిది సెకన్ల క్రితం లీడర్‌తో సమకాలీకరించబడింది మరియు ఇప్పుడు 7456 సందేశాలు వెనుకబడి ఉన్నాయి. బ్రోకర్ 1 ఒక సెకను మాత్రమే వెనుకబడి ఉన్నాడు. మా నిర్మాత మెసేజ్ పంపి, నాయకుడు ఎదురుచూడని స్లో లేదా డెడ్ ఫాలోయర్‌ల ఓవర్‌హెడ్ లేకుండా, త్వరగా తిరిగి అందుకుంటారు.

అన్నం. 7. మూడు ప్రతిరూపాలతో ISR

బ్రోకర్ 2 విఫలమైంది మరియు నిర్మాత కనెక్షన్ లోపాన్ని అందుకుంటారు. నాయకత్వం బ్రోకర్ 1కి చేరిన తర్వాత, మేము 123 సందేశాలను కోల్పోతాము. బ్రోకర్ 1లోని అనుచరుడు ISRలో భాగం, కానీ అది పడిపోయినప్పుడు లీడర్‌తో పూర్తిగా సమకాలీకరించబడలేదు.

అన్నం. 8. క్రాష్ అయినప్పుడు సందేశాలు పోతాయి

ఆకృతీకరణలో bootstrap.servers తయారీదారు అనేక బ్రోకర్‌లను జాబితా చేసారు మరియు కొత్త సెక్షన్ లీడర్ ఎవరో మరొక బ్రోకర్‌ని అడగవచ్చు. ఇది బ్రోకర్ 1కి కనెక్షన్‌ని ఏర్పరుస్తుంది మరియు సందేశాలను పంపడం కొనసాగిస్తుంది.

అన్నం. 9. చిన్న విరామం తర్వాత సందేశాలను పంపడం మళ్లీ ప్రారంభమవుతుంది

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

అన్నం. 10. బ్రోకర్ 3ని అనుసరించేవారు ISR నుండి తీసివేయబడతారు

బ్రోకర్ 1 తగ్గుతుంది మరియు 3 సందేశాలను కోల్పోవడంతో నాయకత్వ పాత్ర బ్రోకర్ 15286కి వెళుతుంది! తయారీదారు కనెక్షన్ దోష సందేశాన్ని అందుకుంటారు. ISR వెలుపల ఉన్న నాయకుడిగా మారడం అనేది సెట్టింగ్ కారణంగా మాత్రమే సాధ్యమైంది unclean.leader.election.enable=true. ఇది ఇన్‌స్టాల్ చేయబడితే తప్పుడు, అప్పుడు పరివర్తన జరగదు మరియు అన్ని చదవడం మరియు వ్రాయడం అభ్యర్థనలు తిరస్కరించబడతాయి. ఈ సందర్భంలో, బ్రోకర్ 1 ప్రతిరూపంలో అతని చెక్కుచెదరకుండా ఉన్న డేటాతో తిరిగి వచ్చే వరకు మేము వేచి ఉంటాము, అది మళ్లీ నాయకత్వాన్ని తీసుకుంటుంది.

అన్నం. 11. బ్రోకర్ 1 వస్తుంది. వైఫల్యం సంభవించినప్పుడు, పెద్ద సంఖ్యలో సందేశాలు పోతాయి

నిర్మాత చివరి బ్రోకర్‌తో సంబంధాన్ని ఏర్పరచుకున్నాడు మరియు అతను ఇప్పుడు విభాగానికి నాయకుడిగా ఉన్నట్లు చూస్తాడు. అతను బ్రోకర్ 3కి సందేశాలు పంపడం ప్రారంభించాడు.

అన్నం. 12. చిన్న విరామం తర్వాత, సందేశాలు మళ్లీ విభాగం 0కి పంపబడతాయి

కొత్త కనెక్షన్‌లను ఏర్పాటు చేయడానికి మరియు కొత్త నాయకుడి కోసం శోధించడానికి చిన్న అంతరాయాలు కాకుండా, తయారీదారు నిరంతరం సందేశాలను పంపుతున్నట్లు మేము చూశాము. ఈ కాన్ఫిగరేషన్ స్థిరత్వం (డేటా భద్రత) ఖర్చుతో లభ్యతను నిర్ధారిస్తుంది. కాఫ్కా వేలకొద్దీ సందేశాలను కోల్పోయాడు కానీ కొత్త వ్రాతలను అంగీకరించడం కొనసాగించాడు.

అక్స్=అన్ని మరియు ISR

ఈ దృశ్యాన్ని మళ్లీ పునరావృతం చేద్దాం, కానీ acks = అన్నీ. బ్రోకర్ 3 సగటు జాప్యం నాలుగు సెకన్లు కలిగి ఉంటుంది. తయారీదారు ఒక సందేశాన్ని పంపుతాడు acks = అన్నీ, మరియు ఇప్పుడు త్వరిత ప్రతిస్పందనను అందుకోలేదు. ISRలోని అన్ని ప్రతిరూపాల ద్వారా సందేశం సేవ్ చేయబడుతుందని నాయకుడు వేచి ఉంటాడు.

అన్నం. 13. మూడు ప్రతిరూపాలతో ISR. ఒకటి నెమ్మదిగా ఉంది, ఫలితంగా రికార్డింగ్ ఆలస్యం అవుతుంది

నాలుగు సెకన్ల అదనపు ఆలస్యం తర్వాత, బ్రోకర్ 2 ఒక యాక్‌ని పంపుతుంది. అన్ని ప్రతిరూపాలు ఇప్పుడు పూర్తిగా నవీకరించబడ్డాయి.

అన్నం. 14. అన్ని ప్రతిరూపాలు సందేశాలను సేవ్ చేస్తాయి మరియు పంపండి

బ్రోకర్ 3 ఇప్పుడు మరింత వెనుకబడి ISR నుండి తీసివేయబడింది. ISRలో నెమ్మదిగా ప్రతిరూపాలు మిగిలి లేనందున జాప్యం గణనీయంగా తగ్గింది. బ్రోకర్ 2 ఇప్పుడు బ్రోకర్ 1 కోసం మాత్రమే వేచి ఉంది మరియు అతను సగటున 500 ms లాగ్‌ని కలిగి ఉన్నాడు.

అన్నం. 15. బ్రోకర్ 3లోని ప్రతిరూపం ISR నుండి తీసివేయబడింది

అప్పుడు బ్రోకర్ 2 పడిపోతుంది మరియు నాయకత్వం సందేశాలను కోల్పోకుండా బ్రోకర్ 1కి పంపబడుతుంది.

అన్నం. 16. బ్రోకర్ 2 వస్తుంది

తయారీదారు కొత్త నాయకుడిని కనుగొని అతనికి సందేశాలను పంపడం ప్రారంభిస్తాడు. ISR ఇప్పుడు ఒక ప్రతిరూపాన్ని కలిగి ఉన్నందున జాప్యం మరింత తగ్గించబడింది! అందువలన ఎంపిక acks = అన్నీ రిడెండెన్సీని జోడించదు.

అన్నం. 17. బ్రోకర్ 1లో ప్రతిరూపం సందేశాలను కోల్పోకుండా ముందంజలో ఉంటుంది

అప్పుడు బ్రోకర్ 1 క్రాష్ అవుతుంది మరియు 3 సందేశాల నష్టంతో లీడ్ బ్రోకర్ 14238కి వెళుతుంది!

అన్నం. 18. బ్రోకర్ 1 డైస్ మరియు అపరిశుభ్రమైన సెట్టింగ్‌తో నాయకత్వ పరివర్తన ఫలితంగా విస్తృతమైన డేటా నష్టం జరుగుతుంది

మేము ఎంపికను ఇన్‌స్టాల్ చేయలేకపోయాము unclean.leader.election.enable అర్థం లోకి నిజమైన. డిఫాల్ట్‌గా ఇది సమానంగా ఉంటుంది తప్పుడు. సెట్టింగ్‌లు acks = అన్నీ с unclean.leader.election.enable=true కొంత అదనపు డేటా భద్రతతో ప్రాప్యతను అందిస్తుంది. కానీ మీరు చూడగలిగినట్లుగా, మేము ఇప్పటికీ సందేశాలను కోల్పోవచ్చు.

కానీ మనం డేటా భద్రతను పెంచాలనుకుంటే? మీరు పెట్టవచ్చు unclean.leader.election.enable = తప్పు, కానీ ఇది తప్పనిసరిగా డేటా నష్టం నుండి మమ్మల్ని రక్షించదు. నాయకుడు గట్టిగా పడిపోయి, దానితో డేటాను తీసుకుంటే, అప్పుడు సందేశాలు ఇప్పటికీ పోతాయి మరియు నిర్వాహకుడు పరిస్థితిని పునరుద్ధరించే వరకు లభ్యత కోల్పోతుంది.

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

Acks=all, min.insync.replicas మరియు ISR

టాపిక్ కాన్ఫిగరేషన్‌తో min.insync.replicas మేము డేటా భద్రత స్థాయిని పెంచుతున్నాము. మునుపటి దృష్టాంతంలోని చివరి భాగాన్ని మళ్లీ చూద్దాం, కానీ ఈసారి min.insync.replicas=2.

కాబట్టి బ్రోకర్ 2కి ప్రతిరూప నాయకుడు ఉన్నారు మరియు బ్రోకర్ 3లోని అనుచరుడు ISR నుండి తీసివేయబడతారు.

అన్నం. 19. రెండు ప్రతిరూపాల నుండి ISR

బ్రోకర్ 2 పడిపోతుంది మరియు నాయకత్వం సందేశాలను కోల్పోకుండా బ్రోకర్ 1కి పంపబడుతుంది. కానీ ఇప్పుడు ISR ఒక ప్రతిరూపాన్ని మాత్రమే కలిగి ఉంది. ఇది రికార్డులను స్వీకరించడానికి కనీస సంఖ్యను అందుకోలేదు మరియు అందువల్ల బ్రోకర్ ఒక లోపంతో వ్రాసే ప్రయత్నానికి ప్రతిస్పందిస్తాడు NotEnoughReplicas.

అన్నం. 20. ISRల సంఖ్య min.insync.replicasలో పేర్కొన్న దానికంటే ఒకటి తక్కువగా ఉంది

ఈ కాన్ఫిగరేషన్ స్థిరత్వం కోసం లభ్యతను త్యాగం చేస్తుంది. సందేశాన్ని అంగీకరించే ముందు, అది కనీసం రెండు ప్రతిరూపాలకు వ్రాయబడిందని మేము నిర్ధారిస్తాము. ఇది తయారీదారుకు మరింత విశ్వాసాన్ని ఇస్తుంది. ఇక్కడ, సందేశం ఒక అదనపు అనుచరుడికి ప్రతిరూపం అయ్యేంత వరకు రెండు ప్రతిరూపాలు ఒకేసారి విఫలమైతే మాత్రమే సందేశ నష్టం సాధ్యమవుతుంది, ఇది అసంభవం. కానీ మీరు చాలా మతిస్థిమితం లేని వారైతే, మీరు ప్రతిరూపణ కారకాన్ని 5కి సెట్ చేయవచ్చు మరియు min.insync.replicas 3 ద్వారా. ఇక్కడ ముగ్గురు బ్రోకర్లు రికార్డ్‌ను కోల్పోవాలంటే ఒకేసారి పడాలి! వాస్తవానికి, మీరు ఈ విశ్వసనీయత కోసం అదనపు జాప్యంతో చెల్లిస్తారు.

డేటా భద్రత కోసం ప్రాప్యత అవసరమైనప్పుడు

లోపు RabbitMQ తో కేసు, డేటా భద్రత కోసం కొన్నిసార్లు ప్రాప్యత అవసరం. మీరు దీని గురించి ఆలోచించవలసినది ఇక్కడ ఉంది:

• ప్రచురణకర్త ఎర్రర్‌ని అందించి, అప్‌స్ట్రీమ్ సేవ లేదా వినియోగదారుని తర్వాత మళ్లీ ప్రయత్నించగలరా?
• ప్రచురణకర్త తర్వాత మళ్లీ ప్రయత్నించడానికి సందేశాన్ని స్థానికంగా లేదా డేటాబేస్‌లో సేవ్ చేయగలరా?

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

ISR యొక్క అర్థం

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

అర్థాన్ని మనమే ఎంచుకుంటాము replica.lag.time.max.ms మీ అవసరాలకు అనుగుణంగా. ముఖ్యంగా, ఈ పరామితి అంటే మనం ఎంత ఆలస్యం చేసినప్పుడు అంగీకరించడానికి సిద్ధంగా ఉన్నాము acks = అన్నీ. డిఫాల్ట్ విలువ పది సెకన్లు. ఇది మీకు చాలా పొడవుగా ఉంటే, మీరు దానిని తగ్గించవచ్చు. అప్పుడు ISRలో మార్పుల ఫ్రీక్వెన్సీ పెరుగుతుంది, ఎందుకంటే అనుచరులు తీసివేయబడతారు మరియు తరచుగా జోడించబడతారు.

RabbitMQ అనేది కేవలం ప్రతిబింబించాల్సిన అద్దాల సమితి. స్లో మిర్రర్‌లు అదనపు జాప్యాన్ని పరిచయం చేస్తాయి మరియు డెడ్ మిర్రర్‌లు ప్రతి నోడ్ (నెట్ టిక్) లభ్యతను తనిఖీ చేసే ప్యాకెట్‌లు ప్రతిస్పందించే వరకు వేచి ఉండగలవు. ఈ జాప్యం సమస్యలను నివారించడానికి ISR ఒక ఆసక్తికరమైన మార్గం. కానీ ISR నాయకుడికి మాత్రమే కుదించబడుతుంది కాబట్టి మేము రిడెండెన్సీని కోల్పోయే ప్రమాదం ఉంది. ఈ ప్రమాదాన్ని నివారించడానికి, సెట్టింగ్‌ని ఉపయోగించండి min.insync.replicas.

క్లయింట్ కనెక్షన్ హామీ

సెట్టింగులలో bootstrap.servers క్లయింట్‌లను కనెక్ట్ చేయడానికి నిర్మాత మరియు వినియోగదారు బహుళ బ్రోకర్‌లను పేర్కొనవచ్చు. ఆలోచన ఏమిటంటే, ఒక నోడ్ తగ్గినప్పుడు, క్లయింట్ కనెక్షన్‌ని తెరవగల అనేక విడివి మిగిలి ఉన్నాయి. ఇవి తప్పనిసరిగా సెక్షన్ లీడర్‌లు కావు, కానీ ప్రారంభ లోడింగ్‌కు స్ప్రింగ్‌బోర్డ్ మాత్రమే. రీడ్/రైట్ పార్టిషన్ లీడర్‌ని ఏ నోడ్ హోస్ట్ చేస్తుందో క్లయింట్ వారిని అడగవచ్చు.

RabbitMQలో, క్లయింట్లు ఏదైనా నోడ్‌కి కనెక్ట్ చేయగలరు మరియు అంతర్గత రౌటింగ్ అభ్యర్థనను ఎక్కడికి వెళ్లాలి అనే దానికి పంపుతుంది. దీని అర్థం మీరు RabbitMQ ముందు లోడ్ బ్యాలెన్సర్‌ని ఇన్‌స్టాల్ చేయవచ్చు. సంబంధిత విభజన లీడర్‌ను హోస్ట్ చేసే నోడ్‌కు క్లయింట్‌లు కనెక్ట్ కావడానికి కాఫ్కా అవసరం. అటువంటి పరిస్థితిలో, మీరు లోడ్ బాలన్సర్ను ఇన్స్టాల్ చేయలేరు. జాబితా bootstrap.servers క్లయింట్‌లు వైఫల్యం తర్వాత సరైన నోడ్‌లను యాక్సెస్ చేయడం మరియు కనుగొనడం చాలా కీలకం.

కాఫ్కా ఏకాభిప్రాయ ఆర్కిటెక్చర్

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

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

జూకీపర్ క్లస్టర్ స్థితిని నిల్వ చేస్తుంది:

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

ప్రతిరూప నాయకులను ఎన్నుకునే బాధ్యత కలిగిన కాఫ్కా బ్రోకర్లలో కంట్రోలర్ నోడ్ ఒకటి. జూకీపర్ క్లస్టర్ మెంబర్‌షిప్ మరియు టాపిక్ మార్పుల గురించి కంట్రోలర్‌కు నోటిఫికేషన్‌లను పంపుతుంది మరియు కంట్రోలర్ ఈ మార్పులపై తప్పనిసరిగా చర్య తీసుకోవాలి.

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

ప్రతి విభాగం కంట్రోలర్ కోసం:

• ISR మరియు లీడర్ గురించి జూకీపర్‌లో సమాచారాన్ని అప్‌డేట్ చేస్తుంది;
• ఈ విభజన యొక్క ప్రతిరూపాన్ని హోస్ట్ చేసే ప్రతి బ్రోకర్‌కు లీడర్‌అండ్‌ఐఎస్‌ఆర్‌కమాండ్‌ను పంపుతుంది, ISR మరియు లీడర్ గురించి బ్రోకర్‌లకు తెలియజేస్తుంది.

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

ప్రతి నాయకుడు ISRలను రిక్రూట్ చేయడానికి బాధ్యత వహిస్తాడు. సెట్టింగ్‌లు replica.lag.time.max.ms అక్కడ ఎవరు ప్రవేశించాలో నిర్ణయిస్తుంది. ISR మారినప్పుడు, నాయకుడు కొత్త సమాచారాన్ని జూకీపర్‌కు బదిలీ చేస్తాడు.

ఏదైనా మార్పుల గురించి జూకీపర్‌కు ఎల్లప్పుడూ తెలియజేయబడుతుంది, తద్వారా వైఫల్యం సంభవించినప్పుడు, నిర్వహణ సజావుగా కొత్త నాయకునికి మారుతుంది.

అన్నం. 21. కాఫ్కా ఏకాభిప్రాయం

రెప్లికేషన్ ప్రోటోకాల్

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

నమూనా ప్రశ్నలు, లాగ్ ఎండ్ ఆఫ్‌సెట్ (LEO) మరియు హైవాటర్ మార్క్ (HW)

అనుచరులు క్రమానుగతంగా లీడర్‌కి పొందే అభ్యర్థనలను పంపుతారని మేము పరిగణించాము. డిఫాల్ట్ విరామం 500ms. ఇది RabbitMQకి భిన్నంగా ఉంటుంది, ఎందుకంటే RabbitMQలో ప్రతిరూపం క్యూ మిర్రర్ ద్వారా కాకుండా మాస్టర్ ద్వారా ప్రారంభించబడుతుంది. మాస్టర్ అద్దాలకు మార్పులను నెడుతుంది.

నాయకుడు మరియు అనుచరులందరూ లాగ్ ఎండ్ ఆఫ్‌సెట్ (LEO) మరియు హైవాటర్ (HW) లేబుల్‌ను సేవ్ చేస్తారు. LEO గుర్తు స్థానిక ప్రతిరూపంలో చివరి సందేశం యొక్క ఆఫ్‌సెట్‌ను నిల్వ చేస్తుంది మరియు HW చివరి కమిట్ ఆఫ్‌సెట్‌ను కలిగి ఉంటుంది. కమిట్ స్టేటస్ కోసం, అన్ని ISR ప్రతిరూపాలలో సందేశం తప్పనిసరిగా కొనసాగించబడాలని గుర్తుంచుకోండి. దీని అర్థం LEO సాధారణంగా HW కంటే కొంచెం ముందుంది.

నాయకుడు సందేశాన్ని స్వీకరించినప్పుడు, అది స్థానికంగా నిల్వ చేస్తుంది. అనుచరుడు తన LEOని ప్రసారం చేయడం ద్వారా పొందే అభ్యర్థనను చేస్తాడు. నాయకుడు ఈ LEO నుండి ప్రారంభమయ్యే సందేశాల బ్యాచ్‌ను పంపుతాడు మరియు ప్రస్తుత HWని కూడా ప్రసారం చేస్తాడు. ఇచ్చిన ఆఫ్‌సెట్‌లో అన్ని ప్రతిరూపాలు సందేశాన్ని నిల్వ చేసినట్లు లీడర్ సమాచారం అందుకున్నప్పుడు, అది HW గుర్తును తరలిస్తుంది. నాయకుడు మాత్రమే HWని తరలించగలరు, కాబట్టి ఫాలోవర్లందరికీ వారి అభ్యర్థనకు ప్రతిస్పందనలలో ప్రస్తుత విలువ తెలుస్తుంది. సందేశం మరియు HW జ్ఞానం రెండింటిలోనూ అనుచరులు నాయకుడి కంటే వెనుకబడి ఉండవచ్చని దీని అర్థం. వినియోగదారులు ప్రస్తుత HW వరకు మాత్రమే సందేశాలను స్వీకరిస్తారు.

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

నాయకుడి వైఫల్యం

నాయకుడు పడిపోయినప్పుడు, జూకీపర్ కంట్రోలర్‌కి తెలియజేస్తాడు మరియు అది కొత్త లీడర్ ప్రతిరూపాన్ని ఎంచుకుంటుంది. కొత్త నాయకుడు తన LEO ప్రకారం కొత్త HW గుర్తును సెట్ చేస్తాడు. అనుచరులు కొత్త నాయకుడి గురించి సమాచారాన్ని అందుకుంటారు. కాఫ్కా సంస్కరణపై ఆధారపడి, అనుచరుడు రెండు దృశ్యాలలో ఒకదాన్ని ఎంచుకుంటారు:

1. ఇది తెలిసిన HWకి స్థానిక లాగ్‌ను కత్తిరించి, ఈ గుర్తు తర్వాత సందేశాల కోసం కొత్త నాయకుడికి అభ్యర్థనను పంపుతుంది.
2. నాయకుడిగా ఎన్నుకోబడిన సమయంలో హెచ్‌డబ్ల్యూని కనుగొనడానికి నాయకుడికి అభ్యర్థనను పంపుతుంది, ఆపై ఈ ఆఫ్‌సెట్‌కు లాగ్‌ను కత్తిరించండి. ఇది ఈ ఆఫ్‌సెట్ నుండి క్రమానుగతంగా పొందే అభ్యర్థనలను చేయడం ప్రారంభిస్తుంది.

కింది కారణాల వల్ల అనుచరుడు లాగ్‌ను కత్తిరించాల్సి రావచ్చు:

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

క్లస్టర్‌తో పునఃకలయిక

క్లస్టర్‌లో మళ్లీ చేరినప్పుడు, ఒక నాయకుడు విఫలమైనప్పుడు ప్రతిరూపాలు అదే విధంగా చేస్తాయి: వారు నాయకుడి ప్రతిరూపాన్ని తనిఖీ చేస్తారు మరియు వారి లాగ్‌ను దాని HWకి (ఎన్నికల సమయంలో) కత్తిరించుకుంటారు. పోల్చి చూస్తే, రాబిట్‌ఎమ్‌క్యూ రీయూనిటెడ్ నోడ్‌లను పూర్తిగా కొత్తదిగా పరిగణిస్తుంది. రెండు సందర్భాల్లో, బ్రోకర్ ఇప్పటికే ఉన్న ఏదైనా రాష్ట్రాన్ని విస్మరిస్తాడు. ఆటోమేటిక్ సింక్రొనైజేషన్ ఉపయోగించబడితే, మాస్టర్ తప్పనిసరిగా "ప్రపంచమంతా వేచి ఉండనివ్వండి" పద్ధతిలో కొత్త అద్దంలో ప్రస్తుత కంటెంట్‌ను ఖచ్చితంగా ప్రతిబింబించాలి. ఈ ఆపరేషన్ సమయంలో మాస్టర్ ఎలాంటి రీడ్ లేదా రైట్ ఆపరేషన్‌లను అంగీకరించరు. ఈ విధానం పెద్ద క్యూలలో సమస్యలను సృష్టిస్తుంది.

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

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

కనెక్టివిటీ కోల్పోవడం

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

క్రింద అనేక కనెక్టివిటీ వైఫల్య దృశ్యాలు ఉన్నాయి:

• దృశ్యం 1: అనుచరుడు నాయకుడిని చూడలేదు, కానీ ఇప్పటికీ జూకీపర్‌ని చూస్తాడు.
• దృశ్యం 2: నాయకుడికి అనుచరులు ఎవరూ కనిపించలేదు, కానీ ఇప్పటికీ జూకీపర్‌ని చూస్తారు.
• దృశ్యం 3: అనుచరుడు నాయకుడిని చూస్తాడు, కానీ జూకీపర్‌ని చూడడు.
• దృశ్యం 4: నాయకుడు అనుచరులను చూస్తాడు, కానీ జూకీపర్‌ని చూడడు.
• దృశ్యం 5: అనుచరుడు ఇతర కాఫ్కా నోడ్‌లు మరియు జూకీపర్ రెండింటి నుండి పూర్తిగా వేరుగా ఉంటాడు.
• దృష్టాంతం 6: ఇతర కాఫ్కా నోడ్స్ మరియు జూకీపర్ రెండింటి నుండి లీడర్ పూర్తిగా వేరు.
• దృశ్యం 7: కాఫ్కా కంట్రోలర్ నోడ్ మరొక కాఫ్కా నోడ్‌ను చూడలేదు.
• దృశ్యం 8: కాఫ్కా కంట్రోలర్ జూకీపర్‌ని చూడలేదు.

ప్రతి దృష్టాంతంలో దాని స్వంత ప్రవర్తన ఉంటుంది.

దృశ్యం 1: అనుచరుడు నాయకుడిని చూడలేదు, కానీ ఇప్పటికీ జూకీపర్‌ని చూస్తున్నాడు

అన్నం. 22. దృశ్యం 1: మూడు ప్రతిరూపాల ISR

కనెక్టివిటీ వైఫల్యం బ్రోకర్ 3ని బ్రోకర్లు 1 మరియు 2 నుండి వేరు చేస్తుంది, కానీ జూకీపర్ నుండి కాదు. బ్రోకర్ 3 ఇకపై పొందే అభ్యర్థనలను పంపలేరు. సమయం గడిచిన తర్వాత replica.lag.time.max.ms ఇది ISR నుండి తీసివేయబడింది మరియు సందేశ కమిట్‌లలో పాల్గొనదు. కనెక్టివిటీ పునరుద్ధరించబడిన తర్వాత, ఇది అభ్యర్థనలను పొందడం పునఃప్రారంభించబడుతుంది మరియు లీడర్‌ను సంప్రదించినప్పుడు ISRలో చేరుతుంది. జూకీపర్ పింగ్‌లను స్వీకరిస్తూనే ఉంటాడు మరియు బ్రోకర్ సజీవంగా మరియు క్షేమంగా ఉన్నాడని ఊహిస్తాడు.

అన్నం. 23. దృష్టాంతం 1: replica.lag.time.max.ms విరామంలోపు బ్రోకర్ ISR నుండి ఎలాంటి అభ్యర్థనను స్వీకరించకుంటే దాని నుండి తీసివేయబడతారు

RabbitMQలో వలె స్ప్లిట్-మెదడు లేదా నోడ్ సస్పెన్షన్ లేదు. బదులుగా, రిడెండెన్సీ తగ్గుతుంది.

దృష్టాంతం 2: లీడర్‌కు ఫాలోవర్లు ఎవరూ కనిపించలేదు, కానీ ఇప్పటికీ జూకీపర్‌ని చూస్తున్నారు

అన్నం. 24. దృశ్యం 2. నాయకుడు మరియు ఇద్దరు అనుచరులు

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

అన్నం. 25. దృశ్యం 2. ISR కేవలం నాయకుడికి మాత్రమే కుంచించుకుపోయింది

దృశ్యం 3. అనుచరుడు నాయకుడిని చూస్తాడు, కానీ జూకీపర్‌ని చూడడు

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

అన్నం. 26. దృష్టాంతం 3: అనుచరుడు లీడర్‌కు పొందే అభ్యర్థనలను పంపడం కొనసాగిస్తాడు

దృశ్యం 4. నాయకుడు అనుచరులను చూస్తాడు, కానీ జూకీపర్‌ని చూడడు

అన్నం. 27. దృశ్యం 4. నాయకుడు మరియు ఇద్దరు అనుచరులు

నాయకుడు జూకీపర్ నుండి వేరు చేయబడ్డాడు, కానీ అనుచరులతో ఉన్న బ్రోకర్ల నుండి కాదు.

అన్నం. 28. దృశ్యం 4: నాయకుడు జూకీపర్ నుండి వేరుచేయబడ్డాడు

కొంత సమయం తర్వాత, జూకీపర్ బ్రోకర్ వైఫల్యాన్ని నమోదు చేస్తాడు మరియు దాని గురించి కంట్రోలర్‌కు తెలియజేస్తాడు. తన అనుచరుల మధ్య కొత్త నాయకుడిని ఎన్నుకోనున్నారు. అయితే, అసలు నాయకుడే నాయకుడని అనుకుంటూనే ఉంటాడు మరియు నుండి ఎంట్రీలను స్వీకరిస్తూనే ఉంటాడు acks=1. అనుచరులు ఇకపై అతనికి అభ్యర్థనలను పొందడం పంపడం లేదు, కాబట్టి అతను వారిని చనిపోయినట్లు పరిగణించి, ISRని కుదించడానికి ప్రయత్నిస్తాడు. కానీ దీనికి జూకీపర్‌కి కనెక్షన్ లేనందున, ఇది దీన్ని చేయదు మరియు ఆ సమయంలో తదుపరి ఎంట్రీలను అంగీకరించడానికి నిరాకరిస్తుంది.

సందేశాలను acks = అన్నీ ISR మొదట అన్ని ప్రతిరూపాలను ఆన్ చేస్తుంది మరియు సందేశాలు వారికి చేరవు కాబట్టి రసీదుని అందుకోలేరు. అసలైన నాయకుడు వారిని ISR నుండి తీసివేయడానికి ప్రయత్నించినప్పుడు, అది అలా చేయడం సాధ్యపడదు మరియు ఎటువంటి సందేశాలను అంగీకరించడం ఆపివేస్తుంది.

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

అన్నం. 29. దృశ్యం 4. నెట్‌వర్క్ పునరుద్ధరించబడిన తర్వాత బ్రోకర్ 1లోని నాయకుడు అనుచరుడు అవుతాడు

దృశ్యం 5: అనుచరుడు ఇతర కాఫ్కా నోడ్‌లు మరియు జూకీపర్ రెండింటి నుండి పూర్తిగా వేరుగా ఉంటాడు

అనుచరుడు ఇతర కాఫ్కా నోడ్స్ మరియు జూకీపర్ రెండింటి నుండి పూర్తిగా వేరుచేయబడ్డాడు. నెట్‌వర్క్ పునరుద్ధరించబడే వరకు అతను ISR నుండి తనను తాను తీసివేస్తాడు, ఆపై ఇతరులతో కలుసుకుంటాడు.

అన్నం. 30. దృశ్యం 5: ఐసోలేటెడ్ ఫాలోయర్ ISR నుండి తీసివేయబడతారు

దృష్టాంతం 6: ఇతర కాఫ్కా నోడ్స్ మరియు జూకీపర్ రెండింటి నుండి లీడర్ పూర్తిగా వేరు

అన్నం. 31. దృశ్యం 6. నాయకుడు మరియు ఇద్దరు అనుచరులు

నాయకుడు అతని అనుచరులు, కంట్రోలర్ మరియు జూకీపర్ నుండి పూర్తిగా ఒంటరిగా ఉంటాడు. స్వల్ప కాలానికి ఇది నుండి ఎంట్రీలను ఆమోదించడం కొనసాగుతుంది acks=1.

అన్నం. 32. దృశ్యం 6: ఇతర కాఫ్కా మరియు జూకీపర్ నోడ్‌ల నుండి నాయకుడిని వేరుచేయడం

గడువు ముగిసిన తర్వాత అభ్యర్థనలను స్వీకరించలేదు replica.lag.time.max.ms, ఇది ISRని తనకుతానే కుదించుకోవడానికి ప్రయత్నిస్తుంది, కానీ జూకీపర్‌తో కమ్యూనికేషన్ లేనందున అలా చేయడం సాధ్యం కాదు, అప్పుడు అది వ్రాతలను అంగీకరించడం ఆపివేస్తుంది.

ఇంతలో, జూకీపర్ ఒంటరిగా ఉన్న బ్రోకర్‌ను చనిపోయినట్లు గుర్తు చేస్తాడు మరియు కంట్రోలర్ కొత్త నాయకుడిని ఎన్నుకుంటాడు.

అన్నం. 33. దృశ్యం 6. ఇద్దరు నాయకులు

ఒరిజినల్ లీడర్ కొన్ని సెకన్ల పాటు ఎంట్రీలను ఆమోదించవచ్చు, కానీ ఆ తర్వాత ఏదైనా సందేశాలను అంగీకరించడం ఆపివేస్తుంది. క్లయింట్లు తాజా మెటాడేటాతో ప్రతి 60 సెకన్లకు నవీకరించబడతారు. నాయకుడి మార్పు గురించి వారికి తెలియజేయబడుతుంది మరియు కొత్త నాయకుడికి ఎంట్రీలను పంపడం ప్రారంభమవుతుంది.

అన్నం. 34. దృశ్యం 6: తయారీదారులు కొత్త నాయకుడికి మారతారు

కనెక్టివిటీని కోల్పోయినప్పటి నుండి ఒరిజినల్ లీడర్ చేసిన అన్ని ధృవీకరించబడిన ఎంట్రీలు పోతాయి. నెట్‌వర్క్ పునరుద్ధరించబడిన తర్వాత, అసలు నాయకుడు జూకీపర్ ద్వారా తాను ఇకపై నాయకుడు కాదని తెలుసుకుంటారు. అప్పుడు అది ఎన్నికల సమయంలో కొత్త నాయకుడి HWకి తన లాగ్‌ను కత్తిరించి, అనుచరుడిగా అభ్యర్థనలను పంపడం ప్రారంభిస్తుంది.

అన్నం. 35. దృశ్యం 6: నెట్‌వర్క్ కనెక్టివిటీని పునరుద్ధరించిన తర్వాత అసలు నాయకుడు అనుచరుడు అవుతాడు

ఈ పరిస్థితిలో, తార్కిక విభజన స్వల్ప కాలానికి సంభవించవచ్చు, అయితే మాత్రమే acks=1 и min.insync.replicas అలాగే 1. నెట్‌వర్క్ పునరుద్ధరించబడిన తర్వాత, అసలు నాయకుడు తాను ఇకపై నాయకుడు కాదని తెలుసుకున్నప్పుడు లేదా క్లయింట్‌లందరూ లీడర్ మారినట్లు గ్రహించి కొత్త నాయకుడికి రాయడం ప్రారంభించినప్పుడు - ఏది ముందుగా జరిగితే అది స్వయంచాలకంగా ముగుస్తుంది. ఏదైనా సందర్భంలో, కొన్ని సందేశాలు పోతాయి, కానీ వాటితో మాత్రమే acks=1.

ఈ దృష్టాంతంలో మరొక రూపాంతరం ఉంది, ఇక్కడ నెట్‌వర్క్ విభజనకు ముందు, అనుచరులు వెనుకబడి ఉన్నారు మరియు నాయకుడు ISRని తనకే కుదించుకున్నాడు. కనెక్టివిటీని కోల్పోవడం వల్ల ఇది ఒంటరిగా మారుతుంది. కొత్త నాయకుడు ఎన్నుకోబడ్డాడు, కానీ అసలు నాయకుడు ఎంట్రీలను కూడా అంగీకరించడం కొనసాగిస్తాడు acks = అన్నీ, ఎందుకంటే ISR లో అతను తప్ప మరెవరూ లేరు. నెట్‌వర్క్ పునరుద్ధరించబడిన తర్వాత ఈ రికార్డ్‌లు పోతాయి. ఈ ఎంపికను నివారించడానికి ఏకైక మార్గం min.insync.replicas = 2.

దృష్టాంతం 7: కాఫ్కా కంట్రోలర్ నోడ్ మరొక కాఫ్కా నోడ్‌ని చూడలేదు

సాధారణంగా, కాఫ్కా నోడ్‌తో కనెక్షన్ పోయిన తర్వాత, కంట్రోలర్ ఏ నాయకుడి మార్పు సమాచారాన్ని దానికి ప్రసారం చేయలేరు. చెత్త సందర్భంలో, ఇది దృష్టాంతంలో 6 వంటి స్వల్పకాలిక తార్కిక విభజనకు దారి తీస్తుంది. చాలా తరచుగా, బ్రోకర్ విఫలమైతే నాయకత్వానికి అభ్యర్థిగా మారడు.

దృశ్యం 8: కాఫ్కా కంట్రోలర్ జూకీపర్‌ని చూడలేదు

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

దృశ్యాల నుండి తీర్మానాలు

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

కనెక్టివిటీని కోల్పోవడం వల్ల నాయకుడు జూకీపర్ నుండి విడిపోతే, దీని వలన సందేశాలు పోతాయి. acks=1. జూకీపర్‌తో కమ్యూనికేషన్ లేకపోవడం ఇద్దరు నాయకులతో క్లుప్త తార్కిక విభజనకు కారణమవుతుంది. ఈ సమస్య పరామితి ద్వారా పరిష్కరించబడుతుంది acks = అన్నీ.

పరామితి min.insync.replicas రెండు లేదా అంతకంటే ఎక్కువ ప్రతిరూపాలు అటువంటి స్వల్పకాలిక దృశ్యాలు దృష్టాంతం 6లో వలె తప్పిపోయిన సందేశాలకు దారితీయవని అదనపు హామీని అందిస్తుంది.

పోయిన సందేశాల సారాంశం

మీరు కాఫ్కాలో డేటాను కోల్పోయే అన్ని మార్గాలను జాబితా చేద్దాం:

• సందేశాలను ఉపయోగించి నిర్ధారించబడినట్లయితే ఏదైనా నాయకుడు వైఫల్యం acks=1
• నాయకత్వం యొక్క ఏదైనా అపరిశుభ్రమైన పరివర్తన, అంటే, ISR వెలుపల ఉన్న అనుచరుడికి కూడా acks = అన్నీ
• సందేశాలను ఉపయోగించి నిర్ధారించబడినట్లయితే, జూకీపర్ నుండి నాయకుడిని వేరుచేయడం acks=1
• ఇప్పటికే ISR సమూహాన్ని తనంతట తానుగా కుదించుకున్న నాయకుడిని పూర్తిగా వేరుచేయడం. అన్ని సందేశాలు కూడా పోతాయి acks = అన్నీ. ఇది నిజం అయితే మాత్రమే min.insync.replicas=1.
• అన్ని విభజన నోడ్‌ల ఏకకాల వైఫల్యాలు. మెమొరీ నుండి సందేశాలు గుర్తించబడినందున, కొన్ని ఇంకా డిస్క్‌కు వ్రాయబడకపోవచ్చు. సర్వర్‌లను రీబూట్ చేసిన తర్వాత, కొన్ని సందేశాలు కనిపించకుండా పోయి ఉండవచ్చు.

అశుద్ధ నాయకత్వ పరివర్తనలను నిషేధించడం ద్వారా లేదా కనీసం రెండు రిడెండెన్సీలను నిర్ధారించడం ద్వారా నివారించవచ్చు. అత్యంత మన్నికైన కాన్ఫిగరేషన్ కలయిక acks = అన్నీ и min.insync.replicas 1 కంటే ఎక్కువ.

RabbitMQ మరియు కాఫ్కా విశ్వసనీయత యొక్క ప్రత్యక్ష పోలిక

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

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

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

• ప్రతి కొన్ని వందల మిల్లీసెకన్లకు fsync
• ప్రతి నోడ్ (నెట్ టిక్) లభ్యతను తనిఖీ చేసే ప్యాకెట్ల జీవితకాలం ముగిసిన తర్వాత మాత్రమే అద్దం యొక్క వైఫల్యాన్ని గమనించవచ్చు. అద్దం మందగించినా లేదా పడిపోయినా, ఇది ఆలస్యాన్ని జోడిస్తుంది.

కాఫ్కా యొక్క పందెం ఏమిటంటే, ఒక సందేశం బహుళ నోడ్‌లలో నిల్వ చేయబడితే, అది మెమోరీని నొక్కిన వెంటనే సందేశాలను గుర్తించగలదు. దీని కారణంగా, ఏ రకమైన సందేశాలను అయినా కోల్పోయే ప్రమాదం ఉంది (కూడా acks = అన్నీ, min.insync.replicas=2) ఏకకాల వైఫల్యం విషయంలో.

మొత్తంమీద, కాఫ్కా మెరుగైన సాఫ్ట్‌వేర్ పనితీరును ప్రదర్శిస్తుంది మరియు క్లస్టర్‌ల కోసం గ్రౌండ్ అప్ నుండి రూపొందించబడింది. విశ్వసనీయత కోసం అవసరమైతే అనుచరుల సంఖ్యను 11కి పెంచవచ్చు. రెప్లికేషన్ ఫ్యాక్టర్ 5 మరియు సింక్రొనైజేషన్‌లో ప్రతిరూపాల కనీస సంఖ్య min.insync.replicas=3 సందేశాన్ని కోల్పోవడం చాలా అరుదైన సంఘటనగా మారుతుంది. మీ ఇన్‌ఫ్రాస్ట్రక్చర్ ఈ రెప్లికేషన్ రేషియో మరియు రిడెండెన్సీ స్థాయికి మద్దతు ఇవ్వగలిగితే, మీరు ఈ ఎంపికను ఎంచుకోవచ్చు.

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

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

చివరగా, RabbitMQ మరియు Kafka రెండింటి యొక్క క్లస్టరింగ్ మరియు రెప్లికేషన్ మెకానిజమ్స్‌లోని అనేక బగ్‌ల గురించి మర్చిపోవద్దు. కాలక్రమేణా, సిస్టమ్‌లు మరింత పరిణతి చెందాయి మరియు స్థిరంగా మారాయి, కానీ ఏ సందేశం నష్టం నుండి 100% సురక్షితంగా ఉండదు! దీనికి తోడు డేటా సెంటర్లలో పెద్ద ఎత్తున ప్రమాదాలు జరుగుతున్నాయి!

నేను ఏదైనా కోల్పోయినా, పొరపాటు చేసినా లేదా మీరు ఏవైనా అంశాలతో విభేదించినా, వ్యాఖ్య వ్రాయడానికి సంకోచించకండి లేదా నన్ను సంప్రదించండి.

నేను తరచుగా అడుగుతాను: “ఏమి ఎంచుకోవాలి, కాఫ్కా లేదా రాబిట్‌ఎమ్‌క్యూ?”, “ఏ ప్లాట్‌ఫారమ్ మంచిది?”. నిజం ఏమిటంటే ఇది నిజంగా మీ పరిస్థితి, ప్రస్తుత అనుభవం మొదలైన వాటిపై ఆధారపడి ఉంటుంది. అన్ని వినియోగ సందర్భాలు మరియు సాధ్యమయ్యే పరిమితుల కోసం ఒక ప్లాట్‌ఫారమ్‌ను సిఫార్సు చేయడం చాలా సరళీకృతం అయినందున నా అభిప్రాయాన్ని తెలియజేయడానికి నేను సంకోచించాను. మీరు మీ స్వంత అభిప్రాయాన్ని ఏర్పరచుకోవడానికి నేను ఈ వ్యాసాల పరంపరను వ్రాసాను.

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

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

మూలం: www.habr.com