Redis

Redis

⭐Часто задаваемые вопросы на собеседовании:

  1. Механизм сохранения Redis

  2. Лавина кеша, проникновение кеша, прогрев кеша, обновление кеша, понижение кеша и т. д.

  3. Что такое горячие и холодные данные

  4. В чем разница между Memcache и Redis?

  5. Почему однопоточный Redis такой быстрый?

  6. Типы данных Redis, каждый тип данных и сценарии использования

  7. Политика истечения срока действия Redis и механизм устранения памяти

  8. Почему Redis однопоточный?

  9. Общие проблемы с производительностью Redis и решения?

  10. Почему операции Redis являются атомарными и как обеспечить атомарность?

  11. Транзакции Redis

12.TODO...........

Анализ анализа высокой частоты

⭐1. Механизм сохранения Redis

Redis — это база данных в памяти, которая поддерживает сохранение данных.Данные в памяти синхронизируются с файлами на жестком диске с помощью механизма сохранения для обеспечения сохранения данных.

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

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

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

РБД:

RDB — это метод сохраняемости Redis по умолчанию.

Согласно определенному периоду времени стратегий памяти данных, сохраненных на жестком диске в виде двоичных снимков. Это смягкое хранение снимка,

Соответствующий сгенерированный файл данных называется dump.rdb, а период моментального снимка определяется параметром сохранения в файле конфигурации. (Моментальный снимок может быть копией данных, которые он представляет, или репликой данных.)

  • Недостатки сохраняемости RDB

Невозможно обеспечить постоянство в реальном времени, существует большая вероятность потери данных.

Когда объем хранилища велик, эффективность низкая, а производительность ввода-вывода низкая.

Создание дочерних процессов на основе форка, дополнительное потребление памяти

Риск потери данных из-за простоя

Aof:

Redis будет добавлять каждую полученную команду записи в конец файла с помощью функции записи, аналогично binlog MySQL.

Когда Redis перезапускается, он перестраивает все содержимое базы данных в памяти, повторно выполняя команды записи, сохраненные в файле.

  • Преимущества АОФ

  • AOF может лучше защитить данные от потери.Как правило, AOF теряет данные на срок до 1 секунды каждую 1 секунду.

  • Производительность записи очень высока, и файл нелегко повредить.

  • Подходит для аварийного восстановления катастрофических случайных делеций.

  • Недостатки Aof.

Для одних и тех же данных файлы журнала AOF обычно больше, чем файлы моментальных снимков данных RDB.

более медленное восстановление

  • Когда оба метода включены одновременно, восстановление данных Redis отдает приоритет восстановлению AOF.

Как выбрать между RDB и AOF

Очень чувствителен к данным, рекомендуется использовать схему сохранения AOF по умолчанию.

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

На этапе потери данных нет, восстановление происходит быстро.Восстановление данных на этапе этапа обычно использует схему RDB.

всесторонний:

Если вы не можете допустить потери данных в течение нескольких минут и очень чувствительны к бизнес-данным, выберите AOF.

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

Стратегия двойной страховки, одновременное открытие RDB и AOF, после перезапуска Redis предпочтительно использовать AOF для восстановления данных и уменьшения количества потерянных данных

⭐ 2. Лавина кеша, проникновение кеша, предварительный прогрев кеша, обновление кеша, понижение кеша и т. д.

Кэш Лавина

Мы можем просто понять это как: из-за аннулирования исходного кеша новый кеш еще не прибыл (например: когда мы устанавливаем кеш с одинаковым сроком действия, срок действия большой области кеша истекает одновременно ), все запросы, которые должны были получить доступ к кешу. Все они отправились на запрос к базе данных, что вызовет огромную нагрузку на ЦП и память базы данных и приведет к серьезному сбою базы данных. Таким образом, возникает ряд цепных реакций, приводящих к коллапсу всей системы.

  • решение:
    Большинство проектировщиков систем рассматривают возможность использования блокировок (наиболее частое решение) или очередей, чтобы гарантировать, что не будет большого количества потоков, читающих и записывающих в базу данных одновременно, чтобы избежать большого количества одновременных запросов, попадающих в базовое хранилище. системы в случае отказа. Еще одно простое решение — время от времени распространять инвалидацию кеша.

проникновение в кеш

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

  • решение:

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

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

Непосредственно установленное значение по умолчанию хранится в кеше, так что во второй раз, когда вы получите значение из кеша, вы не будете продолжать обращаться к базе данных.Этот способ самый простой и грубый. Жесткий диск объемом 5 ТБ заполнен данными, пожалуйста, напишите алгоритм для дедупликации данных.

Что, если эти данные являются 32-битными данными? А если 64бит? Использование пространства достигло предела, то есть Bitmap и фильтр Блума.

Bitmap: Типичным недостатком хэш-таблицы является то, что Bitmap может записывать только 1 бит информации для каждого элемента.Если вы хотите выполнить дополнительные функции, я боюсь, что вы можете пожертвовать только более пустыми фильтрами Блума (рекомендуется) - это введение k (k>1) k(k>1) взаимно независимых хеш-функций гарантируют, что процесс взвешивания элементов будет завершен при заданном пространстве и частоте ложных срабатываний.

Его преимущество заключается в том, что эффективность использования пространства и время запроса намного больше, чем у общего алгоритма, а недостаток заключается в том, что существует определенная частота неправильного распознавания и сложность удаления. Основная идея алгоритма Bloom-Filter заключается в использовании нескольких различных хэш-функций для разрешения «конфликтов». У хэша есть проблема конфликта (коллизии), и значение двух URL-адресов, полученных с одним и тем же хэшем, может быть одинаковым.

Для уменьшения конфликтов мы можем ввести еще несколько значений Hash.Если через одно из значений Hash мы обнаружим, что элемента нет в множестве, то элемента точно нет в множестве. Элемент может быть определен как существующий в наборе только в том случае, если все хеш-функции сообщают нам, что элемент находится в наборе. Это основная идея Bloom-Filter.

Фильтр Блума обычно используется для определения того, существует ли элемент в наборе больших объемов данных.

прогрев кеша

Этот подогрев кеша должен быть более общей концепцией, я считаю, что многие мелкие партнеры должны быть в состоянии легко понять, линия кеша предварительно нагревается.

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

библиотека, а тут проблема с кешем данных! Пользователь напрямую запрашивает предварительно прогретые кэшированные данные!

  • Решения

(1) Напишите страницу обновления кеша напрямую и вручную управляйте ею при подключении к сети;

(2) объем данных невелик, и они могут автоматически загружаться при запуске проекта;

(3) Регулярно обновляйте кеш;

(4) Обновление кеша

В дополнение к стратегии аннулирования кеша, которая поставляется вместе с сервером кеша (по умолчанию у Redis есть 6 стратегий на выбор), мы также можем настроить удаление кеша в соответствии с конкретными потребностями бизнеса.Существуют две общие стратегии:

(1) Регулярно очищайте кэш с истекшим сроком действия;

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

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

Деградация кэша

Когда происходит скачок трафика, возникают проблемы со службами (например, медленное время отклика или отсутствие отклика) или когда неосновные службы влияют на производительность основных процессов, все равно необходимо гарантировать, что службы по-прежнему доступны, даже с убытком. Система может автоматически переходить на более раннюю версию в соответствии с некоторыми ключевыми данными или может быть настроена с помощью переключателей для перехода на более раннюю версию вручную. Конечная цель перехода на более раннюю версию — сохранить доступность основных служб, даже с убытком. И некоторые услуги не могут быть понижены (например, добавление в корзину, оформление заказа).

Установите сценарий с эталонным уровнем журнала:

(1) Общее: например, время ожидания некоторых служб иногда истекает из-за дрожания сети или служба находится в сети, и ее можно автоматически понизить;

(2) Предупреждение: некоторые службы колеблются в степени успешности в течение определенного периода времени (например, между 95 и 100%), который может быть автоматически понижен или вручную понижен, и будет отправлен сигнал тревоги;

(3) Ошибка: например, уровень доступности ниже 90%, или пул соединений с базой данных перегружен, или объем доступа внезапно увеличивается до максимального порога, который может выдержать система, в это время он может быть автоматически понижен. или вручную понижен в зависимости от ситуации;

(4) Серьезные ошибки: например, по особым причинам данные неверны, и в настоящее время требуется аварийный переход на более раннюю версию вручную. Целью понижения службы является предотвращение сбоя службы Redis, что может привести к лавинной проблеме с базой данных. Поэтому для неважных кэшированных данных может быть принята стратегия перехода на более раннюю версию службы.Например, общепринятой практикой является то, что в случае возникновения проблемы с Redis вместо запроса к базе данных он напрямую возвращает пользователю значение по умолчанию.

⭐3. Что такое горячие данные и холодные данные

Для горячих данных ценен кеш, для холодных данных большая часть данных может быть выжата из памяти перед повторным доступом, что не только занимает память, но и не имеет никакой ценности. Для данных о точках доступа
Например, один из наших продуктов обмена мгновенными сообщениями, модуль поздравления с днем ​​​​рождения и список дней рождения дня могут быть прочитаны сотни тысяч раз после кэширования.

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

Существует ли он, и частота модификаций высока, но как насчет сценария, в котором необходимо учитывать кеш? имеют! Например, этот интерфейс чтения создает большую нагрузку на базу данных, но это также и горячие данные.
В настоящее время необходимо рассмотреть возможность снижения нагрузки на базу данных с помощью кэширования.

Например, количество отметок «Мне нравится», «Избранное», «Поделиться» и т. д. одного из наших продуктов-помощников — очень типичные горячие данные, но они постоянно меняются.
На этом этапе необходимо синхронно сохранять данные в кэш Redis, чтобы уменьшить нагрузку на базу данных.

⭐ 4. В чем разница между Memcache и Redis?

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

2. Тип поддержки данных Все значения memcached представляют собой простые строки, а redis, как его заменитель, поддерживает более распространенные типы данных и обеспечивает хранение таких структур данных, как list, set, zset и hash.

3. Используются разные базовые модели, различаются лежащие в их основе методы реализации и прикладной протокол для связи с клиентом. Redis напрямую сам строит механизм ВМ, потому что, если общая система вызывает системные функции, она будет тратить определенное количество времени на перемещение и запрос.

4. Размер value отличается: Redis может достигать максимум 1gb, memcache всего 1mb.

5. Скорость Redis намного быстрее, чем у memcached 6. Redis поддерживает резервное копирование данных, то есть резервное копирование данных в режиме master-slave.

⭐5. Почему однопоточный Redis такой быстрый

1. Чистая работа с памятью

2. Однопоточная работа, позволяющая избежать частого переключения контекста

3. Использование неблокирующего механизма мультиплексирования ввода/вывода

⭐6 Типы данных Redis и сценарии использования каждого типа данных (5 типов)

1. Про String и говорить нечего, для самых обычных операций set/get значение может быть либо String, либо числом. Как правило, выполняйте кэширование сложных функций подсчета.

2. Значение хеша здесь является структурированным объектом, и оперировать одним из полей удобнее. Когда блоггеры используют единый вход, они используют эту структуру данных для хранения информации о пользователе, используют cookieId в качестве ключа и устанавливают 30 минут в качестве времени истечения кэша, что может хорошо имитировать эффект, подобный сеансу.

3. List использует структуру данных List для выполнения простых функций очереди сообщений. Во-вторых, вы можете использовать команду lrange для подкачки на основе Redis с отличной производительностью и удобным пользовательским интерфейсом. Я также использую сцену, которая очень подходит для получения информации о рынке. Это также сценарий производителя и потребителя. LIST вполне может дополнить принцип организации очереди по принципу «первым пришел — первым обслужен».

4. Установить, потому что набор объединяет набор неповторяющихся значений. Так можно сделать функцию глобальной дедупликации. Почему бы не использовать набор, поставляемый с JVM, для дедупликации? Поскольку наши системы, как правило, развертываются в кластерах, использовать Set, поставляемый с JVM, сложнее, чем запускать публичный сервис для глобальной дедупликации? Кроме того, используя такие операции, как пересечение, объединение и разность, вы можете вычислить общие предпочтения, все предпочтения и ваши собственные уникальные предпочтения.

5. Отсортированный набор

⭐7. Политика истечения срока действия Redis и механизм устранения памяти

Redis использует定期删除+惰性删除策略.

Почему бы не удалять политику периодически?

Удаление по времени, таймер используется для отслеживания ключа, и он автоматически удаляется по истечении срока его действия. Хотя память освобождается вовремя, она потребляет много ресурсов процессора.

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

Как работает периодическое удаление + отложенное удаление?

  • регулярно удалять

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

Почему случайно? Если подумать, если Redis хранит сотни тысяч ключей и просматривает все ключи со сроком действия каждые 100 мс, это будет сильно нагружать ЦП!

Следовательно, если будет принята только стратегия периодического удаления, многие ключи не будут удалены со временем. Итак, ленивое удаление пригодится.

То есть, когда вы получаете ключ, Redis проверит его.Если у ключа есть время истечения срока действия, он истек?

Если он истекает, то он будет удален.

Ленивое удаление: периодическое удаление может привести к тому, что многие ключи с истекшим сроком действия не будут удалены, когда придет время. Так что есть ленивое удаление. Если ваш ключ с истекшим сроком действия не удален обычным удалением, он все еще остается в памяти, если ваша система не проверит ключ, он будет удален с помощью Redis.

Есть ли другая проблема с периодическим удалением + ленивое удаление?

Нет, но просто установить время истечения пока проблематично. Давайте подумаем: что произойдет, если вы пропустите много ключей с истекшим сроком действия при обычном удалении, и вы не проверите вовремя, и вы не используете ленивое удаление? Если в памяти накапливается большое количество ключей с истекшим сроком действия, блок памяти redis исчерпывается. Как решить эту проблему?

Механизм устранения памяти Redis.

⭐механизм удаления данных redis

Стратегия удаления данных, когда память достигает максимального предела памяти

  1. Новые операции записи будут сообщать об ошибке. (Политика Redis по умолчанию)

  2. В пространстве ключей удалите последний использованный ключ. (рекомендовано LRU)

  3. В ключевом пространстве ключ удаляется случайным образом.

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

  5. В ключевом пространстве с установленным сроком действия ключ удаляется случайным образом.

  6. В ключевом пространстве с установленным сроком действия сначала удаляются ключи с более ранним сроком действия.

  • Реализация алгоритма LRU: 1. Реализовано через вдвойне связанный список, новые данные вставляются в головку связанного списка; 2. Всякий раз, когда кэш-хит (то есть кэш

доступ к данным), переместить данные в начало связанного списка; 3. Когда связанный список заполнен, отбросить данные в хвосте связанного списка.

LinkedHashMap: комбинация HashMap и двусвязного списка называется LinkedHashMap. HashMap неупорядочен

Да, LinkedHashMap гарантирует порядок итераций, поддерживая дополнительный двусвязный список. Порядок итерации можно вставить

Порядок входа (по умолчанию) или порядок доступа.

  • расширять:

Конкретная реализация LRU Redis

Традиционный LRU находится в виде стека, и вновь используемый переводятся в верхнюю часть стека каждый раз, но с использованием стека в форме стека приведет к большому количеству не горячих данных, чтобы занять Данные заголовка при выполнении выбора *.

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

Произвольно возьмите пять ключей из dict и исключите тот, у которого наименьшее значение поля lru. В версии 3.0 была улучшена еще одна версия алгоритма: во-первых, ключи, выбранные случайным образом в первый раз, будут помещены в пул (размер пула равен 16),

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

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

Над кодом:

В redis.conf есть строчка конфигурации

maxmemory-policy volatile-lru

Скопируйте код из конфигурации оснащен стратегиями памяти (что, вы тоже не подходите? Хорошее отражение самостоятельно)

volatile-lru: выберите данные из набора данных (server.db[i].expires), которые использовались наименее недавно, с установленным временем истечения срока действия.

volatile-ttl: выберите данные, срок действия которых истекает, из набора данных (server.db[i].expires), в котором установлено время истечения срока действия.

volatile-random: произвольный выбор удаления данных из набора данных с установленным временем истечения срока действия (server.db[i].expires)

allkeys-lru: выбрать наименее использованные данные из набора данных (server.db[i].dict) для исключения

allkeys-random: Случайный выбор данных из набора данных (server.db[i].dict) для исключения

no-enviction (eviction): запретить удаление данных, новая операция записи сообщит об ошибке

Дополнение: Если ключ expire не установлен, то пререквизиты (prerequisites) не соблюдены, то поведение стратегий volatile-lru, volatile-random и volatile-ttl в основном такое же, как и noeviction (не удалять).

⭐8.Почему Redis однопоточный?

Поскольку Redis — это операция, основанная на памяти, ЦП не является узким местом Redis, а узким местом Redis, скорее всего, является размер машинной памяти.
или пропускная способность сети. Так как один поток легко реализовать и ЦП не станет узким местом, логично использовать один поток.

Решение (ведь использование многопоточности доставит много хлопот!)

Redis использует технологию очередей, чтобы превратить одновременный доступ в последовательный доступ.

1. Большая часть запроса является чистой операцией памяти (очень быстро)

2. Использование одного потока, чтобы избежать ненужного переключения контекста и условий гонки

3. Преимущества неблокирующего ввода-вывода:

1) Быстрый, т.к. данные хранятся в памяти, аналогично HashMap, преимущество HashMap в том, что временная сложность поиска и работы O(1)

2) Поддержка расширенных типов данных, поддержка строки, списка, набора, отсортированного набора, хэша.

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

4) Богатые возможности: можно использовать для кеша, сообщения, установить время истечения срока действия в соответствии с ключом, он будет автоматически удален после истечения срока действия.

Ключевая проблема одновременной конкурентной ключей Redis имеет несколько подсистем для установки ключа одновременно. Что мы должны обратить внимание в это время?

Механизм транзакций Redis не рекомендуется.

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

Когда используется несколько ключей, эти несколько ключей не обязательно хранятся на одном и том же сервере redis. Поэтому редис

Механизм транзакций очень безвкусный.

(1) Если вы работаете с этим ключом, приказ не требуется: подготовьте распределенный замок, все захватят замок, и вы сможете выполнить операцию установки после захвата замка. И так далее.

(2) Использование очередей и изменение метода set на последовательный доступ также могут позволить Redis столкнуться с высоким параллелизмом.Если согласованность чтения и записи ключей гарантирована, операции Redis являются атомарными и потокобезопасными, и у вас нет чтобы подумать об этом Проблемы параллелизма, Redis уже помог вам решить проблемы параллелизма

⭐9. Распространенные проблемы с производительностью Redis и их решения?

1. Мастеру лучше не выполнять никакой постоянной работы, такой как снимки памяти RDB и файлы журнала AOF.

2. Если данные более важны, ведомое устройство позволяет AOF выполнять резервное копирование данных, а политика настроена на синхронизацию один раз в секунду.

3. Для скорости репликации master-slave и стабильности соединения Master и Slave желательно должны находиться в одной локальной сети

4. Старайтесь не добавлять подчиненные библиотеки в основную библиотеку под большим давлением

5. Не используйте структуру графа для репликации master-slave.Более стабильно использовать структуру односвязного списка, то есть: Master

⭐10. Почему операции Redis атомарны и как обеспечить атомарность?

Для Redis атомарность команды такова: операцию нельзя разделить, и операция либо выполняется, либо нет.

Причина, по которой Redis является атомарным, заключается в том, что Redis является однопоточным.

Все API, предоставляемые самим Redis, являются атомарными операциями, а транзакции в Redis фактически обеспечивают атомарность пакетных операций.

Являются ли несколько команд атомарными в параллелизме? Не обязательно менять get и set на одну командную операцию, вкл. Используйте транзакции Redis или используйте Redis+Lua== для реализации.

⭐ 11. Транзакции Redis

Функция транзакции Redis заключается в том, что Redis, реализованный с помощью четырех примитивов MULTI, EXEC, DISCARD и WATCH, сериализует все команды в транзакции и выполняет их последовательно.

1. Redis не поддерживает откат. «Redis не выполняет откат при сбое транзакции, а продолжает выполнять оставшиеся команды», поэтому внутренние компоненты Redis могут оставаться простыми и быстрыми.

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

  • (1) MULTI команда для включения транзакции, она всегда возвращает OK. После выполнения MULTI клиент может продолжать отправлять на сервер любое количество команд, которые не будут выполняться немедленно, а будут помещены в очередь, при вызове команды EXEC будут выполнены все команды очереди.

  • (2) EXEC: выполнение команд во всех блоках транзакций. Возвращает возвращаемые значения всех команд в блоке транзакций в порядке их выполнения. Когда операция прервана, вернуть пустое значение nil.

  • (3) Вызывая DISCARD, клиент может очистить очередь транзакций и отказаться от выполнения транзакции, и клиент выйдет из состояния транзакции.

  • (4) Команда WATCH может обеспечить поведение проверки и установки (CAS) для транзакций Redis. Можно отслеживать один или несколько ключей.После изменения (или удаления) одного из ключей последующие транзакции выполняться не будут.Наблюдение продолжается до команды EXEC.

Это разделительная линия ------------------------------------------------------------ ------------------ Это разделительная линия

TODO(20200408)

⭐Сценарии применения

  1. тайник

  2. Общий сеанс

  3. система очереди сообщений

  4. Распределенная блокировка

⭐ Структура данных таблицы переходов zset

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

  • принцип:

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

Поскольку индекс может пропустить более одного элемента, поэтому скачок найдет, что он будет скорость становится быстрее.

  • Зачем использовать таблицу прыжков

Прежде всего, поскольку zset должен поддерживать случайную вставку и удаление, его не следует реализовывать с использованием массивов.Что касается проблемы сортировки, мы можем легко представить древовидные структуры, такие как красно-черные деревья/сбалансированные деревья.Почему Redis не использует такие структуры??

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

  2. Соображения по реализации: В случае той же сложности, что и красно-черное дерево, таблица переходов проще в реализации и выглядит более интуитивно понятной;

⭐redis устанавливает время истечения срока действия

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

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

Когда мы устанавливаем ключ, мы можем указать время истечения срока действия, которое является временем истечения срока действия.Через время истечения срока действия мы можем указать время, в течение которого ключ может существовать.

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

⭐Как обеспечить согласованность данных кеша и базы данных?

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

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

  • Разумно установите время истечения кэша.

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

  • Добавьте механизм повтора при сбое кеша.

⭐Как в Redis реализованы распределенные блокировки?

Распределенная блокировка Redis фактически занимает «яму» в системе. Когда другим программам также необходимо занять «яму», она может продолжить выполнение, если оккупация прошла успешно. В случае неудачи она может только сдаться или повторить попытку позже.

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

Он также может автоматически снять блокировку с помощью клавиши EXPIRE в секундах.

Установите время жизни ключа, когда срок действия ключа истечет (время жизни равно 0), он будет автоматически удален

Недостатки: Атомарность не устраивает, не рекомендуется.

⭐Знаете ли вы, с какими проблемами или проблемами вы столкнетесь при использовании кеша в реальных проектах?

Проблемы с согласованностью данных кеша и базы данных

репликация master-slave

эффект:

Разделение чтения и записи: основная запись, подчиненное чтение, улучшение нагрузки на чтение и запись сервера.

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

Неспособность восстановления: когда мастер не удается, раб предоставляет услуги для достижения быстрого восстановления неудачи

Избыточность данных: реализация горячего резервного копирования данных — это метод избыточности данных, отличный от сохраняемости.

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

процесс:

  • Ведомый узел выполняет slaveof IP, порт отправляет команды
  • ответ главного узла
  • Подчиненный узел сохраняет информацию о главном узле (IP, порт) и устанавливает соединение Socket с главным узлом.
  • Ведомый узел отправляет сигнал Ping, а главный узел возвращает Pong, чтобы подтвердить, что обе стороны могут общаться друг с другом.
  • После установления соединения ведущий узел отправляет все данные подчиненному узлу (синхронизация данных).
  • После того, как главный узел синхронизирует текущие данные с подчиненным узлом, процесс установления репликации завершается. Затем главный узел продолжит отправлять команды записи подчиненным узлам, чтобы обеспечить согласованность данных ведущий-ведомый.

Процесс репликации/синхронизации данных разделен на две фазы.

  1. Полная копия:

    Подчиненное устройство получает файл RDB, сгенерированный ведущим, сначала очищает свои старые данные, затем выполняет процесс восстановления RDB, а затем информирует главное устройство о завершении восстановления.

  2. Частичная копия (добавочная репликация)

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

Репликация master-slave имеет следующие проблемы:

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

  • Возможность записи главного узла ограничена одной машиной.

  • Емкость хранилища главного узла ограничена одной машиной.

часовой:

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

эффект:

  • монитор

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

  • уведомление (напоминание)

Отправляйте уведомления другим (Sentinels, Clients) при возникновении проблем с отслеживаемым сервером.

  • автоматический переход на другой ресурс

Отключите мастер от ведомого, выберите ведомого в качестве ведущего, подключите другие ведомые устройства к новому ведущему и сообщите клиенту адрес нового сервера.

Категории