Poszukuje się implementacji magistrali komunikatów, które oferują coś pomiędzy pełnym ACID i niczym.

Question

Ktoś wie o implementacji magistrali komunikatów, która oferuje szczegółową kontrolę nad gwarancjami spójności? Pełny ACID jest zbyt wolny i brak ACID jest zbyt zły.

Obecnie używamy systemu MSMQ do pakowania Rhino ESB do przesyłania wiadomości. Podczas używania trwałego, transakcyjnego przesyłania wiadomości z transakcjami rozproszonymi, MSMQ może zablokować zatwierdzenie przez dłuższy czas, gdy oczekuje na zakończenie operacji wejścia/wyjścia.

Nasze wiadomości dzielą się na dwie ogólne kategorie: logika biznesowa i denormalizacja. Te ostatnie stanowią znaczny odsetek ruchu magistrali komunikatów.

Wiadomości logiki biznesowej wymagają gwarancji pełnego ACID i MSMQ okazały się do tego odpowiednie.

wiadomości Denormalizacja:

1. muszą być trwałe.
2. NIE MOŻE być przetwarzane do momentu zakończenia transakcji źródłowej.
3. MOGĄ być przetwarzane wiele razy.
4. MOŻE być przetwarzane, nawet jeśli dochodzi do wycofania inicjującej transakcji, tak długo jak 2).

(W niektórych szczególnych przypadkach wymagania wytrzymałościowe prawdopodobnie mogłyby zostać złagodzone, ale identyfikacji i obsługi tych przypadków jako wyjątki od reguły zwiększa złożoność.)

wszystkie wiadomości Denormalizacja są obsługiwane w procesie tak tam nie jest potrzeba IPC.

Jeśli proces zostanie zrestartowany, wszystkie transakcje mogą zostać uznane za zakończone (zatwierdzone lub wycofane), a wszystkie komunikaty o denormalizacji, które nie zostały jeszcze przetworzone, muszą zostać odzyskane. Dopuszczalne jest powtórzenie komunikatów denormalizacyjnych, które już zostały przetworzone.

O ile mi wiadomo, systemy przesyłania wiadomości, które obsługują transakcje, zwykle oferują wybór między pełnym ACID lub nic, a ACID powoduje obniżenie wydajności. Widoczne są połączenia do TransactionScope # Commit() trwające nawet kilkaset milisekund, w niektórych przypadkach w zależności od liczby wysłanych wiadomości.

Korzystanie z nietransakcyjnej kolejki komunikatów powoduje, że komunikaty są przetwarzane przed zakończeniem transakcji początkowej, co powoduje problemy z konsystencją.

Kolejna część naszego systemu, która ma podobne wymagania co do spójności, ale ma mniejszą złożoność, już używa niestandardowej implementacji czegoś podobnego do dziennika transakcji, i ogólne, że dla tego przypadku jest z pewnością opcja, ale wolałbym nie implementować system operacyjny o niskim opóźnieniu, równoczesny, trwały, transakcyjny, jeśli nie muszę: P

W przypadku, gdy ktoś się zastanawia, powodem wymagającym trwałości komunikatów do denormalizacji jest to, że wykrywanie desynchronizacji i desynchronizacji może być niezwykle trudne i wyjątkowo drogie. Ludzie do zauważają, że coś jest nie tak, a odświeżenie strony tego nie naprawia, więc ignorowanie desynchronów nie jest opcją.

Answer 1

Okazuje się, że MSMQ + SQL + DTC nie oferuje nawet gwarancji spójności, których potrzebujemy. Wcześniej napotkaliśmy problem, w którym wiadomości były przetwarzane, zanim transakcja rozproszona, która je czeka w kolejce, została zatwierdzona do bazy danych, co spowodowało nieaktualne odczyty. Jest to efektem ubocznym stosowania izolacji ReadCommitted spożywać kolejkę, ponieważ:

1. transakcja start A.
2. Aktualizacja bazy danych w tabeli A.
3. wiadomość Kolejka w A.
4. Zapytanie commit A.
kolejka
5. wiadomość popełnia
6. rozpocząć transakcji B.
7. wiadomość odczytywane B.
8. Odczytaj tabelę bazy danych w B, używając ReadCommitted < - pobiera dane z pre-A.
9. Database zobowiązuje A.

Naszym warunkiem jest, że B Przeczytajmy bloku tabeli na użytkownika popełnienia, który wymaga Serializable transakcji, które niesie ze sobą karę wydajności.

Wygląda na to, że normalnym zadaniem jest wprowadzenie koniecznych ograniczeń i gwarancji, nawet jeśli brzmi to jak wymyślanie koła.

Ktoś ma jakieś uwagi na ten temat?

Answer 2

To nie jest dokładnie odpowiedź szukasz, ale Jonathan Oliver pisze obszernie o tym, jak unikać transakcji rozproszonych w wiadomości, a jednocześnie utrzymać integralność transakcyjną:

http://blog.jonathanoliver.com/2011/04/how-i-avoid-two-phase-commit/ http://blog.jonathanoliver.com/2011/03/removing-2pc-two-phase-commit/ http://blog.jonathanoliver.com/2010/04/idempotency-patterns/

Nie jasne, jeśli to ci pomoże, ale, hej.