Оригинал Запись онлайн-процесса устранения неполадок с медленным запросом Mysql

Java

задний план

Некоторое время назад я получил отзывы об эксплуатации и обслуживании, и онлайн-база данных Mysql рано утром выдала сигнал о медленном запросе и отправила исходный SQL:

--去除了业务含义的sql
update test_user set a=1 where id=1;

Объем данных в таблице около 200 Вт, что не очень много, и обновляется она по первичному ключу.

Устранение неполадок

  1. Устранение неполадок базы данных Mysql

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

  1. Проверьте бизнес-код (первый раз)

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

  1. Проверьте бизнес-код (второй раз)

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

Говоря об общем процессе системы, WeChat (A) перезванивает в нашу кассовую службу (B), кассир обновляет информацию о заказе и звонит в бизнес-службу (C).

Причина проблемы:

В первый раз, когда A вызывает B, B блокирует строку и вызывает C. В это время C не отвечает, в результате чего A отправляет второй запрос.

Второй вызов B, B для обновления записей, когда возникает взаимоблокировка, появляются медленные запросы.

решение

  1. Метод получения обратного вызова кассовой системы B добавляет распределенную блокировку, чтобы гарантировать, что один и тот же заказ может быть обновлен только один раз в одно и то же время.

  2. Касса использует HttpClient 4.4 для вызова бизнес-сервиса.Тайм-аут по умолчанию 60 секунд.Если другая сторона не отвечает в течение такого длительного времени, он будет завершен.Если изменить его на 5 секунд, тайм-аут будет возвращен немедленно, не затрагивая другие службы.

Версия HttpClient4.4 устанавливает код тайм-аута следующим образом:

 HttpPost httpPost = new HttpPost(url);
 RequestConfig.custom().setSocketTimeout(5000).setConnectTimeout(5000).setConnectionRequestTimeout(5000).build();
 httpPost.setConfig(requestConfig);

Выше установлены три тайм-аута со следующими значениями:

SetConnectTimeout: Установите тайм-аут соединения в миллисекунды.

setConnectionRequestTimeout: установите время ожидания для получения соединения от диспетчера соединений в миллисекундах. Это новое свойство, поскольку текущая версия может совместно использовать пул соединений.

setSocketTimeout: тайм-аут для запроса сбора данных в миллисекундах. Если к интерфейсу обращаются и данные не могут быть возвращены в течение определенного периода времени, вызов просто отбрасывается.

Наконец, после преобразования и запуска этих двух схем система работает нормально и проблема решена.

Рекомендуемое чтение

1. Оригинал | Как решить проблему OOM при парсинге POI в Excel?

Если вы считаете, что статья хорошая, я надеюсь, что вы можете переслать ее или «посмотреть», большое спасибо! Подпишитесь на официальный аккаунт ниже и ответьте «1024», вас ждут сюрпризы!

Категории