Automatycznie zapisuj architekturę serwera

Question

Chcę zapisać dane wejściowe długich formularzy na serwerze. Ale nie sądzę, że robienie wywołań db dla każdej akcji automatycznego zapisu jest najlepszym rozwiązaniem.

Co stanowiłoby dobre podejście do rozwiązania tego problemu?

Innym problemem jest to, że mam 3 serwery aplikacji. Więc w pamięci podręcznej pamięć podręczna nie działałaby.

Zastanawiałem się, czy dane są przechowywane na bieżąco i aktualizuję je przy każdym połączeniu, a na koniec aktualizuję db. Ale ponieważ mam 3 serwery, w jaki sposób upewnić się, że połączenia są w kolejce?

Czy ktoś może pomóc w architekturze?

Answer 1

Jest to bardzo poważna problemem podczas skalowania swoją architekturę, ale pozwala przyjść do skalowania później jako zasadniczo początkowej aplikacji wymaga wielu połączeń z danymi poziom podstawowy pozwala to najpierw zoptymalizować.

Ponieważ nie podałeś żadnych szczegółów na temat twoich urządzeń, opiszę poniżej metody ich rozwiązania, w rosnącej kolejności obciążenia, wszystkie podejścia mają naturę kaskadową, to jest ostatnie podejście jest faktycznie oparte na wszystkich poprzednich rozwiązaniach :

Direct Database Podejście {połączenia db na każdej akcji auto-save}:

klient -> warstwa aplikacji -> bazy danych (zapisać dane tutaj bezpośrednio)

W przypadku każdej aktualizacji danych bezpośrednio propagujemy ją do poziomu bazy danych.Główny blok w tym schemacie jest baza danych warte dbać w tym podejściu:

• Dla najbardziej popularnie używane relacyjnych baz danych takich jak MySQL:

  • Kwerenda wkładka zajmuje mniej czasu niż aktualizacji zapytanie, w przypadku projektu uczelnianego można aktualizować wiersz w odniesieniu do tego samego klucza podstawowego i będzie on działał pięknie.

  • Jednak w dowolnej aplikacji średniej wielkości, w której modyfikacja pojedynczego formularza zajmuje 30-40 żądań, zapytanie o aktualizację spowoduje zablokowanie zasobu bazy danych.

  • Zachowaj więc dodatkowy rodzaj schematu, np. Zachowaj klucz dodatkowy, taki jak status, który śledzi, do którego poziomu użytkownik wypełnił formularz, ale nadal wstawia dane dla każdej aktualizacji. Zawsze czytaj zgodnie z najnowszym wprowadzonym stanem.

  • do dalszego wykorzystania optymalizacji wskaźników, takich jak klucz obcy ograniczenia powinny być stosowane

  Kiedy ten etap się nie powiedzie, następnym krokiem jest samej bazy danych, kolejnym krokiem w celu optymalizacji na to, że typ dane masz do czynienia, można wybrać db schematu mniej jak Mongo, dynamodb etc dla non dane transakcyjne

• Użyj db schematu mniej może być bardzo pomocne w przypadku dużych ilości danych nietransakcyjnych jako z natury pozwalają one na ddendum podejście do tego samego rzędu danych.

  • Aby uzyskać dodatkową optymalizację, użyj indeksów dodatkowych, aby szybciej wyszukiwać dane.

Zaangażowanie Podejście warstwie aplikacji {warstwa buforowanie Zastosowanie}:

klient -> warstwa aplikacji (z wyjątkiem niektórych danych tutaj następnie rozprzestrzeniać później) -> baza danych (wreszcie zapisać tutaj)

• Gdy prosta baza danych jest w stanie obsługiwać i skala wymaganych najprostszy sposób jest przeniesienie obciążenia na twój serwer API. Ponieważ poziome skalowanie tego samego jest znacznie łatwiejsze i tańsze.
• To jest dokładnie tak, jak rozumiesz podejście do pamięci podręcznej, ale nie planuj własnego - Zajmuje lata zrozumienia dużej sieci infrastruktury, to także ludzie nie są w stanie zaprojektować wydajnego cache na warstwie aplikacji.
• użyj czegoś podobnego do Express Session, Używałem tego dla aplikacji internetowej mającej 10 instancji nodejs ec2, przechowujących około 15 MB danych użytkownika na sesję. Pięknie się skaluje, utrzymuje unikalne dane sesji użytkownika na wszystkich serwerach - tak przy każdej automatycznej aktualizacji zapisuj dane do sesji użytkownika - na formularzu przesyłaj zapis do bazy danych z sesji. Można go łatwo skalować, dodając więcej serwerów api, najlepszy przypadek użycia i użyć go do zapisania danych na czerwono {Dlaczego chcesz wymyślić koło?}

Ponowne wynalezienie koła: Custom Application poziom warstwy buforowanie + buforowanie db + db optymalizacji

klienta -> warstwa aplikacji (z wyjątkiem niektórych danych tutaj) -> {Dodaj swoją pamięć podręczną db } -> bazy danych (zapisać dane tutaj wreszcie)

• tym miejscu dochodzimy do projektowania naszą własną rzecz użyciu Redis/Dynamodb/Mongo działać jako pamięci podręcznej do swojej pierwotnej d atabase. (Należy pamiętać, że w przypadku bazy nietransakcyjnej należy stosować metodę addendum - jest to o wiele bardziej odpowiednie do skalowania transakcyjnych baz danych poprzez dodanie opakowania bazy danych nietransakcyjnych). w ten sam sposób, poprzez cachowanie danych na redis w warstwie aplikacji, zawsze staraj się zmniejszyć liczbę wywołań do db w jak największym stopniu.

• Więc jeśli masz w pełni funkcjonalne buforowanie warstwy aplikacji i zoptymalizowane db, to idź do tego podejścia, ponieważ potrzebuje doświadczonych programistów i jest zasobochłonny i zwykle jest używany do aplikacji na bardzo dużą skalę, takich jak miałem warstwę buforowania redis po sesji ekspresowej dla aplikacji, która ma ponad 300 000 odpowiedzi na sekundę,

• Podejściem tutaj byłoby zapisanie danych w sesji użytkownika, zastosowanie leniwego zapisu do pamięci podręcznej. Maritain księgę pamięci podręcznej, a następnie napisz do głównej bazy danych. Dla podejścia kolejek w tak wielkoskalowym systemie napisałem całą oddzielną mikroserwisę, która pracowała w tle, aby przenosić dane z sesji do redis do mysql, w związku z tym, jak zachować kolejkę, przeczytaj więcej o kolejkach priorytetowych i pracownikach w tle. Kiedyś Kue is a priority job queue backed by redis, built for node.js.

• Maintaining parallel and sequential queues

• php client for KUE
• Background Services

Answer 2

Ale nie sądzę, że wykonywanie wywołań db dla każdej akcji automatycznego zapisywania jest najlepszym rozwiązaniem.

To jest prawdziwe pytanie, zacznijmy od tego. Dlaczego tak myślisz? Chcesz automatycznie zapisać, prawda? Jest to jedyna czynność, którą użytkownik zapisuje w pracy użytkownika.

Wszystkie inne wymienione opcje (memcached/redis, buforowanie w procesie) - nie tylko nie oszczędzają pracy użytkownika, ale także odmierzają czasowe bomby. Pomyśl o wszystkich rzeczach, które mogą tam zawieść: Redis umiera, sieć jest podzielona, ​​całe centrum danych zostaje uderzone piorunem.

Po co tworzyć całą złożoność, gdy można po prostu ... zaoszczędzić? Możesz się przekonać, że nie jest to zbyt powolne (jeśli to była twoja troska).

Answer 3

Rozwiązanie to przyjęto z powodzeniem w całej branży. Skonfiguruj klaster 3-węzłowy redis, który zajmuje się replikacją danych. Zapisuje się tylko do węzła głównego.

Redis (master) - aplikacja serwera 1 Redis (slave1) - aplikacja serwera 2 Redis (slave2) - aplikacja serwera 3

Dodanie slave straighforward pomocą slaveof: polecenia portu. Replikacja odbywa się przez przewód (nie tymczasowy pamięci dyskowej) Link - https://redis.io/topics/replication