Как вести трансляцию в Pulsar
Я исследую технологию для нашего кластера. Pulsar выглядит неплохо, но использование больше похоже на систему очередей. Конечно, система массового обслуживания - это хорошо, но у меня есть конкретное требование: широковещательная передача.
Мы хотели бы использовать одну машину для генерации данных и публикации их в теме Pulsar. Затем мы используем группу серверов, формируя реплику. Каждый сервер использует поток сообщений по этой теме и обслуживает клиентов через WebSocket.
Это отличается от общей подписки, потому что каждый сервер должен получать все сообщения, а не их часть.
Я пришел к этому сообщению: https://kafkaesque.io/subscriptions-multiple-groups-of-consumers-on-pulsar-topic/, в котором объясняется, как выполнять такую работу: каждому серверу необходимо создать новую эксклюзивную подписку, скажем используйте UUID в качестве имени подписки, из уникальной эксклюзивной подписки вы можете получить полный поток сообщений этой темы.
Но поскольку наша реплика сервера может быть динамической, поэтому после перезапуска некоторых серверов они снова создадут новую подписку UUID, что оставит множество бесхозных подписок в теме, что в конечном итоге станет головной болью при обслуживании.
У кого-нибудь есть опыт настройки сценария использования вещания с помощью Pulsar?
2 ответа
Использование эксклюзивной подписки для каждого потребителя - единственный способ гарантировать, что каждый из ваших потребителей получит ВСЕ сообщения по теме, а Pulsar достаточно хорошо справляется с несколькими подписками.
Проблема, похоже, связана с вариантом использования перезапуска сервера, и я не думаю, что простое подключение с новой подпиской UUID является правильным подходом (если отбросить потерянные подписки). Вы действительно хотите, чтобы сервер повторно использовал предыдущую подписку после перезапуска. Это связано с тем, что каждая подписка отслеживает последнее сообщение в теме, которое было обработано и подтверждено, поэтому вы можете продолжить с того места, на котором остановились до сбоя сервера, если вы повторно подключитесь с тем же UUID подписки. Если вы подключаетесь с новым UUID, вы начнете обрабатывать сообщения, созданные с этого момента времени, и все сообщения, созданные во время периода перезапуска, будут "потеряны"
Следовательно, вам нужно будет найти механизм для совместного использования этих UUID при сбоях сервера и возврата их на перезапускающийся сервер. Один из подходов мог бы заключаться в использовании механизма, аналогичного выбору лидера зоопарка, при котором каждому серверу предоставляется эксклюзивная аренда, срок действия которой истекает периодически. Затем сервер должен периодически обновлять аренду, чтобы сохранить ее. Затем, если сервер выйдет из строя, он не сможет обновить аренду для этого UUID, и перезапускающемуся серверу затем будет предоставлена аренда при попытке повторного подключения.
См. https://curator.apache.org/curator-recipes/leader-election.html для лучшего объяснения шаблона.
На самом деле, я обнаружил, что "Интерфейс читателя" как раз для такого случая использования: