Redis — це розширена база даних ключових значень. Це схоже на memcached, але дані можна зберігати, а типи даних багаті. Існують рядки, пов'язані списки, множини та впорядковані колекції. Він підтримує обчислення сумування, перетину та доповнення (різниці) колекцій на стороні сервера, а також підтримує різноманітні функції сортування. Отже, Redis також можна розглядати як сервер структур даних.
Усі дані Redis зберігаються в пам'яті, а потім час від часу асинхронно зберігаються на диску (це називається «напівперсистентним режимом»); Ви також можете записувати кожну зміну даних у файл лише додавання (AOF) (це називається «режим повної збереженості»).
Перший метод — filesnapshotting: за замовчуванням redis зберігає дані на диск у вигляді знімка (бінарний файл, dump.rdb, можна вказати цю назву), а формат у файлі конфігурації: save N M означає, що протягом N секунд redis зробить знімок на диск, якщо в redis відбуваються принаймні M модифікацій. Звісно, ми також можемо вручну виконати збереження або bgsave (асинхронно) для створення знімків.
Ось короткий вступ до того, як це працює: коли Redis потрібно зберігати, Redis форкує дочірній процес; Дочірній процес записує дані у тимчасовий RDB-файл на диску; Коли підпроцес завершує запис тимчасового файлу, він замінює оригінальний RDB, який має перевагу копіювання при записі
Існує також метод збереження Append-only:filesnapshotting method. Коли redis аномально мертвий, останні дані будуть втрачені (кількість втрачених даних залежить від конфігурації вашої політики збереження), тому це його найбільший недолік: коли обсяг бізнесу великий, втрачених даних багато. Метод додавання може повністю втратити дані, але продуктивність Redis гірша. AOF можна зберігати протягом усього процесу, потрібно лише увімкнути у конфігураційному файлі (за замовчуванням — ні), додаток — так. Після увімкнення AOF кожного разу, коли redis виконує команду на зміну даних, він додається до файлу aof, а при перезапуску AOF 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 більше не може завантажувати цей OF OV, ви можете виконати кроки нижче, щоб це виправити: спочатку зробіть резервну копію файлу AOF і скопіюйте його в інше місце; Виправити оригінальний файл OF, виконати: $redis-check-aof –fix; Ви можете скористатися командою diff –u, щоб побачити, де файли несумісні до і після ремонту. Перезапустіть сервіс Redis.
Як працює LOG Rewrite: Те саме використовує копіювання при записі: спочатку redis форкує дочірній процес; Дочірній процес записує останній AOF у тимчасовий файл; Батьківський процес поступово записує останні виконані зміни в пам'ять (на даний момент старий AOF все ще записується, і його безпечно переписувати, якщо він не спрацює); Коли дочірній процес завершує переписування тимчасового файлу, батьківський процес отримує сигнал і записує попередні інкрементні зміни в пам'яті в кінець тимчасового файлу. Redis перейменовує старий файл OF, перейменовує тимчасовий файл і починає запис у новий OF.
Нарешті, на всяк випадок (якщо машина або диск зависне), пам'ятайте регулярно робити резервні копії файлу *rdb *.aof, створеного за допомогою filesnapshoting або Append-only на віддалену машину. Я використовую crontab для SCP кожні півгодини. Я не використовував функцію master-slave у Redis, бо півгодинна резервна копія має бути достатньою, і мені здається, що це трохи марна трата часу, якщо у вас майстер-слейв. Це зрештою залежить від конкретного застосування.
|
Опубліковано 24.08.2017 16:37:45
|
|
|
