1. Передмова
Нещодавно Redis використовується як кеш у проєкті для полегшення обміну даними між кількома бізнес-процесами. Оскільки дані Redis зберігаються в пам'яті, якщо збереження не налаштовано, усі дані будуть втрачені після перезавантаження Redis, тому потрібно увімкнути функцію збереження Redis для збереження даних на диск, і при перезавантаженні Redis можна відновити дані з диска. Redis пропонує два способи збереження: збереження RDB (принцип полягає в тому, щоб скинути записи баз даних Рідса в пам'ять у збереження RDB на диску) і інший — збереження AOF (принцип полягає в тому, щоб записувати журнали операцій Рейдса у файл у вигляді додатку). Отже, у чому різниця між цими двома методами стійкості і як їх змінити? Більшість того, що я читаю в Інтернеті, вказують на те, як налаштовувати та використовувати ці два методи, але немає жодного введення про різницю між ними і в яких застосунках варто використовувати.
2. Різниця між ними
Persistence RDB означає запис знімка набору даних у пам'яті на диск у визначений часовий проміжок, а фактичний операційний процес полягає у форкуванні підпроцесу, спочатку записі набору даних у тимчасовий файл, а після успішного запису замінити попередній файл і зберегти його за допомогою бінарного стиснення.
Збереження AOF фіксує кожну операцію запису та видалення, виконану сервером у вигляді журналу, і ця операція запиту не записується, а буде записана у тексті, і ви можете відкрити файл, щоб побачити детальний запис операції.
3. Переваги та недоліки обох
Які переваги RDB?
1). Після використання цієї системи вся база даних Redis міститиме лише один файл, що ідеально підходить для резервного копіювання. Наприклад, ви можете захотіти архівувати останні 24 години кожну годину, а також останні 30 днів щодня. З такою резервною стратегією ми легко можемо відновитися у разі катастрофічної відмови системи.
2). RDB — дуже хороший вибір для відновлення після катастрофи. Тому що ми можемо легко стиснути один файл і перенести його на інший носій зберігання.
3). Максимізувати продуктивність. Для сервісного процесу Redis єдине, що потрібно зробити при запуску збереження — це видалити дочірні процеси, і тоді дочірні процеси виконують ці завдання збереження, що значно дозволяє уникнути виконання операцій IO.
4). Порівняно з механізмом AOF, якщо набір даних великий, ефективність запуску RDB буде вищою.
Які недоліки має RDB?
1). Якщо ви хочете забезпечити високу доступність даних, тобто максимально уникнути втрати даних, то RDB не буде хорошим вибором. Тому що, коли система виходить з ладу до запланованого збереження, дані, які раніше були записані на диск, будуть втрачені.
2). Оскільки RDB допомагає зберігати дані через підпроцеси форків, якщо набір даних великий, це може призвести до зупинки обслуговування всього сервера на сотні мілісекунд або навіть на 1 секунду.
Які переваги AOF?
1). Цей механізм може забезпечити більшу безпеку даних, тобто збереження даних. У Redis передбачено 3 стратегії синхронізації: синхронізація за секунду, синхронізація за модифікацію та десинхронізація. Насправді синхронізація за секунду також здійснюється асинхронно, і її ефективність також дуже висока, різниця в тому, що коли система виходить з ладу, змінені дані втрачаються протягом цієї секунди. І кожного разу, коли модифікація синхронізується, ми можемо уявити це як збереження синхронізації, тобто кожна зміна даних, що відбувається, одразу записується на диск. Можна передбачити, що цей метод є найменш ефективним. Щодо відсутності синхронізації, більше не потрібно казати, думаю, кожен правильно це розуміє.
2). Оскільки механізм використовує режим додавання для запису файлів журналу, навіть якщо під час написання буде простой, вже існуючий у файлі журналу не буде знищений. Однак, якщо ми запишемо лише половину даних, і система цього разу зависне, не хвилюйтеся, ми можемо використати інструмент redis-check-aof, щоб допомогти вирішити проблему узгодженості даних перед наступним початком Redis.
3). Якщо журнал занадто великий, Redis може автоматично увімкнути механізм переписування. Тобто Redis постійно записує дані модифікації у старий файл на диску в режимі додавання, а також створює новий файл для запису, які команди модифікації виконуються в цей період. Тому безпека даних може бути краще гарантована при перемиканні між переписуваннями.
4). AOF містить чіткий, легкий для розуміння файл журналу, який фіксує всі зміни. Насправді ми також можемо завершити реконструкцію даних через цей файл.
Які недоліки OV?
1). Для тієї ж кількості наборів даних файли OF зазвичай більші за файли RDB. RDB відновлює великі набори даних швидше, ніж AOF.
2). Залежно від стратегії синхронізації, AOF, як правило, повільніший за RDB за ефективністю роботи. Коротко кажучи, ефективність політики синхронізації на секунду відносно висока, а ефективність політики синхронного вимкнення така ж ефективні, як і політика синхронного відключення.
Критерії вибору цих двох — чи готова система пожертвувати частиною продуктивності заради вищої послідовності кешу (AOF), чи готова вона не вмикати резервні копії в обмін на вищу продуктивність при частих операціях запису, а потім робити резервне копіювання (RDB) при ручному запуску збереження. RDB має більш остаточне послідовне значення. Однак виробниче середовище насправді більше поєднує обидва варіанти.
4. Поширені конфігурації
Конфігурація збереження RDB
Redis завантажує знімок набору даних у файл dump.rdb. Крім того, ми також можемо змінювати частоту дампів сервера Redis через конфігураційний файл; після відкриття файлу 6379.conf ми шукаємо save і бачимо наступну інформацію про конфігурацію:
Постійна конфігурація AOF
Існує три способи синхронізації в профілі Redis, а саме:
Повна конфігурація:
Новий файл "appendonly.aof" буде створено у тестовому каталозі наступним чином:
|
Опубліковано 04.02.2021 13:47:27
|
|
|
|
Орендодавець|
Опубліковано 08.02.2021 11:45:25
|
Опубліковано 22.09.2021 20:26:16