эта статьяgithub/JavaMapОн был включен, есть карта расширенных технических знаний Java-программистов и моя серия статей, добро пожаловать в Star.
фон аварии
Компания недавно устроила волну срочных закупок товаров.Из-за ошибки работы младшего брата в фоновом режиме эффект от этой деятельности был плохим, и на него жаловались пользователи и агенты. Менеджер попросил меня взять моих коллег для ознакомления с онлайн-инцидентом.
Что вызывает это?
Снап-ап планируется начать вовремя в 0:00,
22:00 Оператор выкладывает товар онлайн через фон
23:00 Младший брат на заднем плане завез товар в тайник и заранее разогрел
На момент начала панической закупки трафик был очень большой, по плану большая часть запросов пользователей обрабатывалась через Redis, чтобы все запросы не попадали в базу.
Как показано на рисунке выше, ожидается, что большинство запросов попадет в кеш, но поскольку брат за кулисами предварительно нагревает кеш, время кеша всех продуктов истекает через 2 часа, все продукты недействительны в момент один и тот же момент времени, и все запросы мгновенно отбрасываются. В базе данных база данных не выдерживает давления и рушится, и время ожидания всех пользовательских запросов истекает, и сообщается об ошибке.
На самом деле все запросы попадают сразу в базу данных, как показано ниже:
Когда это было обнаружено?
В 01:02 утра SRE получил системный сигнал тревоги, вошел в систему управления эксплуатацией и обслуживанием и обнаружил, что ЦП и память узла базы данных превысили пороговое значение, и быстро связался с фоновым разработчиком, чтобы найти и устранить неполадки. .
Почему его не обнаружили раньше?
Поскольку срок действия параметра кеша составляет 2 часа, кеш может обработать большинство запросов до часа ночи, а служба базы данных находится в нормальном состоянии.
Какие действия были предприняты при его обнаружении?
После обнаружения проблемы с помощью поиска журналов и устранения неполадок младший брат в фоновом режиме выполнил ряд операций:
Сначала ограничьте большую часть трафика, поступающего через шлюз API (шлюз). Затем перезапустите неработающую службу базы данных. Разогрейте кеш еще раз После подтверждения того, что службы кеша и базы данных работают нормально, трафик шлюза будет выпущен в обычном режиме, а действия по паническим покупкам вернутся в нормальное состояние примерно в 01:30.
Как избежать этого в следующий раз?
Причиной этой аварии на самом деле была лавина кеша.Объем данных запроса был огромным, и запрос попадал прямо в базу данных, что приводило к перегрузке базы данных и закрытию.
Методы решения лавин кэша в отрасли на самом деле относительно зрелые, например:
- Истекает равномерно
- добавить мьютекс
- кеш никогда не истекает
(1) Равномерное истечение
Установите разные сроки действия, чтобы сделать временные точки аннулирования кеша как можно более одинаковыми. Обычно к сроку действия может быть добавлено случайное значение или период действия может быть запланирован единообразно.
(2) Добавить блокировку мьютекса
В соответствии с решением для разбивки кеша только одному потоку разрешено создавать кеш одновременно, а другие потоки блокируются и ставятся в очередь.
(3) Срок действия кеша не ограничен.
В соответствии с решением по разбивке кэша срок действия кэша никогда не истекает физически, а для обновления кэша используется асинхронный поток.
Итоги обзора
Изучив эту онлайн-аварию с коллегами, каждый получил более глубокое представление о лавине кеша. Чтобы избежать очередной аварии с лавиной кеша, мы вместе обсудили несколько решений:
(1) Равномерное истечение
(2) Добавить блокировку мьютекса
(3) Срок действия кеша не ограничен.
Я надеюсь, что технические специалисты могут испытывать благоговейный трепет перед каждой строкой кода!
-- END --
Ежедневные лайки: Привет, технари, сначала лайкайте, а потом смотрите, чтобы выработать привычку, ваши лайки — движущая сила на моем пути вперед, а следующий выпуск будет более захватывающим.
Введение: Блогер окончил Хуачжунский университет науки и технологий со степенью магистра, он программист со страстью к технологиям и страстью к жизни. За последние несколько лет он побродил по многим интернет-компаниям первой линии и имеет многолетний опыт разработки.
Публичный номер поиска в Wechat [Архитектор, который любит смеяться], у меня есть технологии и истории, которые ждут вас.
Статья постоянно обновляется вgithub/JavaMapВы можете увидеть мою заархивированную серию статей в , с опытом интервью и техническими галантерейными товарами, добро пожаловать в Star.