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

1. Проникновение в кэш

В большинстве интернет-приложений кэш используется, как показано на следующей диаграмме:

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

После понимания описанного выше процесса давайте поговорим о проникновении в кеш.

1.1 Что такое проникновение в кэш?

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

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

1.2 Вред проникновения в кэш

Если будут массовые запросы на запрос данных, которых вообще не существует, то эти массовые запросы будут попадать в БД, нагрузка на БД резко возрастет, и система может дать сбой (вы должны знать, что наиболее уязвимая часть Текущая бизнес-система — это IO. Она рухнет под давлением, поэтому мы должны думать о способах ее защиты).

1.3 Почему происходит проникновение в кеш?

Существует множество причин проникновения в кеш, обычно это две:

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

1.4 Решения для проникновения в кэш

Вот два способа предотвратить проникновение в кеш.

1.4.1 Кэшировать пустые данные

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

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

1.4.2 BloomFilter

Второй способ избежать проникновения в кеш — использовать BloomFilter.

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

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

1.4.3 Сравнение двух схем

Оба решения могут решить проблему проникновения в кеш, но сценарии использования разные.

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

2. Лавина кеша

2.1 Что такое кэш-лавина?

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

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

Это кеш-лавина.

2.2 Как избежать лавины кеша?

2.2.1 Используйте кластер кеша для обеспечения высокой доступности кеша

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

2.2.2 Использование Hystrix

Hystrix — это «антилавинный инструмент» с открытым исходным кодом, который снижает потери после схода лавин с помощью трех средств плавления, понижения версии и ограничения тока.

Hystrix — это библиотека классов Java, которая принимает командный режим, и каждый запрос на обработку службы имеет свой собственный процессор. Все запросы проходят через соответствующие обработчики. Процессор записывает частоту отказов запросов текущей службы. Как только будет обнаружено, что частота отказов запросов текущей службы достигает заданного значения, Hystrix отклонит все последующие запросы службы и напрямую вернет заданный результат. Это так называемый "предохранитель". Через некоторое время Hystrix отпустит некоторые запросы службы и снова подсчитает частоту отказов запросов. Если частота отказов запросов соответствует заданному значению в это время, текущий концевой выключатель полностью включен; если частота отказов запросов все еще высока, все запросы на услугу будут по-прежнему отклоняться. Это называется«Ограничение». И Hystrix напрямую возвращает предварительно заданный результат на эти отклоненные запросы, называемые"Понижение"**.

Дополнительные сведения о Hystrix см. по адресу: https://segmentfault.com/a/1190000005988895.

3. Централизованный сбой данных горячих точек

3.1 Что такое централизованный сбой данных точки доступа?

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

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

Если данные определенной точки доступа терпят неудачу, то при повторном запросе данных [req-1] они будут отправлены в базу данных для запроса. Однако в период с момента отправки запроса в БД до момента обновления данных в кеше, так как таких данных в кеше еще нет, запросы-запросы, поступающие в этот период, все попадут в БД, что приведет к повреждению базы данных.Огромное давление. Кроме того, кэш повторно обновляется по завершении этих запросов.

3.2 Решения

3.2.1 Мьютекс

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

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

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

3.3.2 Установка различных сроков действия

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