Что использовать для получения TCP-пакетов в python?

Question

[z0ng]

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

Пока что нагуглил что нужно использовать streams из asyncio, и поднимать свой TCP-сервер, но пока не разобрался как с этим работать.

UPD:
Устройств будет довольно много - несколько сотен. Они собирают данные с датчиков и отсылают это на сервер раз в минуту.

Answer 1

[Сергей Горностаев]

Использовать нужно сокеты. В некоторых случаях можно с asyncio.

Comments

[z0ng]

Спасибо. Поправил вопрос, устройств будет много (сотни), а не 1. Видимо, именно в этом случае и нужен asyncio?

[Roman K]

z0ng, да, в этом случае на asyncio сокеты гораздо проще писать. Иначе всё равно придётся реализовывать какое-то подобие поверх select, не запускать же 100 тредов.

Answer 2

[Сергей П]

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

Comments

[z0ng]

Устройств могут быть сотни или тысячи, поэтому подумал что asyncio подойдет больше. Когда написал "Нужно принимать данные с одного устройства" я имел в виду с "с некого устройства", а не то что его будет 1 единица) Поправлю вопрос.

Каждое устройство отправляют запрос раз в минуту.

[Сергей П]

z0ng, ну тогда конечно. Но возможно ваша задача неплохо горизонтально масштабируется? Насколько разнообразны и велики по объёму данных передачи от этих устройств?

[z0ng]

Сергей Паньков, как я понял из описания протокола (https://7gis.ru/assets/files/docs/manuals_ru/opisa... ) объем запроса - несколько десятков байт и в одном и том же формате.

[Сергей П]

z0ng, разделите процессы приёма сообщений и записи их в БД персистентной очередью. Это сделает предсказуемыми нагрузки на все части системы, позволит горизонтально отмасштабировать отдельно приём и отдельно запись в БД.
Приём, конечно, лучше сделать асинхронным.

[z0ng]

Сергей Паньков, спасибо большое! Буду копать в этом направлении.

Answer 3

[Владимир Олохтонов]

Если у вас тысячи запросов в минуту по паре десятков байт (~150 rps и 3 kbps, что мало), то вы их можете просто парой тредов в цикле обрабатывать, причём я бы начал с одного.

Система получится простая и достаточно надёжная.

Comments

[z0ng]

Нужно также складывать данные с устройств в БД, чтобы потом из django работать с ними. А это самое затратное, как я полагаю.

[Владимир Олохтонов]

z0ng, отдельный поток для работы с базой и threading.Queue не решают эту проблему? При таком подходе мы практически бесплатно получаем буферизацию записи.

Поймите меня правильно, асинхронность — отличный инструмент, но там тоже полно подводных камней, стоит всё-таки инструменты под задачу подбирать, имхо :)

Про персистентные очереди, предложенные Сергей Паньков, я вообще молчу, можно заодно предложить развернуть kubernetes и нанять команду сисадминов, чтобы процесс перезапускать.

Ищите самое простое из всё ещё работающих решений, усложнить всегда успеете.

[Сергей П]

Про персистентные очереди

Владимир Олохтонов, а что может быть проще и надёжнее очередей? Это не ваш код, он сделан качественно для куда бОльших нагрузок, он изолирован, запускается в отдельном докере, хорошо задокументирован и все подводные камни его использования давно и тщательно исследованы.
Чтение из очереди и запись в БД - отдельный тривиальный процесс. Работает в один поток, масштабируется простым запуском любого нужного количества таких процессов. Решение изолированное, средствами очереди нормально обрабатываются падения и дисконнекты при перезапусках.
Осталось самое интересное - приём пакетов. Тут я с вами вынужден согласиться. Действительно, если заработает более простое решение, то имеет смысл его придерживаться. Но вам всё равно захочется несколько бэкендов, как-то бесшовно их переключать при обновлениях... Если асинхронное решение будет близкО к самому типовому случаю применения выбранного фреймворка, а фреймворк достаточно надёжный, то нет ничего плохого и такого уж сложного в асинхронности. Тем более под тот же капот вам не придётся прятать работу с БД,

[Владимир Олохтонов]

Сергей Паньков, примерно всё проще брокеров очередей, имхо, согласованные распределённые системы простыми не бывают :)

Я работал только с Kafka и RabbitMQ — оба проекта с кучей артефактов и огромной кодовой базой: кафке нужен отдельный ZooKeeper, который несмотря на проверку временем, всё ещё требует от пользовательского кода умения восстановить все данные с нуля, поскольку в случае сбоев это самый простой способ его починить; у кролика блокирующая репликация, которая регулярно стреляет под нагрузкой.

Вот неплохая серия статей про их правильное использование: https://jack-vanlightly.com/blog/2017/12/3/rabbitm...

Без репликации они неплохо работают, да, но какой смысл тогда говорить о надёжности?

Главное, что совокупная сложность системы при их использовании возрастает многократно. Если данные простые и нужно только какие-нибудь счётчики вести, то я бы предложил даже от полноценной базы отказаться в пользу какого-нибудь redis.

[Сергей П]

Владимир Олохтонов, ок, вы меня убедили.