Система Pub / Sub с подсчетом ссылок

Я ищу способ спроектировать свою систему, состоящую из нескольких издателей, нескольких каналов и нескольких подписчиков, всех из которых можно легко однозначно идентифицировать. Мне нужно отправлять сообщения в обоих направлениях с минимальной задержкой. Однако, если подписчик умирает, сообщения, на которые он подписался, не следует отбрасывать, когда он возвращается в сеть, он должен получить все ожидающие сообщения. Поскольку я обрабатываю очень большое количество сообщений (до 1000 в секунду происходит на регулярной основе), имея сервер с низкими характеристиками, это означает, что постоянное хранение списков всех сообщений не является вариантом.

Я рассматривал возможность использования счетчика / списка ссылок для сообщений. Когда сообщение публикуется, оно инициализируется списком подписчиков на этот конкретный канал, когда подписчик получает сообщение, подписчик удаляется из списка. Сообщение удаляется, если список пуст.

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

Возможно, потребуется тайм-аут сообщений / подписчиков, например, если подписчик был неактивен в течение 10 минут, все записи списка, содержащие его, будут очищены.

Это хорошая идея, не забыл ли я о проблемах, которые могут возникнуть, в частности, с этой системой? Есть ли какая-нибудь система, которая уже это делает? RabbitMQ и подобные системы PubSub, похоже, не имеют этого - если нет, я думаю, Redis - это путь?


publish-subscribe reference-counting
person CBenni    schedule 16.02.2015    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Я могу представить себе управление счетчиком ссылок для жизненного цикла сообщений. Это звучит разумно с точки зрения управления сообщениями и памятью во время нормальной работы службы. Конечно, таймауты предоставляют патч для ссылок с мертвых сервисов.

Однако с точки зрения мониторинга работоспособности и восстановления сервисов это совсем другая история.

Опасность, которую я сейчас вижу здесь, - это государственное управление. Представьте себе службу, которая является подписчиком с отслеживанием состояния (т.е. имеет конечный автомат), который переводится из начального состояния (I) в определенное состояние (S). Каждое сообщение обрабатывается по-разному в разных состояниях. А теперь представьте, что ваша служба умирает и перезапускается. Тем временем некоторые сообщения сохраняются, и после того, как служба снова работает в сети, они отправляются ей. Однако Сервис получает их в неправильном состоянии (I вместо S) и действует неожиданно.

Сможете ли вы восстановить службу в том состоянии, в котором она была на момент сбоя? На практике это чрезвычайно сложно, поскольку даже в подходе с конечным автоматом служба имеет побочные эффекты / взаимодействует с глобальными состояниями и т. Д.

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

person breeze    schedule 23.02.2015
comment
Спасибо за ваш ответ. Сообщения и фактически не имеют состояния, поэтому я не вижу в этом проблемы. Я начал внедрять систему с помощью redis, посмотрю, сработает ли она так, как я надеюсь. - person CBenni; 24.02.2015