Предотвращение столкновений при одновременной генерации уникальных идентификаторов

Question

У меня есть веб-крючок для получения событий Stripe и создания новых счетов соответственно. В соответствии с местным законодательством я должен самостоятельно генерировать номера счетов и не могу использовать идентификаторы Stripe. Это последовательные уникальные идентификаторы.

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

Номера счетов в основном выглядят так: YYYY-XXXXX, где YYYY - год, и XXXXX - порядковый номер, начиная с 00001 для первого счета за год. Если последний номер был 2020-00017, следующим не может быть ничего, кроме 2020-00018.

Так что это вроде работает, но не кажется идеальным. Вы знаете какое-нибудь лучшее решение, чем позволить Stripe повторить попытку?

Answer 1

Существует пара опций для выполнения этого требования.

Как уже упоминалось @jjanes, вы можете вернуть код состояния HTTP> 2XX код состояния, который заставит Stripe повторить запрос. Это хорошо, если вы ожидаете несколько дубликатов, но если вы ожидаете быстрого масштабирования и часто отвечаете с> 200 кодами ошибок, я бы встроил логи повторных попыток и последовательной обработки c в ваш бэкэнд.

Например, Вы можете поместить sh данные события в очередь, а затем сразу же ответить кодом состояния 200. Затем обработайте события последовательно из очереди в фоновом задании. Это позволит вам написать собственный лог c для дедупликации идентификаторов, обеспечения их последовательности и избежания риска того, что ваша конечная точка Webhook в полосе отключена (для ответа слишком большим количеством ответов> 200 с кодом состояния).

Answer 2

Я думаю, что лучше всего сделать повторную попытку Stripe, поскольку она уже реализована и протестирована. Если кто-то др aws наберет следующий номер, невозможно будет узнать, собираются ли они совершить или нет, пока они на самом деле не сделали этого. Таким образом, вам нужно либо потерпеть неудачу и повторить попытку, либо заблокировать и подождать, либо взять следующий номер и разрешить пропуски, если предыдущий не удался. Есть ли проблема с повторной попыткой, или вы просто нашли ее неопрятной? Если есть проблема, что это? Трудно разработать новое решение, не зная, в чем проблема со старым.