Redis е усъвършенствана база данни с ключови стойности. Подобно е на memcached, но данните могат да се запазват и типовете данни са богати. Има низове, свързани списъци, комплекти и подредени колекции. Той поддържа изчисляване на сумирането, пресичането и допълването (разлика) на колекции от страна на сървъра, както и различни функции за сортиране. Така Redis може да се разглежда и като сървър за структури от данни.
Всички данни на Redis се съхраняват в паметта и след това се съхраняват асинхронно на диск от време на време (това се нарича "полуперсистентен режим"); Можете също така да записвате всяка промяна в Append Only File (AOF) (това се нарича "режим на пълна устойчивост").
Първият метод е filesnapshotting: Стандартният redis запазва данните на диска под формата на snapshot (двоичен файл, dump.rdb, това име може да се зададе), а форматът в конфигурационния файл е: save N M означава, че в рамките на N секунди redis ще направи снимка на диска, ако поне M модификации се случат в redis. Разбира се, можем също ръчно да направим save или bgsave (асинхронно), за да правим снимки.
Ето кратко въведение в това как работи: Когато Redis трябва да продължи, Redis ще форкне на дъщерен процес; Дъщерният процес записва данните във временен RDB файл на диска; Когато подпроцесът завърши записването на временния файл, той заменя оригиналния RDB, който има предимството на копиране при запис
Има и метод за запазване Append-only:filesnapshotting method. Когато redis е необичайно мъртъв, последните данни се губят (количеството загубени данни зависи от конфигурацията на вашата политика за запазване), така че това е най-големият му недостатък – когато бизнес обемът е голям, загубените данни са много. Методът само с добавяне може да постигне пълна загуба на данни, но производителността на redis е по-лоша. AOF може да се запази през целия процес, само трябва да се включи в конфигурационния файл (по подразбиране е не), само в приложение да. След като AOF е активиран, всеки път, когато redis изпълни команда за промяна на данни, тя се добавя към aof файла, а когато redis се рестартира, AOF файлът се чете за "възпроизвеждане" и се възстановява до последния момент преди redis да бъде затворен.
Презаписване на LOG Докато AOF файлът става все по-голям с промяната на данните, много от които записите се променят в даден ключ. Затова redis има интересна функция: реконструиране на AOF файла във фонов режим, без да влияе на клиентската страна. Изпълнението на командата BGREWRITEAOF по всяко време ще запише най-кратката последователност от команди в текущата памет на диск, като тези команди могат напълно да конструират текущата ситуация с данните без излишни промени (като промени на състояние, промени в брояча и др.), намалявайки размера на AOF файла. Затова при използване на OF, Redis препоръчва да се използва и BGREWRITEAOF.
Има три начина за обновяване на AOF файла, вижте конфигурационния параметър appendfsync: appendfsync винаги извиква fsync, за да се изчисти с AOF файла всеки път, когато се изпрати команда за модификация, което е много, много бавно, но и много безопасно; appendfsync everysec извиква fsync всяка секунда, за да се превърне бързо в AOF файла, но може да загуби данни в рамките на секунда; appendfsync no разчита на ОС за обновяване, redis не обновява активно OV, което е най-бързо, но сигурността е слаба. По подразбиране се препоръчва опресняване на секунда, така че да се вземат предвид както скоростта, така и сигурността.
Може да е поради системни причини, че AOF е повреден, redis вече не може да зареди това ОТ OV, можете да следвате стъпките по-долу, за да го поправите: Първо, направете резервно копие на AOF файла и го копирайте на друго място; Поправи оригиналния OF файл, изпълни: $redis-check-aof –fix; Можете да използвате командата diff –u, за да видите къде файловете са несъвместими преди и след ремонта. Рестартирай услугата Redis.
Как работи LOG Rewrite: Същото използва copy-on-write: първо redis ще форква дъщерен процес; Дъщерният процес записва последния AOF във временен файл; Родителският процес постепенно записва последните изпълнени промени в паметта (към момента старият AOF все още е записан и е безопасно да се пренапише, ако се провали); Когато дъщерният процес приключи с пренаписването на временния файл, родителският процес получава сигнал и записва предишните инкрементални промени в паметта в края на временния файл. Redis преименува стария OF файл, преименува временния файл и започва да записва към новия OF.
Накрая, за всеки случай (при срив на машината или при срив на диска), не забравяйте редовно да правите резервни копия на *rdb *.aof файла, генериран чрез filesnapshotting или Append-only към отдалечената машина. Използвам crontab за SCP на всеки половин час. Не използвах функцията master-slave на Redis, защото половинчасово резервно копие би трябвало да е достатъчно, и ми се струва, че е малко загуба на машината, ако имаш master-slave. Това в крайна сметка зависи от приложението.
|
Публикувано в 24.08.2017 г. 16:37:45 ч.
|
|
|
