Привет, Редис, у меня есть к тебе несколько вопросов.
Привет, Редис! Мы вместе уже много лет. От смутного понимания до сих пор мы глубоко интегрировались. Я всегда знал и всегда помнил о твоей доброте. Можешь задать мне еще несколько вопросов, чтобы помочь мне понять глубже? Чтобы узнать тебя.
1. Что такое коммуникационный протокол Redis
Коммуникационный протокол Redis — это текстовый протокол. Да, сервер Redis взаимодействует с клиентом через протокол RESP (протокол сериализации REdis). Да, текстовый протокол тратит трафик впустую, но его преимущества интуитивно понятны, очень просты и обеспечивают высокую производительность синтаксического анализа. Ну, нам не нужен специальный клиент Redis для связи с Redis только через telnet или текстовые потоки.
Формат клиентской команды:
- Простые строки, начинающиеся со знака плюс "+"
- Ошибки, начинайте со знака "-" минус
- Целое число типа Integer, начинающееся с двоеточия ":"
- Массовые строки, начинающиеся со знака доллара "$"
- Тип массива Массивы, начинающиеся со звездочки "*"
set hello abc
一个简单的文本流就可以是redis的客户端
простое резюме
Подробнее см.Redis.IO/topics/pro T…, документация Redis считает, что простая реализация, быстрый анализ и интуитивное понимание являются наиболее важными аспектами использования текстового протокола RESP.Возможно, что текстовый протокол вызовет определенное количество потерь трафика, но он быстрый и простой в производительность и функционирование Процесс баланса и координации.
2. Есть ли в Redis ACID-транзакции?
Чтобы узнать, имеет ли Redis транзакцию, это на самом деле очень просто. Проверьте документ на официальном сайте Redis и найдите:
атомарность
Атомарность транзакции означает, что база данных выполняет несколько операций в транзакции в целом, а сервис либо выполняет все операции в транзакции, либо ни одна из операций не выполняется.
очередь транзакций
Сначала разберитесь, что после того, как redis запустит мультикоманду транзакции, redis сгенерирует очередь для этой транзакции, и команды каждой операции будут вставлены в эту очередь по порядку.Команды в этой очереди не будут выполняться сразу, зная, что Команда exec отправляет транзакцию. Все команды в очереди будут выполняться только один раз.
Как видно из приведенного выше примера, при успешном выполнении транзакции команды в транзакции выполняются в порядке очереди и выполняются монопольно. Но еще одна особенность атомарности заключается в том, что либо все они выполняются успешно, либо все они терпят неудачу, что является откатом в нашей традиционной БД.
Когда мы выполняем неудачную транзакцию:
Можно обнаружить, что даже если в середине произошел сбой, операция set abc x была выполнена, и откат не выполняется, Строго говоря, redis не является атомарным.
Почему redis не поддерживает откат
На самом деле это связано с позиционированием и дизайном Redis. Давайте сначала посмотрим, почему наш mysql может поддерживать откат. Это все еще связано с записью журналов. Redis будет выполнять журналирование aof после завершения операции. Позиционирование журналов aof предназначено только для записи Командная запись mysql, а mysql имеет идеальный журнал повторов, а журнал повторов и binlog записываются до фиксации транзакции.
Вы должны знать, что mysql стоит дорого, чтобы иметь возможность отката.Сценарий приложения Redis более высокопроизводителен по сравнению с высоким параллелизмом, поэтому Redis выбирает более простой и быстрый способ обработки транзакций без отката, что также соответствует сценарию.
последовательность
Непротиворечивость транзакции означает, что если база данных непротиворечива до выполнения транзакции, то после ее выполнения, независимо от того, была ли транзакция успешной, база данных также должна быть непротиворечивой.
С точки зрения Redis существует два уровня: один — обеспечивают ли ошибки выполнения согласованность, а другой — имеет ли Redis механизм для обеспечения согласованности во время простоя.
Обеспечивают ли ошибки выполнения согласованность
Тем не менее выполнение ошибочной транзакции выявит и обработает ошибки во время выполнения транзакции.Эти ошибки не изменят базу данных и не повлияют на согласованность транзакции.
Влияние простоя на согласованность
На данный момент игнорируя распределенное решение Redis с высокой доступностью, давайте сначала проверим, может ли восстановление во время простоя удовлетворить ограничения целостности данных с автономной машины.
Независимо от схемы сохранения rdb или aof файл rdb или файл aof можно использовать для восстановления данных, тем самым восстанавливая базу данных до согласованного состояния.
Пересмотренная согласованность ❓❓
Вышеизложенная точка зрения на влияние ошибок выполнения и времени простоя на согласованность взята из книги Хуанга Цзяньхуна «Проектирование и реализация Redis». При чтении этой главы все еще возникают некоторые сомнительные моменты. В конечном счете, Redis не является реляционной базой данных. , Если приходит только выражение ACID Говорят, что согласованность — это бизнес, который переходит из состояния A через транзакцию в состояние B, не разрушая всех видов ограничений, и говоря только о redis, что, очевидно, является удовлетворительной согласованностью.
Но если к разговору о непротиворечивости добавить бизнес, например, А переходит в Б, А уменьшается на 10 юаней, а Б увеличивается на 10 юаней, потому что у redis нет отката, у него нет атомарности в традиционном понимании, поэтому из Redis также не должен иметь традиционной согласованности.
На самом деле, здесь просто краткое обсуждение того, как связать концепцию Redis с традиционной ACID. Возможно, это может быть связано с тем, что я слишком много думаю. Бессмысленно использовать ACID традиционной реляционной базы данных для аудита Redis. Redis не имеет намерение реализовать его ACID-транзакции.
изоляция
Изоляция относится к тому факту, что в базе данных одновременно выполняются несколько транзакций, каждая транзакция не влияет друг на друга, а результаты транзакций, выполняемых в параллельном состоянии, и транзакций, выполняемых последовательно, абсолютно одинаковы.
Поскольку операция Redis является однопоточной, она имеет естественный механизм изоляции. Когда Redis выполняет транзакцию, сервер Redis гарантирует, что транзакция не будет прервана во время выполнения транзакции. Поэтому транзакции Redis всегда сериализуются. также изолирован.
Упорство
Долговечность транзакции означает, что при выполнении транзакции результаты, полученные при выполнении транзакции, сохраняются в постоянном хранилище.Даже если сервер остановится после выполнения транзакции, результаты выполненной транзакции не будут потеряны.
Наличие у Redis постоянства зависит от режима сохранения Redis.
- Работа с чистой памятью, без сохранения, после остановки службы все данные будут потеряны.
- Режим RDB, в зависимости от политики RDB, bgsave будет выполняться только тогда, когда политика будет удовлетворена, асинхронное выполнение не гарантирует, что Redis имеет постоянство
- В режиме aof, только если для appendfsync установлено значение always, программа будет синхронно сохраняться на диск при выполнении команд.
(Установите для appendfsync значение always, теоретически возможно сохраниться, но обычно это не делается)
простое резюме
- Redis обладает определенной атомарностью, но не поддерживает откат
- Redis не имеет концепции согласованности в ACID (или Redis спроектирован так, чтобы игнорировать это).
- редис изолирован
- Redis может гарантировать постоянство с помощью определенных стратегий.
Redis и ACID созданы исключительно с точки зрения пользователей Redis разработан для обеспечения простоты и высокой производительности и не будет ограничиваться традиционным ACID.
3. Как реализованы оптимистичные блокирующие часы Redis?
Когда мы упоминаем оптимистическую блокировку, на ум приходит CAS (Compare And Set).Операция CAS состоит из трех операндов — значения ячейки памяти (V), ожидаемого исходного значения (A) и нового значения (B). Если значение ячейки памяти совпадает с ожидаемым исходным значением, процессор автоматически обновляет ячейку новым значением. В противном случае процессор ничего не делает.
Используя реализацию наблюдения в транзакции Redis, часы будут смотреть на 1 или более ключевых переменных до начала транзакции, когда транзакция выполняется. То есть, когда сервер получает команду exec для последовательного выполнения кэшированной очереди транзакций, Redis проверит, были ли изменены ключевые переменные с момента просмотра.
Оптимистичный механизм блокировки Java AtomicXXX
В java мы часто используем некоторые оптимистичные параметры блокировки, такие как AtomicXXX, как реализованы эти механизмы, и является ли Redis таким же, как механизм реализации CAS в java, давайте посмотрим на класс Atomic в java, мы преследуем исходный код, вы можете видим, что за ним на самом деле находится Unsafe_CompareAndSwapObject
Вы видите, что compareAndSwapObject — нативный метод, вам нужно продолжить его трассировку, вы можете скачать исходный код или открыть его.hg.openjdk.java.net/jdk8u/
cmpxchg
Можно обнаружить, что прослеживается до конечного cas, «сравнить и изменить», изначально две семантики, но, наконец, инструкция ЦП cmpxchg завершена, cmpxchg — это команда инструкции ЦП, а не несколько инструкций ЦП, поэтому она не будет многопоточной. планирование прерывается, поэтому можно гарантировать, что операция CAS будет атомарной операцией. Конечно, у механизма cmpxchg на самом деле есть проблема ABA и множественных повторных попыток, которая здесь не обсуждается.
часовой механизм redis
Часы Redis также используют cmpxchg? Между ними есть сходство и некоторые различия в использовании. В часах Redis нет проблемы с aba и нет механизма множественных повторных попыток. Одно из наиболее важных отличий:
Выполнение транзакции Redis на самом делесериалДа, просто следуйте исходному коду: Извлеченный исходный код может быть немного запутанным, но было бы хорошо просто обобщить диаграмму структуры данных и простую блок-схему, а затем посмотреть на исходный код, и он станет намного яснее.
место хранения
redisDb хранит структуру dcit из наблюдаемых_ключей, а значение каждого наблюдаемого ключа представляет собой структуру связанного списка, в которой хранится набор флагов клиента Redis.
Процесс
Каждый раз, когда watch, multi, exec будет запрашивать структуру watch_keys для оценки, и каждый раз, когда вы касаетесь клавиши watch, она будет помечена как CLIENT_DIRTY_CAS.
Поскольку все транзакции в Redis являются последовательными, при условии, что и клиент A, и клиент B следят за одним и тем же ключом, когда клиент A выполняет сенсорную модификацию или A завершает выполнение первым, клиент A будет удален из этого наблюдаемого_ключа. Удалите список этого ключа, а затем установите все клиенты в этом списке в CLIENT_DIRTY_CAS.Когда последующий клиент B начинает выполняться, он определяет, что его состояние CLIENT_DIRTY_CAS, и discardTransaction завершает транзакцию.
простое резюме
Реализация cmpxchg в основном использует инструкции процессора.Похоже, что две операции завершаются одной инструкцией процессора, поэтому они не будут прерваны многопоточностью. Механизм наблюдения Redis использует однопоточный механизм самого Redis и принимает структуру данных и последовательный процесс Watch_keys для реализации механизма оптимистичной блокировки.
4. Как сохраняется Redis
Существует два механизма сохранения redis: первый — RDB, то есть моментальный снимок, и моментальный снимок — это полная резервная копия, которая сериализует бинарные файлы и сохраняет все данные памяти redis на диск. Другим является дневник aof, который записывает журнал записей инструкций по изменению операций с данными, который может быть аналогичен бинарному журналу mysql.Дата aof будет только бесконечно увеличиваться с течением времени.
При восстановлении redis моментальный снимок rdb можно восстановить, непосредственно прочитав диск, но для восстановления aof необходимо повторить все инструкции по эксплуатации, этот процесс может быть очень долгим.
RDB
Redis может создавать моментальные снимки RDB двумя способами. Один из них — сохранение. Поскольку Redis — это один процесс и один поток, если вы используете непосредственное сохранение, Redis выполнит огромную файловую операцию ввода-вывода. Поскольку один процесс и один поток неизбежно заблокируют онлайн Для бизнеса, как правило, save не используется напрямую, но используется bgsave.Всегда говорили, что Redis — это один процесс и один поток.На самом деле, при использовании bgsave, Redis создаст дочерний процесс, а постоянство моментальных снимков будет передано дочернему процессу для обработки, в то время как родительский процесс продолжит обработку онлайн-бизнес-запросов.
вилочный механизм
Если вы хотите понять принцип создания моментального снимка RDB, вы должны понимать механизм разветвления. Механизм разветвления — это механизм процесса операционной системы Linux. Когда родительский процесс разветвляет дочерний процесс, дочерний процесс и процесс-муж имеют общая структура данных памяти.Дочерний процесс только что был создан, он разделяет сегмент кода и сегмент данных в памяти с родительским процессом.
Вначале оба процесса имеют один и тот же сегмент памяти. Когда дочерний процесс выполняет сохранение данных, он не будет изменять текущие данные в памяти, а будет использовать cow (копирование при записи) для разделения страниц сегмента данных. изменяет сегмент данных, общая страница будет скопирована и разделена, а затем родительский процесс изменит ее в новом сегменте данных.
Расколоть
Этот процесс также является процессом разделения.Первоначально родительский и дочерний процессы указывают на множество идентичных блоков памяти, но если родительский процесс изменяет один из блоков памяти, он будет скопирован, разделен и затем выполнен в новой памяти. блок.
Поскольку вилка дочернего процесса может быть зафиксирована в памяти того времени, эта точка данных не успеет измениться, поэтому мы можем спокойно создавать моментальный снимок моментального снимка, не беспокоясь о том, что содержание запроса на обслуживание получено. влияние родительского процесса, а с другой стороны возможно, что, если bgsave процесс не выполняет Redis, родительский процесс не получает никаких запросов на обслуживание, не удаляет какие-либо просроченные, например, позади других операций, родительский и дочерний процессы будут использовать тот же блок памяти.
AOF
AOF — это журнал хранения инструкций по операциям redis, аналогичный binlog mysql.Предполагая, что AOF был выполнен с момента создания redis, тогда AOF записывает записи всех инструкций redis.Если вы хотите восстановить redis, вы можете выполнить сброс инструкции в AOF. Весь экземпляр redis можно восстановить, выпустив его, но журнал AOF также имеет две основные проблемы. Первая заключается в том, что журнал AOF со временем увеличивается. Если большой объем данных выполняется в течение длительного времени, объем журнала AOF станет чрезвычайно большим.Еще одна проблема заключается в том, что когда AOF выполняет восстановление данных, из-за огромного количества повторов время восстановления будет очень долгим.
Операция записи AOF заключается в сохранении некоторых журналов AOF в соответствии с определенными стратегиями после того, как Redis обработает бизнес-логику. также является одной из причин, по которой Redis нельзя откатить.
bgrewriteaof
В ответ на вышеуказанные проблемы Redis также использует bgrewriteaof для уменьшения размера журнала AOF после версии 2.4.Команда bgrewriteaof используется для асинхронного выполнения операции перезаписи файла AOF. Перезапись создает оптимизированную по размеру версию текущего файла AOF.
RDB и AOF режим смешивания и сопоставления
При восстановлении redis, если мы используем метод RDB, мы можем потерять много данных из-за стратегии bgsave. Если мы примем режим AOF и восстановим через воспроизведение журнала операций AOF, воспроизведение журнала AOF будет намного дольше, чем у RDB.
После redis4.0, чтобы решить эту проблему, был введен новый режим сохранения, гибридное сохранение, объединяющее файлы rdb и локальные инкрементные файлы AOF, rdb может использовать стратегию сохранения с большим интервалом времени, aof не требуется. Это полный журнал .Необходимо только сохранить инкрементный журнал aof от начала предыдущего хранилища rdb до периода.Вообще говоря, объем журнала очень мал.
5. Как Redis открывает исходный код и снижает затраты на использование памяти
Redis отличается от других традиционных баз данных. Redis — это база данных чистой памяти, в которой хранятся данные некоторых структур данных. Если память не контролируется, Redis может привести к сбою системы из-за чрезмерного объема данных.
ziplist
127.0.0.1:6379> hset hash_test abc 1
(integer) 1
127.0.0.1:6379> object encoding hash_test
"ziplist"
127.0.0.1:6379> zadd z_test 10 key
(integer) 1
127.0.0.1:6379> object encoding z_test
"ziplist"
Когда я впервые попытался открыть хеш-структуру и структуру zset с небольшим объемом данных, я обнаружил, что их реальный тип структуры в redis — это ziplist, ziplist — это компактная структура данных, а каждый элемент — это непрерывная память, если в Redis объем данных структуры данных, поддерживаемой Redis, очень мал, Redis переключится на форму компактного хранилища для сжатого хранилища.
Например, в приведенном выше примере мы используем хэш-структуру для хранения, которая представляет собой двумерную структуру, которая является типичной структурой, в которой пространство обменивается на время. Однако, если количество используемых данных невелико, использование двумерной структуры приведет к пустой трате места, и производительность по времени не будет значительно улучшена.Лучше напрямую использовать одномерную структуру для хранения.При поиске, хотя сложность это O (n), но обход также очень быстрый из-за небольшого объема данных, который увеличивается, чтобы быть быстрее, чем запрос самой хеш-структуры.
Если элементы объекта коллекции продолжают увеличиваться или значение определенного значения слишком велико, это хранилище небольших объектов также будет обновлено для создания стандартной структуры. Redis также может определить параметры преобразования для компактных структур и стандартных структур в конфигурации:
hash-max-ziplist-entries 512 # hash的元素个数超过512就必须用标准结构存储
hash-max-ziplist-value 64 # hash的任意元素的key/value的长度超过 64 就必须用标准结构存储
list-max-ziplist-entries 512
list-max-ziplist-value 64
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
set-max-intset-entries 512
quicklist
127.0.0.1:6379> rpush key v1
(integer) 1
127.0.0.1:6379> object encoding key
"quicklist"
Структура данных быстрого списка представляет собой структуру данных двусвязного списка, представленную Redis в 3.2.Это действительно двусвязный список ziplist. Каждый узел данных quicklist является ziplist, а сам ziplist представляет собой компактный список.Если quicklist содержит 5 узлов ziplist, а каждый ziplist содержит 5 данных, то извне quicklist содержит 25 элементов данных.
Дизайн структуры быстрого списка можно легко описать как компромисс между пространством и временем:
- Двусвязный список может выполнять операции push и pop на обоих концах, но он также сохраняет два указателя в дополнение к своим собственным данным в каждом узле, добавляя дополнительные затраты памяти. Во-вторых, поскольку каждый узел независим, адреса памяти не являются непрерывными, и большее количество узлов подвержено фрагментации памяти.
- Ziplist сам по себе является непрерывным фрагментом памяти с высокой эффективностью хранения и обработки запросов. Однако он не способствует операциям модификации. Каждый раз при изменении данных будет запускаться перераспределение памяти. Если ziplist очень длинный, результатом будет одно перераспределение в большом пакете копий данных.
Поэтому, сочетая в себе преимущества ziplist и двусвязного списка, родился quciklist.
совместное использование объектов
Redis создала метод подсчета ссылок в своей собственной объектной системе. С помощью этого метода можно отслеживать информацию о подсчете ссылок объекта. Помимо выпуска объекта в нужное время, его также можно использовать для совместного использования как объекта. . Например, если ключ A создает строку с целочисленным значением 100 в качестве объекта-значения, то ключ B также создает строковый объект с тем же целым значением 100 в качестве объекта-значения, а затем при работе Redis:
- Указатель на ключ базы данных, указывающий на существующий объект-значение.
- Увеличьте счетчик ссылок объекта общего значения на единицу
Предположим, что в нашей базе данных есть сотни ключей, которые указывают на целочисленное значение 100, не только ключи A и B, но и только один строковый объект на сервере Redis может сохранить первоначальную потребность в сотнях строковых объектов. храниться в памяти.
6. Как Redis реализует репликацию master-slave
несколько определений
- runID ID, на котором работает сервер
- offset Смещение репликации мастера и смещение реплики
- буфер невыполненной репликации мастера невыполненной репликации
После redis2.8 для выполнения операции синхронизации репликации вместо команды sync используется команда psync.Команда psync имеет два режима полной ресинхронизации и частичной ресинхронизации:
- Полная синхронизация используется для обработки начальной ситуации репликации: шаги выполнения полной ресинхронизации такие же, как шаги выполнения команды sync. Оба синхронизируются, позволяя главному серверу создать и отправить файл rdb, а также отправить команду записи. сохраняется в буфере на ведомом сервере.
- Частичная ресинхронизация используется для решения ситуации дублирования репликации после отключения: когда подчиненный сервер повторно подключается к главному серверу после отключения, главная служба может отправить команды записи, выполненные во время отключения главного и подчиненных серверов, подчиненному серверу, а подчиненному серверу нужно только получить и выполнить эти команды записи, база данных может быть обновлена до состояния, в котором в настоящее время находится основной сервер.
Полная повторная синхронизация:
- Слейв отправляет psync мастеру, потому что отправляет первый раз, без runid и смещения
- Мастер получает запрос и отправляет runid и смещение мастера подчиненному узлу.
- master создает и сохраняет файлы rdb
- Мастер отправляет файл rdb подчиненному
- При отправке операции rdb операция записи будет скопирована в буфер невыполненной репликации буфера и отправлена из области буфера на ведомое устройство.
- Подчиненный загружает данные файла rdb и обновляет свои собственные данные.
Если дрожание сети или кратковременное отключение также требуют полной синхронизации, это вызовет много накладных расходов, таких как время bgsave, время передачи файла rdb, время перезагрузки подчиненного устройства rdb, если у подчиненного устройства есть aof, это также приведет к тому, что aof переписано. Это очень много накладных расходов, поэтому механизм частичной ресинхронизации также реализован после redis2.8.
Частичная повторная синхронизация:
- Произошла ошибка сети, и ведущий и ведомый потеряли связь
- Мастер по-прежнему записывает данные в буферный буфер
- ведомый снова подключается к ведущему
- Слейв отправляет свой текущий runid и смещение мастеру
- Ведущее устройство определяет, существует ли в буферной очереди смещение, отправленное ведомым устройством самому себе. Если оно существует, оно посылает продолжение ведомому устройству. Если оно не существует, это означает, что слишком много данных может быть ошибочным, и буфер был опустошен. В это время его нужно повторить. полная копия
- Мастер отправляет смещение данных буфера от смещения к ведомому
- Ведомый получает данные и обновляет свои собственные данные
7. Как Redis формулирует политику удаления с истекшим сроком действия
Когда ключ находится в просроченном состоянии, на самом деле память в redis не удаляется из памяти в реальном времени, а redis удаляет некоторые просроченные ключи через определенный механизм, тем самым добиваясь высвобождения памяти, то при просроченном ключе , когда Redis удалит его? Существует три возможности его удаления, и эти три возможности также представляют три разные стратегии удаления Redis.
- Удаление по времени: создайте таймер при установке истекшего времени ключа и позвольте таймеру удалить ключ сразу после истечения срока действия ключа.
- Ленивое удаление: пусть срок действия ключа истечет независимо, но каждый раз, когда ключ будет получен из пространства ключей, он будет проверять, истекает ли срок действия ключа, и, если он истекает, удаляет ключ.
- Периодическое удаление: Время от времени программа должна проверять базу данных и удалять в ней просроченные ключи, а сколько просроченных ключей удалять, зависит от алгоритма.
Регулярно удалять
Установите время истечения срока действия ключа, создайте таймер, и как только наступит время истечения срока действия, немедленно используйте ключ, что является дружественным к памяти, но наиболее неблагоприятным для процессорного времени, особенно когда бизнес занят, а срок действия ключа истекает Во многих случаях операция удаления просроченного ключа будет занимать большую часть процессорного времени.Вы должны знать, что redis является однопоточной операцией.Когда памяти не тесно, а ЦП туго, время ЦП тратится на удаление ключи с истекшим сроком действия, которые не имеют никакого отношения к делу.Вышеупомянутое повлияет на время отклика и пропускную способность сервера redis. Кроме того, при создании таймера необходимо использовать событие времени на сервере Redis, а когда событие pro-time реализовано в неупорядоченном связанном списке, временная сложность составляет O(n), так что сервер создает большое количество таймеры для реализации стратегии удаления по времени. Это окажет большое влияние на производительность, поэтому удаление по времени не является хорошей стратегией удаления.
ленивое удаление
В отличие от удаления по времени, стратегия ленивого удаления является наиболее дружественной к ЦП.Программа будет проверять только удаление ключа, что является пассивным процессом. В то же время наиболее недружественным к памяти является ленивое удаление: по истечении срока действия ключа, пока его больше не вынимают, просроченный ключ не будет удален, а занимаемая им память не будет освобождена. Очевидно, что ленивое удаление не является хорошей стратегией.Redis очень зависит от памяти и хорошей памяти.Если к некоторым долгосрочным ключам не обращаться в течение длительного времени, это вызовет много мусора в памяти и даже вызовет утечки памяти.
При записи данных выполнения функция expireIfNeeded используется для оценки истечения срока действия записанного ключа.ExpireIfNeeded внутри выполняет три вещи, а именно:
- Проверьте, не истек ли срок действия ключа
- Распространение действий по выполнению прошлых ключей на подчиненные узлы
- удалить просроченный ключ
регулярно удалять
Вышеупомянутые две стратегии удаления, будь то удаление по расписанию или отложенное удаление, имеют очевидные недостатки при однократном использовании, либо занимая слишком много процессорного времени, либо тратя слишком много памяти. Стратегия периодического удаления представляет собой интеграцию и компромисс первых двух стратегий.
- Стратегия периодического удаления выполняет удаление ключей с истекшим сроком действия через регулярные промежутки времени и уменьшает влияние удаления на время ЦП за счет ограничения времени и частоты операций удаления.
- Разумное удаление ключей с истекшим сроком действия достигается за счет разумного времени и частоты выполнения удаления.
Суммировать
Можно сказать, что редис можно описать как широкий и глубокий, простые семь последовательных вопросов, или просто слепой, касающийся слона, или на этот раз он просто коснулся хобота слона, или он должен коснуться хобота, и в следующий раз он может коснуться уха слона, пока он готов опуститься Чтобы понять и исследовать в глубину, а не просто применять и не думать, однажды вы поймете слона, как Редис.
[Примечание: некоторые главы ссылаются на «Проектирование и внедрение Redis» Хуана Цзяньхуна и цитируют его]