предисловие

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

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

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

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

• Некоторые пропущенные пункты в указателе
• Достаточно двух базовых знаний Redis (1)
• Достаточно двух базовых знаний Redis (2)
• Все включено - блокирует JAVA
• Преодолеть JVM — объекты JVM и позиционирование доступа к объектам (1)
• Преодолеть JVM — механизм сборки мусора JVM (2)
• Преодолеть JVM — сборщик мусора JVM (3)

1. Лавина кэша, пробой, проникновение

На этот раз, начиная с третьего краха кеша, о котором больше всего говорят (и часто спрашивают в интервью) Redis.

Кэш Лавина

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

Как возникла лавина кеша?

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

Решение:

• 1. При хранении данных в пакетной сети Redis добавьте случайное значение ко времени истечения срока действия каждого KEY, чтобы гарантировать, что он не истечет одновременно.
• 2. Установите для данных точки доступа неограниченный срок действия и обновите кеш, если есть операция обновления (но этот метод не годится, бессрочный срок действия приведет к большому накоплению кешей, а многие кеши не обязательно полезны)
• 3. Развертывание кластера Redis, равномерное распределение горячих данных в разных библиотеках Redis также может избежать всех сбоев и избежать лавин кеша, вызванных проблемами Redis.

разбивка кеша

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

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

Решение:

• 1. Установите неограниченный срок действия данных точки доступа
• 2. Добавить блокировку взаимного исключения [проще говоря, когда кеш недействителен (извлекаемое значение считается пустым), вместо того, чтобы сразу загружать БД, сначала используйте некоторые операции инструмента кеша с возвращаемым значением успешная операция (например, SETNX в Redis или ADD в Memcache) для установки ключа мьютекса, когда операция завершается успешно, выполняется операция загрузки базы данных и сброс кеша]

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

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

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

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

Однако проникновение в кеш на самом деле пытаются предотвратить хакеры.

Если хакер каждый раз преднамеренно запрашивает часть данных, которые не должны существовать в кеше, это приведет к тому, что каждый запрос будет отправляться на уровень хранения для запроса, и кеш потеряет свое значение. Если БД может зависнуть при интенсивном трафике, это тоже поломка кеша. Решение:

• 1. Добавьте проверку параметров
• 2. Добавьте элементы конфигурации из Nginx на уровне шлюза, чтобы заблокировать блокировку обработки количества обращений в секунду с одного IP-адреса, превышающего пороговое значение.
• 3.Фильтр Блума может очень хорошо предотвращать проникновение в кеш.Его принцип тоже очень прост.Он использует эффективные структуры данных и алгоритмы,чтобы быстро определить есть ли ваш ключ в БД.Если прямого возврата нет,если есть,идем сразу к БД, чтобы обновить KV. вернуться снова

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

Что такое фильтр Блума

Фильтр Блума - это, по сути, структура данных, относительно оригинальная вероятностная структура данных, которая характеризуется эффективной вставкой и запросом и может использоваться, чтобы сказать вам, что «что-то не должно существовать или что-то может существовать».

Фильтры Блума производятся компаниейОчень длинный битовый массив и набор хеш-функций.

Каждый элемент массива занимает только 1 бит, и каждый элемент может быть только 0 или 1.

Фильтр Блума имеет k хэш-функций.При добавлении элемента в фильтр Блума используются k хэш-функций для выполнения над ним k вычислений, получаются k хеш-значений, и в соответствии с полученными хеш-значениями устанавливается значение соответствующего индекса на 1 в битовом массиве.

Чтобы определить, находится ли определенное число в фильтре Блума, выполните k хеш-вычислений над элементом, а полученное значение определяется в битовом массиве, чтобы определить, равен ли каждый элемент 1. Если каждый элемент равен 1, это означает, что это значение равно в фильтре Блума.

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

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

С помощью этого метода можно эффективно предотвратить проникновение в кэш, вызванное хакерами.

2. Реализация кластера Redis

1. Традиционный режим ведущий-ведомый

На самом деле это не очень традиционно, но я чувствую, что все кластеры имеют режим master-slave или

Одной из функций режима ведущий-ведомый является резервное копирование данных, чтобы при повреждении узла (имеется в виду неисправимое повреждение оборудования) данные можно было легко восстановить благодаря резервному копированию. Еще одна функция — балансировка нагрузки.Все клиенты, обращающиеся к узлу, обязательно повлияют на эффективность работы Redis.В режиме master-slave операции запроса могут выполняться путем запроса подчиненных узлов.

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

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

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

Таким образом, мы можем обнаружить, что master-slave Redis полностью отличается от master-slave Zookeeper!Он даже не будет голосовать!

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

2. Sentinel mode (сторожевой режим)

Режим Sentinel следует использовать с режимом master-slave.Мастер и ведомый не могут выбирать сами по себе, поэтому мы добавляем сторожевой.Когда сторожевой обнаруживает, что главный узел не работает, сторожевой переизбирает ведущего из ведомого.

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

（1）监控主服务器和从服务器是否正常运行。 
（2）主服务器出现故障时自动将从服务器转换为主服务器。

Разве это не вся радость?

Как работает Сентинел:

• 1. Каждый процесс Sentinel начинается скаждую секундуЧастота отправки команды PING на главный главный сервер, подчиненный подчиненный сервер и другие процессы Sentinel (сторожевые) во всем кластере.
• 2. Если время с момента последнего действительного ответа на команду PING от экземпляра превышает значение, указанное параметром down-after-milliseconds, экземпляр будет помечен процессом Sentinel как субъективно отключенный (SDOWN).
• 3. Если главный главный сервер помечен как субъективно отключенный (SDOWN), все процессы Sentinel, отслеживающие главный главный сервер, должны подтверждать, что главный главный сервер действительно перешел в субъективное автономное состояние с частотой один раз в секунду.

Когда имеется достаточное количество процессов Sentinel (больше или равно значению, указанному в файле конфигурации) в указанном диапазоне времени, подтверждается, что главный главный сервер вошелСубъективный нижестоящийсостоянии (SDOWN), главный первичный сервер будет помечен какобъективно офлайн(ОДАУН)

• 4. Как правило, каждый процесс Sentinel будет отправлять команды INFO всем ведущим главным серверам и подчиненным подчиненным серверам в кластере с частотой один раз в 10 секунд.

Когда главный главный сервер помечен процессом Sentinel (сторожевым) как объектный в автономном режиме (ODOWN), частота отправки команд INFO всем подчиненным серверам главного главного сервера процесса часового (сторожевого) изменится с одного раза каждые 10 секунд. к каждой каждой секунде.

• 5. Если процессов Sentinel недостаточно, чтобы согласиться на отключение главного главного сервера, объективный статус автономного главного главного сервера будет удален. Если главный главный сервер повторно отправляет команду PING процессу Sentinel и возвращает действительный ответ, субъективный статус главного главного сервера в автономном режиме будет удален.

Режим Sentinel может в основном удовлетворить потребности общего производства и имеет высокую доступность. Однако, когда объем данных слишком велик для хранения на одном сервере, режим «ведущий-ведомый» или режим «дозорный» не могут удовлетворить спрос, поэтому сохраненные данные необходимо разбить на сегменты и хранить в нескольких экземплярах Redis. кластерный режим.

3. Кластерный режим

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

Redis-Cluster использует бесцентровую структуру со следующими характеристиками:

• Все узлы redis взаимосвязаны друг с другом (механизм PING-PONG), а внутренний бинарный протокол используется для оптимизации скорости передачи и пропускной способности.

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

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

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

Обратитесь к изображению большого парня, чтобы наглядно показать, что такое Redis-Cluster.

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

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

woooooo.brief.com/afraid/49 с 9 ох 03 ох ох…Несколько мелочей о режиме кластера redis (ten) redis

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

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

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

Так как Redis может хранить данные, естественно удалить лишние данные, иначе место будет заполнено.Где разместить новый контент? Умные программисты придумали три решения проблем памяти Redis.

• 1. Удаление по времени
• 2. Ленивое удаление - если он истечет после запроса, он не будет возвращен, а если истечет, то будет удален. Эта ситуация подвержена большому количеству избыточных данных, которые занимают много места.

1. Удаление по времени

Создайте таймер. Когда для ключа установлено время истечения срока действия, и время истечения срока действия наступает, задача таймера немедленно удалит ключ. По умолчанию некоторые ключи будут выбраны случайным образом в течение 100 мс, чтобы определить, истек ли срок их действия. Если срок их действия истек , они будут удалены.Используйте производительность процессора В обмен на место для хранения (обмен времени на пространство)

• преимущество:Сохраняйте память, удаляйте ее, когда придет время, и быстро избавляйтесь от ненужного использования памяти

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

2. Ленивое удаление

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

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

• недостаток:Нагрузка на память очень высока, и есть данные, которые занимают память в течение длительного времени.

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

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

Механизм исключения также можно настроить, выполнив поиск maxmemory-policy в файле redis.config Redis.

noeviction：当内存使用达到阈值的时候，所有引起申请内存的命令会报错。
allkeys-lru：在主键空间中，优先移除最近未使用的key。
volatile-lru：在设置了过期时间的键空间中，优先移除最近未使用的key。
allkeys-random：在主键空间中，随机移除某个key。
volatile-random：在设置了过期时间的键空间中，随机移除某个key。
volatile-ttl：在设置了过期时间的键空间中，具有更早过期时间的key优先移除。

Эпилог

После того, как я закончил писать главу о Redis, я почувствовал, что в Redis действительно много контента. Мне казалось, что я освоил все это раньше. Оглядываясь назад, я обнаружил, что еще многого не понимаю~~~~~ Я очень рад, что могу поделиться с вами своими достижениями здесь. Я знаю, что между моим технологическим стеком и большими парнями все еще есть разрыв, но откуда люди узнают, что они не могут, если они не работают усердно? Надеюсь, вам всем понравилась моя статья, и я надеюсь, что эта статья может вам помочь.

В то же время, если вам нужна интеллект-карта, вы можете обратиться ко мне, ведь чем большим количеством знаний вы делитесь, тем оно ароматнее!