Как запретить одновременные (одинаковые) входящие запросы на стороне API?

Question

[Sergey Pashkevich]

Коллеги, всем привет.
Словил проблему при синхронизации данных между разными сайтами.

Есть сайт A с которого собираются данные о чеках и отправляются на сайт Б пачками по 1000шт последовательно. На сайте А сделали блокировку кнопки от повторного нажатия и т.д., но всё равно что-то случилось, что на сайт Б прилетели дубликаты запросов в одно и тоже время.

На сайте Б мы ждём входящих запросов с пачками чеков по 1000, проверяем каждый чек по отдельности, что он не существует в бд для сайта БД и после проверки сохрянем их в бд. И ждём следующую пачку чеков. Обработка одной пачки, занимает ~30 сек., всё работало год хорошо, но что-то случилось, что пришли одновременно запросы и данные задублировались, так как первый запрос не успел положить в бд данные и из-за этого второй запрос прошёл валидацию с дублирующей информацией.

Как можно решать такие проблемы на стороне API?

Comments

[Slava Rozhnev]

1. уникальный индекс на стороне базы данных
2. организация очереди

[Sergey Pashkevich]

Slava Rozhnev, спасибо за ответ.
1) но запросы же приходят почти в одно время и первый запрос может не успеть положить сформированный индекс в бд или кэш
2) последовательная очередь?

[Slava Rozhnev]

Sergey Pashkevich,

• Уникальный индех не даст записать дубликаты в таблицу
  
• Последовательная очередь - писать всё во временное хранилище, затем вносить в базу последовательно
  

[Sergey Pashkevich]

Slava Rozhnev, понял вашу мысль.

1) структура бд не хранит в основной таблице receipts (идентификатор из сайта А на которой можно было бы повесить индекс, он хранится в другой таблице mappings[receipt_id, external_id, ...]), а по всем остальным полям в таблице receipts могут быть дубликаты и уникальный индекс не получится
2) с очередью, понял. это конечно привнесёт доп. слой логики, но суть понял.

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

[Slava Rozhnev]

Sergey Pashkevich, Вычисляйте ХЭШ, кладите его отдельным столбцом в базу, объявите уникальный индекс на этот столбец

Answer 1

[Сергей Соколов]

Laravel прекрасен и продуман ) В нём есть и заготовка для организации Очереди задач.

В общем ваша задача выглядит как преобразование из возможно параллельных запросов в последовательные.
Очередь задач с единственным рабочим для этого вполне подходит.

Через artisan создайте новый Job и перенесите в него логику обработки запроса. При поступлении api запроса просто создавайте новую задачу и возвращайте мгновенно ответ "Ок, принято".

Рабочий будет постоянно работать: обрабатывать долгоиграющую пачку или ожидать поступления новой задачи. Точно не возьмётся за 2 параллельно.

p.s. почему так долго обрабатываются 1000 чеков? База тормозит при вставке? Индексы не те?

Comments

[Sergey Pashkevich]

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

Answer 2

[Quadrollionaire]

Не думаю что это лучшее решение, но как вариант.
1) Вычисляете хэш (либо идентификаторов чеков, либо еще чего нить, но главное чтоб запрос можно было уникализировать)
2) Добавляете это все в редис, rabbit, kafka (лучше кафка если нужна какая-никакая, гарантия, хотя с тем же редисом ее тоже можно достигнуть за счет правильного конфига)
3) Создаете обработчики которые читают очередь и выполняют всю работу

P.S.) Можете обойтись и без хэша просто записывая в редис обработанные чеки за последние пол дня к примеру и когда прилетает запрос, смотрите какие уже обработаны, их не добавляете в очередь, а те что новые - пускаете в дальнейший путь. В таком случае и уникализировать ничего не надо (гемора меньше)

Comments

[k2lhu]

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

[k2lhu]

Еще как вариант, для решения проблемы конкурентных запросов - если ожидается небольшая нагрузка в течение дня, то можно в конфиге указать лимит запросов в определенный временной промежуток на определенный эндпоинт в приложении, в данном случае - эндпоинт обработки чеков, ставим лимит в 1 запрос на 30 секунд - и уже полегче решать проблему, даже если прилетит повторных запрос - он будет только через 30 секунд и нужные идентификаторы уже будут в бд

[Quadrollionaire]

k2lhu, я так и написал, что там гемора меньше если без хэшей, по поводу разбора очередей больше чем 1 воркером - совсем не понял в чем проблема, у редиса операции атомарные, в той же кафке можно чтобы только одна очередь что-то одно обрабатывала, то есть убрать кейсы когда два воркера возьмут одни и те же данные - вообще не проблема, поэтому тут именно кейс с обработкой очереди самое то. По поводу навешивания уникального индекса: он и должен быть навешан, только надо проверку делать до вставки в БД, а не считать что вставка с ошибкой это "ок".

Но если нет времени разбираться, переделывать и нужно быстро (а еще лучше вчера), то да, решение через индекс будет самое быстрое