API-сервер - служба очереди против локальной мини-очереди
Я создал сервер API в узле js, который должен работать под большой нагрузкой. В основном я хочу накапливать входящие запросы на вставку небольшими партиями (по 10 штук в каждом), и после заполнения пакета вставлять эти элементы в базу данных. В настоящее время я использую Amazon SQS в качестве службы очередей и отдельное приложение для пользователей очереди, которое я разработал. Однако я подумал, что, возможно, я смогу накапливать сообщения локально, а затем вставлять пакет прямо из API. Это позволило бы избежать накладных расходов на связь со службой удаленной очереди, и, поскольку пакеты малы, память сервера API не будет завышена. Как вы думаете? плюсы и минусы?
1 ответ
Вы упомянули, что на вашем сервере есть большая нагрузка. Если вы попытаетесь реализовать очередь для сбора входящих запросов, это может в конечном итоге потреблять огромную память на вашем сервере. До тех пор, пока у вас не появится возможность самостоятельно масштабироваться, это всегда будет риском. Вам следует учесть следующее: - общий размер пакета - максимальный размер каждого запроса. Это поможет вам избежать проблем с нехваткой памяти.
другие соображения должны быть: - это распределенная / кластерная среда? Если да, то подумайте, связаны ли 2 запроса, и хотите ли вы объединить их вместе на одном сервере? - таймер: есть ли в вашей очереди какой-либо механизм таймера. Я вижу, что я не вставляю в БД, поэтому есть сценарий, когда вставка не может дождаться завершения пакета для записи в БД. Если да, то используйте таймер для сохранения (независимо от того, заполнен пакет или нет) - Проверьте, не получил ли сервер всплески атак, сможет ли ваш механизм очередей справиться с этим? что-нибудь вроде политики выскакивания. - является ли сбой системы проблемой, когда вы можете потерять данные частичной пакетной вставки? - Я вижу, что, делая это, вы пытаетесь сэкономить транзитное время для удаленного вызова. Но если вы блокируете запросы на сохранение (в пакете), действительно ли вы заботитесь о времени прохождения (реальная проблема)? Если нет, то SQS является более надежным и эффективным решением.
кроме этого, попытайтесь предотвратить вашу систему от атак SQL инъекций.