Теория и практика науки и образования №6 (6) август 2026 г.

Между созданием отложенной публикации и её отправкой могут перезапуститься компоненты, оборваться соединение или повторно поступить одно задание. Поэтому одного сохранения времени недостаточно: нужны механизмы, сохраняющие задание, допускающие повтор обработки и исключающие повторный видимый результат.

Постановка задачи

Цель исследования — обосновать схему надёжной отложенной публикации в Telegram-каналах. Рассматривается путь от создания задания до фиксации результата: сохранение, передача ответственности, восстановление соединения и подавление повторной обработки.

Сбой возможен до приёма сообщения, после приёма RabbitMQ либо после отправки в Telegram, но до сохранения результата. Общей транзакции между PostgreSQL, RabbitMQ и Telegram нет. Надёжность достигается локальными транзакциями, подтверждениями и повторяемыми операциями [1–3].

Требования: сохранение задания после подтверждения пользователю; автоматическое восстановление после временного отказа; отсутствие нескольких видимых сообщений при повторной доставке; явное состояние ошибки.

Метод исследования

Выделены границы ответственности и точки отказа; каждой сопоставлен защитный механизм. Реализация проверялась модульными проверками серверной части на Go и исполнителя на Python. Модельные отказы разобраны качественно, без неподтверждённых количественных результатов.

Архитектурные ограничения

Система включает службу публикаций на Go, RabbitMQ и исполнителя на Python. Состояния хранятся в PostgreSQL; исполнитель получает задание, вызывает TelegramBotAPI и возвращает результат. Пользовательский запрос не зависит от текущей доступности Telegram, но требуется согласовать независимые состояния компонентов.

Схема отложенной публикации

Служба сохраняет в PostgreSQL идентификатор, канал, содержимое, время, состояние и ключ идемпотентности, затем создаёт сообщение RabbitMQ. Задержка передаётся в заголовке x-delay; расширение x-delayed-message удерживает сообщение до заданного момента [7].

Последовательность показана на рисунке 1. При успехе сохраняются состояние и внешний идентификатор сообщения; при окончательной ошибке — состояние отмены и причина.

Рисунок 1. Контур обработки отложенной публикации

Передача ответственности

Подтверждение RabbitMQ означает приём сообщения, подтверждение исполнителя — завершение обработки [5, 6]. Преждевременное подтверждение создаёт окно потери. Оно отправляется после вызова Telegram и фиксации результата либо управляемой ошибки.

Доставка «не менее одного раза» допускает повтор. Ключ идемпотентности связан с публикацией; перед отправкой обработчик проверяет её состояние. Уже выполненное задание завершается без новой отправки, что соответствует образцу идемпотентного получателя [3].

Восстановление после временных отказов

После разрыва соединения отдельный фоновый процесс повторяет подключение к RabbitMQ: первая пауза равна 1 с, затем удваивается, но не превышает 30 с. Такой интервал снижает нагрузку на недоступный узел. Соединение и канал защищены взаимным исключением.

Планировщик запускает задачи по интервалу или расписанию. Если предыдущий запуск не завершён, новый пропускается. Это уменьшает число одинаковых заданий, но не заменяет идемпотентность: повтор может прийти из сети или очереди.

Таблица 1

Модельные сценарии отказов

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

Проверка реализации

Создана 251 автоматизированная проверка: 170 для серверной части на Go и 81 для исполнителя на Python. Среднее покрытие основных модулей — 63,47 %. Это характеристики проверочного набора, а не вероятностная оценка надёжности.

Проверки охватывают идемпотентность, планировщик, RabbitMQ, Redis, обработчики запросов, публикацию в Telegram, модели сообщений и взаимодействие служб. Тем самым затронуты основные границы контура.

Обсуждение результатов

Время выполнения отделено от надёжности доставки: время преобразуется в задержку, а надёжность обеспечивают состояние, подтверждения, восстановление соединения и идемпотентность. Способ ожидания можно заменить без изменения модели публикации.

Строгой гарантии однократной отправки нет: если Telegram принял сообщение, но ответ потерян, выполненную операцию не всегда можно отличить от невыполненной [1, 2]. Риск снижают внешний идентификатор, предел повторов и проверка состояния перед возобновлением.

TelegramBotAPI возвращает объект созданного сообщения [8], PostgreSQL даёт локальную транзакционную границу [9]. Но запись задания и отправка в RabbitMQ остаются двумя действиями. Перспективное решение — журнал исходящих сообщений, создаваемый одной транзакцией с заданием.
Изолированный механизм x-delayed-message можно заменить встроенной отложенной очередью либо выбором наступивших заданий без изменения состояний и идемпотентности.

Заключение

Предложена схема надёжной отложенной публикации: задание сохраняется в PostgreSQL, ожидание отделяется от выполнения посредством RabbitMQ, соединение восстанавливается с растущей задержкой, повторная доставка компенсируется ключом идемпотентности. Результат фиксируется в службе публикаций.

Модельные отказы показывают необходимость сочетания механизмов: очередь и повторы по отдельности не исключают потерю и дублирование. Реализация содержит 251 проверку при среднем покрытии 63,47 %. Перспективы — журнал исходящих сообщений и перенос задержки на поддерживаемые средства RabbitMQ.

***

1. Helland P. Life beyond Distributed Transactions: an Apostate’s Opinion // CIDR 2007: Proceedings of the Third Biennial Conference on Innovative Data Systems Research. Asilomar, 2007. URL: https://www.cidrdb.org/cidr2007/papers/cidr07p15.pdf (дата обращения: 24.07.2026).
   
   
2. Bailis P., Davidson A., Fekete A., Ghodsi A., Hellerstein J. M., Stoica I. Highly Available Transactions: Virtues and Limitations // Proceedings of the VLDB Endowment. 2014. Vol. 7, no. 3. P. 181–192. URL: https://www.vldb.org/pvldb/vol7/p181-bailis.pdf (дата обращения: 24.07.2026).
   
   
3. Hohpe G., Woolf B. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Boston : Addison-Wesley, 2003. 736 p.
4. Kleppmann M. Designing Data-Intensive Applications. Sebastopol : O’Reilly Media, 2017. 616 p.
   
   
5. RabbitMQ Team. Reliability Guide [Электронный ресурс]. URL: https://www.rabbitmq.com/docs/reliability (дата обращения: 24.07.2026).
   
   
6. RabbitMQ Team. Consumer Acknowledgements and Publisher Confirms [Электронный ресурс]. URL: https://www.rabbitmq.com/docs/4.2/confirms (дата обращения: 24.07.2026).
   
   
7. Videla A. Scheduling Messages with RabbitMQ [Электронный ресурс]. URL: https://www.rabbitmq.com/blog/2015/04/16/scheduling-messages-with-rabbitmq (дата обращения: 24.07.2026).
   
   
8. Telegram. Telegram Bot API [Электронный ресурс]. URL: https://core.telegram.org/bots/api (дата обращения: 24.07.2026).
   
   
9. PostgreSQL Global Development Group. Transaction Isolation [Электронный ресурс]. URL: https://www.postgresql.org/docs/current/transaction-iso.html (дата обращения: 24.07.2026).