Блог

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

Вот список моих целей:

• Масштабируемость — должна быть возможность распараллеливания архитектуры на несколько процессоров или даже на несколько серверов.
• Способность справляться с огромным количеством параллельных подключений.
• Не должно вызывать проблем с блокировкой, если обработка одного запроса занимает много времени.
• Время обработки запроса до ответа должно быть минимальным.
• Построен вокруг .NET framework (будет писать это на C #)

Предлагаемая мной архитектура и поток довольно сложны, поэтому вот схема моего первоначального проекта:

(и вот это на tinypic на случай, если он сильно изменится)

Идея заключается в том, что запросы поступают по сети (хотя я еще не решил, будет ли лучше TCP или UDP) и сразу передаются высокоскоростному балансировщику нагрузки. Затем балансировщик нагрузки выбирает очередь запросов (RQ) для размещения запроса, используя генератор взвешенных случайных чисел. Веса являются производными от размера каждой очереди. Причина использования взвешенного RNG, а не просто размещения запросов в наименее загруженную очередь, заключается в том, что он предотвращает блокировку всего сервера пустой, но заблокированной очередью (из-за зависшего запроса). Если все RQ превышают определенный размер, балансировщик нагрузки отбрасывает запрос и помещает ответ «сервер слишком занят» в очередь вывода (OPQ) — эта часть не показана на диаграмме.

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

1. Немедленные — немедленные запросы, как следует из названия, обрабатываются немедленно.

2. Отложенные — отложенные запросы считаются низкоприоритетными. Они обрабатываются немедленно при низкой нагрузке или помещаются в очередь отложенных запросов (DRQ), если нагрузка высокая. Балансировщик нагрузки извлекает эти отложенные запросы из DRQ, помечает их как немедленные, а затем помещает их обратно в соответствующие RQ.

3. Запросы с временной синхронизацией помещаются в очередь запросов с временной синхронизацией (TRQ) вместе с их целевой временной меткой. Эти запросы часто генерируются в результате другого запроса, а не явно отправляются клиентом. Когда временная метка запроса превышена, следующий доступный поток обработки запросов использует ее и обрабатывает.

Когда запрос обрабатывается, данные могут быть извлечены из кэша пары ключ / значение в памяти, кэша пары ключ / значение или на диске, или с выделенного сервера базы данных SQL. Кэшированные значения будут BSON, а индекс будет строкой. Я подумываю об использовании Dictionary<T1,T2> для реализации этого в памяти и btree (или аналогичного) для дискового кэша.

Ответ создается по завершении обработки и помещается в очередь вывода (OPQ). Затем цикл использует ответы из OPQ и передает их обратно клиенту по сети. Если OPQ достигает 80% от своего максимального размера, одна четверть потоков обработки запросов останавливается. Если OPQ достигает 90% от своего максимального размера, половина потоков обработки запросов останавливается. Если OPQ достигает своего максимального размера, все потоки обработки запросов останавливаются. Это будет достигнуто с помощью семафора, который также должен предотвращать блокировку отдельных потоков обработки запросов и оставлять устаревшие запросы.

Я ищу предложения по нескольким областям:

• Есть ли какие-либо серьезные недостатки в этой архитектуре, которые я пропустил?
• Есть ли что-нибудь, что я должен рассмотреть по соображениям производительности?
• Будут ли TCP или UDP более подходящими для запросов? Было бы очень полезно иметь «подтверждение доставки», которое предлагает TCP, но легкий характер UDP также привлекателен.
• Есть ли какие-либо особые соображения, о которых мне нужно подумать при работе с более чем 100 тыс. одновременных подключений на сервере Windows? Я знаю, что стек TCP в Linux работает хорошо, но я не уверен в Windows.
• Есть ли какие-либо другие вопросы, которые я должен задать? Я забыл что-нибудь учесть?

Я знаю, что это было много для чтения, и, вероятно, тоже много вопросов, поэтому спасибо за ваше время.

Обновленная версия схемы здесь.

Также вы можете рассмотреть следующее:

• Отработка отказа. Вы могли бы разработать подход к сохранению запросов во время возможных сбоев службы, чтобы все ожидающие запросы обрабатывались даже после перезапуска службы
• Очередь ошибок. (также известный как шаблон канала мертвых писем)
• Каналы и фильтры. Предоставляя такую функцию, вы бы достигли высокого уровня гибкости и расширяемости сервиса
• Подтверждение запроса. В некоторый заранее определенный промежуток времени клиент, отправивший запрос в сервис, ожидает сообщения подтверждения с идентификатором корреляции, установленным на начальный идентификатор запроса. Таким образом, сервис может уведомлять клиентов о том, что конкретный запрос получен и помещен во входящую очередь, если клиент не получает подтверждение для только что отправленного запроса — он может повторно отправитьэто или пометить как сбой.

PS: Также я бы посоветовал отличную книгу «Шаблоны корпоративной интеграции«

Я не понимаю, зачем вам нужно несколько очередей запросов. Мне кажется, вам нужна только одна очередь запросов, из которой многие процессоры все читают. Это не должно быть проблемой ни с одной системой очередей. Наличие только одной очереди отделяет ввод от процессоров, обеспечивая лучшую масштабируемость — запускайте больше процессоров, когда это необходимо, больше никому не нужно заботиться об этом.

Что касается TCP и UDP — какую производительность вы ищете? И не было бы лучше использовать некоторую существующую инфраструктуру связи, такую как ZeroMQ, чтобы позаботиться об этих технических деталях для вас?

Итай.

Если вы хотите, чтобы это хорошо масштабировалось, вам нужно убедиться, что все компоненты масштабируемы — элементы обработки, части ввода / вывода и очереди. Если вы собираетесь делать это в стеке Microsoft, я бы серьезно рекомендовал изучить Windows Azure, которая предлагает большинство, если не все, ключевые функции, которые вам понадобятся. Одна вещь, которую вы не упомянули — будет ли уровень постоянного хранения (например, база данных)? Если это так, будьте готовы масштабировать и это, иначе это станет вашей единственной точкой отказа.