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


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

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

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

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

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

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

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

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

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

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

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

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. В таблице не сохраняется название акции, только ее идентификатор.

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

 

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