Устройство

Где стоит ruststream-pulsar: между рантаймом RustStream и клиентом pulsar, один консьюмер и одна управляющая задача на подписку, один продюсер на топик.

Схема текстом

1. Ваш сервис: #[subscriber] обработчики-подписчики; RustStream::new(..) .with_broker(..)
2. Ядро RustStream: Рантайм: диспетчер, воркеры, завершение, пакеты
3. ruststream-pulsar: PulsarSubscriber и управляющая задача; PulsarPublisher продюсер на топик; PulsarMessage; PulsarSeeker; PulsarBroker конфигурация; PulsarSubscription, PulsarTopic
4. Клиент pulsar: Consumer по одному на подписку; Producer по одному на топик
5. #[subscriber] обработчики-подписчики → Рантайм: диспетчер, воркеры, завершение, пакеты: монтируются
6. Рантайм: диспетчер, воркеры, завершение, пакеты → PulsarSubscriber и управляющая задача: опрашивает поток
7. PulsarSubscriber и управляющая задача → Consumer по одному на подписку
8. PulsarPublisher продюсер на топик → Producer по одному на топик
9. Consumer по одному на подписку → Кластер Pulsar
10. Producer по одному на топик → Кластер Pulsar
11. С фичей testing место клиента может занять внутрипроцессный транспорт

Крейт реализует трейты брокера из ядра поверх клиента pulsar. Рантайм над ним один для всех брокеров. Всё, что относится к Pulsar, лежит в этом крейте: дескрипторы, что отправляет каждый исход, политика dead-letter и позиции, на которые переходит перемотка.

Подключённый брокер держит один клиент. Все издатели соединения делят этот клиент и его продюсеры, по одному на топик. Продюсер топика открывает первая публикация в него.

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

Клиент выдаёт сообщения по одному. Обработчик пакетов получает пакеты, которые собирает рантайм в сервисе, как показывает страница Партиции воркеров.

Повтор выполняет брокер: доставка получает отрицательное подтверждение, и брокер доставляет её снова. Чтобы вернуть сообщение, сервис ничего не публикует, поэтому регистрации на этом брокере не нужно объявлять издателя для повторов, как показывает страница Завершение.

Как части запускаются и останавливаются, показывает страница Жизненный цикл, а путь одного сообщения - страница Путь.

Внутрипроцессный транспорт

С фичей testing TestApp::start подключает тот же брокер не к серверу, а к внутрипроцессному транспорту. Дескрипторы, политики и доставки - те же, что в продакшене, и их настройки тоже. Транспорт воспроизводит полные имена топиков; подписки на один топик, на список и на шаблон; четыре типа подписки; отрицательное подтверждение; политику dead-letter клиента; отложенные повторы по часам рантайма; и хранимый журнал, по которому идёт перемотка. Он отвергает то же, что отвергает сервер: полезную нагрузку больше max_message_size, второй консьюмер подписки Exclusive, дескриптор, которым пользуются после завершения работы.

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

Без фичи транспорт не компилируется. В продакшен-сборке транспорт брокера занимает ровно столько же, сколько клиент, а поток подписки и завершение доставки - ровно столько же, сколько канал, который они оборачивают. Эти размеры проверяет компилятор.