ప్రతి సర్వర్‌కు కాకుండా ఒక్కసారే వెళ్లే అలర్ట్‌లు

మా కార్యాచరణ అలర్ట్‌లలో ఒకటి — బిల్డర్ యాప్‌కు “తక్కువ క్రెడిట్‌లు” — మాకు రోజుకు ఒక్కసారే చేరాలి. ఒక మధ్యాహ్నం అది ఐదుసార్లు వచ్చింది. కారణం: మా API యొక్క ప్రతి కాపీ ఏ అలర్ట్‌లు ఇప్పటికే పంపిందో తన స్వంత మెమరీలో గుర్తుంచుకుంది, కాబట్టి రెండు సర్వర్లు దాన్ని రెండుసార్లు పంపాయి, మరియు ప్రతి డిప్లాయ్ ఆ మెమరీని తుడిచేసి వాటిని మళ్లీ పంపడానికి అనుమతించింది. అదే నమూనా ఒక బ్యాక్‌గ్రౌండ్ జాబ్ తన పనిని రెండుసార్లు చేయడానికి కారణమైంది. ఇప్పుడు రెండూ ఒక షేర్డ్ స్టోర్ ద్వారా సమన్వయం చేసుకుంటాయి, మరియు ఆ స్టోర్ అందుబాటులో లేకపోతే రెండూ సురక్షితమైన వైపు విఫలమవుతాయి.

లక్షణం

ఏదైనా చూడాల్సినప్పుడు Mythex తన బృందానికి అలర్ట్‌లు పంపుతుంది: ఒక సర్వీస్ డౌన్ అయినప్పుడు, ఒక జాబ్ ఆగిపోయినప్పుడు, లేదా ఒక బిల్డర్ యొక్క క్రెడిట్ బ్యాలెన్స్ వారి యాప్ పబ్లిష్ అయి ఉండగానే తగ్గుతున్నప్పుడు. ప్రతి అలర్ట్‌కు ఒక డిడూప్ విండో ఉంటుంది — అదే అలర్ట్ ఒక్కసారే పంపబడే వ్యవధి. తక్కువ క్రెడిట్‌ల అలర్ట్ కోసం, ఆ విండో 24 గంటలు.

ఒకే మధ్యాహ్నంలో ఒకే అలర్ట్ ఐదు కాపీలు అంటే విండో నిలవలేదు. అంతకంటే ఘోరంగా, అవి జతలుగా, దాదాపు 11 నిమిషాల తేడాతో వచ్చాయి.

ఇది ఎందుకు జరిగింది

మా అలర్ట్స్ ప్యాకేజీ డిడూప్‌ను మెమరీలో ఉంచింది: ఒక టేబుల్, “అలర్ట్ కీ → అది చివరిసారి ఎప్పుడు పంపబడింది” అనేది, నడుస్తున్న ప్రాసెస్ లోపల. ఒకే ప్రాసెస్ ఉండి, అది ఎప్పుడూ రీస్టార్ట్ కాకపోతే అది పనిచేస్తుంది. ప్రొడక్షన్‌లో ఈ రెండూ లేవు:

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

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

అదే కోడ్‌లో రెండవ, మరింత నిశ్శబ్ద బగ్ ఉంది. టేబుల్ అనంతంగా పెరగకుండా ఆపడానికి, అది 500 కీలు ఉన్నప్పుడు తనను తాను ప్రూన్ చేసేది — ప్రతి పాత 15 నిమిషాల ఎంట్రీని, దాని విండోతో సంబంధం లేకుండా, తొలగించేది. భారం కింద, 24 గంటల డిడూప్ పావు గంట మాత్రమే నిలిచేది.

పరిష్కారం

ప్రతి అలర్ట్‌కు ఒక షేర్డ్ రికార్డ్

API ఒక అలర్ట్‌ను పంపే ముందు, ఇప్పుడు అది Redis లో ఆ అలర్ట్ యొక్క డిడూప్ కీని క్లెయిమ్ చేస్తుంది — రెండు రెప్లికాలు మాట్లాడే, API రీస్టార్ట్ అయినప్పుడు కూడా పోని ఒక షేర్డ్ ఇన్-మెమరీ స్టోర్. క్లెయిమ్ అనేది ఒకే ఆపరేషన్: “ఈ కీ లేకపోతేనే సెట్ చేయి, మరియు విండో తర్వాత గడువు ముగియనివ్వు”. మొదట క్లెయిమ్ చేసిన రెప్లికా అలర్ట్‌ను పంపుతుంది; మరొకటి కీ తీసుకోబడిందని కనుగొని మౌనంగా ఉంటుంది. డిప్లాయ్ తర్వాత కొత్త ప్రాసెస్ కీ ఇంకా అక్కడే ఉందని కనుగొంటుంది.

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

విఫలమైతే తెరిచి ఉండండి, మూసివేయకండి

అత్యంత ముఖ్యమైన నిర్ణయం Redis చేరుకోలేనప్పుడు ఏమి చేయాలో అది. మేము అలర్ట్‌ను ఏమైనా పంపాలని ఎంచుకున్నాము. Redis డౌన్ అయితే, లేదా 1.5 సెకన్లలో స్పందించకపోతే, అలర్ట్ వెళ్తుంది. డూప్లికేట్ అలర్ట్ శబ్దం. డ్రాప్ అయిన అలర్ట్ అంటే ఎవరికీ చెప్పబడని విషయం.

అత్యంత తీవ్రమైన అలర్ట్‌లు, P0, డిడూప్ ద్వారా అస్సలు ఆపబడవు.

ప్రతి ఎంట్రీ తన స్వంత విండోను ఉంచుకుంటుంది

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

అదే బగ్, మరెక్కడో

అదే నమూనా ఒక బ్యాక్‌గ్రౌండ్ పనిని కూడా రెట్టింపు చేసింది: మా సాండ్‌బాక్స్ ప్రొవైడర్‌తో సరిపోయేలా ప్రతి వర్క్‌స్పేస్ స్టేటస్‌పై మా రికార్డును ఉంచే ఒక రికన్సిలియేషన్ జాబ్. ప్రతి పాస్ ఖాతాలోని ప్రతి సాండ్‌బాక్స్‌ను జాబితా చేస్తుంది — ప్రొడక్షన్‌లో వేలాది, సుమారు ఐదు సెకన్లు — అలాగే ప్రతి రన్ అవుతున్న లేదా పాజ్ అయిన ప్రాజెక్ట్‌ను. రెండు రెప్లికాలు దీన్ని ప్రతి రెండు నిమిషాలకు నడిపేవి.

దాని రైట్‌లు ఐడెంపొటెంట్ — అంటే రెండుసార్లు నడపడం ఒక్కసారి నడిపినట్లే ఫలితం ఇస్తుంది — కాబట్టి ఏదీ విరగలేదు. కేవలం రెట్టింపు పని అంతే. ఇప్పుడు ప్రతి రెండు నిమిషాల విండో Redis లో అలాగే క్లెయిమ్ చేయబడుతుంది, మా యూసేజ్ మీటర్లు ఇప్పటికే తమవాటిని క్లెయిమ్ చేసినట్లే, మరియు ఆ క్లెయిమ్ చేసిన రెప్లికా మాత్రమే పాస్‌ను నడుపుతుంది. Redis చేరుకోలేకపోతే, పాస్ ఎలాగూ నడుస్తుంది: పనిని రెండుసార్లు చేయడం హానికరం కాదు, చేయకపోవడం అలా కాదు.

మేము దీన్ని ఎలా పరీక్షించాము

పరీక్షలు నిజమైన సెటప్‌ను మోడల్ చేస్తాయి. అవి అలర్ట్ మాడ్యూల్‌ను రెండుసార్లు లోడ్ చేస్తాయి, “ఇద్దరు రెప్లికాలు”గా వేర్వేరు కాపీలుగా, ఇద్దరినీ ఒకే షేర్డ్ స్టోర్‌కు సూచిస్తాయి, ప్రతిదాని నుండి ఒకే అలర్ట్‌ను పెంచుతాయి, తర్వాత “డిప్లాయ్ తర్వాత”ను సూచించడానికి మూడవ తాజా కాపీని లోడ్ చేసి మళ్లీ పెంచుతాయి. సరిగ్గా ఒక అలర్ట్ పంపబడుతుంది. ఇతర పరీక్షలు వేరే బిల్డర్ అలర్ట్ ఇంకా వెళ్తుందని, P0 రెండు రెప్లికాల నుండి పంపబడుతుందని, మరియు స్టోర్ డౌన్ అయినా లేదా టైమ్‌అవుట్ దాటి వేలాడినా అలర్ట్ ఇంకా పంపబడుతుందని తనిఖీ చేస్తాయి. ప్రూన్ ఫిక్స్‌కు దాని స్వంత పరీక్ష ఉంది: 20 నిమిషాల తర్వాత వచ్చే 600 ఇతర అలర్ట్‌లను 24 గంటల కీ తట్టుకుంటుంది.

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

మేము దీనినుండి నేర్చుకున్నది

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

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