Что использовать для получения TCP-пакетов в python?
Помогите выбрать правильный инструмент для решения задачи. Нужно принимать данные со множества одинаковых устройств, у которых свой протокол поверх TCP, и складывать их в базу. До этого ни разу не работал с сетью на этом уровне, только с http.
Пока что нагуглил что нужно использовать streams из asyncio, и поднимать свой TCP-сервер, но пока не разобрался как с этим работать.
UPD:
Устройств будет довольно много - несколько сотен. Они собирают данные с датчиков и отсылают это на сервер раз в минуту.
z0ng, да, в этом случае на asyncio сокеты гораздо проще писать. Иначе всё равно придётся реализовывать какое-то подобие поверх select, не запускать же 100 тредов.
Вот простой пример.
Для описанных вами задач скорее всего не потребуется asyncio.
Конечно, может быть ваше устройство шлёт данные с огромной скоростью и не каждая БД успеет их принимать, или данным в потоке нужна нетривиальная и трудоёмкая обработка, а может быть их требуется обогащать доп-запросами к другим API, тогда вам, может быть и пригодится асинхронная работа. Но, чтобы сделать окончательный вывод, нужно больше подробностей.
Устройств могут быть сотни или тысячи, поэтому подумал что asyncio подойдет больше. Когда написал "Нужно принимать данные с одного устройства" я имел в виду с "с некого устройства", а не то что его будет 1 единица) Поправлю вопрос.
z0ng, ну тогда конечно. Но возможно ваша задача неплохо горизонтально масштабируется? Насколько разнообразны и велики по объёму данных передачи от этих устройств?
z0ng, разделите процессы приёма сообщений и записи их в БД персистентной очередью. Это сделает предсказуемыми нагрузки на все части системы, позволит горизонтально отмасштабировать отдельно приём и отдельно запись в БД.
Приём, конечно, лучше сделать асинхронным.
Если у вас тысячи запросов в минуту по паре десятков байт (~150 rps и 3 kbps, что мало), то вы их можете просто парой тредов в цикле обрабатывать, причём я бы начал с одного.
z0ng, отдельный поток для работы с базой и threading.Queue не решают эту проблему? При таком подходе мы практически бесплатно получаем буферизацию записи.
Поймите меня правильно, асинхронность — отличный инструмент, но там тоже полно подводных камней, стоит всё-таки инструменты под задачу подбирать, имхо :)
Про персистентные очереди, предложенные Сергей Паньков, я вообще молчу, можно заодно предложить развернуть kubernetes и нанять команду сисадминов, чтобы процесс перезапускать.
Ищите самое простое из всё ещё работающих решений, усложнить всегда успеете.
Владимир Олохтонов, а что может быть проще и надёжнее очередей? Это не ваш код, он сделан качественно для куда бОльших нагрузок, он изолирован, запускается в отдельном докере, хорошо задокументирован и все подводные камни его использования давно и тщательно исследованы.
Чтение из очереди и запись в БД - отдельный тривиальный процесс. Работает в один поток, масштабируется простым запуском любого нужного количества таких процессов. Решение изолированное, средствами очереди нормально обрабатываются падения и дисконнекты при перезапусках.
Осталось самое интересное - приём пакетов. Тут я с вами вынужден согласиться. Действительно, если заработает более простое решение, то имеет смысл его придерживаться. Но вам всё равно захочется несколько бэкендов, как-то бесшовно их переключать при обновлениях... Если асинхронное решение будет близкО к самому типовому случаю применения выбранного фреймворка, а фреймворк достаточно надёжный, то нет ничего плохого и такого уж сложного в асинхронности. Тем более под тот же капот вам не придётся прятать работу с БД,
Сергей Паньков, примерно всё проще брокеров очередей, имхо, согласованные распределённые системы простыми не бывают :)
Я работал только с Kafka и RabbitMQ — оба проекта с кучей артефактов и огромной кодовой базой: кафке нужен отдельный ZooKeeper, который несмотря на проверку временем, всё ещё требует от пользовательского кода умения восстановить все данные с нуля, поскольку в случае сбоев это самый простой способ его починить; у кролика блокирующая репликация, которая регулярно стреляет под нагрузкой.
Без репликации они неплохо работают, да, но какой смысл тогда говорить о надёжности?
Главное, что совокупная сложность системы при их использовании возрастает многократно. Если данные простые и нужно только какие-нибудь счётчики вести, то я бы предложил даже от полноценной базы отказаться в пользу какого-нибудь redis.
Простой