Brīdinājumi, kas skan vienreiz, nevis reizi katrā serverī

Viens no mūsu operatīvajiem brīdinājumiem — „zems kredītu atlikums” publicētai builder lietotnei — paredzēts tā, lai mūs sasniegtu ne vairāk kā vienu reizi dienā. Vienā pēcpusdienā tas ieradās piecas reizes. Iemesls: katra mūsu API kopija atmiņā atcerējās, kurus brīdinājumus jau bija nosūtījusi, tāpēc divi serveri nosūtīja to divreiz, un katra izvietošana šo atmiņu izdzēsa un ļāva tiem sūtīt vēlreiz. Tas pats raksturs bija arī fona darbam, kas tika veikts divreiz. Tagad abi koordinējas caur kopīgu krātuvi, un abi kļūst drošā pusē, ja šī krātuve nav pieejama.

Simptoms

Mythex sūta komandas brīdinājumus, kad kaut kam vajadzīga uzmanība: pakalpojums nedarbojas, darbs ir iestrēdzis, builder kredītu atlikums ir zems, kamēr tā lietotne ir publicēta. Katram brīdinājumam ir dublēšanas logs — laiks, kura laikā tas pats brīdinājums tiek nosūtīts tikai vienreiz. Zemu kredītu brīdinājumam šis logs ir 24 stundas.

Pieci viena brīdinājuma eksemplāri vienā pēcpusdienā nozīmēja, ka logs neturējās. Vēl sliktāk — tie nāca pāros, aptuveni 11 minūšu intervālā.

Kāpēc tas notika

Mūsu brīdinājumu pakotne glabāja dublēšanu atmiņā: tabulu „brīdinājuma atslēga → kad tas pēdējoreiz nosūtīts”, darbojošā procesā. Tas strādā, kad ir viens process, kas nekad nerestartējas. Produkcijā nav nevienas no šīm īpašībām:

• Divas API replikas. Produkcijā darbojas divas API kopijas. Katrai bija sava tabula, tāpēc katra nosūtīja brīdinājumu vienreiz. Tie ir pāri.
• Izvietošanas. Katra izvietošana aizstāj abas replikas ar jauniem procesiem un tukšām tabulām. Pēc izvietošanas brīdinājums tika nosūtīts vēlreiz, it kā nekad nebūtu tikts sūtīts.

11 minūšu intervāls starp diviem brīdinājumiem katrā pārī nāca no darba, kas paaugstina šo brīdinājumu. Tas darbojas abās replikās un ņem bloķēšanu, tāpēc replikas to iegūst pa kārtai, un katra paaugstināja brīdinājumu, kad bija tās kārta.

Tajā pašā kodā bija otra, klusāka kļūda. Lai tabula neaugtu bezgalīgi, tā tīrīja sevi, kad tajā bija 500 atslēgu — dzēsa katru ierakstu, kas bija vecāks par 15 minūtēm, neatkarīgi no tā loga. Lielā slodzē 24 stundu dublēšana varēja ilgt ceturtdaļstundu.

Labojums

Viens kopīgs ieraksts katram brīdinājumam

Pirms API nosūta brīdinājumu, tā tagad Redis krātuvē — kopīgā atmiņas krātuvē, ar kuru runā abas replikas un kura neatjaunojas, kad restartējas API — pieprasa brīdinājuma dublēšanas atslēgu. Pieprasījums ir viena operācija: „iestatīt šo atslēgu tikai tad, ja tās nav, un derīguma termiņš beidzas pēc loga”. Kura replika pirmā pieprasa, nosūta brīdinājumu; otra atrod atslēgu aizņemtu un paliek klusa. Jauns process pēc izvietošanas atrod atslēgu joprojām tur.

Atslēga un logs nāk no tā paša noteikuma, ko izmanto brīdinājumu pakotne, un tagad tas ir kopīgs abiem slāņiem, tāpēc tie nevar nesaskanēt par to, kas ir „tas pats brīdinājums”.

Kļūt atvērtam, nevis slēgtam

Svarīgākais lēmums bija, ko darīt, kad Redis nav sasniedzams. Izvēlējāmies brīdinājumu nosūtīt tik un tā. Ja Redis nav pieejams vai neatbild 1,5 sekunžu laikā, brīdinājums aiziet. Dublēts brīdinājums ir troksnis. Nosūtīts brīdinājums nav tikai tas, ka kāds nepaziņots.

Visnopietnākie brīdinājumi — P0 — dublēšanas dēļ nekad netiek aizturēti.

Katram ierakstam savs logs

Brīdinājumu pakotnes pašas atmiņas dublēšanā katrs ieraksts tagad glabā, kad beidzas tā logs, un tīrīšana noņem tikai ierakstus, kuru logs ir beidzies. 24 stundu atslēga paliek 24 stundas neatkarīgi no tā, cik citu brīdinājumu ierodas.

Tā pati kļūda citur

Tas pats raksturs bija dubultojis arī fona darbu: saskaņošanas darbu, kas uztur mūsu ierakstu par katras darbvides statusu atbilstošu mūsu smilškastes nodrošinātāja ierakstiem. Katrā ciklā tas uzskaita katru smilškasti kontā — produkcijā tūkstošiem, aptuveni piecas sekundes — un katru darbojošos vai pauzētu projektu. Abas replikas to palaida ik pēc divām minūtēm.

Tā rakstīšana ir idempotenta — divreiz palaižot, rezultāts ir tāds pats kā vienreiz —, tāpēc nekas nesabojājās. Vienkārši bija divreiz vairāk darba. Tagad katrs divu minūšu logs tiek pieprasīts Redis tāpat kā mūsu lietojuma skaitītāji jau pieprasīja savus, un darbu veic tikai replika, kas to ieguvusi. Ja Redis nav sasniedzams, process tik un tā tiek palaists: darbu divreiz veikt ir nekaitīgi, nedarīt to nav.

Kā mēs to testējām

Testi atdarina reālo uzstādījumu. Tie ielādē brīdinājumu moduli divreiz — kā divas atsevišķas „replikas” — un norāda abas uz vienu kopīgu krātuvi, paaugstina vienu un to pašu brīdinājumu no katras, un pēc tam ielādē trešo jaunu kopiju, lai tā kalpotu par „pēc izvietošanas”, un paaugstina to vēlreiz. Tiek nosūtīts tieši viens brīdinājums. Citi testi pārbauda, ka cita builder brīdinājums joprojām aiziet, ka P0 tiek nosūtīts no abām replikām un ka brīdinājums joprojām tiek nosūtīts, kad krātuve ir nepieejama vai pārsniedz laika limitu. Tīrīšanas labojumam ir savs tests: 24 stundu atslēga pārdzīvo 600 citus brīdinājumus, kas ierodas 20 minūtes vēlāk.

Saskaņošanas darbam divas replikas, kas tiek palaistas vienlaikus, plus trešais takts tajā pašā logā, rada vienu uzskaitījumu.

Ko no tā guvām

• Atmiņas stāvoklis ir katram procesam atsevišķs. Viss, kam jābūt patiesam visos serveros — „nosūtīts vienreiz”, „palaists vienreiz” —, jāglabā vietā, ko tie kopīgi izmanto.
• Izvietošanas ir restartēšanas. Stāvoklis, kas izdzīvo tikai līdz nākamajam restartam, neizdzīvo parastu darba dienu.
• Izlemiet, kā kļūt. Brīdinājumiem kopīgas krātuves nepieejamība nozīmē vairāk brīdinājumu, nevis mazāk.
• Meklējiet raksturu, nevis tikai gadījumu. Brīdinājums bija skaļais gadījums; dubultotais saskaņošanas darbs bija tā pati kļūda, kas klusi maksāja darbu.

Neko no tā nevar redzēt no Mythex iekšpuses. Lai uzzinātu vairāk par to, kā uzturam platformu stabilu, skatiet kā panācām izvietošanas bez 502 kļūdām un trūkstošo swap failu. Ja jūs tikko iepazīstaties ar ideju par vairāku servera kopiju darbināšanu, mūsu rokasgrāmata kas ir serveris sniedz pamatus.