В веб-серверах высокая доступность относится к времени, когда к серверу можно получить нормальный доступ, а мерой является то, как долго могут предоставляться нормальные услуги (99,9%, 99,99%, 99,999% и т. д.).
Однако в контексте Redis значение высокой доступности представляется более широким: помимо обеспечения предоставления обычных услуг (таких как разделение master-slave, технология быстрого аварийного восстановления) также необходимо учитывать расширение емкость данных и безопасность данных без потерь.

В Redis технологии для достижения высокой доступности в основном включают сохраняемость, репликацию ведущий-подчиненный, сигнальные устройства и кластерные кластеры.
● Постоянство : Постоянство — это простейший метод обеспечения высокой доступности (иногда даже не классифицируемый как метод обеспечения высокой доступности). Его основная функция — резервное копирование данных, т. е. сохранение данных на жестком диске во избежание потери данных из-за выход из процесса.
● Репликация «главный-ведомый» : репликация «главный-подчиненный» является основой высокой доступности Redis, Sentinels и кластеры основаны на репликации «главный-подчиненный» для достижения высокой доступности. Репликация master-slave в основном реализует резервное копирование данных на нескольких машинах, а также балансировку нагрузки для операций чтения и простое восстановление после сбоев. Недостатки: восстановление после сбоя не может быть автоматизировано; операции записи не могут быть сбалансированы по нагрузке; емкость хранилища ограничена одной машиной.
● Sentry : на основе репликации master-slave Sentinel реализует автоматическое устранение сбоев. Дефекты: Операции записи не могут быть сбалансированы по нагрузке; емкость хранилища ограничена одной машиной.
● Кластерный кластер . Благодаря кластеризации Redis решает проблему, связанную с тем, что операции записи не могут быть сбалансированы по нагрузке, а емкость хранилища ограничена одной машиной, и реализует относительно полное решение высокой доступности.

Второе: постоянство Redis

1. Функция сохранения

Функция сохранения: Redis является базой данных в памяти, и данные хранятся в памяти.Чтобы избежать безвозвратной потери данных после аварийного завершения процесса Redis из-за таких причин, как сбой питания сервера, необходимо регулярно сохранять данные в Redis в той или иной форме (данные или команды) из памяти на жесткий диск; при следующем перезапуске Redis используйте постоянный файл для восстановления данных. Кроме того, постоянные файлы можно скопировать в удаленное место для аварийного резервного копирования.

2. Redis предоставляет два метода сохранения

● Постоянство RDB : принцип заключается в том, чтобы сохранять записи базы данных Reids в памяти на диск через регулярные промежутки времени.
● Постоянство AOF: (добавлять только файл): принцип заключается в том, чтобы записывать журнал операций Reids в файл в добавленном виде, аналогично бинарному журналу MySQL.

Поскольку производительность сохраняемости AOF в реальном времени выше, то есть меньше данных теряется при неожиданном завершении процесса, поэтому AOF в настоящее время является основным методом сохраняемости, но сохраняемость RDB по-прежнему имеет свое место.

3. Постоянство RDB

Постоянство RDB относится к сохранению моментального снимка данных в текущем процессе в памяти на жесткий диск в течение заданного интервала времени (поэтому его также называют постоянством моментального снимка), сохраненному в двоичном сжатии, а суффикс сохраненного файла — rdb ; когда Redis перезапустится, вы сможете прочитать файл моментального снимка, чтобы восстановить данные.

(1) Условия срабатывания

Активация сохраняемости RDB делится на ручную и автоматическую.

(1.1) Ручной триггер

И команда save, и команда bgsave могут создавать файлы RDB.
Команда сохранения заблокирует процесс сервера Redis до тех пор, пока не будет создан файл RDB.Во время блокировки сервера Redis сервер не может обрабатывать запросы команд.
Команда bgsave создает дочерний процесс, который отвечает за создание RDB-файла, а родительский процесс (то есть основной процесс Redis) продолжает обрабатывать запросы.

Во время выполнения команды bgsave только дочерний процесс fork будет блокировать сервер, но для команды сохранения весь процесс будет блокировать сервер, поэтому сохранение в основном заброшено, и следует избегать использования сохранения в онлайн-режиме. среда.

(1.2) Автоматический триггер

При автоматическом запуске сохранения RDB Redis также выберет bgsave вместо сохранения для сохранения.

Наиболее распространенным случаем автоматического запуска команды save mn
является передача save mn в файле конфигурации, чтобы указать, что когда n изменений произойдет в течение m секунд, bgsave будет запущен для создания моментального снимка.

vim /usr/local/redis/conf/redis.conf
--433行--RDB默认保存策略
# save 3600 1 300 100 60 10000
#表示以下三个save条件满足任意一个时，都会引起bgsave的调用
save 3600 1 ：当时间到3600秒时，如果redis数据发生了至少1次变化，则执行bgsave
save 300 10 ：当时间到300秒时，如果redis数据发生了至少10次变化，则执行bgsave
save 60 10000 ：当时间到60秒时，如果redis数据发生了至少10000次变化，则执行bgsave

--454行--是否开启RDB文件压缩
rdbcompression yes
--481行--指定RDB文件名
dbfilename dump.rdb
--504行--指定RDB文件和AOF文件所在目录
dir /usr/local/redis/data

(1.3) Другие автоматические спусковые механизмы

Помимо сохранения mn, есть и другие ситуации, которые запускают bgsave:
● В сценарии репликации ведущий-ведомый, если подчиненный узел выполняет операцию полного копирования, главный узел выполнит команду bgsave и отправит файл rdb подчиненному узлу. .
● Когда выполняется команда выключения , сохранение RDB выполняется автоматически.

4. Процесс исполнения

(1) Родительский процесс Redis сначала решает: выполняет ли он в настоящее время сохранение или дочерний процесс bgsave/bgrewriteaof, если он выполняется, команда bgsave вернется напрямую. Дочерние процессы bgsave/bgrewriteaof не могут выполняться одновременно, в основном из-за соображений производительности: два параллельных дочерних процесса одновременно выполняют большое количество операций записи на диск, что может вызвать серьезные проблемы с производительностью.
(2) Родительский процесс выполняет операцию fork для создания дочернего процесса.Во время этого процесса родительский процесс блокируется, и Redis не может выполнять какие-либо команды от клиента.(3)После разветвления родительского процесса команда bgsave возвращает Сообщение «
Фоновое сохранение началось» и больше не блокируется. Родительский процесс может отвечать на другие команды.
(4) Дочерний процесс создает файл RDB, генерирует временный файл снимка на основе снимка памяти родительского процесса и атомарно заменяет исходный файл. после завершения
(5) Дочерний процесс отправляет сигнал родительскому процессу о завершении, и родительский процесс обновляет статистику.

5. Загружать при запуске

Загрузка файла RDB выполняется автоматически при запуске сервера, и для этого не требуется специальной команды. Однако, поскольку AOF имеет более высокий приоритет, когда AOF включен, Redis будет отдавать приоритет загрузке файлов AOF для восстановления данных; только когда AOF отключен, файлы RDB будут обнаружены и загружены автоматически при запуске сервера Redis. Сервер блокируется при загрузке файла RDB до завершения загрузки.
Когда Redis загружает файл RDB, он проверяет файл RDB.Если файл поврежден, в журнале будет напечатана ошибка, и Redis не запустится.

6. Стойкость АОФ

Постоянство RDB предназначено для записи данных процесса в файлы, а постоянство AOF — для записи каждой команды записи и удаления, выполняемой Redis, в отдельный файл журнала, и операция запроса не будет записана; при перезапуске Redis снова выполните команду файла AOF в для восстановления данных.
По сравнению с RDB, AOF имеет лучшую производительность в режиме реального времени, поэтому он стал основным решением для сохраняемости.

(1) Включите АОФ

Redis服务器默认开启RDB，关闭AOF；要开启AOF，需要在配置文件中配置：
vim /usr/local/redis/conf/redis.conf
--1380行--修改，开启AOF
appendonly yes
--1407行--指定AOF文件名称
appendfilename "appendonly.aof"
--1505行--是否忽略最后一条可能存在问题的指令
aof-load-truncated yes


systemctl restart redis-server.service

7. Процесс исполнения

Поскольку каждая команда записи Redis должна быть записана, AOF не нужно запускать.Ниже описан процесс выполнения AOF.

Процесс выполнения AOF включает в себя:
команду append (добавление) : добавление команды записи Redis в буфер aof_buf;
● запись файла (запись) и синхронизацию файлов (синхронизация) : синхронизация содержимого aof_buf на жесткий диск;
● перезапись файла (перезапись). ) : Периодически перезаписывайте файл AOF для достижения цели сжатия.

(1) Добавление инструкции (добавить)

Сначала Redis добавляет команду записи в буфер , а не записывает файл напрямую, главным образом для того, чтобы каждый раз не записывать команду непосредственно на жесткий диск, в результате чего ввод-вывод на жесткий диск становится узким местом нагрузки Redis.
Формат добавления команды — это формат протокола запроса команды Redis.Это обычный текстовый формат, который имеет преимущества хорошей совместимости, хорошей читабельности, простоты обработки, простоты работы и отсутствия вторичных накладных расходов. В файле AOF, за исключением команды select, используемой для указания базы данных (например, select 0 для выбора базы данных 0), которая добавляется Redis, все остальные являются командами записи, отправляемыми клиентом.

(2) Запись файлов (запись) и синхронизация файлов (синхронизация)

Redis предоставляет различные стратегии файлов синхронизации для области кэша AOF.Стратегия включает функцию записи и функцию fsync операционной системы.Чтобы
повысить эффективность записи файла, в современных операционных системах, когда пользователь вызывает функцию записи для записи данных в файл, операция Система обычно временно сохраняет данные в буфере памяти и записывает данные из буфера на жесткий диск только тогда, когда буфер заполнен или превышает указанный предел времени. Хотя такого рода операции повышают эффективность, они также создают проблемы с безопасностью: если компьютер выключается, данные в буфере памяти будут потеряны, поэтому система также предоставляет функции синхронизации, такие как fsync и fdatasync, которые могут заставить операционную систему для немедленного обновления данных в буфере Данные записываются на жесткий диск для обеспечения безопасности данных.

AOF缓存区的同步文件策略存在三种同步方式，它们分别是：
vim /usr/local/redis/conf/redis.conf
--1439--
●appendfsync always： 命令写入aof_buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命。

●appendfsync no： 命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证。

●appendfsync everysec： 命令写入aof_buf后调用系统write操作，write完成后线程返回；fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置。

(3) Перезапись файлов (перезапись)

Со временем сервер Redis выполняет все больше и больше команд записи, и файл AOF будет становиться все больше и больше; слишком большие файлы AOF не только повлияют на нормальную работу сервера, но и заставят восстановление данных занять слишком много времени.

Перезапись файла относится к периодической перезаписи файла AOF для уменьшения размера файла AOF. Следует отметить, что перезапись AOF предназначена для преобразования данных в процессе Redis в команды записи и синхронизации с новым файлом AOF; она не будет выполнять никаких операций чтения или записи в старом файле AOF!

Еще одно замечание о перезаписи файлов: для сохраняемости AOF настоятельно рекомендуется, но не обязательно перезаписывать файлы; даже без перезаписи файлов данные могут сохраняться и запускаться в Redis. Время импорта; поэтому в некоторых реальностях автоматическая перезапись файлов будет выключен, а затем запланировано выполняться в определенное время каждый день через запланированное задание.

(3.1) Причина, по которой перезапись файлов может сжимать файлы AOF

●Устаревшие данные больше не будут записываться в файл
●Недопустимые команды больше не будут записываться в файл: например, некоторые данные повторно устанавливаются (set mykey v1, set mykey v2), некоторые данные удаляются (set myset v1, дель myset) и т. д. .
● Несколько команд можно объединить в одну: например, sadd myset v1, sadd myset v2, sadd myset v3 можно объединить в sadd myset v1 v2 v3.

Из приведенного выше содержания видно, что, поскольку команды, выполняемые AOF, после перезаписи сокращаются, перезапись файла может не только уменьшить пространство, занимаемое файлом, но и ускорить скорость восстановления.

(3.2) Триггер перезаписи файла делится на ручной и автоматический триггер.

● Запуск вручную : вызов команды bgrewriteaof напрямую, выполнение этой команды чем-то похоже на bgsave: оба подпроцесса ветвления выполняют определенную работу, и оба блокируются только при ветвлении.
● Автоматический запуск : автоматически выполнять BGREWRITEAOF, задав параметр auto-aof-rewrite-min-size и auto-aof-rewrite-percentage. Только при одновременном выполнении двух параметров auto-aof-rewrite-min-size и auto-aof-rewrite-percentage автоматически запускается перезапись AOF, то есть операция bgrewriteaof.

vim /usr/local/redis/conf/redis.conf
--1480--
●auto-aof-rewrite-percentage 100	：当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作
●auto-aof-rewrite-min-size 64mb ：当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF	


关于文件重写的流程，有两点需要特别注意：(1)重写由父进程fork子进程进行；(2)重写期间Redis执行的写命令，需要追加到新的AOF文件中，为此Redis引入了aof_rewrite_buf缓存。

(3.3) Процесс перезаписи файла

(1) Родительский процесс Redis сначала оценивает, существует ли дочерний процесс, выполняющий в данный момент bgsave/bgrewriteaof. Если он существует, команда bgrewriteaof вернется напрямую.Если есть команда bgsave, дождитесь завершения выполнения bgsave перед ее выполнением.
(2) Родительский процесс выполняет операцию fork для создания дочернего процесса, и родительский процесс блокируется во время этого процесса.
(3.1) После разветвления родительского процесса команда bgrewriteaof возвращает сообщение «Фоновое добавление, только перезапись файла началась» и больше не блокирует родительский процесс и может отвечать на другие команды. Все команды записи Redis по-прежнему записываются в буфер AOF и синхронизируются с жестким диском в соответствии со стратегией appendfsync, чтобы обеспечить правильность исходного механизма AOF.
(3.2) Поскольку в операции форка используется технология копирования при записи, дочерний процесс может совместно использовать данные памяти только во время операции форка. Поскольку родительский процесс все еще отвечает на команду, Redis использует буфер перезаписи AOF (aof_rewrite_buf) для сохранения этой части данных, чтобы предотвратить потерю этой части данных во время создания нового файла AOF. Другими словами, во время выполнения bgrewriteaof команды записи Redis одновременно добавляются в два буфера, aof_buf и aof_rewrite_buf.
(4) В соответствии со снимком памяти дочерний процесс записывает в новый файл AOF в соответствии с правилами слияния команд.
(5.1) После того, как дочерний процесс записывает новый файл AOF, он отправляет сигнал родительскому процессу, и родительский процесс обновляет статистическую информацию, которую можно просмотреть с помощью сохранения информации.
(5.2) Родительский процесс записывает данные из буфера перезаписи AOF в новый файл AOF, тем самым обеспечивая соответствие состояния базы данных, сохраненного в новом файле AOF, текущему состоянию сервера.
(5.3) Замените старый файл новым файлом AOF, чтобы завершить перезапись AOF.

8. Загружать при запуске

Когда AOF включен, Redis сначала загружает файл AOF для восстановления данных при запуске; только когда AOF выключен, он загружает файл RDB для восстановления данных.
Когда AOF включен, но файл AOF не существует, он не будет загружен, даже если файл RDB существует.
Когда Redis загружает файл AOF, он проверяет файл AOF.Если файл поврежден, в журнале будет напечатана ошибка, и Redis не запустится. Однако, если конец файла AOF неполный (внезапный простой машины и т. д. может легко привести к тому, что конец файла будет неполным), а параметр aof-load-truncated включен, в журнал будет выведено предупреждение. , Redis игнорирует конец файла AOF, и запуск выполняется успешно. Параметр aof-load-truncated включен по умолчанию.

9. Преимущества и недостатки RDB и AOF

● Преимущества сохраняемости RDB : файлы RDB компактны, небольшого размера, быстро передаются по сети и подходят для полного копирования; скорость восстановления намного выше, чем у AOF. Конечно, одним из наиболее важных преимуществ RDB по сравнению с AOF является относительно небольшое влияние на производительность.

Недостатки : фатальным недостатком файлов RDB является то, что метод сохранения моментальных снимков данных определяет невозможность сохранения в реальном времени.Сегодня, когда данные становятся все более и более важными, большая потеря данных часто недопустима, поэтому сохраняемость AOF стать мейнстримом. Кроме того, файлы RDB должны соответствовать определенному формату и иметь плохую совместимость (например, старые версии Redis несовместимы с новыми версиями файлов RDB).
Для сохраняемости RDB, с одной стороны, основной процесс Redis будет заблокирован, когда bgsave выполняет операцию ветвления; с другой стороны, запись данных на жесткий диск дочерним процессом также вызовет нагрузку на ввод-вывод.

● Сохраняемость AOF
Преимущество AOF, аналогичное сохранению RDB, заключается в том, что он поддерживает сохранение второго уровня и хорошую совместимость, а недостатком является большой размер файла, низкая скорость восстановления и значительное влияние на производительность.
Для постоянства AOF значительно увеличивается частота записи данных на жесткий диск (второй уровень в стратегии Everysec), увеличивается нагрузка на ввод-вывод, и это может даже вызвать дополнительные проблемы с блокировкой AOF.
Перезапись файла AOF аналогична bgsave RDB, и будет блокировка во время разветвления и давления ввода-вывода дочернего процесса. Условно говоря, поскольку AOF чаще записывает данные на жесткий диск, это окажет большее влияние на производительность основного процесса Redis.

Третье: управление производительностью Redis

1. Просмотр использования памяти Redis

127.0.0.1:6379> info memory

2. Скорость фрагментации памяти

mem_fragmentation_ratio : Скорость фрагментации памяти. mem_fragmentation_ratio = used_memory_rss / used_memory
used_memory_rss : это память, запрошенная Redis у операционной системы.
used_memory : это память, занимаемая данными в Redis.
used_memory_peak : пиковое значение использования памяти Redis.

(1) Как происходит фрагментация памяти?

Redis имеет собственный внутренний диспетчер памяти для управления приложением и освобождения памяти, чтобы повысить эффективность использования памяти.
Когда значение в Redis удаляется, память не освобождается напрямую и не возвращается операционной системе, а внутреннему диспетчеру памяти Redis.
При подаче заявки на память в Redis сначала проверьте, достаточно ли памяти в вашем собственном диспетчере памяти.
Этот механизм Redis улучшает коэффициент использования памяти, но при этом часть памяти в Redis не используется сама по себе, но не освобождается, что приводит к фрагментации памяти.

(2) Отслеживание скорости фрагментации памяти очень важно для понимания производительности ресурсов экземпляра Redis.

Скорость фрагментации памяти обычно находится в диапазоне от 1 до 1,5. Это значение указывает на то, что скорость фрагментации памяти относительно низкая, а также указывает на то, что Redis не обменивается памятью.
Если скорость фрагментации памяти превышает 1,5, это означает, что Redis потребляет 150 % фактической требуемой физической памяти, из которых 50 % — это скорость фрагментации памяти.
Если скорость фрагментации памяти ниже 1, это означает, что выделение памяти Redis превышает физическую память, и операционная система обменивается памятью. Необходимо увеличить доступную физическую память или уменьшить использование памяти Redis.

(3) Решить проблему высокой скорости фрагментации

Если ваша версия Redis ниже 4.0, вам нужно ввести команду сохранения при завершении работы в инструменте redis-cli, чтобы позволить базе данных Redis выполнить операцию сохранения и закрыть службу Redis, а затем перезапустить сервер. После перезапуска сервера Redis Redis вернет бесполезную память операционной системе, и скорость фрагментации снизится.

Redis4.0版本开始，可以在不重启的情况下，线上整理内存碎片。
config set activedefrag yes     #自动碎片清理，内存就会自动清理了。
memory purge					#手动碎片清理

3. Использование памяти

Если использование памяти экземпляром Redis превышает максимально доступную память, операционная система начнет обмен памятью и пространством подкачки.

Способы избежать подкачки памяти:
● Выберите и установите экземпляр Redis в соответствии с размером кэшированных данных.
● Максимально используйте структуру данных Hash для хранения.
● Установите срок действия ключа.

4. Внутренний ключ восстановления

Стратегия исключения данных из памяти обеспечивает разумное распределение ограниченных ресурсов памяти redis.

При достижении заданного максимального порога необходимо выбрать стратегию утилизации ключа, которая по умолчанию запрещает удаление.

vim /usr/local/redis/conf/redis.conf
--1149--
maxmemory-policy noenviction
●volatile-lru：使用LRU算法从已设置过期时间的数据集合中淘汰数据(移除最近最少使用的key，针对设置了TTL的key)
●volatile-ttl：从已设置过期时间的数据集合中挑选即将过期的数据淘汰（移除最近过期的key）
●volatile-random：从已设置过期时间的数据集合中随机挑选数据淘汰（在设置了TTL的key里随机移除）
●allkeys-lru：使用LRU算法从所有数据集合中淘汰数据（移除最少使用的key，针对所有的key）
●allkeys-random：从数据集合中任意选择数据淘汰（随机移除key）
●noenviction：禁止淘汰数据（不删除直到写满时报错）

5. Другие ограничения

● maxclients
устанавливает количество клиентов, к которым Redis может подключаться одновременно.
10000 клиентов по умолчанию.
Если этот предел достигнут, Redis отклонит новые запросы на подключение и отправит в ответ «максимальное количество клиентов достигнуто» этим запросчикам подключения.

● рекомендуется установить maxmemory , иначе память будет переполнена и сервер будет недоступен. Устанавливает объем памяти, который может использовать Redis. Как только будет достигнут верхний предел использования памяти, Redis попытается удалить внутренние данные, и правила удаления могут быть указаны maxmemory-policy. Если redis не может удалить данные в памяти по правилам удаления, или если «удаление не разрешено», то redis будет возвращать сообщения об ошибках для тех инструкций, которые необходимо применить к памяти, таких как SET, LPUSH и т.д. Но на команды без применения памяти он все равно будет нормально реагировать, например GET и так далее. Если ваш редис является основным редисом (указывает на то, что в кластере редисов есть master-slave), то при установке верхнего предела использования памяти вам нужно зарезервировать некоторое пространство памяти в системе для кеша очереди синхронизации, только если вы установите "не удалять" В данном случае этот фактор можно не учитывать.

● maxmemory-samples
задает количество выборок.И алгоритм LRU, и алгоритм минимального TTL не являются точными алгоритмами, а оценочными значениями, поэтому вы можете установить размер выборки.По умолчанию Redis проверит столько-то ключей и выберет LRU-один .
Как правило, устанавливается число от 3 до 7. Чем меньше значение, тем менее точна выборка, но меньше потребление производительности.

Четыре: репликация Redis master-slave

1. Введение в репликацию Redis master-slave

Репликация master-slave относится к копированию данных одного сервера Redis на другие серверы Redis. Первый называется главным узлом (Master), а второй — подчиненным узлом (Slave), репликация данных односторонняя, только от главного узла к подчиненному узлу.

По умолчанию каждый сервер Redis является главным узлом, и главный узел может иметь несколько подчиненных узлов (или не иметь подчиненных узлов), но подчиненный узел может иметь только один главный узел.

2. Роль репликации master-slave

● Избыточность данных . Репликация ведущий-ведомый реализует горячее резервное копирование данных, что является методом избыточности данных, отличным от сохраняемости.
● Восстановление после сбоя : при возникновении проблемы на ведущем узле подчиненный узел может предоставить услуги по быстрому устранению сбоя, что на самом деле является своего рода резервированием служб.
● Балансировка нагрузки : на основе репликации ведущий-ведомый в сочетании с разделением чтения и записи главный узел может предоставлять услуги записи, а подчиненные узлы могут предоставлять услуги чтения (то есть приложение подключается к главному узлу при записи Redis). данные, и приложение подключается к подчиненному узлу при чтении данных Redis), чтобы разделить нагрузку на сервер; особенно в сценарии меньшего количества записей и большего чтения разделение нагрузки чтения через несколько подчиненных узлов может значительно увеличить параллелизм сервера Redis. .
● Краеугольный камень высокой доступности : в дополнение к вышеперечисленным функциям репликация «главный-подчиненный» также является основой для реализации сигнальных систем и кластеров, поэтому репликация «главный-подчиненный» является основой высокой доступности Redis.

3. Процесс репликации master-slave

(1) Если запущен процесс ведомого компьютера, он отправит команду «sync command» на главный компьютер, чтобы запросить синхронное соединение.
(2) Будь то первое подключение или повторное подключение, главный компьютер запустит фоновый процесс для сохранения моментального снимка данных в файл данных (выполнение операции rdb), а главный компьютер также запишет все команды для изменения данных и кэширования. их в середине файла данных.
(3) После того, как фоновый процесс завершит операцию кэширования, главный компьютер отправит файл данных на ведомый компьютер, ведомый компьютер сохранит файл данных на жесткий диск, а затем загрузит его в память, а затем главный компьютер машина изменит все файлы данных. Операция отправляется на подчиненную конечную машину вместе. Если ведомое устройство выходит из строя и приводит к простою, оно автоматически переподключится после возвращения в нормальное состояние.
(4) После того, как главный компьютер получает соединение от ведомого компьютера, он отправляет свой полный файл данных на ведомый компьютер. сохраните файлы данных, а затем отправьте их на все подчиненные машины, чтобы убедиться, что все подчиненные машины работают нормально.

4. Создайте репликацию Redis master-slave

(1) Установите Redis

//环境准备
systemctl stop firewalld
systemctl disable firewalld
setenforce 0
sed -i 's/enforcing/disabled/' /etc/selinux/config

#修改内核参数
vim /etc/sysctl.conf
vm.overcommit_memory = 1
net.core.somaxconn = 2048

sysctl -p


//安装redis
yum install -y gcc gcc-c++ make

tar zxvf /opt/redis-7.0.9.tar.gz -C /opt/
cd /opt/redis-7.0.9
make
make PREFIX=/usr/local/redis install
#由于Redis源码包中直接提供了 Makefile 文件，所以在解压完软件包后，不用先执行 ./configure 进行配置，可直接执行 make 与 make install 命令进行安装。

#创建redis工作目录
mkdir /usr/local/redis/{conf,log,data}

cp /opt/redis-7.0.9/redis.conf /usr/local/redis/conf/

useradd -M -s /sbin/nologin redis
chown -R redis.redis /usr/local/redis/

#环境变量
vim /etc/profile 
PATH=$PATH:/usr/local/redis/bin		#增加一行

source /etc/profile


//定义systemd服务管理脚本
vim /usr/lib/systemd/system/redis-server.service
[Unit]
Description=Redis Server
After=network.target

[Service]
User=redis
Group=redis
Type=forking
TimeoutSec=0
PIDFile=/usr/local/redis/log/redis_6379.pid
ExecStart=/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis.conf
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

(2) Измените файл конфигурации Redis (операция главного узла)

vim /usr/local/redis/conf/redis.conf
bind 0.0.0.0									#87行，修改监听地址为0.0.0.0
protected-mode no								#111行，将本机访问保护模式设置no
port 6379										#138行，Redis默认的监听6379端口
daemonize yes									#309行，设置为守护进程，后台启动
pidfile /usr/local/redis/log/redis_6379.pid		#341行，指定 PID 文件
logfile "/usr/local/redis/log/redis_6379.log"	#354行，指定日志文件
dir /usr/local/redis/data						#504行，指定持久化文件所在目录
#requirepass abc123								#1037行，可选，设置redis密码
appendonly yes									#1380行，开启AOF


systemctl restart redis-server.service

(3) Измените файл конфигурации Redis (операция подчиненного узла)

vim /usr/local/redis/conf/redis.conf
bind 0.0.0.0									#87行，修改监听地址为0.0.0.0
protected-mode no								#111行，将本机访问保护模式设置no
port 6379										#138行，Redis默认的监听6379端口
daemonize yes									#309行，设置为守护进程，后台启动
pidfile /usr/local/redis/log/redis_6379.pid		#341行，指定 PID 文件
logfile "/usr/local/redis/log/redis_6379.log"	#354行，指定日志文件
dir /usr/local/redis/data						#504行，指定持久化文件所在目录
#requirepass abc123								#1037行，可选，设置redis密码
appendonly yes									#1380行，开启AOF
replicaof 192.168.80.10 6379					#528行，指定要同步的Master节点IP和端口
#masterauth abc123								#535行，可选，指定Master节点的密码，仅在Master节点设置了requirepass


systemctl restart redis-server.service

(4) Проверьте эффект ведущий-ведомый

Просмотр журналов на главном узле

tail -f /usr/local/redis/log/redis_6379.log 
Replica 192.168.80.11:6379 asks for synchronization
Replica 192.168.80.12:6379 asks for synchronization
Synchronization with replica 192.168.80.11:6379 succeeded
Synchronization with replica 192.168.80.12:6379 succeeded

Проверьте подчиненные узлы на главном узле

redis-cli info replication
# Replication
role:master
connected_slaves:2
slave0:ip=192.168.80.11,port=6379,state=online,offset=1246,lag=0
slave1:ip=192.168.80.12,port=6379,state=online,offset=1246,lag=1

Пятое: режим Redis Sentinel

1. Метод технологии переключения master-slave

Метод технологии переключения master-slave заключается в следующем: когда сервер не работает, необходимо вручную переключить ведомую машину на ведущую, что требует ручного вмешательства, что не только требует много времени и труда, но и вызывает сервисное обслуживание. быть недоступным в течение определенного периода времени. Чтобы устранить недостатки репликации master-slave, существует дозорный механизм.

Основная функция Sentinel: основанная на репликации master-slave, Sentinel вводит автоматическое аварийное переключение главного узла.

2. Принцип дозорного режима

Sentinel: используется 分布式系统для выбора нового мастера с помощью механизма голосования主从结构中的每台服务器进行监控 и подключения всех подчиненных устройств к новому мастеру в случае сбоя . Итак, номер всего работающего кластера . 【】哨兵不得少于三个节点哨兵必须是奇数

3. Роль дозорного режима

Мониторинг : Sentinel будет постоянно проверять, нормально ли работают главный узел и подчиненные узлы.
Автоматическое переключение при сбое : если главный узел не работает нормально, Sentinel запускает операцию автоматического переключения после отказа, обновляя один из подчиненных узлов вышедшего из строя главного узла до нового главного узла и заменяя другие подчиненные узлы новым главным узлом. .
Уведомления (напоминания) : Sentinels могут отправлять результаты аварийного переключения клиентам.

Структура Sentinel состоит из двух частей: узлов Sentinel и узлов данных.

Дозорный узел : дозорная система состоит из одного или нескольких дозорных узлов, которые представляют собой специальные узлы Redis, не хранящие данные.
Узлы данных : как главные, так и подчиненные узлы являются узлами данных.

4. Отказоустойчивый механизм

1. Дозорный узел регулярно отслеживает неисправность главного узла.Каждый
дозорный узел отправляет команду ping главному узлу, подчиненному узлу и своему дозорному узлу каждую 1 секунду для обнаружения сердцебиения.

Если мастер-узел не отвечает в течение определенного промежутка времени или отвечает сообщением об ошибке, то часовой субъективно (в одностороннем порядке) сочтет, что главный узел находится в автономном режиме.
Когда более половины дозорных узлов считают, что главный узел субъективно находится в автономном режиме, объективно он находится в автономном режиме.

2. Когда главный узел выйдет из строя , дозорный узел реализует механизм выбора с помощью алгоритма плота (алгоритма выбора), чтобы совместно выбрать дозорный узел в качестве лидера, отвечающего за обработку аварийного переключения и уведомление главного узла, поэтому весь кластер, на котором работает дозорный Количество узлов не должно быть меньше 3.

3. Аварийное переключение выполняется ведущим дозорным узлом, процесс выглядит следующим образом :

Обновите подчиненный узел до нового главного узла и позвольте другим подчиненным узлам указывать на новый главный узел;
Если исходный главный узел восстанавливается, он становится подчиненным узлом и указывает на новый главный узел.
Сообщите клиенту, что основной узел был заменен.

Важно отметить, что целевой автономный режим — это концепция, уникальная для главного узла; если подчиненный узел и контрольный узел выходят из строя после того, как контрольный узел субъективно отключил их, последующие объективные операции автономного режима и аварийного переключения выполняться не будут.

Failover : Аналогичен гангстерскому обществу.В нем будет несколько начальников филиалов, а затем будет самый большой начальник, который регулярно ходит к самому большому начальнику на встречи.Если самый большой начальник ошибается и его увольняют, остальные их заменит один из боссов филиалов, и тогда, даже если первоначальный самый большой босс захочет позже восстановить свою первоначальную личность, он не может быть восстановлен напрямую, и выборы все равно потребуются.

Выбор главного узла:

1. Отфильтруйте неработоспособные (офлайновые) подчиненные узлы, которые не ответили на пинг-ответы дозорного устройства.
2. Выберите подчиненный узел с конфигурацией с наивысшим приоритетом в файле конфигурации. (replica-priority, значение по умолчанию 100)
3. Выбрать ведомый узел с наибольшим смещением репликации, то есть наиболее совершенная репликация.

Начало сторожевого режима зависит от режима ведущий-ведомый, поэтому режим ведущего-ведомого должен быть установлен перед выполнением сторожевого режима.

5. Создайте контрольный режим Redis

(1) Строительство окружающей среды

На основе репликации master-slave построена

гостья	Операционная система	айпи адрес	Программное обеспечение/установочный пакет/инструменты
Владелец	CentOS7	192.168.10.27	Redis-7.0.9.tar.gz
Раб1	CentOS7	192.168.10.28	Redis-7.0.9.tar.gz
Раб2	CentOS7	192.168.10.29	Redis-7.0.9.tar.gz

(2) Изменить файл конфигурации режима Redis Sentinel (все операции узла)

systemctl stop firewalld
setenforce 0


cp /opt/redis-7.0.9/sentinel.conf /usr/local/redis/conf/
chown redis.redis /usr/local/redis/conf/sentinel.conf

vim /usr/local/redis/conf/sentinel.conf
protected-mode no									#6行，关闭保护模式
port 26379											#10行，Redis哨兵默认的监听端口
daemonize yes										#15行，指定sentinel为后台启动
pidfile /usr/local/redis/log/redis-sentinel.pid		#20行，指定 PID 文件
logfile "/usr/local/redis/log/sentinel.log"			#25行，指定日志存放路径
dir /usr/local/redis/data							#54行，指定数据库存放路径
sentinel monitor mymaster 192.168.80.10 6379 2		#73行，修改 指定该哨兵节点监控192.168.80.10:6379这个主节点，该主节点的名称是mymaster，最后的2的含义与主节点的故障判定有关：至少需要2个哨兵节点同意，才能判定主节点故障并进行故障转移
#sentinel auth-pass mymaster abc123					#76行，可选，指定Master节点的密码，仅在Master节点设置了requirepass
sentinel down-after-milliseconds mymaster 3000		#114行，判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel failover-timeout mymaster 180000			#214行，同一个sentinel对同一个master两次failover之间的间隔时间（180秒）

(3) Запустить сторожевой режим

所有服务器
先启master，再启slave
cd /usr/local/redis/conf/
redis-sentinel sentinel.conf &

(4) Просмотр дозорной информации

redis-cli -p 26379 info Sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
sentinel_running_scripts:0
sentinel_scripts_queue_length:0
sentinel_simulate_failure_flags:0
master0:name=mymaster,status=ok,address=192.168.80.10:6379,slaves=2,sentinels=3

(5) Моделирование неисправности

[root@master ~]# ps aux | grep redis
avahi      6123  0.0  0.1  62276  2076 ?        Ss   15:07   0:00 avahi-daemon: running [redis.local]
root       9917  0.1  0.4 156452  7860 ?        Ssl  18:46   0:06 /usr/local/redis/bin/redis-server 0.0.0.0:6379
root      10707  0.2  0.4 153892  7828 ?        Ssl  19:58   0:01 redis-sentinel *:26379 [sentinel]
root      10934  0.0  0.0 112728   988 pts/0    S+   20:08   0:00 grep --color=auto redis

[1]+  完成                  redis-sentinel sentinel.conf

Убейте номер процесса redis-сервера на главном узле

kill -9 4547 #Номер процесса redis-сервера на главном узле

(6) Результат проверки

tail -f /usr/local/redis/log/sentinel.log

redis-cli -p 26379 INFO Sentinel

Шесть: кластерный режим Redis

1. Концепция кластера Redis

Кластер, а именно Redis Cluster, представляет собой решение для распределенного хранения, представленное в Redis 3.0.

Кластер состоит из нескольких групп узлов (Nodes), и данные Redis распределяются между этими узлами. Узлы в кластере делятся на главные узлы и подчиненные узлы: только главный узел отвечает за обслуживание запросов на чтение и запись и информацию о кластере; подчиненные узлы только реплицируют данные и информацию о состоянии главного узла .

2. Роль кластера

(1) Раздел данных: Раздел данных (или фрагментация данных) является основной функцией кластера.

Кластер распределяет данные по нескольким узлам.С одной стороны, он преодолевает ограничение размера памяти одной машины Redis, и емкость хранилища значительно увеличивается, с другой стороны, каждый мастер-узел может предоставлять внешние сервисы чтения и записи, что значительно улучшает отзывчивость кластера.
Объем автономной памяти Redis ограничен, о чем упоминалось во введении о сохраняемости и репликации master-slave; в результате ведомый узел не может предоставлять услуги в течение длительного времени, а буфер репликации ведущего узла может переполниться во время фаза полной репликации.

(2) Высокая доступность: кластер поддерживает репликацию master-slave и автоматическое переключение при сбое главного узла (аналогично Sentinel).

В случае сбоя любого узла кластер по-прежнему может предоставлять внешние службы.

3. Фрагментация данных кластера Redis

Кластер Redis представляет концепцию хеш-слотов
Кластер Redis имеет 16384 хеш-слота (пронумерованных от 0 до 16383).
Каждый набор узлов в кластере отвечает за часть хеш-слотов.
После того, как каждый ключ проходит проверку CRC16, возьмите остаток 16384, чтобы определить, какой хеш-слот разместить.По этому значению найдите узел, соответствующий соответствующему слоту, а затем напрямую и автоматически перейдите к соответствующему узлу для операций доступа.

#以3个节点组成的集群为例：
节点A包含0到5460号哈希槽
节点B包含5461到10922号哈希槽
节点C包含10923到16383号哈希槽

#Redis集群的主从复制模型
集群中具有A、B、C三个节点，如果节点B失败了，整个集群就会因缺少5461-10922这个范围的槽而不可以用。
为每个节点添加一个从节点A1、B1、C1整个集群便有三个Master节点和三个slave节点组成，在节点B失败后，集群选举B1位为的主节点继续服务。当B和B1都失败后，集群将不可用

4. Создайте режим кластера Redis

Для кластера Redis обычно требуется 6 узлов, 3 ведущих и 3 подчиненных. Для удобства здесь все узлы моделируются на одном сервере:
различаются номерами портов: 3 номера портов главного узла: 6001/6002/6003, соответствующие номера портов подчиненного узла: 6004/6005/6006.

(1) На всех шести серверах необходимо установить базу данных Redis.

cd /usr/local/redis/
mkdir -p redis-cluster/redis600{1..6}

for i in {1..6}
do
cp /opt/redis-7.0.9/redis.conf /usr/local/redis/redis-cluster/redis600$i
cp /opt/redis-7.0.9/src/redis-cli /opt/redis-7.0.9/src/redis-server /usr/local/redis/redis-cluster/redis600$i
done

(2) Включите функцию кластера

#其他5个文件夹的配置文件以此类推修改，注意6个端口都要不一样。
cd /usr/local/redis/redis-cluster/redis6001
vim redis.conf
#bind 127.0.0.1									#87行，注释掉bind项，默认监听所有网卡
protected-mode no								#111行，关闭保护模式
port 6001										#138行，修改redis监听端口
daemonize yes									#309行，设置为守护进程，后台启动
pidfile /usr/local/redis/log/redis_6001.pid		#341行，指定 PID 文件
logfile "/usr/local/redis/log/redis_6001.log"	#354行，指定日志文件
dir ./											#504行，指定持久化文件所在目录
appendonly yes									#1379行，开启AOF
cluster-enabled yes								#1576行，取消注释，开启群集功能
cluster-config-file nodes-6001.conf				#1584行，取消注释，群集名称文件设置
cluster-node-timeout 15000						#1590行，取消注释群集超时时间设置

(3) Запустите узел redis

#启动redis节点
分别进入那六个文件夹，执行命令：redis-server redis.conf ，来启动redis节点
cd /usr/local/redis/redis-cluster/redis6001
redis-server redis.conf

for d in {1..6}
do
cd /usr/local/redis/redis-cluster/redis600$d
./redis-server redis.conf
done

ps -ef | grep redis

#启动集群
redis-cli --cluster create 127.0.0.1:6001 127.0.0.1:6002 127.0.0.1:6003 127.0.0.1:6004 127.0.0.1:6005 127.0.0.1:6006 --cluster-replicas 1

#六个实例分为三组，每组一主一从，前面的做主节点，后面的做从节点。下面交互的时候 需要输入 yes 才可以创建。
--replicas 1 表示每个主节点有1个从节点。

(4) Тестовый кластер

#测试群集
redis-cli -p 6001 -c					#加-c参数，节点之间就可以互相跳转
127.0.0.1:6001> cluster slots			#查看节点的哈希槽编号范围
1) 1) (integer) 5461
   2) (integer) 10922									#哈希槽编号范围
   3) 1) "127.0.0.1"
      2) (integer) 6003									#主节点IP和端口号
      3) "fdca661922216dd69a63a7c9d3c4540cd6baef44"
   4) 1) "127.0.0.1"
      2) (integer) 6004									#从节点IP和端口号
      3) "a2c0c32aff0f38980accd2b63d6d952812e44740"
2) 1) (integer) 0
   2) (integer) 5460
   3) 1) "127.0.0.1"
      2) (integer) 6001
      3) "0e5873747a2e26bdc935bc76c2bafb19d0a54b11"
   4) 1) "127.0.0.1"
      2) (integer) 6006
      3) "8842ef5584a85005e135fd0ee59e5a0d67b0cf8e"
3) 1) (integer) 10923
   2) (integer) 16383
   3) 1) "127.0.0.1"
      2) (integer) 6002
      3) "816ddaa3d1469540b2ffbcaaf9aa867646846b30"
   4) 1) "127.0.0.1"
      2) (integer) 6005
      3) "f847077bfe6722466e96178ae8cbb09dc8b4d5eb"

127.0.0.1:6001> set name zhangsan
-> Redirected to slot [5798] located at 127.0.0.1:6003
OK

127.0.0.1:6001> cluster keyslot name					#查看name键的槽编号

redis-cli -p 6004 -c
127.0.0.1:6004> keys *							#对应的slave节点也有这条数据，但是别的节点没有
1) "name"


redis-cli -p 6001 -c cluster nodes

5. Добавляйте узлы в кластер Cluster и динамически расширяйте емкость

1. Создайте новый главный узел

redis 5的集群支持在有负载的情况下增加节点动态扩容。

已有集群为6个节点127.0.0.1:6001 - 127.0.0.1:6006，3组主从节点。现要增加第4组主从节点127.0.0.1:6007，127.0.0.1:6008
创建一个新的主节点127.0.0.1:6007。命令里需要指定一个已有节点以便于获取集群信息，本例是指定的127.0.0.1:6001

redis-cli -p 6001 --cluster add-node 127.0.0.1:6007 127.0.0.1:6001
或
redis-cli -p 6001
cluster meet 127.0.0.1 6007
cluster meet 127.0.0.1 6008

2. Установите главный-ведомый узел

将127.0.0.1:6008创建为127.0.0.1:6007的从节点。命令里需要指定一个已有节点以便于获取集群信息和主节点的node ID
redis-cli -p 6001 --cluster add-node 127.0.0.1:6008 127.0.0.1:6001 --cluster-slave --cluster-master-id e44678abed249e22482559136bf45280fd3ac281
或
redis-cli -p 6008
cluster replicate e44678abed249e22482559136bf45280fd3ac281

3. Выделите слоты для новых узлов

新加入的主节点是没有槽数的，只有初始化集群的时候，才会根据主的数据分配好，如新增的主节点，需要手动分配
redis-cli -p 6007 --cluster reshard 127.0.0.1:6001 --cluster-from e1a033e07f0064e6400825b4ddbcd6680c032d10 --cluster-to e44678abed249e22482559136bf45280fd3ac281 --cluster-slots 1000 --cluster-yes
或
redis-cli -p 6007 --cluster reshard 127.0.0.1:6001
How many slots do you want to move (from 1 to 16384)? 1000                    #指定转移槽的数量
What is the receiving node ID? e44678abed249e22482559136bf45280fd3ac281       #指定接收槽数量的主节点node ID
Please enter all the source node IDs.
Type 'all' to use all the nodes as source nodes for the hash slots.
Type 'done' once you entered all the source nodes IDs.
Source node #1: e1a033e07f0064e6400825b4ddbcd6680c032d10           #指定分配的主节点node ID
Source node #2: done                                               #输入完毕，开始转移

4. Просмотр состояния кластера

redis-cli -p 6001 cluster nodes

Подведем итог

1. Оптимизация Redis
Включите сохранение AOF,
установите config set activedefrag yes, чтобы включить автоматическую очистку фрагментов памяти, или регулярно выполняйте очистку памяти для очистки фрагментов памяти,
установите стратегию удаления данных из памяти maxmemory-policy и убедитесь, что использование памяти не превышает Максимальный объем памяти системы
maxmemory и установить Redis, чтобы занимать наибольшее значение памяти, maxmemory-samples устанавливает количество выборок для алгоритма стратегии исключения
. Используйте тип данных Hash для хранения данных как можно больше. Если Hash содержит мало полей, то это Тип данных будет занимать очень мало места
Установите время истечения срока действия ключа Упростите имя ключа и значение ключа и контролируйте размер значения ключа
Установите config set requirepass, чтобы включить проверку пароля
Разумно установите максимальное значение maxclient параметр номера соединения (10000), номер очереди соединений tcp-backlog (1024) и время ожидания соединения timeout (30000) для
развертывания репликации master-slave, резервного копирования данных и использования дозорных или кластерных решений для достижения высокой доступности.

2. Согласованность двойной записи между кешем и базой данных.
Сначала обновите базу данных, затем удалите кеш + срок действия кеша, после истечения срока действия данных будет запрос на чтение для непосредственного обновления кеша из базы данных.

3. Лавина кеша.
Большая площадь кеша истекает одновременно, поэтому последующие запросы будут падать на БД, вызывая коллапс БД из-за большого количества запросов за короткий промежуток времени.

Решение.
Время истечения кэшированных данных задается случайным образом, чтобы предотвратить одновременное истечение срока действия большого объема данных.
Как правило, когда объем параллелизма не особенно велик, наиболее часто используемым решением является блокировка и очередь.
Добавьте соответствующий тег кеша к каждым кэшированным данным, запишите, является ли кеш недействительным, и обновите кеш данных, если тег кеша недействителен.

4. Разбивка кеша
Данные в кеше отсутствуют, а в базе данных есть (обычно время кеша истекает) В это время из-за большого количества одновременных пользователей данные не читаются в кеше чтения на момент одно и то же время, и данные извлекаются из базы данных одновременно, вызывая нагрузку на базу данных Мгновенное увеличение, вызывая чрезмерное давление.
В отличие от лавины кеша, разбивка кеша означает одновременную проверку одного и того же фрагмента данных.Лавина кеша означает, что срок действия разных данных истек, и многие данные не могут быть найдены, поэтому выполняется поиск в базе данных.

Решение
Установите для данных точки доступа неограниченный срок действия.
Добавить мьютекс, мьютекс

5. Проникновение в кеш.
Данные, которых нет ни в кеше, ни в БД, приводят к тому, что все запросы падают на БД, что приводит к коллапсу БД из-за большого количества запросов за короткий промежуток времени.

Решение:
добавить проверку на уровне интерфейса, такую как проверка аутентификации пользователя, id для базовой проверки и прямой перехват id<=0;
данные, которые нельзя получить из кэша, не извлекаются из базы данных, и их также можно использовать в это время Запишите пару ключ-значение как ключ-ноль, а время действия кэша можно установить на короткое время, например 30 секунд (слишком длинное значение приведет к тому, что его нельзя будет использовать в нормальных условиях). Это может помешать атакующему пользователю повторно использовать один и тот же идентификатор для грубой силы
фильтра Блума для хэширования всех возможных данных в достаточно большое растровое изображение, а данные, которые не должны существовать, будут перехвачены этим растровым изображением, тем самым избегая давления запроса на базовый система хранения

Высокая доступность и оптимизация Redis

1: Высокая доступность Redis