Список оптимизаций в версии Системы lmxR4 (2022.2)


Переход на Apache Kafka в асинхронной обработке операций и событий в платёжной системе

Для повышения производительности платёжной системы была изменена логика работы с очередями в ней.

  • Было: все новые транзакции попадали напрямую в базу данных, после чего в фоновом режиме обрабатывались специальным background сервисом.
  • Стало: все новые транзакции попадают в специальную распределённую потоковую платформу Kafka.

Платформа Kafka позволяет:

  • повысить отказоустойчивость Системы за счёт распределения данных на разные узлы;
  • горизонтально масштабировать нагрузку;
  • за счёт высокой пропускной способности обрабатывать в реальном времени абсолютно все проходящие через неё события;
  • не накапливать тем самым очереди для перевода средств между счетами.

Передача данных по транзакциям из системы Loymax в Kafka происходит через распределение сообщений по партициям. Были внесены изменения, благодаря которым теперь транзакции, связанные определённой кассой (например, создание и подтверждение покупки) размещаются в одной и той же партиции. Для предотвращения повышенной нагрузки на процессинг и блокировки со стороны Системы следует отправлять запросы от одной кассы только в 1 поток одновременно.

Документно-ориентированный подход к хранению истории и интеграция protobuf.net в EasyNetQ

В HistoryItem добавлены столбцы LoyaltyUID, MerchantUID, DeviceUID, IsEmulation. Данные изменения необходимы для поддержки работы разделов Управление покупками и Тестовая касса.

Произведён перенос на документы для уменьшения объёма данных. Все вышеупомянутые столбцы остались в том же виде, а все таблицы, связанные с HistoryItem, представлены в сериализованном, сжатом бинарном формате Protobuf.

Интеграция позволила значительно снизить уровень потребления памяти каждым сообщением.

Для уменьшения нагрузки на операционную БД и сокращения объёма хранящихся в ней данных, все покупки старше N дней перемещены в историческую БД. При переносе данных, в историческую БД записываются полные данные о покупке, достаточные для работы пользователей Системы.

  • Разделы АРМ Управление покупками и Клиентская история в карточке клиента отображают полную информацию о покупке, получая её из исторической БД. 
  • Полная информация о новых покупках записывается в историческую БД.
  • Настроенные регулярные задачи удаляют из операционной БД всю информацию о покупках старше заданного периода и устаревшие данные из исторической БД.

Разработан специальный сервис, который приводит покупки из реляционного формата и формата хранения документа Version 1 к документному хранению Version 2. За счёт изменения формата хранения происходит сжатие и оптимизация данных о покупках.

Оптимизация пакетных операций

Удалось значительно повысить скорость пакетных операций за счёт:

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

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

Пакетная операцияКоличество обрабатываемых данныхДо оптимизацииПосле оптимизации

Импорт номеров карт

300 000 номеров карт6 часовот 3 до 11 минут
Импорт атрибутов клиентов, обязательных для регистрации300 000 клиентов30 минут10 минут
Импорт необязательных атрибутов клиентов300 000 клиентов6 часов11 минут
Импорт паролей300 000 паролей5 часов11 минут
Регистрация клиентов300 000 клиентов9 часов10 минут

Также оптимизирована скорость пакетного чтения сообщений из очередей Rabbit.

Новый способ хранения покупок: информация о покупке в виде JSON-документа

Изменился способ хранения покупок. Теперь вместо реляционной модели хранения покупки используется хранение информации о позициях, операциях и результатах обработки в виде JSON-документа. Это позволило ускорить вставку этой информации и преодолеть лимит в 200 чеков в секунду (вплоть до 500 чеков).

Примечание: новый способ хранения покупок не влияет на структуру исторической БД, которая хранит в себе данные о покупках для отображения истории операций в клиентских сервисах или АРМ.

Повышение производительности работы акций

Для повышения скорости работы акций были проведены следующие оптимизации:

  • Параметры акции (фильтры и действия) полностью переведены на кэширование, что позволило ускорить доступ к ним;
  • Исключены внутренние блокировки акций со статусной системы, что позволило повысить скорость работы акций со статусными системами.

Актуализация индексов

  1. Было удалено 15 неиспользуемых индексов. Это позволило уменьшить общий размер таблиц, а также позволило незначительно повысить скорость вставки.
  2. Оптимизированно 6 индексов, что позволило повысить быстродействие некоторых запросов путём снижения нагрузки на ядро БД.

Оптимизация методов получения атрибутов клиента

Для увеличения скорости обработки запросов для получения информации об атрибутах клиентов:

  • Оптимизированы таблицы в БД (за счёт уменьшения размера таблицы в 2 раза);
  • Улучшена фильтрация, которая теперь происходит строго по индексам.

Сняты ограничения по общему объему клиентов

Из Системы убрано ограничение по общему объёму клиентов в 200 млн.

Регулярная очистка данных о покупках старше заданной даты

Для оптимизации хранения информации в Базах данных (БД) и для своевременной очистки информации была сделана регулярная задача "Очистка событий".

При запуске регулярной задачи происходит процесс удаления информации из таблицы бизнес-активностей в базе данных. Таким образом проводится автоматическая очистка БД от старых записей (событий, которые уже были завершены в Системе).

Результаты, полученные в ходе работы регулярной работы представлены в таблице:

 Описание
Продолжительность работыЗа один цикл работы регулярной задачи продолжительностью в один час из Базы данных была удалена информация примерно о 1 500 000 событий. Примерный объем удаленной информации — 2,5 Гб.
Результаты фоновой работы регулярной задачи
  • Нагрузка на CPU не более 40% (при совместной фоновой работе кассового шлюза, API и регулярной задачи).
  • Нагрузка на ОЗУ в пределах норм:
    • до работы регулярной задачи было доступно 5,28 Гб,
    • во время работы регулярной задачи 5 Гб.

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

Влияние на работу Личного кабинета и мобильного приложенияРегулярная задача не виляет на работу Личного кабинета и Мобильного приложения.
Влияние на данные BIДанные в BI остаются без изменений.
Влияние на АРМ

Ниже представлено сравнение результатов работы регулярной задачи (на примере просмотра информации по покупке):

До запуска регулярной задачиПосле завершения работы регулярной задачи

Оптимизация информации о покупках

Оптимизирована таблица БД, связанная с покупками:

  1. Информация о покупках (например, номер чека, идентификатор покупки, чековые позиции и т. д.) сохраняется в сжатом виде.
  2. В таблице не сохраняется название акции, только её идентификатор.

Это позволяет снижать объём хранения данных.

Оптимизирован процесс записи в историю операций пакетных начислений и списаний

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

Оптимизирована работа загрузчика в тестовой кассе

Проведен рефакторинг кода, который улучшил работу загрузчика при совершении покупок на тестовой кассе.

Доработка SDK для реализации отдельного метода подтверждения покупки

Реализован отдельный метод подтверждения покупки, который выполняет дополнительную проверку клиентского идентификатора из чека, сравнивая его с идентификатором, указанным в покупке в БД.

Новости
Обновления
Облако тегов
Словарь
Наш блог
YouTube и Rutube
Telegram