Co to jest rozproszona pamięć podręczna?
Jestem zdezorientowany co do pojęcia rozproszonej pamięci podręcznej. Trochę wiem, co to jest z wyszukiwarki google. Rozproszona pamięć podręczna może obejmować wiele serwerów, dzięki czemu może rosnąć w rozmiarze i pojemności transakcyjnej. Jednak tak naprawdę nie rozumiem, jak to działa lub jak rozprowadza dane.
Na przykład, powiedzmy, że mamy DANE 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 i 2 serwery cache A i B . Jeśli używamy rozproszonej pamięci podręcznej, to jednym z możliwych rozwiązań jest to, że dane 1, 3, 5, 7, 9 są przechowywane w serwerze Cache A, A 2, 4, 6, 8, 10 są przechowywane w serwerze cache B.
Czy to prawda, czy źle to zrozumiałem?
Drugie pytanie brzmi, że zwykle słyszałem słowo węzeł serwera . O co chodzi? W powyższym przykładzie Serwer A jest węzłem serwera, prawda?
Trzecie pytanie, jeśli serwer (powiedzmy serwer a) padnie, co możemy z tym zrobić? Chodzi mi o to, że jeśli mój przykład powyżej jest poprawny, nie możemy pobrać Danych 1, 3, 5, 7, 9 z pamięci podręcznej, gdy serwer A jest w dół, to co może zrobić serwer Cache w tym przypadku?
2 answers
Tak, połowa danych na serwerze a, a połowa na serwerze b byłaby rozproszoną pamięcią podręczną. Istnieje wiele metod dystrybucji danych, choć najpopularniejszy wydaje się rodzaj haszowania kluczy.
Terminy serwer i węzeł są ogólnie wymienne. Węzeł jest na ogół pojedynczą jednostką pewnego zbioru, często nazywaną klastrem. Serwer to zazwyczaj pojedynczy element sprzętu. W erlang można uruchomić wiele instancji środowiska uruchomieniowego erlang na jednego serwera, a co za tym idzie miałbyś wiele węzłów erlang... ale generalnie chcesz mieć jeden węzeł na serwer dla bardziej optymalnego planowania. (W przypadku nie-rozproszonych języków i platform musisz zarządzać procesami w oparciu o swoje potrzeby.)
Jeśli serwer upadnie, a jest to serwer cache, wówczas Dane będą musiały pochodzić z jego pierwotnego źródła. Na przykład: pamięć podręczna jest zwykle bazą danych opartą na pamięci przeznaczoną do szybkiego wyszukiwania. Dane w pamięci podręcznej trzymają się tylko tak dopóki jest używany regularnie, a ostatecznie zostanie oczyszczony. Ale w przypadku systemów rozproszonych, w których potrzebna jest trwałość, powszechną techniką jest posiadanie wielu kopii. Np.: masz serwery A, B, C, D, E i F. dla danych 1, umieścisz je na A, a następnie kopię na B i C. robią to Couchbase i Riak. Dla danych 2 może to być na B, a następnie kopie na C i D. w ten sposób, jeśli jeden serwer pójdzie w dół, nadal masz dwie kopie.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2013-03-17 05:48:29
Używam rozproszonego buforowania rozwiązań już od jakiegoś czasu (NCache, AppFabric itp.) i mam zamiar odpowiedzieć na wszystkie trzy pytania w oparciu o moje doświadczenie z rozproszonego buforowania.
1: rozproszone rozwiązanie buforowania pozwala przechowywać dane na wszystkich serwerach, tworząc klaster pamięci podręcznej. Powiedzmy, że masz 2 serwery pamięci podręcznej (węzły serwera) i dodałeś 10 elementów w pamięci podręcznej. Najlepiej 5 elementów powinno być obecnych w obu węzłach serwera, ponieważ obciążenie danych pobiera rozproszone między liczbą serwerów w klastrze pamięci podręcznej. Zwykle osiąga się to za pomocą algorytmów hashowania i inteligentnej dystrybucji danych. W rezultacie obciążenie żądań danych zostaje również podzielone między wszystkie serwery pamięci podręcznej i osiąga liniowy wzrost ponadnarodowej pojemności, jak więcej serwerów w klastrze pamięci podręcznej.
2: klaster pamięci podręcznej może zawierać wiele maszyn serwerowych, które są również nazywane węzłami serwera. Tak, Serwer A jest węzłem serwerowym lub maszyną serwerową w Twoim przykład.
3: zazwyczaj rozproszony system buforowania jest bardzo niezawodny przy użyciu replikacji. Jeśli jeden lub więcej serwerów ulegnie awarii i masz włączoną replikację, nie będzie utraty danych ani przestoju. NCache ma różne typologie do rozwiązania tego problemu, takie jak replikowana topologia i podział topologii replik, gdzie dane z każdego serwera są replikowane na inny serwer, jak również. W przypadku awarii jednego z serwerów, replikowane dane z tego serwera są automatycznie udostępniane z istniejącego węzła serwera.
W twoim przykładzie dane serwera A(1, 3, 5, 7, 9) jest replikowany na serwer B(2, 4, 6, 8, 10) i vice versa. Jeśli serwer A upadnie, dane serwera a, który jest obecny na serwerze B, zostaną udostępnione i wykorzystane stamtąd, aby nie doszło do utraty danych. Jeśli więc serwer A padnie i aplikacja zażąda danych (1), Dane te zostaną pobrane z serwera B, ponieważ serwer B zawiera kopię zapasową wszystkich danych serwera A. jest to bezproblemowe dla Twojego aplikacji i jest zarządzany automatycznie przez system buforowania.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-06-04 06:33:07