Как сделать трансляцию в Пульсар - PullRequest
1 голос
/ 09 марта 2020

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

Мы хотели бы использовать одну машину для генерации данных и публиковать sh их в Pulsar topi c. Затем мы используем группу серверов, образуя реплику. Каждый сервер использует поток сообщений в этой топи c и обслуживает клиентов через WebSocket.

Это отличается от общей подписки, поскольку каждый сервер должен получать все сообщений, а не часть этого.

Я пришел к этому сообщению: https://kafkaesque.io/subscriptions-multiple-groups-of-consumers-on-pulsar-topic/, в котором объясняется, как выполнять такую ​​работу: каждому серверу необходимо создать новую эксклюзивную подписку, скажем, использовать UUID в качестве своего имя подписки, из уникальной эксклюзивной подписки вы можете получить полный поток сообщений этой топи c.

Но поскольку наша реплика сервера может быть динамической c, поэтому после перезапуска некоторых серверов они будут Снова создайте новую подписку UUID, в результате чего многие топовые подписки останутся в топи c, что в конечном итоге станет головной болью при обслуживании.

У кого-нибудь есть опыт настройки сценария использования с помощью Pulsar?

Ответы [ 2 ]

1 голос
/ 17 марта 2020

На самом деле, я обнаружил, что «Интерфейс считывателя» предназначен именно для этого вида использования:

https://pulsar.apache.org/docs/en/concepts-clients/#reader -интерфейс

1 голос
/ 09 марта 2020

Использование эксклюзивной подписки для каждого потребителя - это единственный способ гарантировать, что каждый из ваших потребителей получит ВСЕ сообщения в топи c, а Pulsar достаточно хорошо обрабатывает несколько подписок.

Проблема Кажется, это вариант использования перезапуска сервера, и я не думаю, что простое подключение с новой подпиской UUID является правильным подходом (откладывая потерянные подписки). Вы действительно хотите, чтобы сервер повторно использовал предыдущую подписку после перезапуска. Это связано с тем, что каждая подписка отслеживает последнее сообщение в topi c, которое было обработано и подтверждено, поэтому вы можете точно узнать, где вы остановились до сбоя сервера, если вы повторно подключитесь с тем же UUID подписки. Если вы подключитесь с новым UUID, вы начнете обрабатывать сообщения, созданные с этого момента времени, и все сообщения, созданные в течение периода перезапуска, будут «потеряны»

Поэтому вам нужно будет найти механизм разделять эти UUID при сбоях сервера и возвращать их на перезагружаемый сервер. Один из подходов заключается в том, чтобы иметь механизм, аналогичный выбору лидера zookeeper, при котором каждому серверу предоставляется эксклюзивная аренда, срок действия которой истекает периодически. Затем сервер должен периодически обновлять sh аренду, чтобы сохранить ее. Затем, если серверу понадобится выполнить sh, он не сможет обновить sh аренду этого UUID, и перезапускающемуся серверу будет предоставлена ​​аренда при попытке повторного подключения.

См. https://curator.apache.org/curator-recipes/leader-election.html для лучшего объяснения модели.

...