Дмитрий, а что означает "отложены"? они останутся в очереди или просто туда не попадут, пока задание с таким id выполняется? я когда пробовала, у меня часть заданий попало в очередь и затем выполнилось, а часть даже в очередь не попало...
Дмитрий, вообще, логика такая, приходит вебхук от Авито, он добавляется в очередь в качестве задания, а дальше уже это задание обрабатывается и сообщение попадает в crm с помощью апи. Может я изначально неправильно построила архитектуру...
Дмитрий, вкратце опишу суть задачи. Пользователи Авито отправляют сообщения в мессенджере, а к моему приложению приходят вебхуки (1 вебхук = 1 сообщение). Нужно выводить эти сообщения в crm, сохраняя очередность. Но, если это новый чат, то перед выводом сообщений необходимо сделать несколько запросов к апи crm для создания сущностей, а уже затем выводить сообщения. Также, одни сообщения могут обрабатываться дольше других, что может повлечь за собой нарушение порядка вывода сообщений
Ипатьев, у меня получилось 12мб. Для сравнения планирую использовать задачу в очереди. Т.е. отправили запрос, добавилось задание в очередь и там висит, пока не выполнится
Ипатьев, вся проблема в том, что для этого приходится выгружать много записей из таблицы с email, а это 100.000+ элементов для одного клиента. Выгрузка может понадобится для нескольких клиентов сразу, получается накладно по памяти
aleksejjjjj, я уже отвечала, что единственное, что мне приходит в голову - это загрузить новые данные во временную таблицу и с помощью join сравнить с данными в другой таблице, но не знаю, насколько такой подход оптимален. Получается много запросов на добавление + очистка после завершения сравнения. Вся проблема тут в том, что надо получить записи из БД, которых нет в приходящих данных. Т.е. сравнение идет в обе стороны. Если бы подсказали что-то конкретное, я была бы очень признательна)
alexalexes, если бы все так и было) Первый источник массива - это БД, второй - это api, которое за один запрос возвращает 100 элементов (пагинация). Следовательно, в БД надо добавить недостающие элементы и получить все записи, которых нет в приходящих от api массиве (т.е. есть в БД, но нет в массиве), чтобы пройтись по ним и выполнить некие действия.
Можно, конечно, загрузить приходящие от api данные во временную таблицу и join-ами сравнить с уже имеющейся, но не знаю, насколько такой подход оптимален. Получается много запросов на добавление + очистка после завершения сравнения
Данные для второго массива приходят частями по 100 элементов, т.е. для получения целого массива их придется складывать. Поэтому и интересуюсь, есть ли вариант, при котором не придется держать в памяти 2 больших массива
Антон Антон, там такая логика, что после того, как все записи, удовлетворяющие условию, разобраны, то в таблицу больше не добавляются новые записи, по крайней мере с такими же данными. Т.е. получается некое временное хранилище
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.