తప్పు సహనం మరియు అధిక లభ్యత పెద్ద అంశాలు, కాబట్టి మేము RabbitMQ మరియు కాఫ్కాకు ప్రత్యేక కథనాలను కేటాయిస్తాము. ఈ కథనం RabbitMQ గురించి మరియు తదుపరిది RabbitMQతో పోల్చితే కాఫ్కా గురించి. ఇది సుదీర్ఘ కథనం, కాబట్టి మిమ్మల్ని మీరు సౌకర్యవంతంగా చేసుకోండి.

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

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

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

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

సింగిల్ నోడ్ రెసిలెన్స్ ప్రిమిటివ్స్

స్థితిస్థాపక క్యూయింగ్/రూటింగ్

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

నోడ్ పునఃప్రారంభించబడినప్పుడు అస్థిర క్యూలు మరియు రూటింగ్ తీసివేయబడతాయి.

నిరంతర సందేశాలు

క్యూ మన్నికైనది అయినందున దాని సందేశాలన్నీ నోడ్ పునఃప్రారంభించబడిన తర్వాత మనుగడ సాగిస్తాయని కాదు. ప్రచురణకర్త ద్వారా సెట్ చేయబడిన సందేశాలు మాత్రమే స్థిరమైన (నిరంతర). నిరంతర సందేశాలు బ్రోకర్‌పై అదనపు లోడ్‌ను సృష్టిస్తాయి, అయితే సందేశ నష్టం ఆమోదయోగ్యం కానట్లయితే, వేరే ఎంపిక లేదు.

అన్నం. 1. సస్టైనబిలిటీ మ్యాట్రిక్స్

క్యూ మిర్రరింగ్‌తో క్లస్టరింగ్

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

క్యూ మిర్రరింగ్:

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

అన్నం. 2. క్యూ మిర్రరింగ్

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

• ha-mode: all
• ha-mode: exactly, ha-params: 2 (ఒక మాస్టర్ మరియు ఒక అద్దం)
• ha-mode: nodes, ha-params: rabbit@node1, rabbit@node2

ప్రచురణకర్త నిర్ధారణ

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

ఫెయిల్ఓవర్ క్యూ

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

అన్నం. 3. బహుళ ప్రతిబింబ క్యూలు మరియు వాటి విధానాలు

బ్రోకర్ 3 తగ్గుతుంది. బ్రోకర్ 2లోని క్యూ సి మిర్రర్ మాస్టర్‌గా ప్రమోట్ చేయబడుతుందని గమనించండి. బ్రోకర్ 1లో క్యూ C కోసం కొత్త అద్దం సృష్టించబడిందని కూడా గమనించండి. RabbitMQ ఎల్లప్పుడూ మీ విధానాలలో పేర్కొన్న ప్రతిరూపణ కారకాన్ని నిర్వహించడానికి ప్రయత్నిస్తుంది.

అన్నం. 4. బ్రోకర్ 3 విఫలమైతే, క్యూ C విఫలమవుతుంది

తదుపరి బ్రోకర్ 1 వస్తుంది! మాకు ఒక బ్రోకర్ మాత్రమే మిగిలి ఉంది. క్యూ B అద్దం మాస్టర్‌గా ప్రమోట్ చేయబడింది.

అంజీర్. 5

మేము బ్రోకర్ 1ని తిరిగి అందించాము. బ్రోకర్ యొక్క నష్టం మరియు పునరుద్ధరణ నుండి డేటా ఎంతవరకు మనుగడ సాగించినప్పటికీ, పునఃప్రారంభించిన తర్వాత అన్ని ప్రతిబింబించిన క్యూ సందేశాలు విస్మరించబడతాయి. ఇది గమనించడం ముఖ్యం ఎందుకంటే పరిణామాలు ఉంటాయి. మేము ఈ చిక్కులను త్వరలో పరిశీలిస్తాము. కాబట్టి బ్రోకర్ 1 ఇప్పుడు మళ్లీ క్లస్టర్‌లో సభ్యుడు, మరియు క్లస్టర్ విధానాలకు అనుగుణంగా ప్రయత్నిస్తుంది మరియు అందువల్ల బ్రోకర్ 1లో మిర్రర్‌లను సృష్టిస్తుంది.

ఈ సందర్భంలో, డేటా వలె బ్రోకర్ 1 యొక్క నష్టం పూర్తయింది, కాబట్టి ప్రతిబింబించని క్యూ B పూర్తిగా పోయింది.

అన్నం. 6. బ్రోకర్ 1 సేవకు తిరిగి వస్తాడు

బ్రోకర్ 3 ఆన్‌లైన్‌కి తిరిగి వచ్చింది, కాబట్టి A మరియు B క్యూలు తమ HA విధానాలను సంతృప్తి పరచడానికి దానిపై సృష్టించబడిన మిర్రర్‌లను తిరిగి పొందుతాయి. కానీ ఇప్పుడు అన్ని ప్రధాన క్యూలు ఒకే నోడ్‌లో ఉన్నాయి! ఇది అనువైనది కాదు, నోడ్‌ల మధ్య సమాన పంపిణీ మంచిది. దురదృష్టవశాత్తూ, మాస్టర్‌లను రీబ్యాలెన్స్ చేయడానికి ఇక్కడ చాలా ఎంపికలు లేవు. మేము ముందుగా ఈ సమస్యకు తిరిగి వస్తాము ఎందుకంటే మేము ముందుగా క్యూ సమకాలీకరణను చూడాలి.

అన్నం. 7. బ్రోకర్ 3 సేవకు తిరిగి వస్తుంది. ఒక నోడ్‌లో అన్ని ప్రధాన క్యూలు!

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

సమకాలీకరణ

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

ఈ సమకాలీకరణ స్వయంచాలకంగా లేదా మాన్యువల్‌గా నిర్వహించబడుతుంది మరియు క్యూ విధానాన్ని ఉపయోగించి నిర్వహించబడుతుంది. ఒక ఉదాహరణ చూద్దాం.

మాకు రెండు అద్దాల క్యూలు ఉన్నాయి. క్యూ A స్వయంచాలకంగా సమకాలీకరించబడుతుంది మరియు క్యూ B మానవీయంగా సమకాలీకరించబడుతుంది. రెండు వరుసలు పది సందేశాలను కలిగి ఉంటాయి.

అన్నం. 8. విభిన్న సమకాలీకరణ మోడ్‌లతో రెండు క్యూలు

ఇప్పుడు మేము బ్రోకర్ 3ని కోల్పోతున్నాము.

అన్నం. 9. బ్రోకర్ 3 పడిపోయింది

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

అన్నం. 10. క్యూ A యొక్క కొత్త అద్దం ఇప్పటికే ఉన్న అన్ని సందేశాలను అందుకుంటుంది, కానీ క్యూ B యొక్క కొత్త అద్దం అందుకోదు.

రెండు క్యూలలో మరో పది సందేశాలు వస్తాయి. బ్రోకర్ 2 తర్వాత క్రాష్ అవుతుంది మరియు క్యూ A బ్రోకర్ 1లో ఉన్న పురాతన మిర్రర్‌కి తిరిగి వస్తుంది. అది విఫలమైనప్పుడు డేటా నష్టం ఉండదు. క్యూ Bలో, మాస్టర్‌లో ఇరవై సందేశాలు ఉన్నాయి మరియు అద్దంలో పది మాత్రమే ఉన్నాయి, ఎందుకంటే ఈ క్యూ అసలు పది సందేశాలను పునరావృతం చేయలేదు.

అన్నం. 11. క్యూ A సందేశాలను కోల్పోకుండా బ్రోకర్ 1కి తిరిగి వస్తుంది

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

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

అన్నం. 12. క్యూ A సందేశాలను కోల్పోకుండా బ్రోకర్ 3కి తిరిగి మార్చబడుతుంది. క్యూ B పది సందేశాలను కోల్పోయి బ్రోకర్ 3కి తిరిగి వస్తుంది

మనం కూడా ఇన్‌స్టాల్ చేసుకోవచ్చు ha-promote-on-failure అర్థం లోకి when-synced. ఈ సందర్భంలో, మిర్రర్‌కు తిరిగి వెళ్లడానికి బదులుగా, బ్రోకర్ 1 డేటాతో ఆన్‌లైన్ మోడ్‌కి తిరిగి వచ్చే వరకు క్యూ వేచి ఉంటుంది. ఇది తిరిగి వచ్చిన తర్వాత, ప్రధాన క్యూ ఎటువంటి డేటా నష్టం లేకుండా బ్రోకర్ 1కి తిరిగి వస్తుంది. డేటా భద్రత కోసం లభ్యత త్యాగం చేయబడింది. కానీ ఇది ప్రమాదకర మోడ్, ఇది పూర్తి డేటా నష్టానికి కూడా దారి తీస్తుంది, దీనిని మేము త్వరలో పరిశీలిస్తాము.

అన్నం. 13. బ్రోకర్ 1ని కోల్పోయిన తర్వాత క్యూ B అందుబాటులో ఉండదు

మీరు అడగవచ్చు, “ఎప్పుడూ ఆటోమేటిక్ సింక్రొనైజేషన్‌ని ఉపయోగించకపోవడమే మంచిదా?” సమకాలీకరణ అనేది నిరోధించే ఆపరేషన్ అని సమాధానం. సమకాలీకరణ సమయంలో, ప్రధాన క్యూ ఏ రీడ్ లేదా రైట్ ఆపరేషన్‌లను నిర్వహించదు!

ఒక ఉదాహరణ చూద్దాం. ఇప్పుడు మాకు చాలా పొడవైన క్యూలు ఉన్నాయి. అవి అంత పరిమాణానికి ఎలా పెరుగుతాయి? అనేక కారణాల వల్ల:

• క్యూలు చురుకుగా ఉపయోగించబడవు
• ఇవి హై-స్పీడ్ క్యూలు మరియు ప్రస్తుతం వినియోగదారులు నెమ్మదిగా ఉన్నారు
• ఇది హై-స్పీడ్ క్యూలు, ఒక లోపం ఉంది మరియు వినియోగదారులు పట్టుకుంటున్నారు

అన్నం. 14. విభిన్న సమకాలీకరణ మోడ్‌లతో రెండు పెద్ద క్యూలు

ఇప్పుడు బ్రోకర్ 3 పడిపోయింది.

అన్నం. 15. బ్రోకర్ 3 పడిపోతుంది, ప్రతి క్యూలో ఒక మాస్టర్ మరియు అద్దం వదిలివేయబడుతుంది

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

అయితే, క్యూ B మొత్తం వ్యవధిలో అందుబాటులో ఉంటుంది. ప్రాప్యత కోసం ఆమె కొంత రిడెండెన్సీని త్యాగం చేసింది.

అన్నం. 16. సమకాలీకరణ సమయంలో క్యూ అందుబాటులో ఉండదు

రెండు గంటల తర్వాత, క్యూ A కూడా అందుబాటులోకి వస్తుంది మరియు చదవడం మరియు వ్రాయడం మళ్లీ అంగీకరించడం ప్రారంభించవచ్చు.

నవీకరించడాన్ని

సమకాలీకరణ సమయంలో ఈ నిరోధించే ప్రవర్తన చాలా పెద్ద క్యూలతో క్లస్టర్‌లను నవీకరించడం కష్టతరం చేస్తుంది. ఏదో ఒక సమయంలో, మాస్టర్ నోడ్ పునఃప్రారంభించబడాలి, అంటే అద్దానికి మారడం లేదా సర్వర్ అప్‌గ్రేడ్ అవుతున్నప్పుడు క్యూను నిలిపివేయడం. మేము పరివర్తనను ఎంచుకుంటే, అద్దాలు సమకాలీకరించబడకపోతే మేము సందేశాలను కోల్పోతాము. డిఫాల్ట్‌గా, బ్రోకర్ అంతరాయం సమయంలో, సమకాలీకరించని మిర్రర్‌కు వైఫల్యం ప్రదర్శించబడదు. దీని అర్థం బ్రోకర్ తిరిగి వచ్చిన వెంటనే, మేము ఎటువంటి సందేశాలను కోల్పోము, సాధారణ క్యూ మాత్రమే నష్టం. బ్రోకర్ డిస్‌కనెక్ట్ చేయబడినప్పుడు ప్రవర్తనా నియమాలు విధానం ద్వారా సెట్ చేయబడతాయి ha-promote-on-shutdown. మీరు రెండు విలువలలో ఒకదాన్ని సెట్ చేయవచ్చు:

• always= సమకాలీకరించని అద్దాలకు పరివర్తన ప్రారంభించబడింది
• when-synced= సమకాలీకరించబడిన అద్దానికి మాత్రమే పరివర్తనం, లేకపోతే క్యూ చదవలేనిదిగా మరియు వ్రాయలేనిదిగా మారుతుంది. బ్రోకర్ తిరిగి వచ్చిన వెంటనే క్యూ సేవకు తిరిగి వస్తుంది

ఒక మార్గం లేదా మరొకటి, పెద్ద క్యూలతో మీరు డేటా నష్టం మరియు లభ్యత మధ్య ఎంచుకోవాలి.

లభ్యత డేటా భద్రతను మెరుగుపరిచినప్పుడు

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

ఇక్కడ మీరు ఈ క్రింది వాటిని పరిగణించాలి:

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

ప్రచురణకర్త సందేశాన్ని మాత్రమే విస్మరించగలిగితే, వాస్తవానికి, యాక్సెసిబిలిటీని మెరుగుపరచడం వల్ల డేటా భద్రత కూడా మెరుగుపడుతుంది.

అందువల్ల, సమతుల్యతను వెతకాలి మరియు పరిష్కారం నిర్దిష్ట పరిస్థితిపై ఆధారపడి ఉంటుంది.

ha-promote-on-failure=when-synced తో సమస్యలు

ఆలోచన ha-promote-on-failure= ఎప్పుడు-సమకాలీకరించబడింది మేము సమకాలీకరించని మిర్రర్‌కు మారడాన్ని నిరోధించడం మరియు తద్వారా డేటా నష్టాన్ని నివారించడం. క్యూ చదవడానికి లేదా వ్రాయడానికి వీలుగా ఉంది. బదులుగా, మేము క్రాష్ అయిన బ్రోకర్‌ను దాని డేటా చెక్కుచెదరకుండా పునరుద్ధరించడానికి ప్రయత్నిస్తాము, తద్వారా అది డేటా నష్టం లేకుండా మాస్టర్‌గా పని చేయడం ప్రారంభించవచ్చు.

కానీ (మరియు ఇది పెద్దది కానీ) బ్రోకర్ తన డేటాను పోగొట్టుకున్నట్లయితే, మాకు పెద్ద సమస్య ఉంది: క్యూ పోయింది! మొత్తం డేటా పోయింది! మీ వద్ద ప్రధాన క్యూలో ఎక్కువగా పట్టుకునే అద్దాలు ఉన్నప్పటికీ, ఆ అద్దాలు కూడా విస్మరించబడతాయి.

అదే పేరుతో నోడ్‌ను మళ్లీ జోడించడానికి, కోల్పోయిన నోడ్‌ను (కమాండ్‌తో) మర్చిపోవాలని మేము క్లస్టర్‌కి చెబుతాము rabbitmqctl మర్చిపోయి_క్లస్టర్_నోడ్) మరియు అదే హోస్ట్ పేరుతో కొత్త బ్రోకర్‌ని ప్రారంభించండి. క్లస్టర్ కోల్పోయిన నోడ్‌ను గుర్తుంచుకున్నప్పుడు, అది పాత క్యూ మరియు సమకాలీకరించని అద్దాలను గుర్తుంచుకుంటుంది. అనాథ నోడ్‌ను మర్చిపోవాలని ఒక క్లస్టర్‌కు చెప్పినప్పుడు, ఆ క్యూ కూడా మరచిపోతుంది. ఇప్పుడు మనం దానిని మళ్లీ ప్రకటించాలి. మేము డేటా యొక్క పాక్షిక సెట్‌తో మిర్రర్‌లను కలిగి ఉన్నప్పటికీ, మేము మొత్తం డేటాను కోల్పోయాము. నాన్-సింక్రొనైజ్డ్ మిర్రర్‌కి మారడం మంచిది!

అందువలన, మాన్యువల్ సింక్రొనైజేషన్ (మరియు సమకాలీకరించడంలో వైఫల్యం) కలిపి ha-promote-on-failure=when-synced, నా అభిప్రాయం ప్రకారం, చాలా ప్రమాదకరం. డేటా భద్రత కోసం ఈ ఎంపిక ఉందని పత్రాలు చెబుతున్నాయి, అయితే ఇది డబుల్ ఎడ్జ్ నైఫ్.

మాస్టర్ రీబ్యాలెన్సింగ్

వాగ్దానం చేసినట్లుగా, మేము ఒకటి లేదా అనేక నోడ్లలో అన్ని మాస్టర్స్ చేరడం యొక్క సమస్యకు తిరిగి వస్తాము. రోలింగ్ క్లస్టర్ అప్‌డేట్ ఫలితంగా కూడా ఇది జరగవచ్చు. మూడు-నోడ్ క్లస్టర్‌లో, అన్ని మాస్టర్ క్యూలు ఒకటి లేదా రెండు నోడ్‌లలో పేరుకుపోతాయి.

మాస్టర్స్ రీబ్యాలెన్సింగ్ రెండు కారణాల వల్ల సమస్యాత్మకం కావచ్చు:

• రీబ్యాలెన్సింగ్ చేయడానికి మంచి సాధనాలు లేవు
• క్యూ సమకాలీకరణ

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

HA విధానాల ద్వారా ప్రధాన క్యూను తరలించడానికి మరొక ట్రిక్ ఉంది. మాన్యువల్‌లో పేర్కొన్నారు స్క్రిప్ట్ దీని కొరకు. ఇది ఇలా పనిచేస్తుంది:

• ఇప్పటికే ఉన్న HA పాలసీ కంటే అధిక ప్రాధాన్యత కలిగిన తాత్కాలిక విధానాన్ని ఉపయోగించి అన్ని మిర్రర్‌లను తొలగిస్తుంది.
• నోడ్ మోడ్‌ని ఉపయోగించడానికి HA తాత్కాలిక విధానాన్ని మారుస్తుంది, మాస్టర్ క్యూను ఏ నోడ్‌కి బదిలీ చేయాలో పేర్కొంటుంది.
• పుష్ మైగ్రేషన్ కోసం క్యూను సమకాలీకరిస్తుంది.
• మైగ్రేషన్ పూర్తయిన తర్వాత, తాత్కాలిక విధానాన్ని తొలగిస్తుంది. ప్రారంభ HA విధానం అమలులోకి వస్తుంది మరియు అవసరమైన మిర్రర్‌ల సంఖ్య సృష్టించబడుతుంది.

ప్రతికూలత ఏమిటంటే, మీకు పెద్ద క్యూలు లేదా కఠినమైన రిడెండెన్సీ అవసరాలు ఉంటే ఈ విధానం పని చేయకపోవచ్చు.

నెట్‌వర్క్ విభజనలతో RabbitMQ క్లస్టర్‌లు ఎలా పని చేస్తాయో ఇప్పుడు చూద్దాం.

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

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

RabbitMQతో మనకు రెండు ప్రధాన ఎంపికలు ఉన్నాయి:

• తార్కిక విభజనను (స్ప్లిట్-మెదడు) అనుమతించండి. ఇది లభ్యతను నిర్ధారిస్తుంది, కానీ డేటా నష్టానికి కారణం కావచ్చు.
• తార్కిక విభజనను నిలిపివేయండి. క్లయింట్‌లు క్లస్టర్‌కి ఎలా కనెక్ట్ అవుతారనే దానిపై ఆధారపడి స్వల్పకాలిక లభ్యత కోల్పోవచ్చు. రెండు-నోడ్ క్లస్టర్‌లో పూర్తి లభ్యతకు కూడా దారితీయవచ్చు.

కానీ తార్కిక విభజన అంటే ఏమిటి? నెట్‌వర్క్ కనెక్షన్‌లను కోల్పోవడం వల్ల క్లస్టర్ రెండుగా విడిపోయినప్పుడు ఇది జరుగుతుంది. ప్రతి వైపు, అద్దాలు మాస్టర్‌గా పదోన్నతి పొందుతాయి, తద్వారా ప్రతి మలుపుకు అనేక మంది మాస్టర్‌లు ఉంటారు.

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

ప్రచురణకర్తలు ఇద్దరు మాస్టర్‌లకు డేటాను పంపితే, మేము క్యూ యొక్క రెండు విభిన్న కాపీలను అందిస్తాము.

RabbitMQ యొక్క విభిన్న మోడ్‌లు లభ్యత లేదా స్థిరత్వాన్ని అందిస్తాయి.

విస్మరించు మోడ్ (డిఫాల్ట్)

ఈ మోడ్ ప్రాప్యతను నిర్ధారిస్తుంది. కనెక్టివిటీని కోల్పోయిన తర్వాత, తార్కిక విభజన జరుగుతుంది. కనెక్టివిటీ పునరుద్ధరించబడిన తర్వాత, నిర్వాహకుడు ఏ విభజనకు ప్రాధాన్యత ఇవ్వాలో నిర్ణయించుకోవాలి. ఓడిపోయిన వైపు పునఃప్రారంభించబడుతుంది మరియు ఆ వైపున సేకరించబడిన మొత్తం డేటా పోతుంది.

అన్నం. 18. ముగ్గురు ప్రచురణకర్తలు ముగ్గురు బ్రోకర్లతో అనుబంధించబడ్డారు. అంతర్గతంగా, క్లస్టర్ అన్ని అభ్యర్థనలను బ్రోకర్ 2లోని ప్రధాన క్యూకి పంపుతుంది.

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

అన్నం. 19. లాజికల్ డివిజన్ (స్ప్లిట్-మెదడు). రికార్డులు రెండు ప్రధాన క్యూలలోకి వెళ్తాయి మరియు రెండు కాపీలు వేర్వేరుగా ఉంటాయి.

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

అన్నం. 20. నిర్వాహకుడు బ్రోకర్ 3ని నిలిపివేస్తాడు.

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

కనెక్టివిటీని కోల్పోయిన సమయంలో మరియు దాని పునరుద్ధరణ తర్వాత, క్లస్టర్ మరియు ఈ క్యూ చదవడానికి మరియు వ్రాయడానికి అందుబాటులో ఉన్నాయి.

ఆటోహీల్ మోడ్

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

మైనారిటీ మోడ్‌ను పాజ్ చేయండి

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

అన్నం. 22. ముగ్గురు ప్రచురణకర్తలు ముగ్గురు బ్రోకర్లతో అనుబంధించబడ్డారు. అంతర్గతంగా, క్లస్టర్ అన్ని అభ్యర్థనలను బ్రోకర్ 2లోని ప్రధాన క్యూకి పంపుతుంది.

బ్రోకర్లు 1 మరియు 2 తర్వాత బ్రోకర్ 3 నుండి విడిపోయారు. వారి మిర్రర్‌ను మాస్టర్‌గా ప్రమోట్ చేయడానికి బదులుగా, బ్రోకర్ 3 సస్పెండ్ చేయబడి అందుబాటులో లేకుండా పోతుంది.

అన్నం. 23. బ్రోకర్ 3 పాజ్ చేస్తుంది, క్లయింట్‌లందరినీ డిస్‌కనెక్ట్ చేస్తుంది మరియు కనెక్షన్ అభ్యర్థనలను తిరస్కరిస్తుంది.

కనెక్టివిటీ పునరుద్ధరించబడిన తర్వాత, అది క్లస్టర్‌కి తిరిగి వస్తుంది.

ప్రధాన క్యూ బ్రోకర్ 3లో ఉన్న మరొక ఉదాహరణను చూద్దాం.

అన్నం. 24. బ్రోకర్ 3లో ప్రధాన క్యూ.

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

అన్నం. 25. బ్రోకర్ 2 అందుబాటులో లేకుంటే బ్రోకర్ 3కి మార్పు.

కనెక్టివిటీ పునరుద్ధరించబడినప్పుడు, బ్రోకర్ 3 క్లస్టర్‌లో చేరుతుంది.

అన్నం. 26. క్లస్టర్ సాధారణ కార్యాచరణకు తిరిగి వచ్చింది.

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

లభ్యతను నిర్ధారించడానికి, క్లయింట్‌లు హోస్ట్‌కి విజయవంతంగా కనెక్ట్ అయ్యారని నిర్ధారించుకోవడం చాలా ముఖ్యం. మా ఎంపికలను చూద్దాం.

కస్టమర్ కనెక్టివిటీకి భరోసా

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

మా ఎంపికలు:

• క్లస్టర్ లోడ్ బ్యాలెన్సర్‌ని ఉపయోగించి యాక్సెస్ చేయబడుతుంది, ఇది నోడ్‌ల ద్వారా సైకిల్ చేస్తుంది మరియు క్లయింట్‌లు విజయవంతం అయ్యే వరకు కనెక్ట్ చేయడానికి మళ్లీ ప్రయత్నిస్తారు. నోడ్ డౌన్ లేదా సస్పెండ్ అయినట్లయితే, ఆ నోడ్‌కి కనెక్ట్ చేసే ప్రయత్నాలు విఫలమవుతాయి, కానీ తదుపరి ప్రయత్నాలు ఇతర సర్వర్‌లకు వెళ్తాయి (రౌండ్-రాబిన్ పద్ధతిలో). కనెక్టివిటీ యొక్క స్వల్పకాలిక నష్టం లేదా డౌన్‌డ్ అయిన సర్వర్‌కు ఇది అనుకూలంగా ఉంటుంది, అది త్వరగా తిరిగి తీసుకురాబడుతుంది.
• లోడ్ బ్యాలెన్సర్ ద్వారా క్లస్టర్‌ను యాక్సెస్ చేయండి మరియు సస్పెండ్ చేయబడిన/విఫలమైన నోడ్‌లను గుర్తించిన వెంటనే జాబితా నుండి తీసివేయండి. మేము దీన్ని త్వరగా చేస్తే మరియు క్లయింట్‌లు కనెక్షన్‌ని మళ్లీ ప్రయత్నించగలిగితే, మేము స్థిరమైన లభ్యతను సాధిస్తాము.
• ప్రతి క్లయింట్‌కు అన్ని నోడ్‌ల జాబితాను ఇవ్వండి మరియు కనెక్ట్ చేస్తున్నప్పుడు క్లయింట్ యాదృచ్ఛికంగా వాటిలో ఒకదాన్ని ఎంచుకుంటుంది. కనెక్ట్ చేయడానికి ప్రయత్నిస్తున్నప్పుడు అది ఎర్రర్‌ను స్వీకరిస్తే, అది కనెక్ట్ అయ్యే వరకు జాబితాలోని తదుపరి నోడ్‌కి తరలించబడుతుంది.
• DNSని ఉపయోగించి విఫలమైన/సస్పెండ్ చేయబడిన నోడ్ నుండి ట్రాఫిక్‌ను తీసివేయండి. ఇది చిన్న TTLని ఉపయోగించి చేయబడుతుంది.

కనుగొన్న

RabbitMQ క్లస్టరింగ్ దాని ప్రయోజనాలు మరియు అప్రయోజనాలు కలిగి ఉంది. అత్యంత తీవ్రమైన ప్రతికూలతలు:

• క్లస్టర్‌లో చేరినప్పుడు, నోడ్‌లు వాటి డేటాను విస్మరిస్తాయి;
• సమకాలీకరణను నిరోధించడం వలన క్యూ అందుబాటులో లేకుండా పోతుంది.

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

• నమ్మదగని నెట్‌వర్క్.
• నమ్మదగని నిల్వ.
• చాలా పొడవైన క్యూలు.

అధిక లభ్యత సెట్టింగ్‌ల విషయానికి వస్తే, ఈ క్రింది వాటిని పరిగణించండి:

• ha-promote-on-failure=always
• ha-sync-mode=manual
• cluster_partition_handling=ignore (లేదా autoheal)
• నిరంతర సందేశాలు
• కొన్ని నోడ్ విఫలమైనప్పుడు క్లయింట్‌లు యాక్టివ్ నోడ్‌కి కనెక్ట్ అయ్యేలా చూసుకోండి

స్థిరత్వం (డేటా భద్రత) కోసం, కింది సెట్టింగ్‌లను పరిగణించండి:

• పబ్లిషర్ కన్ఫర్మ్ మరియు మాన్యువల్ రసీదులను వినియోగదారు వైపు
• ha-promote-on-failure=when-synced, ప్రచురణకర్తలు తర్వాత మళ్లీ ప్రయత్నించగలిగితే మరియు మీకు చాలా నమ్మకమైన నిల్వ ఉంటే! లేకపోతే చాలు =always.
• ha-sync-mode=automatic (కానీ పెద్ద నిష్క్రియ క్యూల కోసం మాన్యువల్ మోడ్ అవసరం కావచ్చు; లభ్యత సందేశాలను కోల్పోయేలా చేస్తుందో లేదో కూడా పరిగణించండి)
• మైనారిటీ మోడ్‌ను పాజ్ చేయండి
• నిరంతర సందేశాలు

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

నేను మరేదైనా మిస్ అయినట్లయితే, దయచేసి నాకు తెలియజేయండి.

నాది కూడా చూడండి పోస్ట్, ఈ కథనంలో వివరించిన కొన్ని సందేశాలను కోల్పోయే దృశ్యాలను పరీక్షించడానికి నేను డాకర్ మరియు బ్లాకేడ్‌ని ఉపయోగించి RabbitMQ క్లస్టర్‌పై విధ్వంసాన్ని ప్రదర్శించాను.

సిరీస్‌లోని మునుపటి కథనాలు:
నం. 1 - habr.com/ru/company/itsumma/blog/416629
నం. 2 - habr.com/ru/company/itsumma/blog/418389
నం. 3 - habr.com/ru/company/itsumma/blog/437446

మూలం: www.habr.com