Как получить статику с помощью параллельного вызова fastcgi без ожидания завершения?

Как можно настроить сервер для выдачи статического контента, при этом отправляя информацию о запросе в fastcgi/python скрипт для сбора статистики, но без необходимости ожидания ответа от fastcgi? Кроме того, как можно настроить так, чтобы при недоступности fastcgi сервер не выдавал ошибку и продолжал работу?
  • 18 декабря 2023 г. 20:37
Ответы на вопрос 2
Для получения статики с помощью параллельного вызова FastCGI без ожидания завершения, вы можете использовать следующий подход:

1. Настройте сервер (например, Nginx) для обработки статического контента. Это обычно делается с помощью директивы `location` в конфигурационном файле сервера. Например:

```
location /static {
    root /path/to/static/files;
}
```

2. Настройте сервер для перенаправления информации о запросе в FastCGI/Python скрипт для сбора статистики. В Nginx это можно сделать с помощью директивы `fastcgi_pass` и включения переменных запроса. Например:

```
location /statistics {
    fastcgi_pass unix:/path/to/socket.sock;
    fastcgi_param REQUEST_METHOD $request_method;
    fastcgi_param QUERY_STRING $query_string;
    fastcgi_param REQUEST_URI $request_uri;
    # и другие необходимые переменные
    include fastcgi_params;
}
```

3. Чтобы сервер не ожидал ответа от FastCGI, вы можете установить опцию `fastcgi_ignore_client_abort` в `on`. Это позволит серверу отправлять данные клиенту и не дожидаться ответа FastCGI. Например:

```
location /statistics {
    fastcgi_pass unix:/path/to/socket.sock;
    fastcgi_param REQUEST_METHOD $request_method;
    fastcgi_param QUERY_STRING $query_string;
    fastcgi_param REQUEST_URI $request_uri;
    # и другие необходимые переменные
    fastcgi_ignore_client_abort on;
    include fastcgi_params;
}
```

4. Чтобы сервер не выдавал ошибку при недоступности FastCGI, вы можете использовать директиву `try_files`. Она позволяет указать альтернативный путь, если основной путь не доступен. Например:

```
location /statistics {
    try_files $uri =404;
    fastcgi_pass unix:/path/to/socket.sock;
    fastcgi_param REQUEST_METHOD $request_method;
    fastcgi_param QUERY_STRING $query_string;
    fastcgi_param REQUEST_URI $request_uri;
    # и другие необходимые переменные
    fastcgi_ignore_client_abort on;
    include fastcgi_params;
}
```

В этом случае, если FastCGI недоступен, сервер будет выдавать статический контент, а не ошибку.

После настройки сервера выполните перезагрузку или перезапуск, чтобы изменения вступили в силу.
А для чего вам такое странное поведение? 
Вообще тут много вопросов из вашей постановки вытекает. Очень тревожных и странных вопросов.
Начать можно с чего. Вы ставите вопрос так, будто хотите передавать данные "в скрипт". Надо перестраивать ход мысли. Вы передаёте данные в некий сторадж. Это может быть некая структура в памяти процесса (например вашего FastCGI-сервера), или в БД (postgres, sqlite, clickhouse, redis), или в очереди какой-нибудь (rabbit, кафка)... Данные не могут передаваться в код. Разве что в виде параметров и аргументов.
Опять же, ваш FastCGI может быть запущен в нескольких инстансах, как вы будете заботиться о синхронзации? Прочитайте про CAP-теорему. Если вы городите какое-то самодельное решение, то вам придётся как следует понимать суть этой теоремы, проблемы, которые она обрисовывает и то, на каких двух стульях из трёх вы хотите сидеть.

Если вы подробнее расскажете о своей задаче, то вам подскажут какими способами правильнее такие вещи делать. Пока что складывается ощущение, что в момент отдачи статики вы хотите делать http-запросы вашему бэкенду. Для чего? Считать статистику? Биллинг?

Вообще лучше всеми этими вопросами не грузить ваш nginx, хотя там можно даже lua-скрипты встраивать с нетривиальной логикой. Для некоторых нужд можно парсить, например, логи nginx-а. Настроить так, чтобы в нужный пайп сыпалось только то, что требуется и отдельным микросервисом его вычитывать и делать что там вам требуется. Агрегировать? Статистику считать? Журналировать?
Так же можно поднять какую-то очередь и заставить nginx туда писать по факту обращений.
Вообще там много вопросов будет. А что если к файлу обратились, но контент не качали, только заголовок? А что если разрыв соединения? А что если один большой файл много раз фрагментами докачивали? А что если кто-то себе поставил перед вашим сервером кэширующий прокси?

Теги вашего вопроса следует привести в соответствие с правилами. Тег Python не нужен, ведь вы не привели никакого кода и к питону ваш вопрос совершенно никакого отношения не имеет.
Похожие вопросы