На С++ такие вещи пишут.

Arm79host.13Если кто разрабатывал похожие проекты, какую архитектуру использовали?
Я делал. На C#. Протокол SSL, около 300 тысяч сообщений в секунду сервер мог обрабатывать... Количество клиентов ограничивалось только ресурсами сервера. Технология очень простая - таски из TPL.Тут принцип простой. Можно на каждое соединение создавать поток. Тогда их будут десятки тысяч. Ресурсов пожрёт много. Нужен многопроцессорный сервер. Подходит при длительных операциях. А если операции короткие, то можно обрабатывать их в одном потоке по очереди. Надо ещё смотреть протокол обмена. Если следующие операции не зависят от предыдущих (датчик просто выдал данные и ничего не ожидает в ответ), то можно буферные очереди организовать. Одни потоки принимают данные и складывают в очереди, другие потоки обрабатывают данные из очередей.

Arm79Dmitry V. LiseevМожно на каждое соединение создавать потокНо не нужно :-) Даже безотносительно длительности операций. Накладные затраты на переключение контекста при десятках тысяч потоков будут очень большимиЗависит от длительности операций. Сравните архитектуру apache и nginx. Накладные затраты - не проблема. Задача легко масштабируется. Поставим сотню серверов.

Arm79Dmitry V. LiseevЕсли следующие операции не зависят от предыдущих (датчик просто выдал данные и ничего не ожидает в ответ), то можно буферные очереди организовать. Одни потоки принимают данные и складывают в очереди, другие потоки обрабатывают данные из очередей.Условие не обязательно. Можно в любом варианте сделать: "Одни потоки принимают данные и складывают в очереди, другие потоки обрабатывают данные из очередей"Обязательное. Если я лезу на сайт, жму кнопку, и жду ответа перед тем, как нажать следующую, то очереди не нужны. А вот если я жму кнопку и мне не важен ответ, то можно поставить запрос в очередь и через пару-тройку часов переслать мне результат мылом.

Если запросы можно переупорядочивать, то очереди делаются в зависимости от предполагаемой длительности операции, приоритета, и т.д.
Arm79Самое главное для ТС обеспечить нужную скорость при работе с БД. Что толку от сервера приложений, если БД не успеет сохранять инфу с десятков тысяч поставщиков информации...Тут дело в колебаниях скорости. Допустим, БД успевает обрабатывать 100 тыс. операций в минуту. Поток от датчиков 70 тыс. Всё хорошо. Потом кратковременно поток подскакивает до 300 тыс. и всё уже плохо. Для этого нужны очереди и буфера. Ещё учебник по теории массового обслуживания.

mvn3Dmitry V. Liseev,

>>Тут принцип простой. Можно на каждое соединение создавать поток. Тогда их будут десятки тысяч. Ресурсов пожрёт много

А объектный пул не?Зависит от архитектуры системы и протоколов обмена данными.

Arm79Dmitry V. LiseevЗадача легко масштабируется. Поставим сотню серверов.А вы из своего кармана будете оплачивать покупку серверов?Сервера стоят намного дешевле, чем оплата труда программиста.

Arm79Dmitry V. LiseevЕсли я лезу на сайт, жму кнопку, и жду ответа перед тем, как нажать следующую, то очереди не нужныочереди НЕ ОБЯЗАТЕЛЬНЫ. Но возможны.Я указал ситуацию, где очереди НЕ ВОЗМОЖНЫ.

Arm79Dmitry V. LiseevДопустим, БД успевает обрабатывать 100 тыс. операций в минуту. Поток от датчиков 70 тыс. Всё хорошо. Потом кратковременно поток подскакивает до 300 тыс. и всё уже плохо.А если БД успевает обработать 100 штук операций в минуту, а извне приходит 110?Ставим вторую БД и вместе они успевают обрабатывать уже 200.