Jeśli nie transakcje rozproszone, to co?
Kontynuując moje rozważania na temat transakcji rozproszonych, dziś chciałbym Wam zaproponować pewną prostą technikę, która z powodzeniem może zastąpić transakcje rozproszone w Waszych systemach. Rozwiązanie to transakcyjne kolejki komunikatów.
Co to takiego?
Transakcyjne kolejki komunikatów są praktycznie tak stare, jak same komputery. Ich historia sięga systemów IBM 360 i dalej. Sama idea jest prosta: wrzucając komunikat do kolejki zapisujemy go trwale na dysku (lub innym trwałym nośniku) uzyskując pewność, że zapis się powiódł. W dowolnym momencie później możemy komunikat odczytać. Nie jest on jednak usuwany z kolejki w chwili odczytania, ale w chwili zatwierdzenia transakcji związanej z odczytem. Co to oznacza?
- Przy zapisie, mamy pewność, że jeśli nie wystąpił błąd, to komunikat został trwale zapisany
- Przy odczycie mamy pewność, że jeśli wystąpił błąd, to komunikat nie został utracony
Komunikacja zdalna
Powyższa definicja nic nie mówi o tym, jak zachowuje się kolejka w środowisku rozproszonym. I słusznie. Są to już kwestie implementacyjne. Większość dostępnych infrastruktur kolejkowych (MSMQ, WebSphere MQ, Active MQ) umożliwia komunikację zdalną w środowisku rozproszonym poprzez automatyczne forwardowanie komunikatów między kolejkami znajdującymi się na różnych maszynach. Jest to naturalne rozwinięcie koncepcji kolejek o kolejną gwarancję:
- Przy zapisie mamy gwarancję, że mając do dyspozycji nieskończeniu długi czas, infrastruktura dostarczy komunikat do kolejki docelowej.
Twierdzenie CAP
Twierdzenie o CAP (Consistency – Availability – Partitionability) mówi, że z wymienionych trzech właściwości w dowolnym systemie osiągalne są co najwyżej dwie. Transakcje rozproszone zapewniają bardzo mocne “C”, co odbywa się oczywiście kosztem “A” i “P”. Zastosowanie transakcyjnych kolejek to nie magia — zwiększenie dostępności i potencjału partycjonowania odbywa się dzięki rozluźnieniu więzów spójności. W tym obszarze jest bardzo dużo miejsca na zastosowanie kreatywnego myślenia do zaprojektowania systemu w ten sposób, aby zmniejszenie “C” było jak najmniej bolesne. Mamy więc zajęcie dla architekta:-)
Events vs compensable transactions
Istnieje wiele dobrze opisanych wzorców projektowania interakcji z wykorzystaniem transakcyjnych kolejek komunikatów.Zajmę się dwoma z nich.
Ze zdarzeniami jako sposobem komunikacji między systemami zetknąłem się pierwszy raz na prezentacji Udiego Dahana. Od tej pory ten temat bardzo mnie zainteresował. Idea polega na analizie problemu biznesowego w kategoriach autonomicznych usług reagujących na zdarzenia publikowane przez inne usługi. Podejście takie wpływa bardzo mocno na dekompozycję systemu na moduły, dzięki czemu komunikacja między modułami jest z natury asynchroniczna, a więc idealnie nadaje się do implementacji za pomocą kolejek. Niestety takie podejście sprawdza się najlepiej wtedy, gdy zaczynamy budowę systemu od podstaw.
W przeciwnym wypadku dobrym wzorcem są transakcje kompensowalne. W tym wypadku kluczowa jest rezygnacja z jednej z właściwości ACID — izolacji. Skutki transakcji kompensowalnych są widoczne dla innych równoległych transakcji. Aby sobie z tym radzić, transakcje takie wynosi się zwykle do warstwy biznesowej (w przeciwieństwie do warstwy infrastruktury, gdzie żyją transakcje ACID), gdzie jest odpowiednie miejsce, aby rozwiązywać problemy związane z brakiem izolacji.
Podsumowaie
Nie bójcie się kolejek komunikatów! Nie bójcie się rezygnacji z ACID. Nie bójcie się eventual consistency! To wszystko są narzędzia wymyślone przez ludzi dla ludzi. O ile większość obszarów w większości systemów świetnie (i tanio) można zrealizować za pomocą klasycznego zestawu RDBMS/ACID, o tyle w przypadkach szczególnych warto sięgnąć po specjalne środki. Wtedy właśnie w Waszej skrzynce na narzędzia nie powinno zabraknąć kolejek komunikatów.
