Сообщение от pax
Ух, ну и спор начался...
|
Да жесть вообще
Сообщение от pax
Запрос примерно такого плана:
"SELECT *
FROM users
WHERE id > @last_largest_id AND sn = 'vk' AND DATE_ADD(last_login, INTERVAL 31 day) > NOW()
ORDER BY id
LIMIT 1000"
|
Заместо использования offset, используй самый большой ID пользователя с последнего списка пользователей. Изначально 0.
Тогда не будет никто влезать если залогинятся.
Сообщение от pax
В ответах api соц сети получаю id получивших. Это новый список (только часть из тех, кому пытался отправить). Вот их надо обновить, не всех в диапазоне min_id ... max_id. Отсюда IN и вопрос что лучше, 10 запросов по 100 или 1 на 1000. (1000 это в худшем случае, обычно меньше, т.к. многие пользователи отключают нотификейшены).
|
Тут, UPDATE c id IN будет "ок", можешь смело делать на каждый ответ с api соц сети.
Если смотреть проще, можешь даже делать по одному запросу на LIMIT 100, обрабатывать его в другом потоке.
Далее если у тебя по времени влезает в ограничения соц. сети, то делаешь еще запрос, и так по кругу, пока не будешь упираться в ограничения по времени.
Таким образом можно будет и паралельно пачками слать, в итоге у тебя будет максимальная скорость рассылки. Т.к. работа с бд у тебя будет по любому в разы быстрее чем их ограничения на api.