Wykorzystanie pamięci podręcznej Redis znacznie poprawia wydajność i efektywność aplikacji, zwłaszcza w zakresie zapytań o dane. Ale jednocześnie niesie też pewne problemy. Spośród nich najważniejszym problemem jest spójność danych, która jest całkowicie nierozwiązywalna. Jeśli wymagana jest spójność danych, nie można stosować buforowania.
Inne typowe problemy to penetracja pamięci podręcznej, lawina cache oraz rozpad pamięci podręcznej. Obecnie w branży dostępnych jest także więcej popularnych rozwiązań. Ten artykuł nie ma na celu rozwiązania tych trzech problemów w sposób bardziej doskonały, ani nie ma na celu podważania popularnych rozwiązań w branży. Zamiast tego zademonstrujemy te trzy zjawiska problemowe z samej operacji kodu. Powodem tego jest to, że trudno jest mieć bardzo wyraźną koncepcję w głowie tylko patrząc na akademickie wyjaśnienia tych problemów, a dzięki rzeczywistym demonstracjom kodu można pogłębić swoje zrozumienie i zrozumienie tych problemów.
Przenikanie pamięci podręcznej
Przenikanie do pamięci podręcznej odnosi się do zapytań o dane, które nie istnieją w bazie danych. Jeśli klucz nie istnieje lub wygasł, baza danych jest zapytywana, a obiekty zapytania umieszczane są w pamięci podręcznej. Jeśli obiekt zapytania bazy danych jest pusty, nie jest on buforowany.
Przepływ kodu
- parametr przekazuje główny identyfikator klucza obiektu
- Pobierz obiekt z pamięci podręcznej na podstawie klucza
- Jeśli obiekt nie jest pusty, zwraca bezpośrednio
- Jeśli obiekt jest pusty, wykonaj zapytanie bazodanowe
- Jeśli obiekt zapytany z bazy danych nie jest pusty, umieść go w pamięci podręcznej (ustaw czas wygaśnięcia). Wyobraź sobie taką sytuację, co by się stało, gdyby parametr przekazany do bazy był -1? Ten -1 to obiekt, który nie może istnieć. Baza danych będzie zapytywana za każdym razem, każde zapytanie będzie puste i nie będzie buforowane za każdym razem. Jeśli dojdzie do złośliwego ataku, ta luka może zostać wykorzystana, aby wywrzeć presję na bazę danych lub ją nawet przytłoczyć. Nawet jeśli użyto UUID, łatwo znaleźć nieistniejący KEY i zaatakować.
W mojej pracy użyję metody buforowania wartości null, czyli kroku 5 w [procesie kodowania], jeśli obiekt zapytany z bazy danych jest pusty, również jest umieszczany w pamięci podręcznej, ale ustalony czas wygaśnięcia pamięci podręcznej jest krótki, np. ustawiając go na 60 sekund.
Lawina cache
Lawina pamięci podręcznej odnosi się do wygaśnięcia zestawu pamięci podręcznej w określonym czasie.
Jednym z powodów lawiny, na przykład, jest to, że gdy piszę ten artykuł, wkrótce będzie godzina zero dwunastego dnia, a wkrótce nastąpi fala szybkich zakupów. A o pierwszej w nocy zapas tej partii towarów wygaśnie. Zapytanie dostępu do tej partii towarów trafia do bazy danych, a dla bazy danych występują okresowe szczyty ciśnienia.
Gdy Xiaobian realizuje projekty e-commerce, zazwyczaj przyjmuje różne kategorie dóbr i magazynuje różne cykle. Towary z tej samej kategorii, plus czynnik losowy. W ten sposób czas wygaśnięcia pamięci podręcznej może być rozproszony tak bardzo, jak to możliwe, a czas pamięci podręcznej produktów w popularnych kategoriach jest dłuższy, a czas pamięci podręcznej produktów w niepopularnych kategoriach krótszy, co również pozwala oszczędzać zasoby usługi cachingowej.
W rzeczywistości scentralizowany wygaśnięcie nie jest bardzo śmiertelne, a bardziej śmiertelną lawiną pamięci podręcznej jest awaria lub rozłączenie węzła serwera pamięci podręcznej. Ponieważ lawina pamięci podręcznej, która naturalnie występuje, musi zostać utworzona w określonym czasie, baza danych może wytrzymać presję, a w tym czasie również może wytrzymać ciśnienie. To nic innego jak okresowa presja na bazę danych. Przestoj węzła obsługi cache powoduje nieprzewidywalną presję na serwer bazy danych i prawdopodobnie natychmiast ją przeciąży.
Podział pamięci podręcznej
Rozbicie pamięci podręcznej odnosi się do klucza, który jest bardzo gorący, stale przenoszący duże współbieżności; duże współbieżności koncentrują się na uzyskaniu dostępu do tego punktu; gdy ten klucz zawodzi, ciągła duża współbieżność przebija się przez pamięć podręczną i bezpośrednio żąda bazy danych, podobnie jak wiercenie w barierze.
Gdy Xiaobian realizował projekty e-commerce, uczynił ten produkt "hitem".
W rzeczywistości w większości przypadków taki wybuch jest trudny do wywierania miażdżącej presji na serwerze bazy danych. Niewiele firm osiągnęło ten poziom. Dlatego pragmatyczny edytor przygotował się na główne produkty wcześniej, aby cache nigdy nie wygasł. Nawet jeśli niektóre produkty fermentują same w hity, można je ustawić jako nigdy nie przeterminowane.
Główna droga jest prosta, a zamek mutex key mutual rejection jest praktycznie rzadko używany.
|
Opublikowano 19.11.2019 09:55:04
|
|
|
|
