LINUX.ORG.RU

Стратегия отложенной записи

 , , ,


0

1

Есть endpointA, приходит запрос на добавление записи. В таблице есть hook на post_save

@receiver(post_save, sender=Some)
def some_create(sender, instance, created, **kwargs):
   ...

В этом хуке some_create вызывает API endpointB. Допустим, endpointB лежит. Что делать? Нужно же куда-то записать эти данные, а потом, когда endpointB поднимется, сделать call API –> endpointB. Как правильно это организовывается? Чтобы я какой-нибудь велосипед не изобретал:)

★★★★

Последнее исправление: bryak (всего исправлений: 1)

Кидать вызов API endpointB в какой-нибудь rq, celery или dramatiq, и пускай он долбится пока не получит приличный статус код в ответ или не сдастся по какому-нибудь условию

gnunixon ★★★
()
Ответ на: комментарий от anonymous

Глобально и надёжно! Скалабильно!

anonymous
()

В твоем случае проще добавить в таблицу код ответа от Б.

ya-betmen ★★★★★
()
Ответ на: комментарий от gnunixon

C celery не совсем ясно как это сделать. Получается, мне нужно создать таску, в нее передать данные и с какой-то периодичностью ее вызывать. Таска вида

some_action
sleep X

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

bryak ★★★★
() автор топика
Ответ на: комментарий от bryak

Не очень понимаю проблему. У тебя есть таски, которые ты пихаешь в очередь. У тебя есть воркеры, которые читают из этой очереди таски и их выполняют. В качестве очереди используют RabbitMQ, Redis или Кафку. Тасок в очереди может быть огромная куча, систему это не положит - в этом и смысл этих брокеров очередей. Можешь использовать для этого всего либо Celery, либо Rq - это всё решает твою задачу.

Либо я тебя не понял, либо ты до конца не разобрался, как работают очереди.

dimuska139 ★★
()

В этом хуке some_create вызывает API endpointB. Допустим, endpointB лежит. Что делать?

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

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

Ну и плюс проверяйте что если ваш брокер рухнет он не потеряет таски что в нем были. Или хоть табличку какую-то заведите чтоб там отмечать "ОК-неОК", чтоб сразу знать какие цепочки запросов не выполнились полностью.

micronekodesu ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.