Я понимаю целесообразность таких методов для фриланса, но не для работы в офисе.
Да, мне дискомфортно, но работодатель не хочет это обсуждать, например.
По моему главное результат, работа выполняется качественно и в срок. А где я по сети лажу в обед или другое время - дело мое. Даже если меня уверяют, что ко мне нет претензий - возможность в любое время меня проверить существует.
Вы не правы.
Squid стоит на сервере, через который идет инет. А я на другом компе запускаю Tor и я являюсь клиентом расшаерной с того сервера сети. Tor работает. Мне интересно что видит squid в логах.
Дмитрий Энтелис: в логике не перепутано, архитектура построена в итеративном процессе в соответствии с решаемой задачей. Вопрос только в оптимизации решения.
Дмитрий Энтелис: в данном случае я вас понял, вы предлагаете долгосрочные запросы обрабатывать иначе (отдельно). Но одно из требований к системе - запросы должны выполняться единообразно. У них единый цикл прохода всех этапов. И хранить быстрые все равно придется, т.к. долгосрочные зависят от быстрых (данные).
Вопрос с тем, чтобы выделить быстрые очереди должен решаться масштабированием.
Дмитрий Энтелис: понял ваше мнение на счет mongo.
А на счет запросов я по моему добавил и описал предельно ясно.
Четкой последовательности нет, выполняются они отдельно. Клиент может выкупить бронь и через неделю и через две.
Мы обсуждаем не изменение задачи, а решение для текущей поставленной задачи.
Дмитрий Энтелис: вы пожалуйста в задачу вникайте. Запрос имеет не один тип, всего типов несколько и они зависят друг от друга (у них есть последовательность, например бронирование, а потом выкуп).
Следовательно зависимые по очередности запросы берут данные из предыдущих (у нас есть один запрос - выдача вариантов бронирования, значит запрос на бронирование должен знать ИД, что выбрал пользователь, далее надо залезть в БД, чтобы взять данные с предыдущего запроса для подготовки текущего запроса).
Я не просто так написал про препроцессинг и постпроцессинг в ТЗ, это важно. Запросы могут быть связаны и данные о предыдущих запросах из БД могут быть нужны. Это и лог и рабочая единица, поторяюсь.
Чаще всего выборка по ИД, поэтому смотрю на Mongo.
Тут не только в запись упираюсь, но в чтение. Эти самые логи являются как логами, так и рабочей единицей. Т.е. по ИД лога Port Request или Worker Request работает бизнес логика, берутся данные. Это должно быть понятно из описания.
Сергей Протько: а если предположить, что контекст задачи все же предпологает высокую нагрузку, отказоустойчивость и возможность масштабирования. Какое решение вы бы рекомендовали тогда? Писать свое на основе того же Gearman или что-то из готовых решений?
И если немного расширить описанную задачу. Что если таких однозапросных API несколько, и когда поступает один запрос в очередь его надо параллелить на N (к-во API) которые надо опросить. Как лучше тут решать? Делать форки воркеров или же делать две очереди (основные запросы и распараллеленые воркеры)?
Да, мне дискомфортно, но работодатель не хочет это обсуждать, например.
По моему главное результат, работа выполняется качественно и в срок. А где я по сети лажу в обед или другое время - дело мое. Даже если меня уверяют, что ко мне нет претензий - возможность в любое время меня проверить существует.