1. Przedmowa
Ostatnio Redis był wykorzystywany jako pamięć podręczna w projekcie, ułatwiając współdzielenie danych między wieloma procesami biznesowymi. Ponieważ dane Redis są przechowywane w pamięci, jeśli persistencja nie jest skonfigurowana, wszystkie dane zostaną utracone po restarcie Redis, więc musisz włączyć funkcję persistencji Redis, aby zapisać dane na dysku, a po reaktywacji Redis możesz odzyskać dane z dysku. Redis oferuje dwa sposoby utrwalania: trwałość RDB (zasada polega na zrzutowaniu rekordów bazy danych Reids do pamięci RDB persistence na dysku) oraz druga to trwałość AOF (zasada polega na zapisywaniu logów operacji Reidsa do pliku w formie załącznika). Jaka jest więc różnica między tymi dwoma metodami trwałości i jak ją zmienić? Większość rzeczy, które czytałem w Internecie, wyjaśnia, jak skonfigurować i używać tych dwóch metod, ale nie ma wprowadzenia do różnic między nimi ani do tego, w jakich scenariuszach zastosować.
2. Różnica między nimi
Trwałość RDB odnosi się do zapisywania migawki zbioru danych w pamięci na dysku w określonym przedziale czasowym, a rzeczywisty proces operacji polega na rozgałęzieniu podprocesu, najpierw zapisaniu zbioru danych do pliku tymczasowego, a następnie zastąpieniu poprzedniego pliku po pomyślnym zapisie i zapisaniu go z kompresją binarną.
AOF utrwalczy rejestruje każdą operację zapisu i usuwania przetwarzaną przez serwer w formie logu, a operacja zapytania nie będzie rejestrowana, lecz zapisana w formie tekstu, a plik można otworzyć i zobaczyć szczegółowy rekord operacji.
3. Zalety i wady obu tych rozwiązań
Jakie są zalety RDB?
1). Po użyciu tego cała baza danych Redis będzie zawierać tylko jeden plik, co jest idealne do tworzenia kopii zapasowych. Na przykład możesz chcieć archiwizować ostatnie 24 godziny co godzinę, a także archiwizować ostatnie 30 dni każdego dnia. Dzięki takiej strategii zapasowej możemy łatwo odzyskać sytuację w przypadku katastrofalnej awarii systemu.
2). RDB to bardzo dobry wybór do odzyskiwania po katastrofie. Ponieważ możemy łatwo skompresować pojedynczy plik i przenieść go na inne nośniki pamięci.
3). Maksymalizuj wydajność. W procesie usługi Redis jedyne, co musi zrobić przy uruchamianiu persistencji, to wyodrębnić procesy podrzędne, a następnie procesy podrzędne kończą te zadania persistencyjne, co znacznie pozwala uniknąć procesu usługowego wykonującego operacje IO.
4). W porównaniu z mechanizmem AOF, jeśli zbiór danych jest duży, efektywność startu RDB będzie wyższa.
Jakie są wady RDB?
1). Jeśli chcesz zapewnić wysoką dostępność danych, czyli uniknąć ich utraty w maksymalnym stopniu, RDB nie będzie dobrym wyborem. Ponieważ gdy system przestanie działać przed zaplanowaną trwałością, dane wcześniej zapisane na dysku zostaną utracone.
2). Ponieważ RDB pomaga w utrzymywania danych poprzez podprocesy fork, jeśli zbiór danych jest duży, może to spowodować zatrzymanie usługi przez cały serwer na setki milisekund, a nawet na 1 sekundę.
Jakie są zalety AOF?
1). Ten mechanizm może zapewnić większe bezpieczeństwo danych, czyli ich trwałość. W Redis dostępne są trzy strategie synchronizacji: synchronizacja na sekundę, synchronizacja na modyfikację oraz desynchronizacja. W rzeczywistości synchronizacja na sekundę również odbywa się asynchronicznie, a jej wydajność jest bardzo wysoka, różnica polega na tym, że gdy system przestaje działać, zmodyfikowane dane są tracone w ciągu tej sekundy. Za każdym razem, gdy modyfikacja jest synchronizowana, możemy to traktować jako trwałość synchronizacji, czyli każda zmiana danych jest natychmiast zapisywana na dysku. Można przewidzieć, że ta metoda jest najmniej wydajna. Jeśli chodzi o brak synchronizacji, nie trzeba mówić więcej, myślę, że każdy potrafi to dobrze zrozumieć.
2). Ponieważ mechanizm przyjmuje tryb dodawania do zapisu plików logów, nawet jeśli podczas zapisu wystąpi przestoj, zawartość już istniejąca w pliku logu nie zostanie zniszczona. Jednak jeśli zapiszemy tylko połowę danych i tym razem system się zawiesi, nie martw się, możemy użyć narzędzia redis-check-aof, aby rozwiązać problem spójności danych przed kolejnym uruchomieniem Redis.
3). Jeśli log jest zbyt duży, Redis może automatycznie włączyć mechanizm przepisywania. Oznacza to, że Redis nieprzerwanie zapisuje dane modyfikacji do starego pliku dysku w trybie dodawania, a Redis tworzy także nowy plik, aby zarejestrować, które polecenia modyfikacji są wykonywane w tym okresie. Dlatego bezpieczeństwo danych można lepiej zagwarantować podczas przełączania się między przepisami.
4). AOF zawiera przejrzysty, łatwy do zrozumienia plik loga, który rejestruje wszystkie modyfikacje. W rzeczywistości możemy również zakończyć rekonstrukcję danych za pomocą tego pliku.
Jakie są wady OV?
1). Dla tej samej liczby zbiorów danych pliki OF są zazwyczaj większe niż pliki RDB. RDB odzyskuje duże zbiory danych szybciej niż AOF.
2). W zależności od strategii synchronizacji, AOF jest zwykle wolniejsze niż RDB pod względem wydajności działania. Krótko mówiąc, efektywność polityki synchronizacji na sekundę jest stosunkowo wysoka, a efektywność polityki synchronicznego wyłączania jest równie efektywna jak w RDB.
Kryteria wyboru obu opcji to, czy system jest gotów poświęcić część wydajności w zamian za wyższą spójność pamięci podręcznej (AOF), czy też nie umożliwiać wykonywania kopii zapasowych w zamian za wyższą wydajność, gdy operacje zapisu są częste, a następnie wykonywanie kopii zapasowych (RDB) podczas ręcznego uruchamiania zapisu. rdb ma bardziej ostateczne, spójne znaczenie. Jednak środowisko produkcyjne to w rzeczywistości bardziej połączenie obu tych rzeczy.
4. Typowe konfiguracje
Konfiguracja trwałości RDB
Redis zrzuca migawkę zbioru danych do pliku dump.rdb. Dodatkowo możemy również modyfikować częstotliwość zrzutów zrzutów serwera Redis przez plik konfiguracyjny, po otwarciu pliku 6379.conf wyszukujemy save i widzimy następujące informacje konfiguracyjne:
Konfiguracja trwała AOF
W profilu Redis są trzy sposoby synchronizacji:
Pełna konfiguracja:
Nowy plik "appendonly.aof" zostanie utworzony w katalogu testowym, w następujący sposób:
|