Katrā integrācijas līgumā kaut kur ir teikums, kas skan aptuveni šādi - "katrs pasūtījums tiks pārraidīts tieši vienu reizi." Tas nekad nav bijis patiess. Tīkls sadalījās pieprasījuma vidū, un sūtītājs mēģināja vēlreiz; rinda piegādāja ziņojumu atkārtoti pēc patērētāja avārijas; noliktavas darbinieks divreiz nospieda eksporta pogu. Dublikāti nav kļūdas režīms - tie ir laikapstākļi.
Idempotences atslēgas, izvēlētas rūpīgi
Risinājums ir vecs un necaurspīdīgs: katrs ziņojums nes atslēgu, un apstrāde neko nedara, ja atslēga jau ir redzēta. Visi interesantie lēmumi slēpjas atslēgas izvēlē.
- Dabiskas atslēgas ir labākas par ģenerētajām. Pasūtījumu sinhronizācija, kas balstīta uz
order_id + status, pārdzīvo sūtītāja izejošās rindas atkārtotu ģenerēšanu; nejauši izveidots UUID nosūtīšanas brīdī to nepārdzīvo. - Piesaistiet atslēgu efektam, nevis ziņojumam. Ja viens ziņojums izveido rēķinu un rezervē krājumus, tie ir divi efekti ar divām atslēgām - pretējā gadījumā daļēja kļūme atstās jūs nespējīgus droši atkārtot nevienu no tiem.
- Atslēgu derīguma termiņu nosakiet apzināti. Dublikātu novēršanas krātuve, kas aug bezgalīgi, ir laika bumba; tāda, kas noilgst pārāk ātri, atkal ievieš dublikātus. Mēs pēc noklusējuma izmantojam 3 reizes lielāku periodu nekā sūtītāja maksimālais atkārtotu mēģinājumu apvārsnis.
Tests, kam ir nozīme
Katra mūsu piegādātā integrācija iztur to, ko iekšēji saucam par dubultā pieskāriena testu: vakardienas visu ziņojumu žurnālu atskaņojam pret šodienas sistēmu divas reizes un salīdzinām rezultātā iegūto stāvokli. Ja otrajā reizē kaut kas ir mainījies, cauruļvads vēl nav gatavs.
Tas ir nežēlīgs tests, un izstrādes laikā tas pastāvīgi neizdodas - uz laika zīmogiem, uz "izveidoja" audita laukiem, uz secības skaitītājiem. Katra kļūme ir vieta, kur atkārtota piegāde plkst. 3 naktī klusi sabojātu datus. Daudz lētāk to noķert izstrādes laikā nekā produkcijas vidē.