Jakie jest najbardziej niezawodne przechowywanie sesji w PHP: Memcache, baza danych lub pliki? [Zamknięte]


10

Jaki jest najlepszy i najbezpieczniejszy sposób obsługi sesji PHP. To najlepszy sposób na przechowywanie sesji w:

  1. Baza danych (bardziej niezawodna, ale o dużym wąskim gardle, niska prędkość, nieodpowiednia dla witryn o dużym wykorzystaniu bazy danych)?

  2. Memcache (super szybki, ale rozproszony więcej problemów z bezpieczeństwem, szanse na utratę danych po ponownym uruchomieniu serwera i szanse na utratę danych, gdy pamięć podręczna jest pełna)?

  3. Pliki (domyślnie opcja, chyba powolna, ponieważ odczytuje i zapisuje z plików we / wy, mniej zabezpieczeń itp.).

Która metoda jest najlepsza? Jakie są problemy i zalety każdego z tych podejść?


2
Uważam, że powinieneś sprecyzować, czy używasz tylko jednego komputera, czy aplikacja jest dystrybuowana, ponieważ będzie to miało duży wpływ na odpowiedzi.
Arseni Mourzenko

1
@haylem jest to najodpowiedniejsze miejsce do zadawania tego pytania, jego pytanie dotyczące programowania nie jest problemem koncepcyjnym dotyczącym programowania,
user1179459,

3
To naprawdę kiepskie pytanie, ponieważ „najlepsze” zależy od konkretnych okoliczności. „Najlepsze” dla Facebooka prawdopodobnie nie jest tym samym „najlepszym” dla Twojej osobistej strony głównej.
GrandmasterB

1
@GrandmasterB wiem, że właśnie dlatego wyraźnie zapytałem „Jakie są problemy i dobre strony każdego z tych podejść?” aby dowiedzieć się, który jest dla mnie najlepszy.
user1179459

Odpowiedzi:


6

Najlepiej jest przechowywać w Memcached, ponieważ możemy łatwo rozwiązać inne problemy (rozmiar pamięci podręcznej, bezpieczeństwo itp.)

Facebook jest # 1 konsument memcached. Proszę przeczytać w razie zainteresowania: http://www.facebook.com/note.php?note_id=39391378919

Jak rozwiązać inne problemy?


4

W zdecydowanej większości codziennych aplikacji utrzymywanie sesji w bazach danych jest w porządku. Objętość i poziom współbieżności, które serwer SQL może obsłużyć, będzie więcej niż wystarczający. Kluczem do sukcesu jest utrzymanie małych rozmiarów każdego wpisu i regularne czyszczenie niepotrzebnych wierszy. I oczywiście prawidłowe indeksowanie.

System plików - nigdy nie widziałem takiej potrzeby. Wolę prostotę zarządzania wierszami w tabelach niż tysiące małych plików. Ponadto nie można wyszukiwać w plikach, jeśli chcesz zagłębić się w statystyki sesji.

Pamiętaj, że dzięki PHP łatwo jest wymienić programy obsługi sesji. Możesz więc zacząć od jednego formatu pamięci i migrować do innego bez nadmiernego wysiłku.


4

Co z użyciem silnika pamięci MEMORY w MySQL?

Nie jest tak szybki jak Memcache, ale ma tę zaletę, że można używać zwykłego SQL, a także można użyć normalnego silnika pamięci, gdy nie będzie on potrzebny, i przełączyć na MEMORY, gdy liczba użytkowników / żądań wzrośnie.

Używam go do przechowywania dużych ilości danych statystycznych w aplikacji internetowej, która często się zmienia, więc nie jest używana do obsługi sesji, ale myślę, że powinna być odpowiednia do tego celu.


3

Ten post na blogu pokazuje wyniki porównania wydajności różnych silników pamięci masowej sesji z Magento i wydaje się, że doszli do wniosku, że do około 75 równoczesnych użytkowników tak naprawdę nie ma między nimi różnicy w wydajności.

Myślę, że na tych poziomach (miały około 5 transakcji na sekundę, co byłoby około 430 tys. Trafień w ciągu 12 godzin) obciążenie ogólne we wszystkich pozostałych zdominowało liczby wyników, które widzisz, ponieważ pliki / DB / Memcache / Redis z przyjemnością sobie poradzą ruch uliczny bez zerwania potu, jeśli jest właściwie stosowany.

Pozostawia to inne czynniki, takie jak skalowalność, niezawodność i bezpieczeństwo.

Najpierw chciałbym powiedzieć, że wszystko, co zagraża przechowywaniu plików, prawdopodobnie wpłynie również na wszystko inne, ponieważ osoba atakująca może następnie zmodyfikować kod aplikacji lub przynajmniej odkryć klucze i protokoły / dane dostępu do pamięci, nawet jeśli mają one tylko do odczytu dostęp. Przechowywanie plików będzie działało dobrze w przypadku witryn o niskim wolumenie, jest łatwe w konfiguracji i łatwe do uzasadnienia. O ile mówisz, że uderzyłeś w dysk, odczyt bazy danych również uderzy w dysk, a jeśli baza danych może go buforować, twój system operacyjny prawdopodobnie również buforuje plik sesji. Odczytany jest również jeden plik, a Twój system plików doskonale się do niego nadaje, jeśli znasz już jego nazwę. Jeśli korzystasz z PHP, czy wiesz, ile plików czyta system, aby obsłużyć aplikację? Minusem jest to, że możesz

Memcache jest stosunkowo szybki, a jeśli rozważasz rozwiązania klasy Memcache szerzej (Redis itp.), Są takie, które obiecują nawet trwałość odczytu pamięci w celu uzyskania szybkości, dzięki czemu uzyskasz jak najwięcej z obu światów. Są również stosunkowo łatwe do uzasadnienia, a kluczową wartością sesji jest dokładnie to, do czego zostały zaprojektowane. Czy wiesz, ile musiałbyś poświęcić na sesję, aby wypełnić jedną z nich? Tak czy inaczej, wszystkie opcje zmusią cię do kompromisu, jeśli osiągniesz ich pojemność. Dyski wypełniają się plikami (tutaj liczba i współczynnik wielkości), magazyny pamięci podręcznej zapełniają się pojemnością, a bazy danych mają ograniczoną liczbę wierszy i te same limity pojemności dyskowej, co podejście do plików. Ponadto systemy te są dystrybuowane tylko wtedy, gdy są uruchamiane w sposób rozproszony. Większość działa dobrze z konfiguracją jednego serwera. Jeśli je rozpowszechnisz, prawdopodobnie masz już rozproszone serwery sieciowe / serwery baz danych itp., Więc problemy z rozproszonym systemem z pewnością nie pojawią się w wyniku wyboru miejsca na sesję. Jednak gdy chcesz uzyskać 10-krotny ruch / pojemność itp., Osiągnięcie tego jest o wiele bardziej naturalne dzięki temu niż w przypadku schematu przechowywania plików. Niektóre magazyny kluczy / wartości pozwalają również stosunkowo łatwo przeprowadzać proste analizy danych sesji, ale większość nie zbliży cię do możliwości SQL.

Nie jestem pewien, dlaczego proponujesz, że baza danych może być bardziej niezawodna niż inne opcje, ale dostaję odwołanie do bazy danych, ponieważ Twoja aplikacja PHP prawdopodobnie już z niej korzysta. Oznacza to, że nie dodajesz innej zależności serwera i prawdopodobnie możesz ponownie użyć tego samego połączenia, którego używasz do pobierania danych sesji, aby uzyskać dane użytkownika, więc nie musisz ustanawiać jednego dla danych, jednego dla Memcache itp. Jeśli indeksujesz dobrze się spisuje, będzie też działał dość szybko i zapewnia dość prostą semantykę, którą już znasz, aby zbierać stare sesje lub nawet analizować dane sesji (nie jestem pewien, dlaczego chcesz, a jeśli nie, to prawdopodobnie nie to bardzo ważne). Skalowanie do ogromnych skal nie jest tak trywialne jak w przypadku czegoś takiego jak Redis,

Myślę, że ten wybór nie jest tak ważny na początku. Każde podejście ma wyzwania i zalety oraz rzeczy, o których musisz pomyśleć. Ogólnie rzecz biorąc, prawdopodobnie możesz uniknąć korzystania z domyślnych frameworków PHP / cokolwiek, którego używasz, lub nawet najłatwiejszej rzeczy. Jeśli później okaże się, że wybór jest zły, Twoje analizy wydajności powiedzą ci, a Ty będziesz uzbrojony w dane potrzebne do dokonania odpowiednich wyborów, biorąc pod uwagę specyfikę ruchu, jaki otrzymujesz. Z góry wszystko, co możesz rozsądnie mieć, to ogólne spekulacje.


0

To zależy od twoich potrzeb.

Istnieją pewne różnice między plikami a pamięcią bazy danych. Zobacz to pytanie .

Możesz jednak domyślnie robić to, co zostało zrobione w Rails 3 i używać tylko zaszyfrowanych plików cookie do sesji. Tak więc szyfrujesz wszystkie wartości w taki sposób, że tylko Ty możesz je później odszyfrować (np. Klucze prywatne / publiczne) i pozwalasz klientowi zachować stan dla ciebie.

Z jednej strony ogranicza Cię do 4Kb, co w rzeczywistości zwykle wystarcza (ponieważ zwykle chcesz przechowywać identyfikatory, a nie całe obiekty), ale naprawdę miłą korzyścią jest to, że nie musisz się martwić o czyszczenie sesji. Zostawiasz to klientowi, gdzie powinno być.


2
O ile nie wydzieliłeś swoich zasobów statycznych, aby znajdować się poza ścieżką plików cookie, pliki cookie to stały podatek, który musisz płacić za każde żądanie.
Joeri Sebrechts,

jQuery i Bootstrap mają łącznie około 150 KB, i to bez innych bibliotek. Cookie max to 4 KB, a zwykle poniżej 1 KB. Chyba że PO pyta o ekstremalne okoliczności - kogo to obchodzi w tego rodzaju opodatkowaniu?
Yam Marcovic,

@YMMarcovic jest kilka problemów 1) pliki cookie również trafiają na serwer (użytkownicy zwykle mają szybsze pobieranie niż przesyłanie) 2) zwykle strony mają 100 żądań plików statycznych (obrazy, js, css), więc może dostać się do 100 KB na każde żądanie idzie w górę
Miro Svrtan

@MiroSvrtan Jeśli zmuszasz użytkowników do wysyłania setek żądań na stronę (gdzie to się kiedykolwiek wydarzyło?), Optymalizacja nie stanowi dla ciebie problemu.
Yam Marcovic,

Miałem klienta, którego witryna wysyła ~ 170 żądań HTTP w celu załadowania strony głównej przed skonsultowaniem się ze mną w sprawie optymalizacji prędkości, więc zdarza się, zaufaj mi. Btw, klucze prywatne / publiczne są koncepcją opartą na kryptografii asymetrycznej, która zasadniczo nie byłaby stosowana w tym scenariuszu, w którym jest równoważna szyfrowi symetrycznemu, a jego wdrożenie jest bardziej skomplikowane. Ponadto większość implementacji przechowywania sesji opiera się na plikach cookie zarządzanych przez klienta, więc korzyść opisana w ostatnim akapicie odpowiedzi dotyczy wszystkich z nich.
jeteon,

0

W mojej szczególnej sytuacji mogę powiedzieć, że sesje w bazie danych są główną przyczyną zawieszania się serwerów z dużym marginesem. nasza tabela sesji jest na tyle często uszkodzona, że ​​zaczęliśmy ją skracać z wyprzedzeniem.

memcache brzmi atrakcyjnie, ale mamy zbyt wiele procesów, które usuwają cały memcache, więc sesje użytkownika byłyby zbyt często przerywane. a starsze sesje zostaną wyczyszczone, gdy pamięć się zapełni ... więc nie będzie już stałych logowań.

Wkrótce wypróbujemy domyślne sesje oparte na plikach.

Jeśli martwisz się o bezpieczeństwo danych sesji, nie powinieneś umieszczać tych danych w sesji - i nie ufać sesji - sprawdzać poprawność użytkownika na każde żądanie.


0

Możesz spróbować zapisać swoją sesję na Redis . Redis jest szybki jak Memcached, ale ma również kilka opcji utrwalania danych. Ponadto obsługiwane są różne klienty PHP.

Ponadto możesz wypróbować usługi innych firm, takie jak Memcached Cloud, która ma wbudowane funkcje replikacji i mechanizmu przechowywania

Ujawnienie, jestem współzałożycielem i CTO Garantia Data.


2
Dzięki za ujawnienie! Upewnij się, że uczestniczysz w tej witrynie poza postami, w których możesz wspominać o swoich produktach. Chcemy, abyś jako osoba, a nie Twoja firma.
Martijn Pieters,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.