0 Предисловие
В повседневной жизни, от офлайн-покупок в супермаркетах до онлайн-заказов на вынос, онлайн-покупок в электронной коммерции и т. д., оплата происходит постоянно, будь то наличные деньги, считывание карты с помощью POS-терминала или сторонние платежи, такие как WeChat Alipay. Онлайн-платежи максимально своевременны и удобны за один раз.Конечно, бывают случаи, когда процесс не достаточно гладкий.Например, мы купили билеты на поезд в версии для ПК 12306 в первые дни.После оплата завершена, статус оплаты заказа часто не обновляется вовремя, будет период временных задержек, а иногда даже долгое ожидание в статусе неоплаченного.
В процессе оплаты по разным причинам (например, проблемы с внешними каналами, задержки асинхронных обратных вызовов) процесс останавливается на полпути, и пользователи видят, что заказ еще не оплачен, и они не будут знать, что делать в этот момент , необходим механизм, облегчающий завершение этой транзакции. В данной статье в качестве примера рассматривается механизм пополнения в трехсторонней платежной системе для введения более общего режима компенсации документов.
1. Знакомство с трехсторонней платежной системой
1.1 Что такое трехсторонний платеж
Так называемый сторонний платеж — это сторонний независимый институт, который подписал контракты с крупными банками, независим от продавцов и банков, имеет определенную силу и доверие и предоставляет платежные и расчетные услуги для продавцов и потребителей. Он является заслуживающей доверия третьей стороной между покупателем и продавцом и берет на себя роль гаранта и хранителя средств. Трехсторонняя оплата также может называться оплатой виртуального счета.Потребители открывают виртуальный счет в стороннем платежном учреждении и расплачиваются средствами на виртуальном счете. Общие трехсторонние платежи в отрасли включают Alipay, WeChat Pay, Meituan Pay, JD Pay и так далее.
1.2 Транзакция и платежная система при трехстороннем платеже
Что такое транзакция, наиболее интуитивно понятное описание - «оплата из одних рук, поставка из первых рук», и транзакция заставит покупателя и продавца сформировать права кредитора и отношения долга.Наличие транзакции является предпосылкой платежа, и пользователь завершает транзакцию, используя определенный способ оплаты.. Транзакция является движущей силой платежного процесса, и различные платежные инструкции комбинируются в соответствии с конкретными сценариями для завершения перевода средств транзакции.
Платежи — это инструменты транзакций для обработки потока денег., цель состоит в том, чтобы погасить права кредитора и долговые отношения, поддержка различных способов оплаты (таких как оплата банковской картой, оплата баланса, оплата купона, кредитная оплата, аналогичная Huabei и т. д.) Возможность получать платежные инструкции и управлять завершить обмен средств. Объедините фактическое платежное поведение (фактические средства) с внутренней бухгалтерией (виртуальные средства), чтобы обеспечить соответствие между реальным и реальным.
Общая бизнес-структура трехстороннего платежа показана на рисунке 1, где ядро транзакции и ядро платежа находятся в «области приобретения и оплаты» с точки зрения бизнес-подразделения и имеют общие функции, такие как сбор, оплата, возврат и пополнение счета, перевод и снятие обычных транзакций, а также возможность оплаты, гарантии и разделения счетов для поддержки бизнеса электронной коммерции. Среди них ядро транзакций и платежей имеет модуль проверки и компенсации аномалий, который включает в себя процесс компенсации всех предприятий, и также является основной частью этой статьи.
Рисунок 1. Архитектура трехстороннего платежного бизнеса
2. Что такое допзаказ и зачем нужен допзаказ
Транзакция прерывается из-за различных аномалий в звене в процессе оплаты.В это время транзакция находится в промежуточном состоянии.Эта ситуация широко известна как "заказ карты", то есть карта туда не перемещается и не не продолжать идти вниз. Также бывает ситуация, когда платежное ядро инициирует вывод на канал.После того, как канал принял платеж, вывод с банковской карты проходит успешно, но по разным причинам платежное ядро не инициирует обратный вызов, в результате чего платеж не проходит. завершена, а пользователь не имеет соответствующих прав и интересов.Списаны деньги с банковской карты, что называется «сброшенный счет».
Будь то карточный заказ или сброшенный заказ, это промежуточный заказ.Пополнение заказа заключается в компенсации заказа в промежуточном состоянии до тех пор, пока он не будет переведен в конечное состояние (успешно или неудачно).. Как правило, при составлении приказа есть два ключевых момента. Один из них - эффективность компенсации. В крайних случаях компенсация может быть неудачной много раз, поэтому от нее нельзя отказываться. Должен быть восходящий механизм; другой - своевременность компенсации, потому что транзакция находится на рассмотрении.Чем дольше время, тем хуже пользовательский опыт.
Ядро транзакций и ядро платежей дополняют друг друга и имеют определенную степень схожего дизайна и реализации.В качестве примера мы возьмем ядро платежей, чтобы представить механизм нештатного пополнения заказа.
3. Как осуществляется дополнительный заказ
В этой главе сначала рассматривается бизнес-процесс, объясняются предпосылки и основы, необходимые для реализации пополнения заказа, а затем вводится путь эволюции механизма пополнения заказа, проблемы, существующие в каждой версии, и способы их решения в следующей версии.
3.1 Конечные автоматы и идемпотентность
Конечный автомат, идентифицирующий денежную операцию
Во-первых, мы возьмем, как пользователь инициирует снятие баланса в качестве примера, чтобы проиллюстрировать бизнес-процесс, как показано на рисунке 2 после упрощения.
Рисунок 2. Процесс вывода баланса
Сначала сгенерируйте платежное поручение, затем запросите у бухгалтерской системы вычет остатка по счету пользователя, а затем инициируйте платежную операцию во внешние каналы.После завершения операции с фондом результат обрабатывается единообразно, а информация о документе обновляется. , есть некоторые асинхронные уведомления для восходящего и нисходящего потоков, формально включает сообщения и обратные вызовы RPC.
Мы храним записи о статусе каждой ключевой операции фонда, как показано в таблице ниже. Среди них, откуда приходят деньги, когда деньги выходят, куда идут деньги, когда приходят деньги, и происходит откат транзакции, когда она реверсируется. В сценарии вывода деньги выплачиваются с платежного счета пользователя на банковскую карту пользователя. В других сценариях, таких как пополнение счета (банковская карта -> платежный счет пользователя), движение средств будет другим. Сцены в последних двух строках, выделенных жирным шрифтом в таблице, еще не достигли конечного состояния, и нам нужно их компенсировать.
| Различные этапные сценарии вывода баланса | Статус платежа | Статус депозита | состояние сброса | общий статус |
|---|---|---|---|---|
| начальное состояние | INIT | INIT | INIT | PROCESSING |
| Вывод средств успешно | SUCCESS | SUCCESS | INIT | SUCCESS |
| Если баланс пользователя успешно списался, но платеж на банковскую карту не проходит, необходимо инициировать реверс на счет, то есть откат баланса пользователя. | SUCCESS | FAILED | SUCCESS | REVERSED |
| Недостаточный баланс пользователя, списание не выполнено | FAILED | INIT | INIT | FAILED |
| Время дебетования учетной записи пользователя истекло или возвращено в обработку | PROCESSING | INIT | INIT | PROCESSING |
| Вызов канала для оплаты банковской карты истек по таймауту или вернулся в обработку | SUCCESS | PROCESSING | INIT | PROCESSING |
Для простоты понимания мы опускаем здесь соответствующие операции реверсирования, а переход конечного автомата процесса снятия баланса показан на рисунке 3.
Рисунок 3. Процесс вывода баланса с переходами конечного автомата
Гарантии реентерабельности и идемпотентности
Инициирование платежа будет включать в себя несколько межсистемных вызовов, а тайм-ауты связи из-за сетевых причин являются распространенной проблемой. В то же время вышестоящая система также может повторно инициировать запрос, что требует от нашей системы обеспечения идемпотентности результата операции. У небольшого числа пользователей также могут быть одновременные запросы, вызванные одновременными операциями нескольких терминалов, что требует от нас обеспечения повторного входа в интерфейс. В дополнение к самой службе, наши подчиненные зависимости также должны гарантировать, что их интерфейсы имеют одинаковые возможности.
Сначала поговорим о реентерабельности и идемпотентности.
- Реентерабельный: корректность гарантируется при одновременных запросах.
- Идемпотентность: повторите один и тот же ввод несколько раз, чтобы получить один и тот же вывод. Технически идемпотентность также включает требования к повторному входу.
Конкретно в бизнесе идемпотентность для платежа, который достиг конечного состояния.Для запроса, который не может получить окончательный бизнес-результат в первый раз, результат повторной инициации вызова может быть другим (Обработка -> Успешно обработано или провал). Так как же обеспечить повторную входимость и идемпотентность бизнес-процессов? Разберем каждый шаг отдельно, чтобы увидеть:
- Создание платежного поручения: во-первых, платежное поручение может использовать уникальный внешний номер заказа, переданный деловой стороной, в качестве уникального индекса. Если при вставке в базу данных возникает конфликт уникального индекса, существующие данные будут проверены на предмет проверки идемпотентного параметра. Если параметры второго запроса полностью совпадают, значит, это повторный запрос, и платежное поручение в БД можно использовать для продолжения последующего процесса, при несоответствии будет возвращена ошибка.
- Поток обработки средств: системы счетов и каналов гарантируют идемпотентность своих интерфейсов. Также мы поддерживаем состояние каждой нисходящей операции, решаем, продолжать ли продвижение в соответствии с конечным автоматом, и стараемся не выводить дублирующийся трафик на нисходящий поток. Например, платежное поручение завершило всю обработку средств, а конечный автомат уже находится в конечном состоянии, тогда интерфейс может напрямую вернуть соответствующий результат.
- Чтобы обновить информацию о платежном поручении, сначала добавьте монопольную блокировку на уровне строки к платежному поручению, а затем обновите ее, чтобы обеспечить успешное выполнение только одного из нескольких одновременных запросов.
- Асинхронное уведомление, которое выполняется после доведения платежного поручения до конечного состояния.
Благодаря гарантиям повторного входа и идемпотентности мы можем повторно использовать процесс переадресации для реализации интерфейса пополнения.
3.2 Первоначальный выпуск
Вообще говоря, наиболее распространенной формой пополнения является установка запланированной задачи для регулярного сканирования счетчика для завершения коммерческой компенсации Реализация относительно проста, но своевременности недостаточно, а пользовательский опыт не подходит для таких транзакций, как сбор и передача. Мы применяем метод мгновенной компенсации через очередь сообщений, как показано на рисунке 4. Потребитель компенсации не выполняет работу по компенсации, а анализирует сообщение, а затем вызывает интерфейс компенсации, предоставляемый платежным ядром, через RPC. Почему бы не компенсировать непосредственно у потребителя? В основном это делается для того, чтобы рассмотреть возможность объединения логики в одном месте для облегчения обслуживания.
Рисунок 4. Процесс пополнения при аномальном выводе баланса
Конечно, пополнение все равно может не получиться, и мы можем снова отправить сообщение о компенсации. Но так зацикливаться нельзя, поэтому нужно установить максимальное количество повторов, после которого оно не будет отправлено. Когда компенсация не выполняется много раз, как правило, возникает проблема с нисходящей системой. В это время нам нужно замедлить частоту компенсации. По мере увеличения количества повторных попыток временной интервал для каждой компенсации будет постепенно увеличиваться. сообщение о задержке RocketMQ выполнить.
Вот три вопроса, которые приходят на ум:
- Если сообщение об исключении не удается отправить и в восходящем направлении нет механизма повторной попытки, порядок может зависнуть здесь навсегда, как показано на рис. 5.
- Когда потребитель компенсации не может запросить оплату основного дополнительного заказа, это может быть связано с тайм-аутом, но фактическая компенсация выполнена успешно или запрос вообще не прошел, как показано на рисунке 6.
- Если максимальное количество повторов все равно не увенчалось успехом, что делать с этим заказом.
Рисунок 5. Не удалось отправить компенсационное сообщение
Рис. 6. Сбой потребления сообщения о компенсации
3.3 Улучшенная версия
Для проблемы 1, если повторная попытка по-прежнему не может быть отправлена, мы можем решить ее, введя таблицу сообщений об исключениях и сохранив неудачные сообщения в базе данных. В таблицу записываются такие поля, как номер заказа, текущее количество повторных попыток, классификация исключений, статус записи и тело сообщения. Если отправка сообщения на шаге 4 на рис. 6 не удалась, заказ будет помещен в таблицу исключений в БД, и для его обработки будет настроено запланированное задание. При текущей доступности RocketMQ аномальные данные возникают редко. Как показано на рисунке 7.
Рис. 7. Улучшенная версия для исключения создания/потребления сообщений — 1
Для второй проблемы, если потребитель компенсации не может вызвать ядро платежа, потребитель компенсации HandleMessage выдаст ошибку на верхний уровень.Используя механизм повторных попыток градиента RocketMQ, когда количество повторных попыток потребителя достигает определенного предела, он будет войти в очередь недоставленных сообщений. Как показано на рисунке 8, в этом случае, как правило, возникает проблема со службой или сетью.После восстановления эти сообщения могут быть извлечены из очереди недоставленных сообщений и обработаны единообразно.
Рис. 8. Улучшенная версия для исключения создания/потребления сообщений — 2
Конечно, бывают и более крайние случаи, что делать, если оба запроса MQ и DB не работают? С точки зрения текущей доступности MQ и DB, одновременный сбой можно игнорировать и выполнять ручное вмешательство.
Для проблемы 3, если количество повторных попыток превышает максимальное число, компенсация все еще не удалась.Как правило, существует проблема с нижестоящими зависимостями. В этом случае мы также помещаем его в таблицу исключений.
Для этих двух видов рыбы, которая проскальзывает через сеть, необходимо поддерживать операционную способность компенсации одиночного/пакетного платежного поручения для ручного вмешательства; лучше всего иметь восходящую задачу, которая выполняется в низкий пиковый период работы. , отсканируйте таблицу бизнес-документов, и она не будет завершена в течение определенного периода времени, чтобы компенсировать.
Кроме того, итоговая задача может привести к кратковременному накоплению сообщений, влияющих на ход онлайн-процесса компенсации в реальном времени, который можно изолировать с помощью независимой очереди.
3.4 Окончательная версия
На самом деле, если есть исключение в работе класса асинхронных уведомлений, нет необходимости каждый раз проходить весь бизнес-процесс заново. Поэтому мы делим исключения на несколько типов, отделяем некоторые асинхронные операции от бизнес-обработки и выполняем уточненную обработку:
- Чтобы уведомить нижестоящий MQ об ошибке, просто повторно отправьте сообщение один раз;
- При сбое обратного вызова RPC транзакции уведомления запрос RPC может быть сериализован в теле сообщения.При компенсации запрос RPC в теле сообщения может быть десериализован, и RPC может быть инициирован снова напрямую;
- При невозможности обновления БД сериализовать параметры обновления в тело сообщения и снова инициировать обновление при пополнении заказа;
- Если вы столкнулись с ненормальной ситуацией во время обработки бизнеса, вам необходимо снова пройти бизнес-компенсацию;
На рис. 9 эти исключения используются в качестве примеров для иллюстрации параметров сообщения для каждого типа компенсации.
Рисунок 9. Компенсация классификации
Наша окончательная система пополнения показана на рисунке 10. Она не только обеспечивает своевременную компенсацию посредством мгновенных сообщений и является единственной, которая берет на себя инициативу атаки, она также использует отложенный повтор сообщения, таблицу исключений сообщений об ошибке приземления и Восходящие задачи для обеспечения эффективности компенсации Секс - непогрешимый щит. Его можно использовать не только для компенсации платежных документов, но и как общее решение, обеспечивающее повторный вход в процесс, но он не подходит для бизнес-форм без гражданства и без повторного входа.
Рисунок 10. Система компенсации аномалий
4. Резюме
В этой статье сначала рассказывается о том, что такое дополнительный заказ, а затем полностью излагается эволюция дополнительного механизма, основанного на реализации трехсторонней платежной системы, и, наконец, развивается относительно общий режим обработки исключений, основанный на очередях сообщений. конечные автоматы и многозадачность Механизм окончательной гарантии согласованности бизнес-уровня предназначен для справки и исправления.
5. О нас
Мы команда финансовых платежных технологий. Мы глубоко вовлечены в платежную сферу, поддерживая быстрый рост бизнеса компании и накапливая собственные платежные возможности. Если вы увлечены технологиями и хотите добиться быстрого роста своего бизнеса, приглашаем вас присоединиться к команде, занимающейся технологиями финансовых платежей. В настоящее время у нас есть потребности в наборе персонала в Пекине, Шэньчжэне и Ханчжоу. Введены доставляемые почтовые ящики:tech@bytedance.com,заголовок письма:Имя - Годы работы - Финансы - Оплата.
поделиться больше
UME — богатый инструмент отладки Flutter
Пример поиска и анализа ошибок оптимизации кода компилятора Go
Douyin Quality Construction - Оптимизация запуска iOS "Принцип"
Добро пожаловать, чтобы следоватьТехническая команда ByteDance"
Контактный адрес электронной почты для возобновления доставкиtech@bytedance.com"