2015-06-30 11 views
5

Chciałbym wiedzieć, który wzorzec jest zalecany do pracy z licznikiem reprezentującym liczbę przetworzonych wiadomości, z aplikacją, która powinna być bezstanowa.Wzorzec, aby uniknąć licznika komunikatów w pojedynczej aplikacji dla wielu wystąpień

Na przykład w architekturze, w której aplikacja jest wdrażana na kilku serwerach, używana jest baza danych do przechowywania trwałych informacji (sesji itp.). Jednak takie informacje nie są narażone na równoczesne aktualizacje, takie jak licznik wiadomości. W aplikacji z pojedynczą instancją możemy użyć singletonu, ale tak nie jest w tym przypadku.

Jaka byłaby Twoja sugestia, aby wprowadzić taki licznik? Czy używanie licznika jest złym projektem?

+0

że DEP wiele z tego, na co masz zamiar użyć licznika. Jaki jest przypadek użycia? –

+0

Na przykład możemy otrzymać wiele transakcji (ilość jest znana), dla których leczenie jest wysyłane na kilka serwerów. Po zakończeniu przetwarzania wszystkich transakcji należy wygenerować raport. Ale jak się dowiedzieć, że ostatnia transakcja została przetworzona? –

+0

Zliczaj transakcje na każdym serwerze niezależnie i dodawaj te numery, gdy potrzebujesz sumy. Każdy serwer odpowiada za własną synchronizację. –

Odpowiedz

0

Nie sądzę, że istnieje jakiś wzorzec do wykonania tego bardzo abstrakcyjnego zadania. Również:

W aplikacji z pojedynczą instancją możemy użyć singletonu, ale tak nie jest w tym przypadku.

Korzystanie z singletonu NIE gwarantuje bezpieczeństwa danych w systemie wielowątkowym. Potrzebujesz prymitywów synchronizacji. Bardzo prosta jest sekcja krytyczna.

Jeśli wszystkie aplikacje powinny zaktualizować jakiś licznik, uzasadnione wydaje się refaktoryzowanie tego ... "licznika" zarządzania w mikroserwisie i użycie krytycznej sekcji wewnątrz mikroserwisu do aktualizacji zasobu. W tym przypadku w danym momencie masz zagwarantowany tylko jeden licznik aktualizacji wątku.

+0

Myślę, że to może być rozwiązanie tego problemu, ale wyobraźmy sobie, że mamy miliardy transakcji, mikroserwis otrzyma żądania od kilkudziesięciu serwerów, a wszystkie te żądania zostaną skondensowane na jednym serwerze, dla którego skalowalność pozioma nie jest możliwa. –

+0

@AnthonyCorrado Nie można utworzyć monotonicznie inkrementującego się licznika wątku bez synchronizacji. Jakie jest prawdziwe za tym zadanie? –

+0

na przykład, możemy otrzymać wiele transakcji (ilość jest znana), dla których leczenie jest wysyłane na kilka serwerów. Po zakończeniu przetwarzania wszystkich transakcji należy wygenerować raport. Ale jak się dowiedzieć, że ostatnia transakcja została przetworzona? –

1

Mogę nie odpowiadać bezpośrednio na twoje pytanie, ale mogę podać referencję dostępnej usługi licznika, która jest wielowątkowa, wielopoziomowa, skalowalna i jednocześnie rozważa scenariusze dostępności. Sprawdź usługę licznika jgroups http://jgroups.org/manual/index.html#CounterService.

To może poprowadzić Cię do zestawu problemów w scenariuszu rozproszonego licznika, a także działać jako działające odniesienie.

+0

Nie sądzę, że rozwiązuje problem. Wciąż jest tylko jeden koordynator liczenia, który dokonuje faktycznego inkrementacji. Może to być tylko jedna maszyna na raz i @AnthonyCorrado chce tego uniknąć. "W skrócie, w klastrze obecny koordynator utrzymuje listę niedziałających nazwanych liczników. Członkowie wysyłają do niego żądania (inkrementacja, dekrementacja itp.), A koordynator atomowo stosuje żądania i odsyła odpowiedzi. " –

+0

Jeśli licznik potrzebuje absolutnej spójności, powinien to być model odniesienia dla (w pamięci), lub możemy iść do podejście bazodanowe (które powoduje większe opóźnienie). Ale na pewno, jeśli potrzebujemy tylko ostatecznie spójnego licznika, będziemy mieć więcej opcji do projektowania. – arunvg

+1

Jaki typ licznika jest potrzebny tylko autor, którego zna;) Możemy tylko sugerować rozwiązania. –

0

Możliwe rozwiązania z bazą danych:

  • utworzyć procedurę przechowywaną, która będzie aktualizować licznik i zwracać nową wartość (aktualizacja ... POWRÓT ... INTO) w Oracle na przykład
  • $ inc w MongoDB np

licznik będą przechowywane w bazie danych i będą dostępne na każdej instancji aplikacji, które będą podłączone do tej bazy danych

Powiązane problemy