Хранилище событий таблицы SQL в виде очереди в Qt App

Мне нужен совет относительно моего приложения Qt, использующего только классы Qt. Я могу принять модули QtNetwork и QSql в качестве решений, но не сторонние инструменты, такие как RabbitMQ и т. Д.

Я использую «Магазин событий как очередь» (см. Грег Янг стр. 46) с CQRS с источником событий. У меня есть простая таблица SQL, хранящая события с уникальным последовательным идентификатором. Таким образом, можно отслеживать «указатель хранилища событий», который будет использоваться «процессом отслеживания».

Цель: я хотел бы запустить несколько процессов для обработки событий как «вытащить их из очереди», чтобы они обрабатывались только один раз ….

На этом этапе я имею только межпроцессное взаимодействие через БД (mySQL, SQLite) и настраиваю общую таблицу, делающую TTL (Time To Live) в качестве списка прослушиваемых ударов. Процесс «ТОП» действует как рабочий. Так что, если он умирает, тайм-аут TTL и следующий вступает во владение. Таким образом, ТОП работник очищает «устаревшие процессы». Это имеет некоторую задержку, равную по меньшей мере TTL, например. 5с, что не является оптимальной ситуацией.

Теперь я хотел бы позволить другим процессам взять на себя определенную работу. Я мог бы изменить роль «TOP» с Worker на Dispatcher, но тогда мне потребовалось бы взаимодействие с другими процессами для выполнения работы (например, Process Events 100-200). Переход через БД к диспетчеризации не выглядит хорошей идеей с точки зрения производительности, поэтому я могу сигнализировать идентификаторы событий через классы QTcp ** … не реальная проблема. Но тогда возникает ряд других вопросов: что происходит, когда умирает мой диспетчер? Является ли хорошей практикой, чтобы один процесс играл в Worker and Dispatcher? Отказоустойчивость? Избыточность? Масштабируемость?

Я уверен, что должно быть какое-то простое решение, не ломая мне голову. Балансировщик нагрузки? Те же вопросы применяются. Балансировщик нагрузки — просто диспетчер. Кажется, мне нужно поддерживать пульс между процессами через TCP. Было бы быстрее …. Реализация чего-то вроде протокола RAFT на этом этапе — излишество! Не уверен, что применяются другие распределенные шаблоны проектирования или протоколы. У меня есть REST Framework … может быть, ATOM? PubSubHubHub и WebHooks? Не нравится WebSockets, так как нам нужно сохранить TCP-соединения …

Мысли, идеи, предложения приветствуются!