|
|
Redis windows 64 bit скачать, официальный адрес для скачивания
h ttps:// www.itsvse.com/thread-2576-1-1.html
Три способа запустить Redis
h ttps:// www.itsvse.com/thread-4008-1-1.html
Разница между save и bgsave в Redis
h ttps:// www.itsvse.com/thread-4010-1-1.html
Учебник по Redis 5.0.3 на CentOS 7
h ttps:// www.itsvse.com/thread-7201-1-1.html
1, предисловие
Недавно Redis был использован в качестве кэша в одном из проектов для облегчения обмена данными между несколькими бизнес-процессами. Поскольку данные Redis хранятся в памяти, если вы не настроите персистентность, данные будут потеряны после перезапуска Redis, поэтому необходимо включить функцию персистентности Redis для сохранения данных на диск, после перезапуска Redis вы сможете восстановить данные с диска. redis предоставляет два способа персистентности, один из них - RDB персистентность (принцип заключается в том, чтобы риды в RDB persistence (принцип заключается в регулярном сбросе записей базы данных ридов в памяти на диск), а другой - AOF persistence (принцип заключается в записи журналов операций ридов в файл в виде аппендикса). В чем же разница между этими двумя методами персистентности, как выбрать? Большинство онлайн-поисков сводится к представлению двух способов, как настроить, как использовать, нет введения в разницу между ними, в каких сценариях применения использовать.
2, разница между двумя способами
RDB постоянство относится к заданному интервалу времени будет в памяти снимки набора данных записываются на диск, фактический процесс операции вилка подпроцесс, сначала записать набор данных во временный файл, написать успешный, а затем заменить предыдущий файл с двоичным сжатого хранения.
AOF persistence в виде логов для записи каждой операции записи и удаления, обработанной сервером, операции запроса не будут записаны, записываются в текстовом виде, вы можете открыть файл, чтобы увидеть подробные записи операций.
3、Преимущества и недостатки двух систем
Каковы преимущества RDB?
1). Если использовать этот подход, то вся база данных Redis будет содержать только один файл, что идеально подходит для резервного копирования файлов. Например, вы можете захотеть архивировать данные за последние 24 часа раз в час, а также архивировать данные за последние 30 дней раз в день. При такой стратегии резервного копирования мы сможем очень легко восстановиться в случае катастрофического сбоя системы.
2). Для аварийного восстановления RDB - очень хороший выбор. Ведь мы можем очень легко сжать один файл, а затем перенести его на другой носитель.
3). Максимизация производительности. Для сервисного процесса Redis, когда он начинает персистенцию, единственное, что ему нужно сделать, это форкнуть дочерний процесс, а затем дочерний процесс завершит работу по персистенции, что позволяет значительно избежать выполнения сервисным процессом операций ввода-вывода.
4). По сравнению с механизмом AOF, RDB запускается более эффективно, если набор данных большой.
Каковы недостатки RDB?
1). Если вы хотите обеспечить высокую доступность данных, т. е. свести к минимуму их потерю, то RDB будет не самым лучшим выбором. Это связано с тем, что если система выйдет из строя до начала временной персистенции, то все данные, которые не успели быть записаны на диск, будут потеряны.
2). Поскольку RDB помогает в сохранении данных путем "вилочных" подпроцессов, это может привести к тому, что весь сервер не будет работать в течение сотен миллисекунд или даже 1 секунды, если и когда набор данных будет большим.
В чем преимущества AOF?
1). Этот механизм обеспечивает более высокую безопасность данных, т. е. их сохранность. В Redis существует 3 стратегии синхронизации: посекундная синхронизация, синхронизация за модификацию и без синхронизации. По сути, посекундная синхронизация также выполняется асинхронно, и ее эффективность также очень высока, с той лишь разницей, что при падении системы данные, измененные в течение этой секунды, будут потеряны. С другой стороны, синхронизацию по модификациям можно рассматривать как синхронную персистентность, то есть при каждом изменении данных они немедленно записываются на диск. Предсказуемо, этот подход является наименее эффективным с точки зрения производительности. Что касается несинхронизированной, то больше говорить не стоит, думаю, мы все и так это прекрасно понимаем.
2). Поскольку этот механизм использует режим добавления для операции записи в файл журнала, даже если в процессе записи произойдет простой, он не уничтожит содержимое, которое уже существует в файле журнала. Однако, если мы запишем только половину данных в этой операции, а затем произойдет сбой системы, не волнуйтесь, перед следующим запуском Redis мы можем использовать инструмент redis-check-aof, который поможет нам решить проблему согласованности данных.
3). Если журнал слишком большой, Redis может автоматически включить механизм перезаписи. То есть Redis постоянно записывает измененные данные в старый дисковый файл в режиме добавления, и в то же время Redis создает новый файл, чтобы записать, какие измененные команды были выполнены за это время. Таким образом, безопасность данных при переключении перезаписи может быть лучше обеспечена.
4). AOF содержит четко отформатированный, простой для понимания файл журнала, в котором фиксируются все изменения. Фактически, мы можем использовать этот файл для завершения реконструкции данных.
Каковы недостатки AOF?
1). Файлы AOF обычно больше, чем файлы RDB для того же количества наборов данных. RDB может восстановить большие наборы данных быстрее, чем AOF.
2). В зависимости от стратегии синхронизации AOF работает медленнее, чем RDB, с точки зрения эффективности. Вкратце, стратегия синхронизации в секунду более эффективна, а стратегия с отключением синхронизации так же эффективна, как и RDB.
Критерием выбора между этими двумя стратегиями является то, готова ли система пожертвовать некоторой производительностью ради более высокой согласованности кэша (AOF), или она готова часто записывать операции, не включать резервное копирование ради более высокой производительности, запускать вручную, когда нужно сохранить время, а затем делать резервное копирование (RDB). rdb в конечном итоге имеет более согласованное значение. Однако производственная среда на самом деле представляет собой скорее комбинацию этих двух вариантов.
4, часто используемые конфигурации
Конфигурация постоянства RDB
Redis будет сбрасывать снимок набора данных в файл dump.rdb. Кроме того, мы также можем изменить частоту дампа снимков сервера Redis через файл конфигурации, после открытия файла 6379.conf, мы ищем сохранить, вы можете увидеть следующую информацию о конфигурации:
Конфигурация AOF Persistence
В конфигурационном файле Redis есть три типа синхронизации, это:
Полная конфигурация:
Новый файл "appendonly.aof" будет создан в тестовом каталоге следующим образом:
|
Предыдущая статья: Экспорт таблиц datatables в excel, csv и печатьСледующая статья: SQL Server устанавливает уровень изоляции транзакций
|
发表于 2021-2-4 13:47:27
избранное0 
发表于 2021-9-22 20:26:16