Всем программистам привет.
Делаю для работы небольшую систему мониторинга на Python с отправкой сообщений в Telegram.
Сейчас сделано так.
Есть скрипт отправки сообщений. Этот скрипт запускают другие скрипты, проверяющие различные параметры. Их несколько. Соответственно они передают через командную строку скрипту отправки параметры (ID чата, сообщение). Скрипты, которые что-то проверяют работают асинхронно. И сейчас получается, что в определенные моменты запускается несколько копий скрипта отправки, который пытается отправить сообщения в Telegram. И получается некая путаница в сообщениях, т.к. в это время скрипту не всегда удается отправить сообщения через прокси и он пытается это делать через другой прокси. Т.е. сообщения тоже уходят асинхронно.
Что хочу сделать.
Пусть наверное отправлять сообщения будет один процесс, а скрипты проверяльщики должны как-то информировать его о новых сообщениях.
Т.е. нужен ресурс, в который будут писать сообщения для отправки скрипты проверяльщики и из которого будет читать и отмечать что все отправлено скрипт отправки.
Вообще думаю про SQL (SQLite, MySQL). Но почитал, что там тоже какая-то хитрая схема одновременного доступа к базе для изменения.
Кто-нибудь делал что-то подобное? Наведите на верный и правильный путь. Если SQL, то какую базу брать?

То что вы хотите в современном мире реализуется менеджерами очередей. Есть некий процесс который отправляет в очередь сообщение (задачу на выполнение) а есть некий процесс который считывает сообщения из очереди и обрабатывает их. И тех и других количество свободно варьируется в зависимости от задачи. В вашем случае нужен 1 обработчик очереди отвечающей за отправку сообщений в телеграм.
Сейчас де-факто стандарт это RabbitMQ. С его можете начать знакомство, в сети куча информации, да и официальный туториал имеется.

rugo
Т.е. сообщения тоже уходят асинхронно.

Так а зачем это сделано, если это не нужно?

JOHN_16
реализуется менеджерами очередей

Согласен в целом.
Пример использования
http://progerson.ru/1579-ocheredi-soobscheniy-amqp-rabbitmq.htm

Без брокеров сообщений тоже как-то жили раньше.

Спасибо всем за совет использовать Rabbit.
Никак только не могу получать кол-во сообщений в очереди. Не подскажете есть ли какие способы получить данный параметр?

rugo
Наведите на верный и правильный путь.

Очереди сообщений RabbitMQ хороши, но когда у вас реальо большая распределенная система. В Вашем случае что вас вынуждает создавать много процессов? У меня сложилось впечатление что так вы проводите разбиение на компоненты.

Это удобнее делать по другому, при помощи импортов. Тогда код у вас будет синхронный и без всех этих заморочек. Если потребуется производительность то на это есть asyncio стандартный пакет питона в котором очереди тоже реализованы.

Для синхронизации sqlite не подходит. Mysql Postgresql Могут решить эту задачу, но явно избыточны. Основная задача баз данных - долговременное хранение данных.

doza_and
В Вашем случае что вас вынуждает создавать много процессов?

У меня проблема не в том, что много процессов, а в том, что создаваемые процессы асинхронны.
Т.е. главный процесс(процессы) что-то проверяют и запускают другой скрипт, который отправляет в Telegram. Из-за того, что отправка в него идет непредсказуемо, этот процесс идет неопределенное время. И если в это время наступит еще одно событие от главного процесса, то возможна ситуация, когда уведомление от первого события придет позднее второго.
На Rabbit мне удалось всю отправку в Telegram от всех скриптов проверки сделать в одном процессе и строго последовательно. Теперь бы еще победить работу с прокси, но это уже другая задача.

rugo
а в том, что создаваемые процессы асинхронны.

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