Есть ли хороший способ для сервера обрабатывать больше запросов, если мне не нужно отправлять данные обратно?

Question

Я хочу обработать много (> 100 К / сек) запросов POST от клиентов javascript с помощью какого-либо сервисного сервера.Не многие из этих данных будут храниться, но мне нужно обработать их все, чтобы я не мог тратить всю свою мощность на сервер только на обслуживание запросов.Вся обработка должна выполняться в одном и том же экземпляре сервера, в противном случае мне нужно будет использовать базу данных для синхронизации между серверами, которая будет медленнее на несколько порядков.

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

Например, скажем, мне нужно обрабатывать 200 тыс. Запросов в секунду, и каждыйСервер может обрабатывать 40 КБ.Я могу разделить нагрузку между 5 из них.Затем каждый из них будет буферизировать запросы и отправлять их обратно на главный сервер в пакетах по 100. Это приведет к 2k запросов / сек на главном сервере (однако каждое сообщение будет в 100 раз больше - что, вероятно, означает около 100-200 КБ),Я мог бы даже отправить их обратно на сервер, используя UDP, чтобы уменьшить количество необходимых ресурсов (тогда мне нужен только один сокет на главном сервере, верно?).

Я просто думаю, что нет другого способаускорить вещи.Особенно, когда, как я уже сказал, мне не нужно ничего отправлять обратно.У меня также есть полный контроль над клиентами javascript, но неудачный javascript не может отправлять данные с использованием UDP, что, вероятно, было бы для меня решением (мне даже все равно, будут ли потеряны 0,1% данных).

Любыеидеи?

---

Редактировать в ответ на ответы, которые я дал до сих пор.

Проблема не в том, что сервер замедляет обработку событий из очереди или помещает события в очередьсам.Фактически я планирую использовать шаблон прерывателя (http://code.google.com/p/disruptor/), который, как было доказано, обрабатывает до 6 миллионов запросов в секунду.

Единственная проблема, с которой я потенциально могу столкнуться, - это необходимость иметь 100, 200 илиОдновременно открываются сокеты 300 тыс., Которые не могут быть обработаны ни одним из основных серверов. Я знаю, что возможны некоторые нестандартные решения (http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3), но мне интересно, нет ли способа еще лучше использовать тот факт, чтоМне не нужно воспроизводить для клиентов.

(Например, какой-то способ встроить часть данных в исходный пакет TCP и обрабатывать пакеты TCP, как если бы они были UDP. Или какой-то другой вид магии;))

Answer 1

Если у вас есть контроль над клиентами, как вы говорите, тогда вашему прокси-серверу даже не нужно быть HTTP-сервером, потому что вы можете предположить, что все запросы действительны.

Вы можете реализовать его как не-HTTP-сервер, который просто отправляет обратно 200, читает запрос клиента до его отключения, а затем ставит в очередь запросы на обработку.

Answer 2

Создайте уникальную и быструю (вероятно, в C) функцию, которая получает все запросы от очень быстрого сервера (такого как nginx).Единственная задача этой функции - хранить запросы в очень быстрой очереди (например, redis, если вы получили оперативную память).

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

Answer 3

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

Answer 4

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

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

Не уверен, на какой платформе вы находитесь, но, возможно, захотите посмотреть на что-то вроде Lighttpd для обслуживания почтовых отправлений.Вы можете (если ограничения в одном домене вас не сбивают) с легкостью запустить Lighttpd на поддомене вашего приложения (например, post.myapp.com).В противном случае вы могли бы поставить правильный балансировщик нагрузки перед вашими веб-серверами (поэтому все запросы идут на www.myapp.com, и балансировщик нагрузки решает, следует ли перенаправлять их на веб-сервер или процессор очереди).

Надеюсь, что поможет