Версия файла конфигурации использует Redis 4.0.14, С некоторыми параметрами нужно разобраться, чтобы понять ядро linux.Автор мало что знает о параметрах ядра linux, и я продолжу усердно работать в будущем.
1. Общие команды
1.1 ./redis-server /path/to/redis.conf
Запустите Redis и сделайте так, чтобы файл конфигурации вступил в силу.
1.2 include /path/to/local.conf
include может использовать несколько файлов конфигурации, если файлы конфигурации имеют одинаковое значение, последний переопределит первый:
include /path/to/local.conf
include /path/to/other.conf
1.3 loadmodule /path/to/my_module.so
Похоже, загружать модули бесполезно, и нужно продолжать изучение
loadmodule /path/to/my_module.so
loadmodule /path/to/other_module.so
1.4 bind 127.0.0.1
Привязать ip адрес, лучше всего привязать его для безопасности
1.5 protected-mode yes
Защищенный режим, если защищенный режим включен, а redis не привязывает ip и не устанавливает пароль, то redis принимает соединения только с 127.0.0.1.Включено по умолчанию
1.6 port 6379
Порт, установленный на 0, не будет прослушиваться
1.7 tcp-backlog 511
Ядро Linux tcp_max_syn_backlog и настройка параметров somaxconn
1.8 unixsocket /tmp/redis.sock unixsocketperm 700
сокет unix, без прослушивания по умолчанию, бесполезен
1.9 timeout 0
Закройте соединение, когда соединение простаивает в течение N секунд
1.10 tcp-keepalive 300
Включает длительное TCP-соединение. Если для него установлено значение, отличное от нуля, будет использоваться системный интервал SO_KEEPALIVE для отправки TCP ACK клиенту, чтобы предотвратить разрыв соединения. Этот полезен:
- Обнаружение мертвых соединений.
- Если между сетями есть другие сетевые устройства, вы можете подключиться, чтобы оставаться в живых
Обратите внимание, что если вы хотите использовать этот механизм для закрытия соединения, это может занять в два раза больше времени, в зависимости от конфигурации ядра.
Значение по умолчанию — 300.
2. Стандартная конфигурация
2.1 daemonize yes
По умолчанию Redis не работает в режиме демона. Если вы хотите, вы можете включить его
Обратите внимание, что если режим демона включен, он будет генерировать/var/run/redis.pidсохранить pid
2.2 supervised no
Я этого не понимаю, поэтому пока не буду переводить, обновлю, когда пойму
If you run Redis from upstart or systemd, Redis can interact with your
supervision tree. Options:
supervised no - no supervision interaction
supervised upstart - signal upstart by putting Redis into SIGSTOP mode
supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
supervised auto - detect upstart or systemd method based on
UPSTART_JOB or NOTIFY_SOCKET environment variables
Note: these supervision methods only signal "process is ready."
They do not enable continuous liveness pings back to your supervisor.
2.3 pidfile /var/run/redis_6379.pid
путь к файлу pid, по умолчанию/var/run/redis.pidЕсли в режиме без демона и путь pidfile не настроен, pid-файл не будет создан. В режиме демона
PID-файл будет создаваться всегда, и если pid-файл не настроен, будет использоваться путь по умолчанию.
2.4 loglevel notice
Укажите уровень журнала для службы:
- debug
- verbose
- notice
- warning
уведомление по умолчанию
2.5 logfile ""
Укажите имя файла журнала Redis и путь. Вы также можете установитьlogfile ""Заставить Redis записывать вывод на стандартный вывод.
Обратите внимание: если вы используете стандартный вывод, а Redis работает в режиме демона, журнал будет отправлен в /dev/null и исчезнет.
2.6 syslog-enabled no
To enable logging to the system logger, just set 'syslog-enabled' to yes,
and optionally update the other syslog parameters to suit your needs.
2.7 syslog-ident redis
Specify the syslog identity.
2.8 syslog-facility local0
Specify the syslog facility. Must be USER or between LOCAL0-LOCAL7.
2.9 databases 16
- При использовании режима кластера база данных равна 0
- Установите количество баз данных. База данных Redis по умолчанию — 0. Вы можете выбрать другую базу данных и выполнить selcet в соединении Redis.Необязательный диапазон dbid — 0~(базы данных-1), а значение по умолчанию — 0~15.
2.10 always-show-logo yes
Забавная конфигурация, всегда отображать логотип Redis
3. Связанные со снимками
3.1 Включить постоянство RDB
Включить постоянство RDB,save <seconds> <changes>
save 900 1: То есть если есть изменение через 900 секунд, сделать rdb snapshot на диск.
Чтобы отключить rdb, нужно закомментировать строку сохранения, если вы настраиваетеsave "", rdb также можно отключить.
Ниже приведены значения по умолчанию
save 900 1
save 300 10
save 60 10000
3.2 stop-writes-on-bgsave-error yes
По умолчанию, если функция моментального снимка RDB включена, а последнее сохранение моментального снимка RDB завершилось неудачно, Redis перестанет получать запросы на запись.
На самом деле это сильный способ сообщить пользователям, что функция сохранения данных ненормальна, иначе никто не узнает, что в текущей системе есть большая проблема.
Если процесс фонового сохранения работает нормально (файл rdb сохраняется нормально), тогда Redis автоматически разрешит запросы на запись.
Однако, если вы настроили мониторинг сервера Redis, вы можете отключить эту функцию, чтобы Redis мог продолжать обрабатывать запросы на запись в случае сбоя диска. просто установитеstop-writes-on-bgsave-error yes
3.3 rdbcompression yes
Используйте алгоритм LZF для сжатия файлов rdb, если вы хотите сэкономить процессор, вы можете установить для него значение no.
3.4 rdbchecksum yes
Начиная с версии redis 5.0 в конце файла rdb устанавливается проверочный код CRC64 (циклический избыточный код). Это может сыграть определенную роль в исправлении ошибок, но также
Для снижения производительности на 10% вы можете отключить эту функцию, чтобы получить максимальную производительность.
Если функция проверки файла rdb отключена, система автоматически пропустит проверку, если код подтверждения не может быть прочитан.rdbchecksum yes
3.5 dbfilename dump.rdb
имя файла rdb
3.6 dir ./
Рабочий каталог redis, файл aof, файл rdb и файл node.conf в режиме кластера redis создаются в этом каталоге.
3.7 slaveof <masterip> <masterport>
Репликация master-slave. Используйте конфигурацию slaveof, чтобы превратить экземпляр Redis в копию других серверов Redis.
- Репликация Redis master-slave является асинхронной, но вы можете настроить мастер так, чтобы он прекращал обработку запросов на запись, когда мастер не может подключиться к заданному количеству подчиненных.
- Если репликация master-slave прерывается на короткий период времени, подчиненный узел redis может выполнить частичную ресинхронизацию, вам может потребоваться установить размер невыполненной репликации.
- Автоматическая репликация master-slave без вмешательства пользователя. Если сеть прерывается, подчиненный узел автоматически повторно подключается к главному узлу и инициирует повторную синхронизацию.
3.8 masterauth <master-password>
Если главный узел имеет пароль, подчиненный узел должен настроить этот пароль, в противном случае главный узел отклоняет запрос на репликацию.
3.9 slave-serve-stale-data yes
При сбое синхронизации ведущий-ведомый подчиненный узел ведет себя двумя способами:
- Если настроено «да», подчиненный узел может продолжать отвечать на запросы клиентов.
- Если конфигурация отсутствует, подчиненный узел напрямую сообщает об ошибке «СИНХРОНИЗАЦИЯ с ведущим устройством в процессе», но команды INFO и SALVEOF могут быть выполнены.
3.10 slave-read-only yes
Вы можете настроить подчиненные узлы так, чтобы они могли обрабатывать запросы на запись. Запись некоторых временных данных на ведомое устройство иногда полезна (поскольку данные удаляются вскоре после повторной синхронизации), но также может вызвать проблемы, если они не совпадают.После версии 2.6 по умолчанию доступен только для чтения. только чтение не предназначено для ненадежных клиентов. Я просто боюсь, что клиент использует неправильную команду. Некоторые команды управления по-прежнему будут выводиться в режиме только для чтения. Если вы хотите ограничить этот тип команд, вы можете использовать rename-command для переименования этих команд управления.
3.11 repl-diskless-sync no
Стратегия синхронизации master-slave: диск или сокет.
Предупреждение: бездисковая репликация в настоящее время является экспериментальной. Когда новый ведомый узел или повторно подключенный ведомый узел не может выполнить инкрементную синхронизацию, необходимо выполнить полную синхронизацию. Файл RDB будет передан с главного узла на подчиненный двумя способами:
- с поддержкой диска: главный узел создает новый процесс для записи файла RDB на диск. Затем этот файл будет постепенно передаваться ведущим процессом нескольким подчиненным узлам.
- бездисковый: главный узел создает новый процесс и напрямую записывает файл RDB в сокетное соединение подчиненного узла, не касаясь диска от начала до конца.
Используя репликацию на диске, после создания файла RDB главный узел создаст очередь для каждого подчиненного узла для передачи файла RDB до конца передачи. Используя бездисковую репликацию, после передачи rdb параллельно может быть подключено только такое количество подчиненных узлов.Если новый подчиненный узел инициирует полную синхронизацию в это время, он может только ждать передачи предыдущих. Если используется бездисковая репликация, мастер будет ждать короткий период времени (это время настраивается) перед передачей, что позволяет прибыть нескольким ведомым устройствам. , и делать параллельные передачи.Если диск работает медленно, а пропускная способность сети особенно высока, стратегия бездисковой репликации будет работать лучше.
3.12 repl-diskless-sync-delay 5
Если бездисковая репликация включена, необходимо настроить время задержки, чтобы главный узел ожидал прибытия всех подчиненных узлов. Это очень важно, потому что после начала передачи главный узел не может ответить на полный запрос репликации нового подчиненного узла и может только ждать в очереди следующей передачи RDB, поэтому главному узлу необходимо подождать некоторое время. времени, чтобы позволить всем подчиненным узлам полностью скопировать все реплики. Единица времени задержки — секунды, по умолчанию — 5 секунд. Отключение этой функции можно установить на 0, чтобы передача всегда начиналась сразу.
3.13 repl-ping-slave-period 10
Ведомый узел отправляет эхо-запросы на главный узел через определенные промежутки времени. По умолчанию 10 секунд.
3.14 repl-timeout 60
Это значение действительно для всех трех сценариев:
- Большое количество операций ввода-вывода, ведомый узел получает время отклика ведущего узла.
- Период тайм-аута для ведомого узла, чтобы рассмотреть главный узел
- Время ожидания для главного узла для рассмотрения подчиненного узла
Обратите внимание, что это значение должно быть установлено в соотношенииrepl-ping-slave-periodБольшой, в противном случае время каждого обнаружения сердцебиения истечет.
3.15 repl-disable-tcp-nodelay no
Нужно ли закрывать TCP_NODELAY после запуска синхронизации SYNC из сокета узла? Если вы выберете YES, Redis будет использовать меньший tcppacket и меньшую пропускную способность для отправки данных на подчиненные узлы. Но это добавит некоторую задержку репликации master-slave, около 40 мс, в зависимости от конфигурации ядра Linux. Если вы выберете «Нет», задержка репликации master-slave будет немного уменьшена, но будет потреблять больше пропускной способности сети. По умолчанию мы предпочитаем низкую задержку, но установка для этого параметра значения «да» может быть хорошим решением, если сетевые условия плохие.
3.16 repl-backlog-size 1mb
Установите размер невыполненной репликации master-slave. отставание — это буфер. Когда ведущий-ведомый не синхронизирован, главный узел кэширует данные репликации ведущий-ведомый в буфер невыполненной работы.Когда подчиненный узел повторно подключается к главному узлу, подчиненный узел может получить данные инкрементной синхронизации из буфера и выполнить инкрементную синхронизацию (частичная синхронизация).синхронизация). Чем больше отставание, тем дольше подчиненному устройству разрешено отключаться. Буфер отставания создается только тогда, когда подключено хотя бы одно подчиненное устройство.
3.17 repl-backlog-ttl 3600
Если главный узел больше не подключен к подчиненному узлу, невыполненная работа этого подчиненного узла будет освобождена. Когда ведомый узел отключен, начинается отсчет сконфигурированного времени.Единица - секунды. Установите значение 0, чтобы никогда не выпускать невыполненную работу.
3.18 slave-priority 100
Эта конфигурация предназначена для режима дозорного. Когда главный узел зависает, дозорный выберет подчиненный узел с наименьшим приоритетом для повышения роли ведущего. Если значение узла redis установлено на 0, то этот узел никогда не будет повышен до главный узел. Значение по умолчанию — 100.
3.19 min-slaves-to-write 3和min-slaves-max-lag 10
Если главный узел имеет менее N подчиненных узлов в сети в течение секунд задержки, главный узел перестает получать запросы на запись. Например, если в течение 10 секунд в сети находятся как минимум 3 подчиненных узла, главный узел принимает запросы на запись.Можно использовать следующую конфигурацию:
min-slaves-to-write 3
min-slaves-max-lag 10
Установка для любой из этих двух конфигураций значения 0 отключает эту функцию. По умолчанию отключено.
3.20 slave-announce-ip 5.5.5.5иslave-announce-port 1234
Существует несколько способов отображения IP-адреса и порта подчиненного узла, который в данный момент находится в сети на главном узле. Например, секция репликации информации или выполнение команды ROLE на мастере.
#
# The listed IP and address normally reported by a slave is obtained
# in the following way:
#
# IP: The address is auto detected by checking the peer address
# of the socket used by the slave to connect with the master.
#
# Port: The port is communicated by the slave during the replication
# handshake, and is normally the port that the slave is using to
# list for connections.
#
# However when port forwarding or Network Address Translation (NAT) is
# used, the slave may be actually reachable via different IP and port
# pairs. The following two options can be used by a slave in order to
# report to its master a specific set of IP and port, so that both INFO
# and ROLE will report those values.
#
# There is no need to use both the options if you need to override just
# the port or the IP address.
#
# slave-announce-ip 5.5.5.5
# slave-announce-port 1234
4. Безопасность
4.1 requirepass foobared
Установите пароль для Redis, поскольку Redis работает быстро, злоумышленник может попробовать 150 000 паролей за одну секунду, поэтому ваш пароль должен быть очень надежным, иначе его легко атаковать.Грубая сила.
4.2 rename-command CONFIG ""和rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52
Просто используйте команду, чтобы убить полностьюrename-command CONFIG ""
rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52Команду можно изменить, чтобы программисты маркеров не использовали опасные команды.
Учтите, что если вы меняете имя команды, то все подчиненные узлы должны быть переименованы единообразно, иначе будут проблемы.
5. Клиент
5.1 maxclients 10000
Установите максимальное количество клиентов одновременно. Значение по умолчанию — 10000. При достижении максимального значения Redis закроет все новые подключения и отправит клиенту сообщение об ошибке «максимальное количество прочитанных клиентов».
6. Управление памятью
6.1 maxmemory
Установите максимальный размер памяти. Когда память достигнет максимального значения, Redis удалит ключ в соответствии с выбранной стратегией ликвидации памяти. Если redis не может удалить ключ в соответствии со стратегией исключения или стратегия исключения — noeviction, redis начнет возвращать ошибку, когда клиент отправляет запрос на запись, и память больше не будет использоваться. Однако запросы на чтение по-прежнему будут поддерживаться. Обратите внимание, что если у вас много подчиненных узлов, параметр памяти не может быть слишком большим, иначе, когда подчиненный узел инициирует полную синхронизацию, память, занимаемая выходным буфером, также находится в пределах этого диапазона maxmemory.Например, максимальное значение равно 4GB, если память уже 3G Теперь ведомый узел инициирует полную синхронизацию, а вы устанавливаете outputbuffer на 2G, так что память будет заполнена, а затем ключ будет устранен, что определенно не то, что мы хотим.
6.2 maxmemory-policy noeviction
Стратегия устранения памяти определяет, как удалять ключи, когда память Redis заполнена. Значение по умолчанию — noeviction.
- volatile-lru -> использовать приблизительное вытеснение LRU для ключей с истекшим сроком действия
- allkeys-lru -> использовать приблизительный LRU во всех ключах
- volatile-lfu -> использовать приблизительное вытеснение LFU в ключах с истекшим сроком действия
- allkeys-lfu -> использовать приблизительный LFU во всех ключах
- volatile-random -> Случайным образом удалить один из ключей с истекшим сроком действия
- allkeys-random -> Случайным образом удалить один из всех ключей
- volatile-ttl -> удалить всех, у кого истекает срок действия
- noeviction -> не удалять ни один ключ, возвращать ошибку при заполнении памяти
LRU means Least Recently Used LFU means Least Frequently Used
LRU, LFU и volatile-ttl реализованы на основе приближенно-случайных алгоритмов. Обратите внимание, что при использовании вышеуказанной стратегии, если нет подходящего ключа для удаления, Redis вернет ошибку при обработке запроса на запись.
Команда записи: set setnx setex append incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd sinter sinterstore sunion sunionstore sdiff sdiffstore zadd цинкрби zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby getset mset msetnx exec sort.
6.3 maxmemory-samples 5
LRU, LFU и алгоритмы минимального TTL не точный алгоритм, а приблизительный алгоритм (в основном для экономии памяти), Таким образом, вы можете сами пожертвовать скоростью и точностью. По умолчанию Redis проверит 5 ключей и выберет последний использованный ключ, вы можете изменить это число. Значение по умолчанию 5 дает достойные результаты. Вы будете очень близки к реальному LRU с 10, но будете использовать больше ЦП, с 3 это будет быстрее, но менее точно.
7. ЛЕНИВАЯ ЗАМОРОЗКА
В Redis есть две основные команды для удаления ключей. Одним из них является DEL, который является блокирующим удалением. DEL заставит Redis прекратить обработку новых запросов, а затем Redis будет использовать синхронный способ восстановления памяти объектов, которые должны быть удалены DEL. Если ключ соответствует очень маленькому объекту, то время выполнения DEL будет очень коротким, близким к O(1) или O(log n). Однако, если объект, соответствующий ключу, большой, Redis будет долго блокироваться для выполнения команды. Ввиду вышеуказанных проблем, Redis также предоставляет неблокирующие команды удаления, такие как UNLINK (неблокирующее DEL) и стратегии асинхронного удаления: FLUSHALL и FLUSHDB, которые могут выполнять высвобождение памяти в фоновом режиме. Время выполнения этих команд постоянное. Новый поток постепенно удаляется и освобождается в фоновом режиме.
Все упомянутые выше команды выполняются пользователем. Конкретная используемая команда зависит от сценария пользователя. Но сам redis также по некоторым причинам удаляет ключи или сбрасывает всю базу данных в памяти. Помимо активного удаления пользователя, сценарии, в которых redis самостоятельно удаляет ключи, следующие:
- Выселение памяти: после настройки политики вытеснения памяти, чтобы освободить место для новых данных, необходимо удалить данные вытеснения, иначе память взорвется.
- истекает, когда истекает срок действия ключа
- Некоторые побочные эффекты, когда ключ уже существует. Например, чтобы установить существующий ключ, нужно удалить старое значение, а затем установить новый ключ.
- Во время репликации master-slave подчиненный узел выполняет полную синхронизацию, и данные памяти перед подчиненным узлом необходимо сбросить.
Если вы хотите, чтобы в приведенных выше четырех сценариях использовалось асинхронное удаление, вы можете использовать следующую конфигурацию:
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
slave-lazy-flush no
8. AOF
8.1 appendonly no
По умолчанию Redis асинхронно сбрасывает зеркальное отображение памяти на диск (RDB). Хотя этот режим очень хорош, если машина выйдет из строя до начала дампа, некоторые данные будут потеряны. AOF (Добавить только файл) — это необязательная стратегия сохраняемости, обеспечивающая лучшую безопасность данных. С конфигурацией по умолчанию, Redis теряет не более одной секунды записи данных, и вы даже можете увеличить уровень, чтобы Redis потерял не более одной операции записи. Сохранение AOF и RDB можно включить одновременно. Если AOF включен, Redis всегда будет сначала загружать файлы AOF, потому что AOF обеспечивает более высокую доступность.
8.2 appendfilename "appendonly.aof"
Имя файла аоф.
8.3 appendfsync everysec
Вызов fsync() операционной системе сообщает операционной системе о необходимости записи буферизованных данных в выходном буфере на диск. Некоторые операционные системы будут Для реальной записи на диск некоторые будут пытаться записать как можно больше, а также могут подождать какое-то время. Redis поддерживает три способа:
- no: не вызывать активно fsync(), пусть операционная система решает, когда производить запись на диск
- всегда: fsync() вызывается после каждой операции записи, что очень медленно, но обеспечивает максимальную безопасность данных.
- каждую секунду: вызывать fsync() каждую секунду, стратегия компромисса.
По умолчанию установлено значение Everysec, которое обычно является рекомендуемой стратегией, обеспечивающей баланс между скоростью и безопасностью данных.
appendfsync always
appendfsync everysec
appendfsync no
8.4 no-appendfsync-on-rewrite no
Если для политики fsync AOF установлено значение «всегда» или «каждую секунду» и фоновый процесс сохранения (может быть, процесс bgsave RDB или процесс перезаписи AOF) выполняет много дисковых операций ввода-вывода, а в некоторых конфигурациях Linux redis может выполнять слишком длинные вызовы fsync(). В настоящее время нет способа решить эту проблему, то есть даже если запущен фоновый процесс для выполнения fsync, если уже есть процесс для выполнения fsync до этого, последующий вызов будет заблокирован. Чтобы решить эту проблему, можно использовать следующую конфигурацию: когда BGSAVE и BGREWRITEAOF уже выполняют fsync(), не запускайте новый процесс. . Если уже есть дочерний процесс, выполняющий bgsave или другие операции с диском, Redis не может продолжать запись файла aof, что эквивалентно appendsync none. На практике это означает, что может быть потеряно до 30 секунд логов. Другими словами, это приведет к потере данных.Если вы чувствительны к данным, вам следует обратить внимание на эту проблему. Если у вас есть проблемы с задержкой, вы можете установить для него значение «да», в противном случае — «нет», что может обеспечить максимальную безопасность данных и редкую потерю данных.
8.5 auto-aof-rewrite-percentage 100和auto-aof-rewrite-min-size 64mb
Автоматически перезаписывать файлы aof. Когда файл aof вырастет до определенного процента, Redis перезапишет файл aof. Redis запомнит размер файла aof после последней перезаписи (если перезапись не происходила с момента запуска, будет использоваться исходный размер aof). Этот размер будет сравниваться с размером текущего файла aof. Если текущий размер больше указанного процента, перезапишите. Кроме того, укажите минимальный размер. Если текущий файл aof меньше минимального размера, перезапись не будет запущена. Это делается для того, чтобы файл не был на самом деле очень маленьким, но Избыточные операции перезаписи при достижении процента роста. Если указанный процент равен 0, функция перезаписи aof отключена.
8.6 aof-load-truncated yes
При запуске Redis загружается файл AOF для восстановления данных в памяти, но иногда файл AOF может быть поврежден. , например, конец файла неправильный. Эта ситуация обычно вызвана простоем Redis, особенно при использовании файловой системы ext4 для монтирования. Когда параметр data=ordered не настроен. В этом случае Redis может напрямую сообщить об ошибке или максимально прочитать оставшийся читаемый файл AOF.
Если aof-load-truncated=yes, Redis все равно будет читать поврежденный файл aof, но распечатает журнал ошибок, Уведомить пользователей. Если aof-load-truncated=no, Redis сообщит об ошибке и откажется запускать службу, пользователю необходимо использовать инструмент redis-check-aof Восстановите файл aof и запустите Redis. Если файл aof выйдет из строя во время работы Redis, Redis все равно сообщит об ошибке и завершит работу. Этот вариант не спасет ситуацию.
8.7 aof-use-rdb-preamble no
Когда redis перезаписывает файл aof, redis может сначала прочитать rdb, чтобы ускорить перезапись.Когда эта опция включена, перезаписанный файл aof записывается Он состоит из двух частей: файл rdb + файл aof. Когда файл aof, загружаемый при запуске Redis, начинается с «REDIS», загружается файл rdb, а затем считываются оставшиеся файлы AOF. По умолчанию эта опция отключена.
9. LUA-скрипт
9.1 lua-time-limit 5000
Указывает максимальное количество миллисекунд для выполнения скрипта lua.
Если время выполнения достигает максимального времени, Redis зарегистрирует, что время ожидания сценария истекло, и сообщит об ошибке.
Когда время выполнения скрипта истекает, толькоSCRIPT KILLиSHUTDOWN NOSAVEдоступны команды. Первая команда может перейти к
Остановить скрипт, который не содержит команд записи. Вторая команда — единственный скрипт, который останавливает тайм-аут записи команд.
Установка lua-time-limit в 0 или отрицательное число означает, что вы не ограничиваете время выполнения, и предупреждений не будет.
10. Redis Cluster
10.1 cluster-enabled yes
Обычный экземпляр Redis не может быть членом кластера, только узел. Чтобы добавить узел в кластер Redis, необходимо установить для параметра «Cluster-enabled» значение yes.
10.2 cluster-config-file nodes-6379.conf
Все узлы кластера имеют файл конфигурации кластера. Этот файл не предназначен для ручного редактирования, он создается самим Redis. Каждый узел redis использует другой файл конфигурации кластера. Обязательно запустите несколько Redis в одной системе. Узлы кластера используют разные файлы конфигурации Redis, не перезаписывая друг друга.
10.3 cluster-node-timeout 15000
тайм-аут узла кластера — это максимальное количество миллисекунд, в течение которого узел может не отвечать. Большинство ограничений времени ожидания кратны этому значению.
10.4 cluster-slave-validity-factor 10
После выхода из строя главного узла, если данные его подчиненного узла А слишком старые (в несинхронизированном состоянии в течение длительного времени), то А не вызовет аварийное переключение, Он не будет повышен до мастера.Не существует простого способа задать политику «возраста данных» ведомого устройства.. Ниже приведены два способа оценить, не устарели ли данные подчиненного узла:
- Если несколько ведомых могут выполнять отработку отказа, они будут обмениваться сообщениями, чтобы выбрать узел с наибольшим смещением репликации (это означает, что этот узел реплицирует больше данных от ведущего узла). Каждый подчиненный узел будет вычислять свой собственный уровень смещения и задержится на некоторое время перед запуском аварийного переключения, которое зависит от их уровня смещения.
- Каждый подчиненный узел вычисляет время последнего взаимодействия с главным узлом. Это взаимодействие может быть последней операцией проверки связи, или командой записи, выдвинутой главным узлом, или последним отключением от главного узла. Если с момента последнего взаимодействия прошло слишком много времени, ведомое устройство вообще не будет инициировать аварийное переключение.
Второй пункт может быть изменен пользователем. Если время последнего взаимодействия между подчиненным узлом и ведущим узлом превышает(node-timeout * slave-validity-factor) + repl-ping-slave-period, отработка отказа не произойдет с узла.
Например, если тайм-аут узла = 30 секунд, фактор достоверности ведомого устройства = 10, период повторного пингования подчиненного устройства = 10 секунд,
Если с момента последнего взаимодействия между ведомым и ведущим прошло 310 секунд, ведомое устройство не переключится.
Увеличение фактора валидности подчиненного устройства позволит повысить уровень подчиненного узла до главного узла, если он содержит слишком старые данные.
В результате подчиненный узел никогда не может быть повышен до главного узла.
Учитывая максимальную доступность,slave-validity-factorУстановите на 0, поэтому подчиненный узел будет игнорировать последний раз с главным узлом.
Время взаимодействия, всегда старайтесь выполнять отработку отказа. (Но он все равно проделает операцию по отсрочке выборов)
10.5 cluster-migration-barrier 1
Рабы могут мигрировать к осиротевшим мастерам (у таких мастеров нет рабов). Подчиненный узел будет мигрировать к другим главным узлам-сиротам только тогда, когда исходный главный узел имеет не менее N подчиненных узлов.Заданное число N является барьером миграции, также называемым критической точкой миграции. Барьер миграции = 1 означает, что если главный узел имеет 2 подчиненных узла, Когда в кластере появляется осиротевший главный узел, на него можно мигрировать один из подчиненных узлов. Чтобы отключить миграцию ведомых устройств, установите для этого параметра большое значение, например 999. Только в режиме отладки это значение может быть установлено равным 0, не устанавливайте его случайным образом в производственной среде.
10.6 cluster-require-full-coverage yes
По умолчанию кластер Redis запрещает операции запросов, когда обнаруживает, что существует хотя бы 1 незанятый хэш-слот.
**В этом случае, если кластер частично отключен, весь кластер будет недоступен. **Только если все остальные хеш-слоты выделены.
Вам может понадобиться подмножество кластера для продолжения обслуживания, для этого просто установитеcluster-require-full-coverage noПросто
10.7 cluster-slave-no-failover no
Если для этой опции установлено значение «да», подчиненный узел никогда не будет повышен до ведущего, если главный узел выйдет из строя. Но главный узел по-прежнему может выполнять обычную отработку отказа. В сценарии с несколькими центрами обработки данных эта конфигурация более полезна.Мы надеемся, что центр обработки данных никогда не будет повышен до главного узла, в противном случае главный узел будет дрейфовать в другие центры обработки данных, что может вызвать проблемы.
11. Поддержка CLUSTER DOCKER/NAT
11.1 Кластер активно информирует ip
В некоторых конкретных сценариях развертывания автоматическое обнаружение адреса узла кластера Redis не будет выполнено, так как адрес NAT или порт пересылается (в контейнере Docker). Чтобы кластер redis нормально работал в этой среде, необходимо настроить адрес и порт статически, Конкретная конфигурация выглядит следующим образом:
- cluster-announce-ip 10.10.10.10
- cluster-announce-port 6379
- cluster-announce-bus-port 6380
Если указанные выше элементы конфигурации отсутствуют в файле конфигурации, то rediscluster будет использовать стандартный механизм автоматического обнаружения.
12. SLOW LOG
12.1 slowlog-log-slower-than 10000иslowlog-max-len 128
Медленный журнал redis — это система, которая записывает медленные операции, пока заданное время превышено, оно будет записано. Время выполнения не включает время операций ввода-вывода. Вы можете настроить медленный журнал с двумя параметрами:
- slowlog-log-slower-than 10000: единица измерения — микросекунды, 1000000 равно 1 секунде.
- slowlog-max-len 128: медленная длина, если команда больше 128, старая будет удалена, это значение не ограничено, если параметр слишком большой, он будет занимать память
Эту очередь можно сбросить с помощью команды SLOWLOG RESET.
13. LATENCY MONITOR
13.1 latency-monitor-threshold 0
Система мониторинга задержек Redis будет пробовать некоторые команды во время выполнения, чтобы помочь пользователям проанализировать причину зависаний Redis.
пройти черезLATENCYКоманда может печатать некоторые представления и отчеты.
Redis будет регистрировать только те команды, которые превышают установленное количество миллисекунд.
Если вы хотите отключить эту функцию,latency-monitor-thresholdУстановите на 0.
По умолчанию монитор закрыт.Если нет проблем с задержкой, не держите монитор все время открытым, так как эта функция может сильно повлиять на производительность.
Вы также можете включить эту функцию во время выполнения, выполнив эту команду:CONFIG SET latency-monitor-threshold <milliseconds>
14. Уведомление о событии
14.1 notify-keyspace-events ""
Redis может уведомлять клиентов публикации/подписки, когда событие происходит в определенном ключевом пространстве. Если функция уведомления о событии включена, и клиент выполняет операцию удаления с ключом «foo», через pub/sub будут отправлены два сообщения:
- PUBLISH keyspace@0:foo del
- PUBLISH keyevent@0:del foo
Можно выбрать уровень событий для уведомлений Redis. Все уровни отмечены одним символом:
- K Keyspace events, published with keyspace@ prefix.
- E Keyevent events, published with keyevent@ prefix.
- g Generic commands (non-type specific) like DEL, EXPIRE, RENAME, ...
- $ String commands
- l List commands
- s Set commands
- h Hash commands
- z Sorted set commands
- x Expired events (events generated every time a key expires)
- e Evicted events (events generated when a key is evicted for maxmemory)
- A Alias for g$lshzxe, so that the "AKE" string means all the events.
Параметр notify-keyspace-events принимает несколько символов или 0 строк. Если для параметра notify-keyspace-events установлено значение Пустая строка эквивалентна отключению уведомлений.
15. Расширенные настройки
15.1 конфигурация, связанная с ziplist
Когда объем данных невелик, хеш-значения могут использовать более эффективную структуру данных. Этот порог можно установить с помощью следующей конфигурации:
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
15.2 list-max-ziplist-size -2
list также может использовать специальную кодировку для экономии памяти. Базовая структура данных списка — это список быстрого доступа, каждый из которых Все узлы – это ziplist. Этот параметр в основном используется для управления размером каждого ziplist. Если настроено положительное число, Тогда максимальное количество узлов в каждом зиплисте быстрого списка не будет превышать настроенное значение. Если вы настраиваете отрицательное число, вы указываете длину ziplist:
- -5: max size: 64 Kb <-- not recommended for normal workloads
- -4: max size: 32 Kb <-- not recommended
- -3: max size: 16 Kb <-- probably not recommended
- -2: max size: 8 Kb <-- good
- -1: max size: 4 Kb <-- good
Конфигурации -2 и -1 являются наиболее производительными
15.3 list-compress-depth 0
Списки также можно сжимать. Нижний слой списка представляет собой двусвязный список, а глубина сжатия показывает, сколько узлов, кроме головных и конечных узлов, не будет сжато. Головной и хвостовой узлы никогда не сдавливаются.
- 0: отключить сжатие
- 1: означает, что все внутренние узлы, кроме головы и хвоста, будут сжаты [голова]->узел->узел->...->узел->[хвост] [голова], [хвост] не будут сжаты, внутренние узлы будут сжаты.
- 2: [голова]->[следующий]->узел->узел->...->узел->[предыдущий]->[хвост] head , head->next , tail->prev и tail четыре узла не будут сжаты, Другие узлы между ними будут сжаты.
- 3: [head]->[next]->[next]->node->node->...->node->[prev]->[prev]->[tail]
и так далее
15.4 set-max-intset-entries 512
Набор также поддерживает внутреннюю оптимизацию.Когда все внутренние элементы набора являются десятичными целыми числами ниже 64 бит, базовая реализация набора будет использовать intset, При добавлении элементов большего размера, чем set-max-intset-entries, базовая реализация преобразует intset в dict.
15.5 zset-max-ziplist-entries 128иzset-max-ziplist-value 64
Когда внутренние элементы zset больше 128 или значение превышает 64 байта, нижний слой zset больше не будет использовать ziplist.
15.6 hll-sparse-max-bytes 3000
Предел разреженного представления HyperLogLog в байтах. Это ограничение включает 16-байтовый заголовок. Когда HyperLogLog использует разреженное представление, если Когда этот предел будет достигнут, он будет преобразован в компактное представление. Установка этого значения выше 16000 бессмысленна, потому что 16000 более удобна для памяти при компактном представлении. Рекомендуемое значение — 0~3000, что позволяет сэкономить место и сократить время выполнения команды PFADD. Если места в памяти больше, чем ресурсов ЦП, , вы можете увеличить это значение до 10000.
15.7 activerehashing yes
Динамическое повторное хеширование использует 1 миллисекунду из каждых 100 миллисекунд для активного повторного хеширования хеш-таблицы Redis. Реализация хэш-таблицы Redis использует значение по умолчанию Ленивый режим повторного хеширования: чем больше вы работаете с хеш-таблицей, тем больше шагов повторного хеширования будет выполнено, поэтому, если служба простаивает, Операция повторного хеширования никогда не заканчивается, а хеш-таблица занимает больше памяти. По умолчанию динамический повторный хэш будет выполняться 10 раз в секунду для освобождения памяти.
15.8 Конфигурация клиентского буфера передачи
Ограничение выходного буфера клиента используется для принудительного отключения клиентского соединения, когда клиент не может вовремя прочитать данные буфера , Redis подумает, что клиент не работает, и отключится.
Это ограничение может быть установлено в соответствии с тремя различными ситуациями:
- нормальный -> обычные клиенты включают клиент MONITOR
- подчиненный -> клиенты подчиненного узла
- pubsub -> pub/sub clients
Синтаксис настройки следующий:client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds>
- жесткий лимит: если данные в буфере достигают значения жесткого лимита, Redis напрямую разрывает соединение с клиентом.
- мягкое ограничение и мягкие секунды: если данные в буфере достигают значения мягкого ограничения, соединение между Redis и клиентом по-прежнему будет сохранять мягкие секунды.
По умолчанию обычные клиенты не имеют этого ограничения, потому что обычные клиенты сначала выполняют команду для получения данных, которых не существует. Redis активно переводит данные в нормальное состояние. Если вы установите три 0 для представления неограниченного количества, подключение навсегда. Но это может разорвать память.
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit slave 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
15.9 client-query-buffer-limit 1gb
Буфер запросов клиента буферизует новые команды. По умолчанию используется фиксированный номер, чтобы избежать десинхронизации протокола.
15.10 proto-max-bulk-len 512mb
В протоколе redis большинство запросов являются строками, и значение по умолчанию не будет превышать 512 МБ. Конечно, вы можете изменить это ограничение.
15.11 hz 10
Redis вызывает некоторые внутренние функции для выполнения многих фоновых задач, таких как закрытие соединений с истекшим сроком действия, очистка ключей с истекшим сроком действия, которые никогда не запрашивались, и т. д. Не все фоновые задачи выполняются с одинаковой частотой, Redis использует параметр hz, чтобы решить, как часто выполнять задачи. По умолчанию hz равно 10. Увеличение этого значения будет потреблять больше ресурсов процессора, когда Redis простаивает, но также сделает Redis более активным для очистки истечения срока действия. ключ, и операция очистки тайм-аута соединений будет более точной. Диапазон этого значения составляет 1~500, но не рекомендуется устанавливать значение больше 100. Большинству пользователей следует использовать значение по умолчанию или до 100.
15.12 aof-rewrite-incremental-fsync yes
Когда дочерний процесс перезаписывает файл aof, если эта функция включена, Redis будет активно отправлять каждые 32 МБ данных в файл. это Фиксируйте файлы на диск поэтапно, чтобы избежать больших всплесков задержки.
15.13 Настройка LFU
Стратегию устранения redis lfu можно настроить. Счетчик LFU каждого ключа имеет всего 8 ключей, а максимальное значение равно 255, поэтому Redis использует алгоритм логарифмического роста, основанный на вероятности, Не каждый доступ к ключу будет counter+1. При доступе к ключу counter+1 выполняется следующим образом:
- Сгенерировать случайное число R от 0 до 1
- Расчетная вероятность P=1/(old_value*lfu_log_factor+1)
- r
По умолчанию lfu-log-factor равен 10. Ниже приведены темпы роста при различных факторах.Вы можете видеть, что чем меньше фактор, тем быстрее рост:
+--------+------------+------------+------------+------------+------------+
| factor | 100 hits | 1000 hits | 100K hits | 1M hits | 10M hits |
+--------+------------+------------+------------+------------+------------+
| 0 | 104 | 255 | 255 | 255 | 255 |
+--------+------------+------------+------------+------------+------------+
| 1 | 18 | 49 | 255 | 255 | 255 |
+--------+------------+------------+------------+------------+------------+
| 10 | 10 | 18 | 142 | 255 | 255 |
+--------+------------+------------+------------+------------+------------+
| 100 | 8 | 11 | 49 | 143 | 255 |
+--------+------------+------------+------------+------------+------------+
注意: 上表结论是执行以下命令得出的:
redis-benchmark -n 1000000 incr foo
redis-cli object freq foo
注意 2: counter初始值是5,否则key很快就被淘汰了
Я не совсем понимаю lfu-decay-time, я добавлю его после тщательного исследования.
lfu-log-factor 10 lfu-decay-time 1
16. Динамическая дефрагментация (в экспериментальной стадии, еще не переведена)
# WARNING THIS FEATURE IS EXPERIMENTAL. However it was stress tested
# even in production and manually tested by multiple engineers for some
# time.
#
# What is active defragmentation?
# -------------------------------
#
# Active (online) defragmentation allows a Redis server to compact the
# spaces left between small allocations and deallocations of data in memory,
# thus allowing to reclaim back memory.
#
# Fragmentation is a natural process that happens with every allocator (but
# less so with Jemalloc, fortunately) and certain workloads. Normally a server
# restart is needed in order to lower the fragmentation, or at least to flush
# away all the data and create it again. However thanks to this feature
# implemented by Oran Agra for Redis 4.0 this process can happen at runtime
# in an "hot" way, while the server is running.
#
# Basically when the fragmentation is over a certain level (see the
# configuration options below) Redis will start to create new copies of the
# values in contiguous memory regions by exploiting certain specific Jemalloc
# features (in order to understand if an allocation is causing fragmentation
# and to allocate it in a better place), and at the same time, will release the
# old copies of the data. This process, repeated incrementally for all the keys
# will cause the fragmentation to drop back to normal values.
#
# Important things to understand:
#
# 1. This feature is disabled by default, and only works if you compiled Redis
# to use the copy of Jemalloc we ship with the source code of Redis.
# This is the default with Linux builds.
#
# 2. You never need to enable this feature if you don't have fragmentation
# issues.
#
# 3. Once you experience fragmentation, you can enable this feature when
# needed with the command "CONFIG SET activedefrag yes".
#
# The configuration parameters are able to fine tune the behavior of the
# defragmentation process. If you are not sure about what they mean it is
# a good idea to leave the defaults untouched.
# Enabled active defragmentation
# activedefrag yes
# Minimum amount of fragmentation waste to start active defrag
# active-defrag-ignore-bytes 100mb
# Minimum percentage of fragmentation to start active defrag
# active-defrag-threshold-lower 10
# Maximum percentage of fragmentation at which we use maximum effort
# active-defrag-threshold-upper 100
# Minimal effort for defrag in CPU percentage
# active-defrag-cycle-min 25
# Maximal effort for defrag in CPU percentage
# active-defrag-cycle-max 75