история проекта
В последнее время по коммерческим причинам проекта необходимо разработать функции пополнения и потребления виртуальной валюты для системы. В компании уже есть зрелая услуга платежного шлюза, поэтому основное внимание уделяется тому, как спроектировать процесс пополнения виртуальной валюты в проекте, чтобы весь процесс пополнения был идемпотентным, чтобы гарантировать, что баланс виртуальной валюты пользователя не будет повторно увеличены или вычтены.
Покупка продукта и процесс оплаты
- Когда пользователь покупает продукт, фон продавца запрашивает создание платежного поручения и возвращает соответствующую информацию клиенту.
- Клиент вызывает платежный SDK в соответствии с возвращенной информацией, и пользователь подтверждает платеж.
- После того, как пользователь совершит платеж, платежная система асинхронно уведомит продавца о результате платежа в фоновом режиме.
- Фон продавца получает обратный вызов платежа и выполняет свою собственную бизнес-логику в интерфейсе обратного вызова.
- После завершения платежа клиент задерживает определенный период времени, чтобы запросить результат платежа из фона продавца.Если обратный вызов платежа не был получен в это время, он может активно синхронизировать результат платежа (Стратегия гарантии).
Процесс оплаты Alipay аналогичен оплате WeChat, который здесь не рассматривается. При нормальных обстоятельствах платежные обратные вызовы уведомляют об обратных вызовах на миллисекундном уровне.
Процесс пополнения виртуальной валюты
Процесс пополнения виртуальной валюты будет вложен в процесс обратного вызова платежа. Если виртуальная валюта не завершит полный бизнес-процесс, платежная система повторит попытку. Поэтому бизнес-процессы должны поддерживать идемпотентность.
- Как поддерживать разделение заказа по пользовательскому параметру? Информация об обратном вызове платежа включает только информацию об идентификаторе заказа.В этом случае таблица может быть разделена только в соответствии с идентификатором заказа. Учитывая, что заказов будет все больше и больше, вначале мы разделим заказы по размеру пользователя. В нормальных условиях существует много запросов, основанных на пользовательском измерении, и меньше запросов, основанных на измерении заказа. Таким образом, при предварительном заказе информация об идентификаторе пользователя записывается во вложенную дополнительную информацию, и исходная дополнительная информация будет перенесена при возврате платежа, так что информация об идентификаторе пользователя и заказа может быть известна, а последующие операции могут быть выполнены. будет завершена.
В более поздней оптимизации, когда генерируется идентификатор заказаРезервный нижний сегментХраните информацию об идентификаторе формы заказа пользователя, чтобы она не полагалась на дополнительную информацию для передачи, а также может применяться уведомление обратного вызова, когда пользователь разрешает автоматическое удержание.
- Как виртуальная валюта выполняет транзакции? Если есть только информация о количестве виртуальных монет пользователей, легко ошибиться в повторяющихся операциях. Следовательно, расходомер должен взаимодействовать с операцией транзакции.Когда у расходомера уже есть такая же запись, это означает, что текущая операция повторяется, и значение виртуальной валюты необходимо откатить. Корректное изменение виртуальной валюты может быть реализовано посредством одномашинной транзакции базы данных, и поддерживается повторный вход.
- Как сделать контроль версий виртуальной валюты? Каждое изменение нашей виртуальной валюты будет соответствовать номеру версии.При параллельной работе виртуальной валюты мы обычно вносим изменения данных, только оценивая, соответствует ли версия ожиданиям. Это похоже на управление оптимистической блокировкой, но в этом случае существует вероятность возникновения взаимоблокировки, особенно если производительность базы данных низкая, вероятность ее срабатывания выше. Поэтому номер версии больше не оценивается строго, пока количество виртуальных монет после изменения не меньше 0, и все изменения, отвечающие этому условию, считаются действительными изменениями. Этот сценарий не подходит для номера версии, только обновление для проверки безопасности данных, которое подходит для модели инвентаризации и имеет более высокую производительность.
update table_xxx set avai_amount=avai_amount+:deltaAmount where user_id=:userId and avai_amount+:deltaAmount >= 0
В большинстве случаев одновременная модификация происходит только при потреблении виртуальной валюты, поэтому нам нужно только строго контролировать ситуацию, когда баланса виртуальной валюты недостаточно для вычета.
Процесс пополнения виртуальной валюты при покупке Apple в приложении
Когда пользователь покупает продукт в приложении, клиент может получить такую информацию, как идентификатор пользователя, квитанция о транзакции и идентификатор транзакции. Общий процесс покупки сильно отличается от стороны Android, потому что процесс проверки квитанции разобран со ссылкой на процесс заказа Android, что упрощает повторный вход.
- Клиент получает список пополнения;
- После успешной оплаты клиентом квитанция ваучера транзакции отправляется на сервер для проверки, и сервер создает соответствующий ваучер и запись заказа, обновляет статус и завершает пополнение;
Меры предосторожности при покупках внутри приложения Apple
- Как избежать повторного использования чека? После успешной оплаты клиент iOS может получить идентификатор транзакции и информацию о квитанции, которые однозначно соответствуют друг другу. Следовательно, после проверки правильности квитанции сервер может создать соответствующую запись транзакции и разделить таблицу в соответствии с идентификатором транзакции, а идентификатор транзакции используется в качестве уникального ключа. Это предотвращает повторное использование квитанции.
- Отображение связи между транзакциями и записями заказов? Запись заказа содержит информацию об идентификаторе транзакции канала, поэтому после создания записи транзакции ее можно однозначно связать с информацией о заказе, чтобы избежать повторного создания заказа.
Резюме дизайна
Идемпотентность является основным соображением при разработке системы заказов, необходимо строго обеспечить точность суммы, и невозможно вычесть или заплатить больше денег пользователям. В целом, мы повышаем надежность системы заказов с помощью автономных транзакций базы данных и идемпотентных повторных попыток.