Разговор о дизайне системы выверки

предисловие

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

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

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

Общий дизайн системы

Структура системы согласования в основном разделена на следующие четыре модуля:

Модуль обработки данных канала
модуль обработки данных
проверить модуль
Модуль дифференциальной обработки данных

Схема иерархии последовательности вызовов модуля выглядит следующим образом.

Давайте сначала представим модуль обработки данных канала.

Модуль обработки данных канала

Этот модуль в основном отвечает за загрузку, анализ и хранение данных файлов согласования каналов.

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

Сторонние каналы регулярно передаются на SFTP/FTP. Этот режим относительно прост, мы регулярно получаем файлы сверки с SFTP/FTP.
Вызов интерфейса загрузки файла согласования стороннего канала. В этом режиме вам необходимо подключиться к каналу для загрузки интерфейса файла сверки и регулярно вызывать загрузку. Alipay и WeChat являются моделями.
Вручную загрузите файл сверки на веб-сайте платежного канала. Этот режим наименее дружественный и требует от нас человеческих усилий для скачивания файлов.

Помимо способа загрузки, есть некоторые отличия в формате файла сверки. Например, формат файла сверки Alipay — csv, формат файла сверки WeChat — txt, а некоторые другие каналы — xml и xls.

Количество полей и имена полей в стороннем файле согласования каналов также различаются.

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

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

商户号
商户订单号
渠道流水号
交易日期
交易金额
手续费
退款原订单号

Поговорим о некоторых деталях, на которые необходимо обратить внимание при разработке этого слоя.

1. Если вы подаете заявку на несколько идентификаторов продавца в одном и том же канале. В этом случае, если для каждого номера продавца в предыдущий день есть транзакция, сторонний канал сгенерирует файл сверки для каждого номера продавца. Поэтому при проектировании системы необходимо учитывать обработку нескольких документов сверки. 2. Файл сверки должен учитывать ситуацию повторной загрузки. При нормальных обстоятельствах после создания файла согласования канала он не изменится. Тем не менее, исключения могут также возникать в сторонних каналах, что приводит к неполной сверке данных файла, полученных нами. В этом случае должен быть механизм для повторной загрузки и анализа в библиотеке. 3. Время загрузки файлов с каждого стороннего канала разное.

модуль обработки данных

Поговорив о модуле обработки файлов сверки, давайте рассмотрим модуль обработки данных.

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

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

проверить модуль

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

Этот процесс может производить три типа разностных данных.

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

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

Третья ситуация заключается в том, что сумма не соответствует.

Эти три показаны на рисунке.

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

Модуль дифференциальной обработки данных

Этот модуль в основном используется для обработки разностных данных, сгенерированных предыдущим модулем.

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

Давайте сначала обсудим ситуацию с несколькими учетными записями на локальном конце.

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

Давайте сначала объясним концепцию дневной стрижки.

Дневной срез, говоря простым языком, это время смены системы учета, и система переключается с текущего рабочего дня на следующий рабочий день. Во время этого процесса, если наш заказ на транзакцию происходит в 23:59:59 в день T, то нашим учетным временем является день T. Время получения ордера по стороннему каналу — 00:00:01 дня Т+1, поэтому дата сверки транзакции на стороннем канале — день Т+1.

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

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

Затем в модуле обработки разницы дней T+1 извлекаются данные разницы за предыдущие дни, и данные нескольких учетных записей локального конца и данные нескольких учетных записей противоположного конца проверяются одна за другой. Если проверка непротиворечива, статус двух различий обновляется для обработки. В итоге, если не останется расхождений данных, счета будут выровнены в тот же день.

Псевдокод выглядит следующим образом:

Могут быть две ситуации, в которых генерируется одноранговый мультиаккаунт.

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

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

Если сторонний канал не может проверить статус заказа. Если мы подтвердим с помощью канала, что заказ, наконец, успешно оплачен, нам нужно изменить платежное поручение на успешный платеж и изменить статус счета разницы.

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

Оптимизация системы

В настоящее время задача синхронизации системы согласования системы использует функцию синхронизации Spring. Более поздняя оптимизация готова получить доступ к распределенному планировщику времени elasticjob, который может быстро изменить время запланированных задач без перезапуска программы. И может быстро запускать запланированные задачи.

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