«Эта статья участвовала в мероприятии Haowen Convocation Order, щелкните, чтобы просмотреть:Двойные заявки на внутреннюю и внешнюю стороны, призовой фонд в 20 000 юаней ждет вас, чтобы бросить вызов!"
предисловие
Привет, я Ураган
Указатель предыдущих статей выглядит следующим образом:
00-Redis, ты действительно понимаешь?
01-Типы данных Redis, о которых вы знаете больше, чем это
02-Проем хеш-таблицы Redis
03-Почему Redis такой быстрый
04-Вы действительно понимаете постоянный AOF Redis?
05-Тайна RDB для Redis Persistence
В предыдущей статье мы в основном говорили о каких-то базовых знаниях по редису, реального боя не было и проблем не возникало на практике, всем будет скучно, сегодня я расскажу о реальном бою.
- Кэш Лавина
- разбивка кеша
- проникновение в кеш
Я считаю, что об этих трех вопросах говорили многие друзья в Интернете, но сегодня я все еще хочу поговорить о них. Я нарисую больше картинок, чтобы углубить общее впечатление. Эти три вопроса также часто являются вопросами интервью, но я могу поставить эти три вопроса вместе.Чтобы прояснить проблему, требуется умение.
Говоря об этих трех вопросах, давайте сначала поговорим об обычном процессе запроса, посмотрим на картинку и поговорим:
Смысл вышеприведенной картинки примерно такой:
Во-первых, в вашем коде это может быть tomcat или ваша служба rpc, сначала определите, существуют ли нужные вам данные в кеше, если они сохранены, затем верните их непосредственно вызывающей стороне, если нет, то вам нужно запросить базу данных , запросите результаты, а затем продолжите кэширование их в кэше, а затем верните результаты вызывающему объекту. При следующем запросе кэш будет поражен.
Кэш Лавина
определение
Помнится, когда я раньше работал над рекомендательной системой, некоторые данные вычислялись офлайн-алгоритмами.Требование - посмотреть, какие похожие товары будет рекомендовать этот товар.После этого подсчета они будут храниться в hbase и сохраняться в redis в то же время, потому что все они являются пакетными алгоритмами.Когда он выходит и сохраняется в Redis, если время истечения срока действия установлено одинаковым, это приведет к одновременному сбою большого количества ключей, тогда большое количество запросов будет попадать в фоновую базу данных, так как пропускная способность базы данных ограничена, и очень вероятно, что база данных будет перегружена. Эта ситуация представляет собой лавину кеша. Посмотрите на картинку и расскажите:
Это в основном для иллюстрации сценария, в котором происходит лавина кеша, особенно при установке кешей в пакетах для запланированных задач, вы должны обратить вниманиеНастройка срока действия.
Как предотвратить сход лавин
На самом деле это тоже очень просто, то есть, когда вы устанавливаете время кеша пачками, задайте случайное число для установленного времени кеша (например, случайное число может быть числом в пределах 10 минут, а Случайное число может быть сгенерировано с помощью Java's Random), Таким образом, не будет появляться большое количество ключей, и они будут одновременно выходить из строя. Смотрите на картинку и говорите:
А если лавина все-таки произойдет?
Трафик не очень большой, база выдерживает, ок, поздравляю с побегом.
Трафик очень большой, превышает лимит количества запросов, которые может обработать база данных.База данных не работает, поздравляем с получением заявки об инциденте P0.
Трафик очень большой.Если ваша схема ограничения тока базы данных достигает параметров, установленных ограничением тока, запрос будет отклонен, тем самым защищая фоновую базу данных. Несколько слов об ограничении тока здесь.
Вы можете ограничить большое количество запросов к базе данных, установив количество запросов в секунду.Обратите внимание, что количество запросов в секунду здесь или количество параллелизма не является текущим количеством запросов в секунду для данных. Он может быть настроен на запрос соответствующего ключа определенного ключа.Количество запросов в секунду, цель этого состоит в том, чтобы предотвратить попадание большого количества запросов с одним и тем же ключом в серверную базу данных, чтобы большинство запросов можно было перехватить. .
Посмотрите на картинку и скажите:
Таким образом, один и тот же ключ будет ограничивать большинство запросов, тем самым защищая базу данных db.
Фактически, ограничение тока также делится на локальное ограничение тока и распределенное ограничение тока.В следующих статьях я расскажу о локальном ограничении тока и распределенном ограничении тока, реализованном в Redis.
разбивка кеша
определение
Например, когда веб-сайт проводит Double Eleven или занимается секиллом и другими операционными действиями, то в это время трафик веб-сайта, как правило, будет очень большим, и определенный продукт станет популярным из-за продвижения, а трафик будет супер большой Если этот продукт, В это время по какой-то причине он выходит из строя в кеше, то трафик этого ключа будет мгновенно поступать в базу данных, тогда БД в конечном итоге не сможет удерживать, вниз, последствия можно себе представить, нормальные другие данные не могу запросить.
Посмотрите на картинку и скажите:
Ключ huawei pro в redis вдруг выходит из строя, может быть просрочен, а может быть устранен из-за нехватки памяти, тогда будет большой поток запросов к redis, и обнаружится, что у redis нет этого ключа, то эти трафик будет передан на Go up to DB и запросить соответствующий huawei pro.В это время DB больше не может держаться и не работает.
Как решить
На самом деле, в конечном счете, достаточно того, что больше трафика не может достичь БД, поэтому нам просто нужно ограничить трафик, поступающий в БД.
1. Ограничение тока
Как и выше, он в основном ограничивает трафик определенного ключа, когда этот ключ сломан, только один трафик ограничен для входа в базу данных, а другие отклоняются или ждут повторной попытки запроса redis.
График ограничения тока см. на графике ограничения тока разбивки кэша.
Также будет локальное ограничение тока и распределенное ограничение тока.
Что такое локальное ограничение тока, так это ограничение трафика этого ключа в рамках одного локального экземпляра, который действителен только для текущего экземпляра.
Что такое распределенное ограничение тока?В распределенной среде, в рамках нескольких экземпляров, накопление ограниченного трафика этого ключа является трафиком из нескольких экземпляров.При достижении лимита все экземпляры будут ограничивать трафик к БД.
2. Используйте распределенные блокировки
Вот краткое описание определения распределенной блокировки.В параллельном сценарии необходимо использовать блокировки для взаимоисключающего доступа к общим ресурсам для обеспечения потокобезопасности, аналогично в распределенном сценарии также требуется механизм для обеспечения что несколько узлов совместно используют ресурсы.Взаимоисключающий доступ, механизм реализации распределенных замков.
Общий ресурс здесь — это huawei pro в примере, то есть при доступе к huawei pro в db необходимо обеспечить наличие только одного потока или одного трафика для доступа, чтобы добиться эффекта распределенной блокировки .
Посмотрите на картинку и скажите:
Чтобы захватить замок:
После того, как большое количество запросов не получили значение ключа huawei pro, они идут к бд для получения данных.В это время добавляется код для получения бд с распределенной блокировкой, тогда каждый запрос и каждый поток будет получать распределенная блокировка huawei pro (распределенная блокировка реализована с помощью Redis на рисунке, и у меня будет отдельная статья, чтобы представить реализацию распределенных блокировок, не ограничиваясь Redis).
После получения блокировки:
В этот момент поток A получил распределенную блокировку huawei pro, затем поток A отправится в БД для загрузки данных, а затем поток A снова установит huawei pro в кеш, а затем вернет данные.
Другие потоки не получают его.Один из способов - напрямую вернуть нулевое значение клиенту.Другой способ - подождать 50-100 мс, потому что запрос БД и ввод Redis будут очень быстрыми.Ожидание в это время, при повторном запросе , результат может быть Есть, если нет, возвращайте null напрямую, конечно, вы можете повторить попытку, конечно, в сценарии большого параллелизма, вы все равно надеетесь быстро вернуть результат, а не повторять слишком много раз.
3. Горячая клавиша обновления задачи по времени
Это легко понять, грубо говоря, это временная задача регулярно отслеживать время ожидания некоторых горячих клавиш, не истекло ли оно, а затем увеличивать время кэширования ключа в кэше, когда оно вот-вот истечет. .
Метод опроса одного потока проверяет и обновляет время истечения срока действия, см. рисунок:
В многопоточном методе обратите внимание на то, что горячих клавиш не слишком много, и определенный поток будет открывать много.Если горячих клавиш много, можно использовать метод пула потоков, см. рисунок:
Реализация очереди задержки
Вышеупомянутый метод является тупым, будь то один поток или несколько потоков, он будет использовать метод опроса (ЦП каждый раз тратится впустую), чтобы проверить, скоро ли истечет срок действия ключа.Точный, это может привести к задержке времени или неточности.Когда вы ждут очередной проверки,ключ ушел,значит в это время произошла поломка.Хотя вероятность этого мала,но тоже возможно.,тогда как нам этого избежать?На самом деле мы можем использовать очередь задержки (круговая очередь для достижения, я не буду вдаваться в принцип этой очереди здесь, вы можете Baidu или Google сами), так называемая очередь задержки заключается в том, что вы отправляете сообщения в эту очередь, я надеюсь потреблять в соответствии с время, которое вы установили. Он не будет израсходован до истечения времени, и он будет израсходован, когда время истечет. Что ж, давайте поговорим о картинке:
1. При первом запуске программы получается время истечения срока действия ключа в списке.
2. Установите время задержки использования ключа по очереди.Обратите внимание, что это время потребления раньше, чем время истечения срока действия.
3. Когда очередь задержки истекает, потребитель потребляет ключ.
4. Потребитель потребляет сообщение и откладывает время истечения срока действия ключа в кэш.
5. Снова отправьте новое время истечения срока действия ключа в очередь задержки и дождитесь истечения срока действия следующего отложенного кеша.
4. Установка ключа не делает недействительной
На самом деле, этот вид ключа также может быть удален из-за нехватки памяти.Вы можете подумать об обстоятельствах, при которых ключ будет удален.
проникновение в кеш
определение
Так называемое проникновение заключается в доступе к ключу, которого нет в кеше и которого нет в базе данных.В это время это эквивалентно попаданию трафика в БД напрямую.Тогда некоторые мошенники могут воспользоваться этой уязвимостью и безумно почистите свой интерфейс, а затем поставьте Если ваша БД не работает, ваш бизнес не сможет нормально работать.
Как это решить?
1. Установите нулевое или специальное значение
Мы можем установить null или определенное значение в redis, и оно не истечет, тогда в следующий раз, когда вы придете снова, вы можете напрямую получить это значение null или специальное значение из redis.
Это решение не может решить фундаментальную проблему.Если этот трафик может имитировать большое количество бесполезных ключей, сколько бы нулей или специальных значений вы не установили, это бесполезно, так как мы должны это решить?
2. Фильтр Блума
Фильтр Блума — это bloomfiler на английском языке. Здесь мы даем лишь краткое введение. Из соображений экономии места будет отдельная статья, чтобы представить его позже.
Например, если мы храним в базе данных данные о десятках миллионов номеров артикулов, наше текущее требование — запрашивать у redis, есть ли в библиотеке этот артикул. Если у redis нет, запросите базу данных, а затем обновите redis. Поместите данные sku в хэш-карту, ключом является sku, потому что количество sku велико, тогда пространство памяти, занимаемое этой хэш-картой, будет очень большим, это может привести к разрыву памяти, и, наконец, выигрыш не стоит потери, Итак, как сэкономить память, мы можем использовать массив битов для хранения того, существует ли артикул или нет.0 означает отсутствие существования, 1 означает существование, мы можем использовать хеш-функцию для вычисления хеш-значения артикула, а затем хэш значение sku по модулю битового массива, найдите позицию массива и установите для нее значение 1. Когда придет запрос, мы вычислим, равна ли позиция массива, соответствующая хэш-значению sku, 1. Если это 1, это означает он существует, и если он равен 0, значит, его не существует. Реализован такой простой блумфильтр.У блумфилера есть частота ошибок.Можно подумать об увеличении длины массива и количества хэш-функций для обеспечения точности.Конкретно можно использовать Baidu или Google.Я не буду говорить об этом здесь сегодня .
Давайте посмотрим на процесс использования bloomfiler для предотвращения проникновения в кеш, посмотрим картинку и поговорим:
Инициализация bloomfiler может читать БД через запланированную задачу и инициализировать размер битового массива.Значение по умолчанию равно 0, что означает, что он не существует.Затем для каждого элемента вычисляется позиция массива, соответствующая хэш-значению , а затем вставляется в битовый массив.
Процесс запроса смотрите на картинке:
Если не использовать фильтр блумфилер, для ключа, которого нет в базе, по факту тратится два ИО, один редис запроса, одна БД запроса, с блумфилером, то эти два бесполезных ИО сохраняются, после сокращения Пустая трата ресурсов Redis и БД.
Суммировать
Сегодня мы рассказали о высокочастотных опросах Redis Cache и проблемах, возникающих в реальных боях, и их решениях.
- Кэш Лавина
решение:
- При установке срока действия добавьте случайное число времени, которое может быть в пределах нескольких минут.
- А что делать, если случилась настоящая лавина, можно воспользоваться методом ограничения тока.
- разбивка кеша
решение:
- Ограничение
- Распределенная блокировка
- Регулярно обновляйте горячую клавишу, здесь мы сосредоточимся на очереди задержки.
- Установленное время не истекает
- проникновение в кеш
решение:
- установить нулевое или конкретное значение для redis
- Реализовано с помощью Bloomfiler
Вот и все, чем мы сегодня поделимся, кодировать слова и рисовать картинки непросто, я с нетерпением жду вашихНравится, подписывайтесь, делайте репост,Благодарность.
Ваши лайки и внимание — самая большая движущая сила для создания Hurricane.
Если у вас есть какие-либо вопросы, пожалуйста, оставьте сообщение, обсудите и исправляйте вместе.
Добро пожаловать, чтобы следоватьgithub
WeChat добавить: zookeeper0