Ребятки, есть какие-нибудь книги по разработке приложений реального времени?

самолет делаешь?

А ядро на линуксе под реалтайм уже пропатчил?

Не, эвенты с телефонии собираю и строю периоды

Линух же не реалтаймовая ось

а тут точно реалтайм нужен? может ты про другой реалтайм?

Есть версия ядра под реалтайм =)

Близко к реальному. Есть три модуля. Один строит периоды по событиям с телефонии, другой делит эти периоды по запланированным сегментам, а третий считает kpi. Сейчас это всё на воркерах, которые раз в минуту запускаются Подумал, что можно каким-то образом это всё на расписании построить. Случилось событие - колбек в нужный модуль и расчёт, не случилось - ничего не делаем.

тебе нужно это считать прям во время разговора и есть ограничения по задержкам?

Да. Все события отображаются на дашборде в близком к реальному времени

а ты не можешь просто в кафку лить события в несколько очередей и соответственно воркерами их слушать?

Дашборд по идее для человеков показывается. Человеки не очень умеют в реальное время.

кажется, тебе не нужно то реальное время о котором все подумали, надо просто как можно быстрее обрабатывать

На данный момент с событиями +- так и происходит. Есть класс-процессор, который вызывается внешним кодом (пускай будет в реальном времени) с событием для сотрудника. Эвент кладется в Redis, а воркером затем обрабатывается. Вопрос больше про события, которые представлены уже имеющимися, запланированными на будущее, сегментами. У них есть время начала, время завершения, и вот на каждую границу нужно вызывать обработчик

то есть ты заранее знаешь когда надо вызвать обработчик и задержка произвольная?

Да, знаю. А задержка чего?

задержка между временем генерации события и временем когда надо его обработать

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

Задержку самих событий телефонии игнорируем, допустим, равна нулю

оу

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

ну в целом мне твоя текущая реализация с опросом раз в минуту нравится

Там ещё один момент есть – событие с телефонии обязательно должно отлежаться одну минуту (эдакое сглаживание против "вышел на линию/слез с линии" по 10 раз в секунду). Так же одно и то же событие может приходить несколько раз (на линии/всё ещё на линии). Поэтому выбрал Redis в качестве буфера. По ключу сотрудника достаю событие и смотрю на прошлое состояние

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

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