Trex Pi
Kiekvienoje integracijos sutartyje kažkur yra sakinys, panašus į „kiekvienas užsakymas bus perduotas lygiai vieną kartą". Tai niekada nebuvo tiesa. Tinklas nutrūko užklausos viduryje, ir siuntėjas bandė iš naujo; eilė pakartotinai pristatė žinutę po vartotojo gedimo; sandėlio darbuotojas du kartus paspaudė eksporto mygtuką. Dublikatai nėra gedimo forma - tai tiesiog oro sąlygos.
Atsargiai parinkti idempotentiškumo raktai
Sprendimas senas ir nepatrauklus: kiekviena žinutė turi raktą, ir jei šis raktas jau buvo matytas anksčiau, apdorojimas nieko nedaro. Visi įdomūs sprendimai slypi paties rakto pasirinkime.
- Natūralūs raktai geresni už sugeneruotus. Užsakymo sinchronizacija, kurios raktas yra
order_id + status, atlaiko atvejį, kai siuntėjas iš naujo sugeneruoja savo išeinančią eilę; atsitiktinai siuntimo metu sukurtas UUID - ne. - Susiekite raktą su poveikiu, o ne su žinute. Jei viena žinutė sukuria sąskaitą faktūrą ir rezervuoja atsargas, tai yra du atskiri poveikiai su dviem raktais - kitaip dalinis gedimas paliks jus be galimybės saugiai pakartoti nei vieno, nei kito veiksmo.
- Sąmoningai nustatykite raktų galiojimo pabaigą. Dublikatų šalinimo saugykla, kuri auga amžinai, yra laikmatinė bomba; jei ji baigia galioti per anksti, dublikatai atsiranda vėl. Numatytoji reikšmė pas mus - 3× didesnė nei maksimalus siuntėjo pakartotinių bandymų laikotarpis.
Testas, kuris tikrai svarbus
Kiekviena mūsų diegiama integracija turi išlaikyti tai, ką viduje vadiname dvigubo paspaudimo testu: visas vakarykštis žinučių žurnalas du kartus paleidžiamas per šiandienos sistemą, o gauta būsena palyginama. Jei po antro karto kas nors pasikeitė, integracija dar nebaigta.
Tai negailestingas testas, ir kūrimo metu jis nuolat nepavyksta - dėl laiko žymų, „sukūrė" audito laukų, sekos skaitiklių. Kiekvienas nesėkmingas atvejis yra vieta, kur pakartotinis pristatymas 3 valandą nakties tyliai sugadintų duomenis. Gerokai pigiau tai pastebėti kūrimo etape nei gamybinėje aplinkoje.