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

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.

Arm79Dmitry V. LiseevСервера стоят намного дешевле, чем оплата труда программиста.
Мда. То есть низкую квалификацию программиста и потраченные несколько дней на продумывание архитектуры закрывать тратами на железо? Вы сильно и сильно ошибаетесь. Я бы сказал - катастрофично.
Dmitry V. LiseevЯ указал ситуацию, где очереди НЕ ВОЗМОЖНЫ.
Что за глупости? А если обработка вашего запроса занимает 10 минут? Вы потеряете коннект просто, ведь есть таймауты на операции. В таком случае запрос только инициирует обращение, а сервер коллбеком (SignalR, к примеру) каждые несколько секунд сообщает о статусе обработки. Так что очереди ВОЗМОЖНЫ
Dmitry V. LiseevСтавим вторую БД и вместе они успевают обрабатывать уже 200.
Да, гениально. У нас сервер с БД стоит почти пол миллиона баксов. Я себе так и представляю, как прихожу к начальству и говорю, что нужно прикупить второй, так как труд программистов стоит дороже, чем сервер.У меня сервер в облаке несколько десятков баксов в месяц. И если мне надо будет на несколько часов процов ему увеличить или памяти добавить, мне только мышкой тыкнуть. И даже к начальству ходить не надо.