Веб-сокеты: прослушивать несколько соединений одновременно?

Question

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

Предположим, что у меня открыты два соединения с веб-сокетом, и я получаю данные в реальном времени с двух разных серверов.Как сделать так, чтобы не пропустить ни одного сообщения?Я немного научился асинхронному программированию (Python Asyncio), но, похоже, это не решает проблему: когда я слушаю одно соединение, я не могу слушать другое одновременно, верно?

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

Это правильно, или я что-то упустил?Большое спасибо.

Answer 1

когда я слушаю одно соединение, я не могу слушать другое одновременно, верно?

Неверно.

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

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

Это правда, чтокод реагирует на события в последовательности, но пока ваш код не «блокирует», эти события можно обрабатывать быстро и эффективно.

Следует избегать блокирования кода и разбивать большие / сложные задачи наряд "событий".Не должно быть точки, в которой ваш код «блокирует» (ожидает) IO read или write.

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

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

Многие встроенные структуры используют внутренний буфер, который передается в IO при«готовые» события подняты.Например, найдите событие drained в файле node.js (или on_ready в facil.io).

Это удобная функция, а не требование.

Событиецикл мог бы также добавить событие «готово» и предполагать, что ваш код будет обрабатывать буферизацию после частичного возврата вызовов write EAGAIN / EWOULDBLOCK.

Второе решение, которое я вижу, это прослушиваниекаждая веб-розетка использует другое ядро.

Нет необходимости.Один поток на одном ядре с равномерным дизайном должен поддерживать тысячи (и десятки тысяч) одновременно работающих клиентов с разумной нагрузкой (нагрузка на клиента является существенным фактором производительности).

Присоединение соединений TCP / IP кконкретное ядро ​​может (иногда) улучшить производительность, но это отношение многие-к-одному.Если бы нам пришлось выделять ядро ​​ЦП для каждого соединения, цены на сервер были бы слишком высокими.