MicroMQ и RabbitMQ очередь запросов внутри сервиса?

Question

[Дмитрий Бычков]

У меня есть сервис "Браузер" который парсит страницу. Отправляешь ему url, он возвращает информацию о том что это за страница, title, description и тд.

Проблема в том что когда сервис падает. Другой микросервис продолжает слать ему задания и в момент когда перезапускается сервис Браузер. Тот получает кучу одинаковых заданий и намертво вешает систему.

Как организовать очередь внутри микросервиса, чтобы он стал одно поточным к примеру? И обрабатывал по 1 заданию, а остальные просто ложил в очередь.

сервис

const app = new MicroMQ({
    name: serviceName, //browser - serviceName
    rabbit: {
        url: rabbitHost,
    }
});
app.post('/tools/urls_info', async function (request, response) {
        let { urls } = request.body;
        let urls_info = [];
        for(const url of urls){
            let info = await browser(url);
            urls_info.push(info)
        }
        response.json({result: true, array: urls_info});
    });
app.start()

Вот так я отправляю данные сервису - браузер

let {responce} = await app.ask('browser', {
            path: '/tools/urls_info',
            method: 'post',
            body: {
                urls: urls_array
            }
        });

Comments

[d-sem]

какие то странные очереди если

Другой микросервис продолжает слать ему задания и в момент когда перезапускается сервис Браузер.

[Дмитрий Бычков]

d-sem, я так понимаю, что другой сервис по таймауту закидывает пакет еще раз и он попадает в очередь rabbitmq, а после старта все то что было в очереди мгновенно отправляется в сервис. В любом случае это мой первый опыт работы с микросервисами. Не кидайтесь тапками плиз.

let {responce} = await app.ask('browser', {
            path: '/tools/urls_info',
            method: 'post',
            body: {
                urls: urls_array
            }
        });

Вот так я отправляю данные сервису браузер

Answer 1

[d'Ivan]

Хотел бы понять что означает

намертво вешает систему.

в контексте микросервисов? И почему это является проблемой?

Тот получает кучу одинаковых заданий

А почему нужно обрабатывать одинаковые URL повторно?
Если, конечно, сильно надо, то можно проверять в K/V хранилище на наличие ключа с таким URL , у которого ограничено время жизни. Тогда при повторном событии просто игнорировать его.

Ну а, вообще, микросервис "Браузер" может работать только в качестве обработчика очереди, получая сообщения, отправленные REST API. Сам же просто складывать в своем темпе результаты сканирования URL в СУБД, а REST API будет проверять наличие в той же СУБД и сообщать результаты клиенту, если готово.

Comments

[Дмитрий Бычков]

Ну так то оно так. Намертво вещает потому что для парсинга страниц я использую puppeter. Открывается 100+ вкладок браузера, оперативка на бедном VPS в красной зоне так же как и CPU. Да я тоже думал про то чтобы складывать запросы по урл и данные в бд. Чтобы не запускать браузер. Но так как вся разработка далека от релиза и при парсинге ошибки вылетают частенько что-то не подхватывается. Данные должны быть актуальные. Буду смотреть в сторону субд положу туда результат парсинга и время через которое данные уже не актуальны и требуют перепроверки.