🎲 — mikrobloggeriet olorm — olorm-26 · olorm-27 · olorm-28

Makro-kappløp

Race conditions er kanskje mest omtalt i forbindelse med tråder, men jeg fant en artig en.

På prosjektet har vi mange tjenester, og en veldig nyttig kommunikasjonsform mellom dem, er meldingskøer. Spesifikt bruker vi Kafka-køer. En vanlig egenskap ved meldingskøer er FIFO-oppførsel: First In, First Out. Altså at rekkefølgen til meldingene blir bevart.

Kafka skiller seg fra mange andre meldingskøer ved at køene gjerne deles opp i partisjoner for å få høyere gjennomstrømming.

Hver melding har et innhold, og en key. Denne key’en brukes til å velge partisjon, og innenfor hver partisjon er man garantert FIFO-rekkefølge.

Vi gjorde noe slikt:

Her blir ID (A, B) brukt som key. Hvis A og B beholder innbyrdes rekkefølge gjennom hele løypa går alt fint.

Men følgende blir et problem:

1. B, endret Adresse, fyker gjennom boksene til Behandling
   1. Leser Ordre A, Status bestilt
2. A, endret Ordre, kjører også gjennom løypa og ankommer Behandling
   1. Ordre A, Status kansellert, sendes videre
3. Ordre A fra punkt 1 blir sendt videre

Vi ender opp med en Status: bestillt etter “kanselleringen”.

Konklusjon: Ikke anta at meldinger ankommer i gitt rekkefølge gjennom et distribuert system (med ulik key).

Løsninger på det aktuelle problemet kan være:

1. Behandling kan sende “Ordre A er endret” i stedet for “Ordre A har fått status X”
2. Bestilling kan alternativt ignorere utdaterte meldinger ved å sammenligne Versjon e.l.

Send gjerne spørsmål eller kommentarer til Richard Tingstad :)