Avalanche, Penetration, Breakout Summary of Redis Cache

• Важная роль кэширования в больших параллельных системах очевидна. Кэширование — это операция в памяти на микросекундном или миллисекундном уровне. Обойти этот кеш в интернет-компаниях совершенно невозможно. В кеше много mc, redis и т.д. Здесь описывается redis.Поскольку redis может быть постоянным, а mc — это чистая память, перезапуск машинных данных не может быть получен. Redis также может повторно импортировать данные с диска. Кэш — еще одна проблема, которой нельзя избежать. Это лавина, пробой, проблема проникновения.

Лавина кеша:

• 1. Феномен:
     Воздействие незначительное, запросы становятся медленнее, а когда параллелизм запросов выше, крупномасштабная служба становится недоступной.
• 2. причина:
     При этом кеш выходит из строя на большой площади, так же как и нет кеша, все запросы напрямую отправляются в БД, и БД не может его удержать. .
• 3. Случай:
     Кэш домашней страницы электронной коммерции, если все ключи на домашней странице недействительны в определенный момент, и в этот момент есть активность seckill, тогда все запросы будут отправлены в БД. В случае большого параллелизма БД не сможет с этим справиться, если нет другого решения типа даунгрейда, то БД может только перезапустить БД, но это будет зависать новым трафиком.
• 4. решение:
     При пакетном хранении данных в redis добавляйте случайное число ко времени истечения срока действия каждого ключа, чтобы гарантировать, что данные не будут давать сбой в большой области одновременно.

Проникновение в кэш:

• 1. Явление и причина:
     Это означает, что данные, которые пользователь постоянно инициирует запросы, не существуют в кеше и БД.Например, идентификатор пользователя в БД самоувеличивается, но пользователь запрашивает -1, или особенно большое число.При этом время, пользователь, скорее всего, является злоумышленником.Такая силовая атака вызовет чрезмерную нагрузку на БД, а если это серьезно, БД зависнет. Потому что он обходит кеш и каждый раз напрямую запрашивает БД
• 2. решение:
     
  • Способ 1: добавьте проверку на уровне интерфейса и напрямую возвращайте недопустимые параметры. Если вы не верите в вызывающую задачу, в соответствии со спецификацией интерфейса API, предоставленной вами как вызывающей стороной, вы должны учитывать любые значения передачи параметров.
  • Способ 2: В случае, когда кеш не может быть найден и его нет в БД, вы можете записать значение соответствующего ключа как null, или записать в кеш другие специальные значения, а время истечения установить равным более короткое время, чтобы не влиять на нормальную ситуацию. Это предотвращает повторные атаки грубой силы с одним и тем же идентификатором.
  • Способ 3: Обычные пользователи не будут делать такие насильственные атаки.Это будут делать только злоумышленники.Вы можете сделать пункт конфигурации в шлюзе NG, чтобы установить порог доступа для каждого IP.
  • Способ 4: Фильтр Блума для опытных пользователей (Bloom Filter), это также может хорошо предотвратить проникновение в кеш. Принцип заключается в использовании эффективных структур данных и алгоритмов, чтобы быстро определить, существует ли ваш ключ в БД.Если он не существует, вы можете его вернуть.Если он существует, вы можете проверить БД, чтобы обновить KV и вернуть его.

Разбивка кеша:

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

Суммировать:

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

• Предварительно: высокая доступность Redis, главный-подчиненный + дозорный, кластер Redis, чтобы избежать полного краха.
• В процессе: локальный кеш ehcache + текущее ограничение Hystrix + даунгрейд, чтобы избежать уничтожения **MySQL**.
• Постфактум: Redis сохраняет RDB + AOF. После перезапуска он автоматически загружает данные с диска и быстро восстанавливает кэшированные данные.

Расширьте свои знания:

Вы можете использовать текущий ограничивающий компонент, чтобы установить запрос в секунду, сколько может передать компонент, и оставшиеся неудачные запросы, что мне делать?перейти на понижение! Может возвращать некоторые значения по умолчанию, дружественные подсказки или пустые значения.
Преимущество этого в том, что: база данных никогда не умрет, а компонент регулирования гарантирует, что только то количество запросов, которое может пройти в секунду. Пока база данных не умирает, это означает, что 3/5 запросов могут быть обработаны пользователем. Пока 3/5 запросов могут быть обработаны, это означает, что ваша система не умерла.Для пользователя может быть так, что страница не может быть пролистнута после нескольких кликов, но после еще нескольких кликов она может быть пролистал один раз.
Выдержка из Интернета