• Переход на Apache Kafka в асинхронной обработке операций и событий в платёжной системе
• Документно-ориентированный подход к хранению истории и интеграция protobuf.net в EasyNetQ
• Оптимизация пакетных операций
• Новый способ хранения покупок: информация о покупке в виде JSON-документа
• Повышение производительности работы акций
• Актуализация индексов
• Оптимизация методов получения атрибутов клиента
• Сняты ограничения по общему объему клиентов
• Регулярная очистка данных о покупках старше заданной даты
• Оптимизация информации о покупках
• Оптимизирован процесс записи в историю операций пакетных начислений и списаний
• Оптимизирована работа загрузчика в тестовой кассе
• Доработка SDK для реализации отдельного метода подтверждения покупки
• Оптимизация работы регулярных задач

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оптимизация работы регулярных задач

Ускорена работа регулярной задачи статусной системы для любимых товаров. Теперь обработка запроса занимает менее 2 с (ранее — от 2,9с).