Redis to zaawansowana baza danych klucz-wartość. To podobne do memcached, ale dane można przechowywać, a typy danych są bogate. Są łańcuchy, listy powiązane, zbiory i uporządkowane kolekcje. Obsługuje obliczanie sumowania, przecinania i uzupełniania (różnic) kolekcji po stronie serwera, a także obsługuje różnorodne funkcje sortowania. Redis można więc również postrzegać jako serwer struktur danych.
Wszystkie dane Redis są przechowywane w pamięci, a następnie od czasu do czasu asynchronicznie na dysku (nazywa się to "trybem półtrwałym"); Możesz także zapisać każdą zmianę danych do pliku tylko do Append Only File (AOF) (nazywa się to "trybem pełnej trwałości").
Pierwszą metodą jest narzut danych: domyślny redis zachowuje dane na dysku w formie migawki (plik binarny, dump.rdb, można określić tę nazwę), a format w pliku konfiguracyjnym to: save N M oznacza, że w ciągu N sekund redis wykona migawkę na dysk, jeśli w redis nastąpi co najmniej M modyfikacji. Oczywiście możemy też ręcznie wykonać save lub bgsave (asynchronicznie), aby zrobić migawki.
Oto krótkie wprowadzenie do działania systemu: Gdy Redis musi przetrwać, Redis rozdziela proces potomny; Proces potomny zapisuje dane do tymczasowego pliku RDB na dysku; Gdy podproces kończy zapisywać plik tymczasowy, zastępuje oryginalny RDB, który ma zalet kopiowania przy zapisie
Istnieje też metoda persistencyjna Append-only:filesnapshotting – gdy redis jest nieprawidłowo martwy, ostatnie dane zostaną utracone (ilość utraconych danych zależy od konfiguracji polityki zapisu), więc to największa wada, gdy wolumen biznesowy jest duży, utraconych danych jest dużo. Metoda tylko z dodawaniem pozwala na całkowitą utratę danych, ale wydajność redis jest gorsza. AOF można utrzymywać przez cały proces, wystarczy go włączyć w pliku konfiguracyjnym (domyślnie nie), tylko addendonly yes. Po włączeniu AOF za każdym razem, gdy redis wykona polecenie modyfikacji danych, zostanie on dodany do pliku AOF, a po reaktywacji AOF plik AOF zostanie odczytany do "powtórki", aby przywrócić go do ostatniej chwili przed zamknięciem redis.
Przepisywanie LOG W miarę jak plik AOF staje się coraz większy wraz z modyfikacją danych, wiele z nich zapisuje się w kluczu. Dlatego redis ma ciekawą funkcję: rekonstruuje plik AOF w tle bez wpływu na operację po stronie klienta. Wykonanie polecenia BGREWRITEAOF w dowolnym momencie zapisuje najkrótszą sekwencję poleceń w bieżącej pamięci na dysku, a te polecenia mogą w pełni zbudować aktualną sytuację danych bez zbędnych zmian (takich jak zmiany stanu, liczników itp.), zmniejszając rozmiar pliku AOF. Dlatego przy korzystaniu z OF redis zaleca również korzystanie z BGREWRITEAOF.
Istnieją trzy sposoby odświeżenia pliku AOF, odwołaj się do parametru konfiguracyjnego appendfsync: appendfsync zawsze wywołuje fsync, aby wyrównać plik AOF za każdym razem, gdy wysyłane jest polecenie modyfikacji, co jest bardzo, bardzo wolne, ale też bardzo bezpieczne; appendfsync everysec wywołuje fsync co sekundę, aby szybko przenieść się do pliku AOF, ale może stracić dane w ciągu sekundy; appendfsync nie polega na systemie operacyjnym do odświeżania, redis nie odświeża aktywnie OV, co jest najszybsze, ale zabezpieczenia są słabe. Domyślnie zaleca się odświeżanie na sekundę, aby brać pod uwagę zarówno szybkość, jak i bezpieczeństwo.
Może to wynikać z powodów systemowych, że AOF jest uszkodzony, redis nie może już załadować tego OF OV, możesz wykonać poniższe kroki, aby to naprawić: Najpierw zrób kopię zapasową pliku AOF i skopiuj ją w inne miejsce; Napraw oryginalny plik OF, wykonaj: $redis-check-aof –fix; Możesz użyć polecenia diff –u, aby zobaczyć, gdzie pliki są niespójne przed i po naprawie. Restartuj usługę Redis.
Jak działa LOG Rewrite: To samo stosuje copy-on-write: first redis rozgałęzia proces potomny; Proces potomny zapisuje najnowszy AOF do pliku tymczasowego; Proces nadrzędny zapisuje inkrementalnie najnowsze wykonane zmiany w pamięci (w tym czasie stary AOF jest nadal zapisany i można go bezpiecznie przepisać w razie niepowodzenia); Gdy proces potomny zakończy przepisywanie pliku tymczasowego, proces nadrzędny otrzymuje sygnał i zapisuje poprzednie zmiany przyrostowe w pamięci na końcu pliku tymczasowego. Redis zmienia nazwę starego pliku OF, zmienia nazwę pliku tymczasowego i zaczyna zapisywać do nowego pliku OF.
Na koniec, na wszelki wypadek (awaria maszyny lub dysku), pamiętaj, aby regularnie robić kopię zapasową pliku *rdb *.aof wygenerowanego za pomocą plików napshotting lub tylko z Append-only na zdalnym komputerze. Używam crontabu do SCP co pół godziny. Nie korzystałem z funkcji master-slave w Redis, bo półgodzinna kopia zapasowa powinna wystarczyć, a mam wrażenie, że to trochę strata maszyny, jeśli masz master-slave. Ostatecznie zależy to od zastosowania.
|
Opublikowano 24.08.2017 16:37:45
|
|
|
