Понимание mod_proxy и Apache 2 для записи сервера кометы

В JavaScript нет термина или ключевого слова static, но мы можем поместить такие данные непосредственно в объект функции (как в любом другом объекте).

function f() {
    f.count = ++f.count || 1 // f.count is undefined at first
    alert("Call No " + f.count)
}

f(); // Call No 1

f(); // Call No 2
8
задан TheHippo 7 July 2009 в 13:43
поделиться

4 ответа

Я почти уверен, что использование mod_proxy заблокирует воркера во время обработки запроса.

Если вы можете использовать 2 IP-адреса, есть довольно простое решение. Допустим, IP A - 1.1.1.1, а IP B - 2.2.2.2, и допустим, ваш домен - example.com.

Вот как это будет работать:

-Настройте Apache для прослушивания порта 80, но ТОЛЬКО на IP A.

-Запустите другой сервер на порту 80, но только на IP B.

-Настройте запросы XHR так, чтобы они находились в поддомене вашего домена, но с тем же портом. Так что междоменные ограничения им не мешают. Итак, ваш сайт - это example.com, а запросы XHR направляются, например, на xhr.example.com.

-Настройте свой DNS так, чтобы example.com разрешал IP A, а xhr.example.com разрешал IP B .

-Все готово.

Это решение будет работать, если у вас есть 2 сервера и каждый имеет свой IP-адрес, и оно также будет работать, если у вас есть один сервер с 2-мя IP-адресами.

Если вы можете не использую 2 IP, у меня может быть другое решение, проверяю,

3
ответ дан 5 December 2019 в 22:20
поделиться

Это сложная проблема. Даже если вы справитесь с проблемами безопасности, с которыми сталкиваетесь, вам придется держать TCP-соединение открытым для каждого клиента, просматривающего веб-страницу. Вы не сможете создать поток для обработки каждого соединения, и вы не сможете «выбирать» все соединения из одного потока. Сделав это раньше, могу сказать, что это непросто. Вы можете изучить libevent , который memcached использует для аналогичной цели.

До некоторой степени вы, вероятно, можете обойтись без установки длинных таймаутов и предоставления Apache огромное количество рабочих, большинство из которых большую часть времени будет простаивать. Я полагаю, что благодаря тщательному выбору и настройке рабочего модуля Apache эта возможность расширится до тысяч одновременных пользователей. В какой-то момент, однако, масштабирование больше не будет.

Я не знаю, как выглядит ваша инфраструктура, но у нас есть блоки балансировки нагрузки в сетевых стойках, называемые F5. Они представляют один внешний домен, но перенаправляют трафик на несколько внутренних серверов в зависимости от времени их ответа, файлов cookie в заголовках запросов и т. Д. Их можно настроить для отправки запросов по определенному пути в виртуальном домене на определенный сервер. Таким образом, у вас могут быть запросы example.com/xhr/foo, сопоставленные с конкретным сервером для обработки этих запросов комет. К сожалению, это не программное решение, а довольно дорогое аппаратное решение.

В любом случае, вам может потребоваться какая-то система балансировки нагрузки (или, может быть, она у вас уже есть), и, возможно, ее можно настроить для обработки этой ситуации лучше, чем это может сделать Apache.

У меня была проблема много лет назад, когда я хотел, чтобы клиенты использовали клиента -серверная система с проприетарным двоичным протоколом для доступа к нашим серверам через порт 80, поскольку у них постоянно возникали проблемы с брандмауэрами на настраиваемом порту, который использовала система. Мне нужен был прокси-сервер, который работал бы на порту 80 и направлял бы трафик либо на Apache, либо на сервер приложений, в зависимости от первых нескольких байтов того, что получал от клиента. Я искал решение и не нашел ничего подходящего. Я подумывал о написании модуля Apache, плагина для DeleGate и т. Д., Но в конечном итоге был добавлен собственной настраиваемой прокси-службой с распознаванием контента. Это, я думаю, худший сценарий того, что вы

3
ответ дан 5 December 2019 в 22:20
поделиться

Чтобы ответить на конкретный вопрос о мод-прокси: да , вы можете настроить mod_proxy для обслуживания контент, который создается сервером (или службой), который не является общедоступным (т. е. доступен только через внутренний адрес или локальный хост).

Я делал это в производственной среде, и это работает очень и очень хорошо. Apache перенаправляет одни запросы на Tomcat через AJP worker, а другие на сервер приложений ГИС через мод-прокси. Как отмечали другие, межсайтовая безопасность может помешать вам работать над субдоменом, но нет причин, по которым вы не можете прокси-запросы к mydomain.com/application


Чтобы поговорить о вашей конкретной проблеме - я думаю на самом деле вы увядаетесь рассматривать проблему как "долгоживущие запросы" - т.е. предполагая, что, когда вы сделаете один из этих запросов, весь процесс должен остановиться. Похоже, вы пытаетесь решить проблему с архитектурой приложения, изменив архитектуру системы. Фактически, что вам нужно сделать, так это обработать эти фоновые запросы именно так; и многопоточность:

  • Клиент делает запрос к удаленной службе « выполнить задачу X с данными A, B и C »
  • Ваша служба получает запрос: он передает его в планировщик который выдает уникальный билет / токен для запроса. Затем служба возвращает этот токен клиенту " спасибо, ваша задача находится в очереди под токеном Z "
  • Затем клиент зависает на этом токене, показывает поле "загрузка / пожалуйста, подождите", и устанавливает таймер, который срабатывает, например, для аргументов, задания можно выполнять с самого начала: просто убедитесь, что код для выполнения задания является потокобезопасным (если вы не получите две работы, извлекающие одно и то же задание из стека).
  • Рабочие потоки могут быть довольно простыми - получить доступ к планировщику, запросить следующее задание: если оно есть, тогда выполните работу, отправьте результаты, в противном случае просто спите на некоторое время, начните заново.

Таким образом, вы никогда не собираетесь блокировать Apache дольше, чем необходимо, поскольку все, что вы делаете, это выдает запросы на «сделать x» или «дать мне результаты для x». Вы, вероятно, захотите встроить некоторые функции безопасности в несколько моментов - например, обработку невыполненных задач и обеспечение тайм-аута на стороне клиента, чтобы он не ждал бесконечно.

просто убедитесь, что код для выполнения задания является потокобезопасным (если вы не получите две работы, извлекающие одно и то же задание из стека).
  • Рабочие потоки могут быть довольно простыми - получить доступ к планировщику, запросить следующее задание: если оно есть, тогда выполните работу, отправьте результаты, в противном случае просто спите на некоторое время, начните заново.
  • Таким образом, вы никогда не собираетесь блокировать Apache дольше, чем необходимо, поскольку все, что вы делаете, это выдает запросы на «сделать x» или «дать мне результаты для x». Вы, вероятно, захотите встроить некоторые функции безопасности в несколько моментов - например, обработку невыполненных задач и обеспечение тайм-аута на стороне клиента, чтобы он не ждал бесконечно.

    просто убедитесь, что код для выполнения задания является потокобезопасным (если вы не получите две работы, извлекающие одно и то же задание из стека).
  • Рабочие потоки могут быть довольно простыми - получить доступ к планировщику, запросить следующее задание: если оно есть, тогда выполните работу, отправьте результаты, в противном случае просто спите на некоторое время, начните заново.
  • Таким образом, вы никогда не собираетесь блокировать Apache дольше, чем необходимо, поскольку все, что вы делаете, это выдает запросы на «сделать x» или «дать мне результаты для x». Вы, вероятно, захотите встроить некоторые функции безопасности в несколько моментов - например, обработку невыполненных задач и обеспечение тайм-аута на стороне клиента, чтобы он не ждал бесконечно.

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

    Таким образом, вы никогда не собираетесь блокировать Apache дольше, чем необходимо, поскольку все, что вы делаете, это проблемы запросы на «сделать x» или «дать мне результаты для x». Вы, вероятно, захотите встроить некоторые функции безопасности в несколько моментов - например, обработку невыполненных задач и обеспечение тайм-аута на стороне клиента, чтобы он не ждал бесконечно.

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

    Таким образом, вы никогда не собираетесь блокировать Apache дольше, чем необходимо, поскольку все, что вы делаете, это проблемы запросы на «сделать x» или «дать мне результаты для x». Вы, вероятно, захотите встроить некоторые функции безопасности в несколько моментов - например, обработку невыполненных задач и обеспечение тайм-аута на стороне клиента, чтобы он не ждал бесконечно.

    0
    ответ дан 5 December 2019 в 22:20
    поделиться

    Для номера 2: вы можете обойти ограничения между доменами, используя JSONP.

    0
    ответ дан 5 December 2019 в 22:20
    поделиться
    Другие вопросы по тегам:

    Похожие вопросы: