Вопрос по архитектуре fl aws: повторная очередь, возвращающая неправильные значения при обработке нескольких запросов

Question

TL; DR:

1. Flask принимает запрос с параметрами и записывает их во «вход» -redis Служба слушает «вход», пока что-то не произойдет.
2. Когда служба получает значения во «вход», она обрабатывает значения и записывает статус в «выход» -redis Flask тем временем слушает «вывод», пока что-то не произойдет.
3. Flask вернет статус и информацию

Проблема: После нескольких запросов случается, что по крайней мере один запрос не может быть обработан, что приводит к возврату результатов [-1] по новому запросу

Вопросы: Почему?
Есть ли проблемы с архитектурой?
Что можно сделать, чтобы это исправить?

Привет, я сейчас создаю REST API, который принимает параметры, запускает их в базе данных, создает Excel с данными в зависимости от параметров и возвращает путь на сервере для интерфейс для запуска загрузки.

Чтобы лучше разделить различные задачи решения и запустить независимый кеш, у меня есть flaskbackend, который только принимает запросы и записывает их в Redis-Queue «Вход». Другая сторона приложения - это, по сути, постоянный объект l oop, который прослушивает входную очередь, выдает желаемые результаты по значению и записывает путь или ошибку в отдельную очередь Redis «Вывод». В конечном итоге это снова используется Flask, который возвращает путь

Проблема в том, что кажется, что инструмент иногда застревает на нескольких запросах, что приводит к поведению, которое возвращает последний запрос на вновь полученном , что для меня не имеет смысла, так как в моем понимании запросы должны обрабатываться один за другим.

Я до сих пор понимал, что веб-серверы обрабатывают запросы линейно. Это предположение неверно?

Есть ли у кого-нибудь предложения, как исправить эту проблему?

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

Наконец-то код для обработчика запросов и службы сокращен до основных частей:

def get(self):
    args = parser.parse_args()
    redismq_input.put(json.dumps(processed_args))
    while redismq_output.empty():
        pass
    output = eval(redismq_output.get())
    return {
        "path": path
    }

И вот service.run ()

try:
    while True:
        if not redismq_input.empty():
            output = eval(redismq_input.get())
            path = cls.get_path(output)
            redismq_output.put(json.dumps(path))
        time.sleep(0.8)
except KeyboardInterrupt:
    quit()

Может быть, быстрый уточняющий вопрос. Я заметил, что vCore приложений был почти на максимуме с этим приложением, и я не понимаю, почему. Уже есть искусственная пауза в виде встроенного в сервис таймера сна. У кого-нибудь есть идея, как проверить, какая часть приложения на самом деле занимает так много ЦП?

Спасибо

Изменить: таймер сна был на неправильном отступе