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

01 、фон

В ходе формирования команды по гибкому подходу в этом году я внедрил автоматическое модульное тестирование в один клик с помощью Suite executor. Кроме экзекьютора Suite, какие еще экзекьюторы есть у Juint? Здесь начинается мое путешествие по исследованию Раннера!

Мониторинг тестового производства обнаружил ошибку взаимоблокировки базы данных: org.springframework.dao.DeadlockLoserDataAccessException:

### Error updating database. Cause: com.mysql.cj.jdbc.exceptions.MySQLTransactionRollbackException: Deadlock found

Как обнаруживается тест?

Начнем с некоторого времени назад.

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

B: В настоящее время проверку производства можно выполнить только путем обращения к деловому персоналу для проверки производства.

Ответ: Тогда давайте проверим и исследуем здесь и посмотрим, какие методы доступны.

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

Именно такой разговор заставил меня открыть для себя инструмент EasyBI, и началась моя судьба с этим инструментом!

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

02 、Подробное описание работы инструмента EasyBI

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

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

Затем была выполнена настройка в соответствии с документацией по использованию инструмента EasyBI. Подробные операции см. в следующем анализе.

(1) Доступ к данным

Настроить разработанный интерфейс на инструментальной платформе EasyBI (EasyBI (jd.com))

(2) Конфигурация приложения

Создайте приложение, настройте настроенные данные интерфейса графически в виде сводных таблиц, гистограмм и т.п. и выведите в таком виде данные мониторинга.

(3) Управление подпиской

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

(4) Анализ данных мониторинга

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

• Интерфейс статистики информации об ошибках
  • 1.1 Классифицируя различные сообщения об ошибках в претензиях, можно определить количество сообщений об ошибках за день, на этой неделе, на прошлой неделе и на предыдущей неделе, что можно обнаружить во времени путем сравнения. Стабильность существующей системы, Корректность данных урегулирования претензий、Рациональность проверки бизнес-логики
  • 1.2 Статистика различных сообщений об ошибках отображается по категориям в таблице сведений о платформе easyBI.
  • 1.3 Своевременно определите, является ли это обычной деловой проверкой или нештатной проблемой, в зависимости от типа ошибки урегулирования претензии.

  

• Еженедельная статистика неудач и успехов, ежедневный интерфейс данных об успехах и неудачах
  • 2.1 Основные продукты группового страхования、Основные продукты личного страхования、Система претензий успешно обрабатывает претензии в течение одной недели подряд или в тот же день.данныеи ошибкаданныестатистика,Своевременно выявляйте правильность основных услуг по рекламациям продуктов путем сравнения,Обеспечивать своевременность урегулирования претензий клиентов.
  • 2.2 Еженедельные данные отображаются в виде гистограммы на платформе easyBI в соответствии с планом продукта, а ежедневные данные отображаются в виде гистограммы на платформе easyBI в соответствии с планом продукта.

  

  

В процессе разработки также возникают некоторые проблемы. Как они решаются?

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

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

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

org.springframework.dao.DeadlockLoserDataAccessException:

### Ошибка обновления базы данных. Причина: com.mysql.cj.jdbc.Exceptions.MySQLTransactionRollbackException: Deadlock обнаружил эту ненормальную информацию о бизнес-исключении.

После открытия синхронизируйтесь с руководством

А: Вау! Мониторинг сделан хорошо

Б: Я буду продолжать усердно работать.

03 、Мысли и резюме

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

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

Началась дискуссия с коллегами

Б: Аномальные данные, которые я обнаруживаю сейчас, регулярно отправляются через инструмент EasyBI. Как я могу обнаружить аномальные данные в режиме реального времени?

C: Вы можете установить пороговое значение. Если аномальные данные превысят этот порог, мы определим это как аномальное.

Б: Можно ли сообщить об этой ненормальной ситуации соответствующему персоналу через сигнализацию Jingme?

С: Это хороший способ

Если у вас есть идея, просто сделайте это

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

Из-за этой тревоги были обнаружены производственные отклонения;

Восходящая система передает неподдерживаемую информацию о вознаграждении и оперативно уведомляет интерфейсную систему и связанные с ней предприятия.