Przechodzimy z konfiguracji z 1 serwerem na konfigurację z dwoma serwerami i muszę zacząć udostępniać sesje PHP między dwoma maszynami z równoważeniem obciążenia. Zainstalowaliśmy już memcache ( i uruchomiliśmy ), więc byłem mile zaskoczony, że mogłem zrealizować sesje udostępniania między nowymi serwerami, zmieniając tylko 3 linie w php.ini
pliku ( session.save_handler i session.save_path ):
Wymieniłem:
session.save_handler = files
z:
session.save_handler = memcache
Następnie na głównym serwerze internetowym ustawiłem session.save_path
punkt na localhost:
session.save_path="tcp://localhost:11211"
i na serwerze podrzędnym ustawiłem session.save_path
punkt na master:
session.save_path="tcp://192.168.0.1:11211"
Praca wykonana, przetestowałem ją i działa. Ale...
Oczywiście użycie memcache oznacza, że sesje są w pamięci RAM i zostaną utracone, jeśli komputer zostanie zrestartowany lub demon memcache ulegnie awarii - trochę mnie to martwi, ale bardziej martwię się o ruch sieciowy między dwoma serwerami WWW (zwłaszcza, że skalujemy w górę), ponieważ ilekroć ktoś jest zrównoważony pod obciążeniem do serwera podrzędnego, jego sesje będą pobierane przez sieć z głównego serwera podrzędnego. Zastanawiałem się, czy mógłbym zdefiniować dwa, save_paths
aby komputery korzystały z własnej pamięci sesji przed użyciem sieci. Na przykład:
Mistrz:
session.save_path="tcp://localhost:11211, tcp://192.168.0.2:11211"
Niewolnik:
session.save_path="tcp://localhost:11211, tcp://192.168.0.1:11211"
Czy to z powodzeniem współużytkuje sesje na serwerach ORAZ poprawia wydajność? tj. oszczędzaj ruch sieciowy w 50% przypadków. Czy jest to technika tylko w przypadku przełączania awaryjnego (np. Gdy jeden demon pamięci podręcznej jest nieosiągalny)?
Uwaga : tak naprawdę nie pytam konkretnie o replikację memcache - więcej o tym, czy klient memcache PHP może osiągnąć szczyt w każdym demonie memcache w puli, zwróć sesję, jeśli ją znajdzie, i utwórz nową, jeśli nie znajdzie we wszystkich sklepach. Pisząc to, myślę, że trochę proszę od PHP, lol ...
Załóżmy : brak sesji lepkich, równoważenie obciążenia w trybie round-robin, serwery LAMP.
źródło
Odpowiedzi:
Zastrzeżenie: Szalejesz, gdybyś mnie wysłuchał bez przeprowadzania wielu testów ORAZ uzyskania drugiej opinii od osoby wykwalifikowanej - jestem nowy w tej grze .
Pomysł poprawy wydajności zaproponowany w tym pytaniu nie zadziała. Głównym błędem, jaki popełniłem, było myślenie, że kolejność, w której sklepy memcached są zdefiniowane w puli, określa pewien priorytet. Tak nie jest . Kiedy definiujesz pulę zapamiętanych demonów (np. Używając
session.save_path="tcp://192.168.0.1:11211, tcp://192.168.0.2:11211"
), nie wiesz, który sklep będzie używany. Dane są dystrybuowane równomiernie, co oznacza, że element może być przechowywany w pierwszym lub może być ostatnim (lub może być oba, jeśli klient Memcache jest skonfigurowany do replikacji - pamiętaj, że to klient obsługuje replikację, serwer memcached robi nie rób tego sam). Tak czy inaczej oznacza, że użycie localhost jako pierwszego w puli nie poprawi wydajności - istnieje 50% szans na trafienie do dowolnego sklepu.Po przeprowadzeniu drobnych testów i badań doszedłem do wniosku, że MOŻESZ udostępniać sesje między serwerami za pomocą memcache, ALE prawdopodobnie nie chcesz - nie wydaje się być popularny, ponieważ nie skaluje się tak dobrze, jak przy użyciu udostępnionego baza danych nie jest tak niezawodna. Byłbym wdzięczny za opinie na ten temat, dzięki czemu mogę dowiedzieć się więcej ...
Wskazówka 1: Jeśli chcesz udostępniać sesje na 2 serwerach za pomocą memcache:
Upewnij się, że odpowiedziałeś „ Tak ” na „ Włączyć obsługę modułu obsługi sesji memcache? ” Po zainstalowaniu klienta memcache PHP i dodać następujące
/etc/php.d/memcache.ini
pliki:Na serwerze internetowym 1 (IP: 192.168.0.1):
Na serwerze internetowym 2 (IP: 192.168.0.2):
Wskazówka 2: Jeśli chcesz udostępniać sesje na 2 serwerach za pomocą pamięci podręcznej ORAZ mieć obsługę przełączania awaryjnego:
Dodaj następujące elementy do
/etc/php.d/memcache.ini
pliku:Na serwerze internetowym 1 (IP: 192.168.0.1):
Na serwerze internetowym 2 (IP: 192.168.0.2):
Uwagi:
session.save_path
na wszystkich serwerach.Wskazówka 3: Jeśli chcesz udostępniać sesje za pomocą pamięci podręcznej ORAZ mieć przejrzystą obsługę przełączania awaryjnego:
Taki sam jak wskazówka 2, z tą różnicą, że musisz dodać do
/etc/php.d/memcache.ini
pliku:Uwagi:
get's
próby są ponawiane na serwerach lustrzanych. Oznacza to, że użytkownicy nie tracą sesji w przypadku awarii jednego demona memcache.memcache.session_redundancy
dotyczy redundancji sesji, ale istnieje równieżmemcache.redundancy
opcja ini, która może być używana przez kod aplikacji PHP, jeśli chcesz mieć inny poziom redundancji.źródło
ext/memcache
wersji 3.x. Gramy również z tą opcją i postanowiłem przejrzeć listę serwerów i napisać do niej osobiście.Odp: Wskazówka 3 powyżej (dla każdego, kto spotka się z tym za pośrednictwem google), wydaje się, że przynajmniej obecnie, aby to zadziałało, musisz użyć
memcache.session_redundancy = N+1
dla N serwerów w puli , przynajmniej wydaje się to minimalny próg wartość, która działa. (Testowane z php 5.3.3 na stabilnej wersji Debiana, pecl memcache 3.0.6, dwa serwery memcachedsession_redundancy=2
uległyby awarii, jak tylko wyłączyłem pierwszy serwer wsave_path
,session_redundancy=3
działa dobrze.)Wygląda na to, że zostało to zarejestrowane w tych raportach błędów:
źródło
Wraz z powyższymi ustawieniami php.ini upewnij się, że ustawione są również:
Następnie uzyskasz pełne przełączenie awaryjne i redundancję po stronie klienta. Zastrzeżenie z tym podejściem polega na tym, że jeśli memcached jest wyłączony na localhost, zawsze będzie brakowało odczytu, zanim klient php memcache spróbuje następnego serwera w puli określonej w session.save_path
Pamiętaj, że wpływa to na globalne ustawienia klienta php memcache działającego na twoim serwerze internetowym.
źródło
consistent
strategii hashowania ma sens, biorąc pod uwagę, żesession.save_path
na każdym serwerze jest inna?memcached nie działa w ten sposób (popraw mnie, jeśli się mylę!)
Jeśli chcesz, aby aplikacja miała nadmiarowe miejsce do przechowywania sesji, musisz utworzyć coś, co zmieni / doda / usunie wpisy do obu zapamiętanych instancji. Memcached nie obsługuje tego, jedyne, co zapewnia, to pamięć kluczowa. Więc nie ma replikacji, synchronizacji, nic, nada.
Mam nadzieję, że się nie mylę w tej sprawie, ale to właśnie wiem o memach, które minęły kilka lat odkąd go dotknąłem.
źródło
memcached nie replikuje się po wyjęciu z pudełka, ale repcached ( łatka memcached) tak. Jeśli jednak już używasz mysql, dlaczego po prostu nie skorzystać z jego funkcji replikacji z replikacją master-master i uzyskać korzyści z pełnej replikacji danych.
DO.
źródło