Українська
Завдання
Відповідно до номера свого варіанта виконайте завдання обраного рівня складності.
Варіанти
Варіант 1. Обробка замовлень магазину
1. Початковий рівень. Створити консольні програми для брокера RabbitMQ: видавець публікує в стійку чергу orders N замовлень (N вводиться з клавіатури) у форматі JSON (номер, товар, сума), а робітник з ручними підтвердженнями виводить кожне отримане замовлення й загальну суму.
2. Базовий рівень. Створити видавця й робітника замовлень з кворумною чергою orders, prefetch 1 і ручними підтвердженнями. Замовлення з сумою понад 50 000 грн «не проходять перевірку»: робітник відхиляє їх з requeue: false у чергу orders.failed через dead letter exchange. Запустити трьох робітників і вивести, скільки замовлень обробив кожен.
3. Високий рівень. Створити застосунок shop для обробки замовлень магазину через RabbitMQ з командами publish --count N --seed S (публікує замовлення JSON у чергу orders), work --name W --prefetch P (робітник з ручними підтвердженнями) і report, опцією --help. Невдалі замовлення (випадковий збій 20 %) повторюються через чергу затримки з TTL 3 с, після трьох спроб потрапляють у orders.parking-lot. Робітник ідемпотентний: ідентифікатори оброблених замовлень зберігаються у файлі. report виводить таблицю «оброблено – дублікатів – у parking-lot»; коди завершення 0/1/2.
Варіант 2. Сповіщення про погоду
1. Початковий рівень. Створити програму-видавця, яка публікує в обмінник weather типу topic прогнози з ключами <область>.<тип> (наприклад, london.rain), та програму-підписника, що отримує шаблон прив’язки з клавіатури й виводить відповідні прогнози.
2. Базовий рівень. Створити систему сповіщень про погоду: видавець щосекунди публікує випадкові події для 5 областей і 3 типів (rain, storm, heat), кожен користувач має стійку чергу з кількома шаблонами з файлу підписок. Підписник перевіряє шаблони (лише слова, *, #) і виводить таблицю кількості отриманих подій за типами.
3. Високий рівень. Створити застосунок сповіщень про погоду через RabbitMQ weather з командами publish --rate N --duration с (випадкові події в обмінник topic з ключами <область>.<тип>), subscribe --user ім’я --pattern шаблон… і unsubscribe --user ім’я, опцією --help. Підписки зберігаються як прив’язки стійкої черги користувача й змінюються без втрати накопичених повідомлень; штормові попередження мають пріоритет (окрема черга). Після завершення виводиться статистика за областями; коди завершення 0/1/2.
Варіант 3. Мініатюри зображень
1. Початковий рівень. Створити видавця, який для кожного файла зображення з теки (шлях вводиться з клавіатури) публікує завдання «створити мініатюру», і робітника, що імітує обробку (пауза пропорційна розміру файла) та виводить ім’я файла й час обробки.
2. Базовий рівень. Створити систему мініатюр із чергою завдань: робітник з prefetch 1 і ручними підтвердженнями зменшує зображення (або імітує обробку паузою 100–500 мс) і публікує результат у чергу thumbs.done; видавець чекає всі результати й виводить загальний час. Порівняти час для 1, 2 і 4 робітників.
3. Високий рівень. Створити застосунок thumbs для створення мініатюр зображень через чергу завдань RabbitMQ з командами enqueue --dir тека --count N (завдання для файлів теки), work --prefetch P (робітник зменшує зображення або імітує обробку паузою) і bench --workers 1,2,4,8, опцією --help. Режим bench сам запускає процеси-робітники, вимірює пропускну здатність (завдань/с, медіана 5 запусків) для prefetch 1, 10, 100 і записує таблицю «робітників – prefetch – завдань/с – прискорення» в CSV.
Варіант 4. Журнали мікросервісів
1. Початковий рівень. Створити програму, яка публікує в обмінник logs типу direct повідомлення журналу з рівнями info, warning, error (рівень і текст вводяться з клавіатури), та програму-збирача, яка отримує лише рівні, передані аргументами командного рядка.
2. Базовий рівень. Створити систему журналів мікросервісів з обмінником topic і ключами <сервіс>.<рівень>: збирач помилок отримує *.error і *.critical і записує їх у файл, консольний монітор отримує все й виводить підсумкову таблицю за сервісами та рівнями кожні 10 с.
3. Високий рівень. Створити застосунок logctl для журналів мікросервісів через RabbitMQ (обмінник topic, ключі <сервіс>.<рівень>) з командами emit --service S --rate N (публікує випадкові записи журналу), collect --pattern шаблон --file шлях (записує отримане у файл) і stats, опцією --help. Збирач використовує кворумну чергу й ручні підтвердження, а архів – потік RabbitMQ; stats читає потік від початку й виводить кількість подій за сервісами й рівнями.
Варіант 5. Банківські платежі
1. Початковий рівень. Створити програму, яка публікує платежі (рахунок, сума) у стійку чергу з підтвердженнями видавця та виводить для кожного платежу «підтверджено брокером» або повідомлення про помилку.
2. Базовий рівень. Створити видавця й обробника платежів: видавець використовує підтвердження видавця (CreateChannelOptions) і mandatory: true, повторює публікацію після PublishException до 3 разів з тим самим MessageId; обробник усуває дублікати за MessageId і виводить баланс кожного рахунку.
3. Високий рівень. Створити застосунок payments для банківських платежів через RabbitMQ з командами send --file платежі.csv, process і audit, опцією --help. Видавець публікує платежі (рахунок, сума, MessageId) пакетами по 100 з очікуванням підтверджень видавця і вимірює швидкість; обробник ідемпотентно зараховує платежі (оброблені ідентифікатори й баланси зберігаються у файлі атомарно). Тест: примусове завершення обробника під час роботи не змінює підсумкових балансів; audit порівнює їх з очікуваними.
Варіант 6. Телеметрія IoT-датчиків
1. Початковий рівень. Створити програму-імітатор датчика, яка щосекунди публікує в чергу показник температури (ідентифікатор датчика, значення, час), та споживача, який виводить показники й середнє значення.
2. Базовий рівень. Створити систему телеметрії з кворумною чергою: 10 імітованих датчиків публікують показники, споживач з prefetch 50 агрегує їх за хвилину (мінімум, максимум, середнє для кожного датчика) і підтверджує повідомлення пакетом (multiple: true) після запису агрегатів у файл.
3. Високий рівень. Створити застосунок телеметрії IoT-датчиків через RabbitMQ iot з командами simulate --sensors N --rate R (імітовані датчики публікують температуру), aggregate --window с (мінімум, максимум, середнє кожного датчика за вікно) і replay --from час, опцією --help. Сирі показники додатково пишуться в потік RabbitMQ, з якого replay перераховує агрегати за будь-який період. Перевірити, що після перезапуску брокера (docker restart) дані не втрачаються.
Варіант 7. Розподілений Монте-Карло
1. Початковий рівень. Створити координатора, який публікує в чергу K завдань «кинути N точок» для оцінки числа π методом Монте-Карло, та робітника, який виконує завдання й публікує кількість точок усередині кола в чергу результатів; координатор виводить оцінку π.
2. Базовий рівень. Створити координатора й робітників методу Монте-Карло з ReplyTo і CorrelationId завдання, prefetch 1 і ручними підтвердженнями. Кожне завдання має власне зерно генератора, тому результат не залежить від кількості робітників. Вивести оцінку π, похибку, час і кількість завдань кожного робітника.
3. Високий рівень. Створити застосунок montecarlo для оцінки π методом Монте-Карло через RabbitMQ з командами run --points N --tasks K (координатор публікує K завдань із власними зернами й збирає кількості точок у колі) і worker --name W, опцією --help. Виміряти час і прискорення для 1, 2, 4, 8 робітників-процесів (медіана 5 запусків) і вивести таблицю; перевірити, що після примусового завершення робітника під час обчислення результат залишається правильним.
Варіант 8. Лікарняна тріаж-черга
1. Початковий рівень. Створити програму реєстрації пацієнтів, яка публікує в класичну чергу з x-max-priority пацієнтів з пріоритетом 0–9 (ім’я й пріоритет вводяться з клавіатури), та програму лікаря, що приймає пацієнтів по одному й виводить їх у порядку прийому.
2. Базовий рівень. Створити систему тріажу: реєстратура публікує випадкових пацієнтів з пріоритетами (червоний 9, жовтий 5, зелений 1) і часом прибуття, два лікарі з prefetch 1 приймають по одному пацієнту (прийом 1–3 с). Вивести для кожного пацієнта час очікування і середній час очікування за категоріями.
3. Високий рівень. Створити застосунок лікарняного тріажу через RabbitMQ triage з командами arrive --rate N --duration с (публікує пацієнтів категорій червона, жовта, зелена в пріоритетну чергу) і doctor --name D (приймає пацієнтів по одному), опцією --help. Пацієнти зеленої категорії, що чекають довше 60 с, отримують вищий пріоритет (повторна публікація). Звіт виводить таблицю «категорія – пацієнтів – середнє – максимальне очікування» і зберігається в CSV.
Варіант 9. Електронний розклад потягів
1. Початковий рівень. Створити програму диспетчера, яка публікує в обмінник типу fanout оновлення розкладу (потяг, час, колія), та програму-табло станції, що виводить кожне отримане оновлення.
2. Базовий рівень. Створити систему розкладу: диспетчер публікує оновлення з файлу з паузами, кожне табло (назва станції – аргумент) має власну стійку чергу, прив’язану до fanout-обмінника, і після перезапуску отримує пропущені оновлення. Табло виводить актуальний розклад таблицею після кожного оновлення.
3. Високий рівень. Створити застосунок розкладу потягів через RabbitMQ trains з командами dispatch --file розклад.csv (публікує оновлення «потяг, час, колія» у fanout-обмінник) і board --station назва [--temporary] (табло виводить актуальний розклад), опцією --help. Оновлення мають TTL 10 хв (застарілі не показуються), постійне табло має стійку чергу, тимчасове – ексклюзивну. Вивести для кожного табло кількість отриманих і прострочених оновлень.
Варіант 10. Перевірка домашніх завдань
1. Початковий рівень. Створити сервер перевірки, який отримує з черги відповідь студента (ім’я, номер завдання, число) і відповідає в чергу ReplyTo оцінкою, та клієнт, що надсилає відповідь, введену з клавіатури, і виводить оцінку.
2. Базовий рівень. Створити RPC через черги для перевірки завдань: клієнт надсилає кілька відповідей одночасно з різними CorrelationId і чекає кожну не довше 3 с; сервер перевіряє відповідь за файлом еталонів. Вивести таблицю оцінок і повідомлення про таймаути.
3. Високий рівень. Створити застосунок перевірки домашніх завдань через RPC на чергах RabbitMQ grader з командами server --answers файл --workers N (оцінює відповіді за еталонами) і submit --student ім’я --file відповіді.json --timeout с, опцією --help. Запити мають Expiration, помилки сервер повертає властивістю Type, клієнт повторює запит після таймауту до 2 разів, а сервер не рахує дублікати (ідемпотентність за MessageId). Клієнт виводить оцінки; коди завершення: 0, 1 – аргументи, 2 – таймаут.
Варіант 11. Аукціон
1. Початковий рівень. Створити програму учасника аукціону, яка публікує ставки (ім’я, сума) у чергу bids, та програму аукціоніста, що обробляє ставки по одній і виводить поточну найвищу ставку.
2. Базовий рівень. Створити аукціон з послідовною обробкою ставок одним споживачем (prefetch 1): ставка, не більша за поточну, відхиляється; про кожну прийняту ставку аукціоніст повідомляє всіх учасників через fanout-обмінник. Вивести історію ставок і переможця.
3. Високий рівень. Створити застосунок аукціону через RabbitMQ auction з командами host --lot назва --duration с (аукціоніст обробляє ставки по одній, приймає лише вищі за поточну) і bid --name ім’я --strategy random|step (учасник публікує ставки), опцією --help. Черга ставок кворумна з single active consumer (x-single-active-consumer), тому другий аукціоніст стає резервним; перевірити перемикання після завершення першого. Звіт – таблиця ставок і переможець.
Варіант 12. Доставка їжі
1. Початковий рівень. Створити програму, яка публікує в обмінник topic події замовлень з ключами <місто>.<статус> (наприклад, madrid.delivered), та підписника, що отримує шаблон з клавіатури й виводить відповідні події.
2. Базовий рівень. Створити систему подій доставки: кур’єрська служба міста отримує <місто>.ready, аналітика – *.delivered, служба підтримки – #.cancelled. Кожен підписник має стійку чергу й виводить кількість подій за містами після завершення потоку подій.
3. Високий рівень. Створити застосунок подій доставки їжі через RabbitMQ (обмінник topic, ключі <місто>.<статус>) з командами simulate --cities A,B,C --orders N і service --role courier|analytics|support --city C, опцією --help. Кур’єрська служба отримує <місто>.ready, аналітика – *.delivered, підтримка – #.cancelled. Статуси кожного замовлення мають іти по порядку; аналітика обчислює середній час доставки за містами, підтримка ідемпотентно обробляє скасування; результат – таблиця.
Варіант 13. Імпорт CSV-файлів
1. Початковий рівень. Створити програму, яка читає CSV-файл (шлях вводиться з клавіатури) і публікує кожен рядок окремим повідомленням у чергу, та споживача, що підраховує рядки й суму числового стовпця.
2. Базовий рівень. Створити імпорт CSV через брокер: видавець ділить файл на пакети по 100 рядків (номер пакета, кількість пакетів), кілька робітників перевіряють рядки й публікують звіт про кожен пакет; координатор виводить прогрес у відсотках і підсумок: рядків, помилок, час.
3. Високий рівень. Створити застосунок csvimport для імпорту CSV-файлу через RabbitMQ з командами import файл --batch N (публікує пакети рядків) і worker (перевіряє рядки пакета), опцією --help. Некоректні рядки потрапляють у чергу помилок з номером рядка й причиною, імпорт відновлюється після падіння робітника без повторної обробки пакетів (ідемпотентність за номером пакета). Вивести звіт (рядків, помилок, час) і записати помилки в CSV.
Варіант 14. Моніторинг цін конкурентів
1. Початковий рівень. Створити планувальника, який щосекунди публікує завдання «перевірити ціну товару» для списку товарів з файлу, та робітника, що імітує запит ціни й виводить товар і ціну.
2. Базовий рівень. Створити систему моніторингу цін через RabbitMQ: планувальник публікує завдання «перевірити ціну товару» для товарів з файлу, робітник імітує запит ціни з помилками сайту (30 %) і відхиляє невдалі завдання в чергу помилок через dead letter exchange; окремий споживач черги помилок виводить товар, причину (x-death) і кількість спроб.
3. Високий рівень. Створити застосунок моніторингу цін конкурентів через RabbitMQ prices з командами schedule --file товари.csv --interval с (публікує завдання перевірки ціни), work (імітує запит ціни з випадковими помилками) і report, опцією --help. Невдалі перевірки повторюються з наростаючою затримкою (черги 1, 5, 25 с), після чотирьох спроб – parking-lot; report виводить таблицю змін цін і завдань у parking-lot.
Варіант 15. Шкільні оголошення
1. Початковий рівень. Створити програму, яка публікує оголошення в обмінник типу headers із заголовками class і role, та програму-отримувача, що прив’язує чергу з x-match = all до класу й ролі, введених з клавіатури.
2. Базовий рівень. Створити розсилку шкільних оголошень через headers-обмінник: вчителі отримують оголошення для своєї ролі (x-match = any), батьки – для свого класу й ролі (x-match = all). Видавець читає оголошення з файлу; кожен отримувач виводить отримані оголошення та їх кількість.
3. Високий рівень. Створити застосунок шкільних оголошень через headers-обмінник RabbitMQ school з командами announce --class К --role Р --text … і inbox --class К --role Р (отримувач прив’язує чергу за заголовками), опцією --help. Термінові оголошення мають пріоритет, а звичайні – TTL 7 днів; тест перевіряє матрицю «клас × роль» і виводить таблицю очікуваних і фактичних доставок.
Варіант 16. Генерація звітів
1. Початковий рівень. Створити RPC-сервер через черги, який на запит (назва звіту) повертає рядок «звіт … сформовано» після паузи 1 с, та клієнт, що надсилає запит і виводить відповідь.
2. Базовий рівень. Створити сервер звітів і клієнт з кореляцією запитів: клієнт одночасно надсилає 5 запитів з різними параметрами, сервер обробляє їх з prefetch 2, клієнт виводить відповіді в порядку надходження й загальний час; неіснуючий звіт повертає помилку.
3. Високий рівень. Створити застосунок генерації звітів через RPC на чергах RabbitMQ reports з командами server --instances N (формує звіт за назвою з паузою) і request --names a,b,c --parallel K --timeout с, опцією --help. Порівняти загальний час для 1, 2, 4 серверів і використання власної черги відповідей з direct reply-to (amq.rabbitmq.reply-to); вивести таблицю.
Варіант 17. Транспортні GPS-треки
1. Початковий рівень. Створити програму, яка публікує в потік RabbitMQ (x-queue-type = stream) точки GPS-треку автобуса (номер, координати, час), та програму, що читає потік від початку й виводить усі точки.
2. Базовий рівень. Створити систему треків на потоці RabbitMQ: імітатор публікує точки 5 автобусів, читач приймає позицію (first, last або номер) з командного рядка, обчислює пройдену відстань кожного автобуса й виводить таблицю.
3. Високий рівень. Створити застосунок GPS-треків автобусів на потоці RabbitMQ (x-queue-type = stream) tracks з командами simulate --buses N --duration с (публікує точки: номер, координати, час) і replay --offset first|last|N|час --bus номер, опцією --help. Кілька незалежних читачів переглядають ту саму історію; вивести відстань, середню й максимальну швидкість автобуса і зберегти трек у CSV.
Варіант 18. Реєстрація на конференцію
1. Початковий рівень. Створити програму реєстрації, яка публікує заявку учасника (ім’я, e-mail) у чергу, та сервіс підтвердження, що «надсилає лист» (виводить текст листа в консоль).
2. Базовий рівень. Створити сервіс підтвердження реєстрації з імітацією поштового сервера, що відмовляє у 30 % випадків: невдалі листи повторюються через чергу затримки (TTL 2 с) до 3 разів, після чого заявка потрапляє в чергу ручного розбору. Вивести підсумок.
3. Високий рівень. Створити застосунок реєстрації на конференцію через RabbitMQ conf з командами register --file учасники.csv (публікує заявки), mailer (імітує надсилання листа-підтвердження з випадковими відмовами поштового сервера й повторами через чергу затримки) і status, опцією --help. Кожен учасник отримує лист рівно один раз навіть після повторів і перезапусків (ідемпотентність за e-mail), status виводить таблицю «надіслано – у повторі – у розборі».
Варіант 19. Складські залишки
1. Початковий рівень. Створити програму складу, яка публікує події «надходження» і «відвантаження» товару (товар, кількість) у fanout-обмінник, та споживача, що веде й виводить залишки.
2. Базовий рівень. Створити систему складських залишків: два незалежні споживачі (облік і аналітика) мають власні стійкі черги; після обробки всіх подій вони порівнюють підсумкові залишки. Події мають номер версії, і споживач ігнорує застарілі та повторні події.
3. Високий рівень. Створити застосунок складських залишків через RabbitMQ stock з командами events --count N --duplicates P (публікує у fanout-обмінник події «надходження/відвантаження» з номерами версій), ledger (споживач веде залишки) і compare, опцією --help. Видавець навмисно дублює P % подій і змінює їхній порядок; два споживачі узгоджують стан за версіями, а compare виводить таблицю розбіжностей їхніх залишків (має бути порожньою).
Варіант 20. Кодування відео
1. Початковий рівень. Створити видавця, який публікує завдання кодування відео (назва, тривалість у секундах), і робітника, що імітує кодування (пауза, пропорційна тривалості) та виводить прогрес.
2. Базовий рівень. Створити систему довгих завдань кодування: робітник з prefetch 1 публікує прогрес в окрему чергу кожні 10 %, підтверджує завдання лише після завершення. Показати, що після примусового завершення робітника завдання повертається в чергу й виконується іншим.
3. Високий рівень. Створити застосунок кодування відео через чергу завдань RabbitMQ encode з командами submit --file відео.csv (завдання: назва, тривалість), work (імітує кодування паузою, публікує прогрес) і progress, опцією --help. Робітник підтверджує завдання після завершення, зберігає контрольні точки й після повторної доставки продовжує з них; progress виводить таблицю стану всіх завдань; перевірити поведінку після перезапуску брокера.
Варіант 21. Спортивні результати
1. Початковий рівень. Створити програму, яка публікує події матчу (хвилина, подія, рахунок) у fanout-обмінник, та програму-табло, що виводить поточний рахунок після кожної події.
2. Базовий рівень. Створити розсилку спортивних подій для трьох сервісів: табло, статистика (кількість ударів, карток за командами) і архів (запис у файл). Кожен сервіс має стійку чергу й ручні підтвердження; наприкінці матчу статистика виводить таблицю.
3. Високий рівень. Створити застосунок розсилки подій спортивного матчу через RabbitMQ match з командами play --file матч.csv --speed k (публікує пронумеровані події) і service --role board|stats|archive (табло рахунку, статистика ударів і карток, архів), опцією --help. Архів використовує потік RabbitMQ і дозволяє переглянути матч з будь-якої хвилини; статистика ідемпотентна (за номерами подій) і перевіряється порівнянням з архівом.
Варіант 22. Пошуковий індекс
1. Початковий рівень. Створити програму, яка публікує в чергу текстові документи з теки (ім’я файла й текст), та індексатор, що будує словник «слово → кількість документів» і виводить 10 найчастіших слів.
2. Базовий рівень. Створити пакетний індексатор документів через RabbitMQ: видавець публікує текстові документи з теки, а споживач з prefetch 100 будує словник «слово → кількість документів» і підтверджує документи одним BasicAckAsync(multiple: true) після індексації пакета з 50 документів. Вивести час індексації та порівняти з підтвердженням кожного документа.
3. Високий рівень. Створити застосунок пошукового індексу через RabbitMQ indexer з командами feed --dir тека (публікує текстові документи), index --batch N (будує словник «слово → документи» з пакетним підтвердженням) і search слово, опцією --help. Індекс зберігається у файлі атомарно разом зі списком оброблених документів, тому повторна доставка не змінює індексу; вивести таблицю часу індексації для пакетів 1, 10, 50, 100.
Варіант 23. Обчислення простих чисел
1. Початковий рівень. Створити координатора, який ділить діапазон [1; N] на K частин і публікує їх у чергу, та робітника, що підраховує прості числа в частині й публікує результат; координатор виводить загальну кількість простих чисел.
2. Базовий рівень. Створити розподілений підрахунок простих чисел з кількома робітниками, prefetch 1, ручними підтвердженнями й CorrelationId задачі; координатор виводить кількість, час і розподіл частин між робітниками, результат перевіряється послідовним обчисленням.
3. Високий рівень. Створити застосунок primes для розподіленого підрахунку простих чисел через RabbitMQ з командами run --max N --parts K (координатор ділить [1; N] на K частин і збирає результати) і worker (рахує прості числа частини), опцією --help. Виміряти час для 1, 2, 4, 8, 16 робітників і 16, 64, 256 частин, вивести таблицю прискорення (медіана 5 запусків), перевірити кількість послідовним обчисленням і пояснити вплив розміру частини.
Варіант 24. Обробка скарг клієнтів
1. Початковий рівень. Створити програму, яка публікує скарги в обмінник direct з ключем категорії (delivery, quality, payment), та програму відділу, що отримує скарги однієї категорії.
2. Базовий рівень. Створити маршрутизацію скарг за категоріями до трьох відділів зі стійкими чергами; скарги з невідомою категорією видавець отримує назад (mandatory: true) і публікує в чергу «нерозподілені». Кожен відділ виводить скарги й кількість оброблених.
3. Високий рівень. Створити застосунок обробки скарг клієнтів через RabbitMQ complaints з командами submit --file скарги.csv (публікує в обмінник direct з ключем категорії), department --category C і sla, опцією --help. Скарги мають TTL, що відповідає SLA категорії, прострочені потрапляють через DLX у чергу ескалації; sla виводить таблицю «категорія – вчасно – прострочено – середній час».
Варіант 25. Інтернет-бібліотека
1. Початковий рівень. Створити програму бібліотеки, яка публікує події «видано» і «повернуто» (книга, читач) у чергу, та споживача, що веде й виводить список виданих книг.
2. Базовий рівень. Створити систему подій бібліотеки з імітацією шаблону outbox: події спочатку записуються у файл-«таблицю» разом зі зміною стану, окремий процес публікує неопубліковані події з підтвердженнями видавця й позначає їх. Споживач ідемпотентний.
3. Високий рівень. Створити застосунок подій інтернет-бібліотеки через RabbitMQ за шаблоном outbox library з командами issue, return (записують зміну стану й подію у файл-«таблицю»), relay (публікує неопубліковані події з підтвердженнями видавця) і readers (ідемпотентний споживач веде видані книги), опцією --help. Перевірити, що після примусового завершення relay посеред публікації жодна подія не втрачається, а дублікати не змінюють стану споживача; вивести таблицю боржників.
Варіант 26. Сигналізація розумного дому
1. Початковий рівень. Створити програму датчиків, яка публікує тривоги (кімната, тип, час) у чергу, та програму пульта, що виводить отримані тривоги.
2. Базовий рівень. Створити систему тривог з TTL: події руху мають TTL 5 с, пожежні тривоги – без TTL і з вищим пріоритетом. Пульт, запущений із затримкою, отримує лише актуальні події; вивести кількість отриманих і прострочених подій (через DLX).
3. Високий рівень. Створити застосунок сигналізації розумного дому через RabbitMQ smarthome з командами sensors --rooms N --rate R (публікують тривоги: рух з TTL 5 с, пожежа без TTL і з вищим пріоритетом) і panel --delay с (пульт, запущений із затримкою), опцією --help. Прострочені події через DLX потрапляють у журнал, пульт групує повторні тривоги з однієї кімнати за 10 с; вивести таблицю за кімнатами й типами.
Варіант 27. Бронювання квитків
1. Початковий рівень. Створити програму, яка публікує запити на бронювання квитків (рейс, місце, клієнт) у чергу, та сервіс бронювання, що підтверджує або відхиляє запит (місце зайняте).
2. Базовий рівень. Створити сагу бронювання з імітацією: сервіси «місце», «оплата», «квиток» обмінюються повідомленнями через черги; якщо оплата не вдалася, публікується компенсаційне повідомлення «звільнити місце». Вивести журнал кроків для кожного бронювання.
3. Високий рівень. Створити застосунок саги бронювання квитків через RabbitMQ booking з командами request --count N --fail-rate P і service --role seat|payment|ticket, опцією --help. Сервіси «місце», «оплата», «квиток» обмінюються повідомленнями через черги; при невдалій оплаті публікується компенсація «звільнити місце». Кожен крок ідемпотентний, сага завершується успіхом або повною компенсацією; звіт перевіряє, що кількість зайнятих місць дорівнює кількості виданих квитків.
Варіант 28. Метеостанції
1. Початковий рівень. Створити програму метеостанції, яка публікує показники в чергу з обмеженням x-max-length 100, та споживача, що виводить показники й кількість отриманих.
2. Базовий рівень. Створити систему метеостанцій з повільним споживачем і дослідити стратегії переповнення: drop-head (втрачаються старі) і reject-publish (видавець отримує відмову з підтвердженнями). Вивести для кожної стратегії кількість надісланих, отриманих і втрачених показників.
3. Високий рівень. Створити застосунок метеостанцій через RabbitMQ meteo з командами station --rate R --overflow drop-head|reject (публікує показники в чергу з обмеженням x-max-length) і consumer --delay мс (повільний споживач), опцією --help. Видавець у режимі reject отримує відмови через підтвердження видавця й зменшує швидкість публікації (зворотний тиск); вивести таблицю втрат і затримок для різних швидкостей.
Варіант 29. Лічильник кліків
1. Початковий рівень. Створити програму, яка публікує N подій «клік» (сторінка, час) у чергу, та споживача, що підраховує кліки для кожної сторінки й виводить таблицю.
2. Базовий рівень. Створити лічильник кліків і порівняти продуктивність споживача: підтвердження кожного повідомлення, пакетне підтвердження (multiple: true) кожні 100 повідомлень і autoAck: true. Вивести кількість повідомлень за секунду для кожного режиму.
3. Високий рівень. Створити застосунок лічильника кліків через RabbitMQ clicks з командами emit --count N --pages P (публікує події «сторінка, час») і count --ack each|batch|auto --prefetch K (підраховує кліки сторінок), опцією --help. Виміряти пропускну здатність споживача для prefetch 1, 10, 100, 1000 і трьох режимів підтвердження (медіана 5 запусків), вивести таблицю й записати CSV.
Варіант 30. Порівняння гарантій доставки
1. Початковий рівень. Створити видавця, який публікує 1000 пронумерованих повідомлень, і споживача з autoAck: true, що завершується після 500-го повідомлення; вивести, скільки повідомлень залишилося в черзі й скільки втрачено.
2. Базовий рівень. Створити експеримент із падінням споживача: режими at-most-once (autoAck: true) і at-least-once (ручні підтвердження після обробки). Споживач аварійно завершується кілька разів; новий споживач дочитує чергу. Вивести кількість втрачених і дубльованих повідомлень для кожного режиму.
3. Високий рівень. Створити застосунок guarantees для порівняння гарантій доставки RabbitMQ з командою run --mode M --count N --crashes K, де M – at-most-once, at-least-once або idempotent, і опцією --help. Застосунок публікує N пронумерованих повідомлень, сам запускає й аварійно завершує K разів процеси споживачів, перезапускає брокер (docker restart) і будує звіт «режим – втрачено – дублікатів – час» для стійких і нестійких повідомлень.
Порядок виконання та захисту роботи
- Опрацювати теоретичні відомості та приклади розв’язання завдань.
- Запустити брокер RabbitMQ у Docker Desktop (
rabbitmq:4-management), відкрити вебконсольhttp://localhost:15672і переконатися, що брокер працює (rabbitmq-diagnostics ping). - Для свого варіанта скласти схему обміну: видавці, обмінники (тип, ім’я), черги (тип, стійкість, аргументи
x-…), прив’язки й ключі маршрутизації, споживачі, формат повідомлень, режим підтверджень і prefetch. - Створити в JetBrains Rider рішення .NET 10 з окремими проєктами видавця й споживачів (або однією програмою з режимами командного рядка) і пакетом
RabbitMQ.Client7.x. - Реалізувати завдання обраного рівня: ручні підтвердження, обробку
PublishExceptionіOperationInterruptedException, коректне закриття з’єднань; для базового й високого рівнів – стійкість, підтвердження видавця та ідемпотентну обробку. - Перевірити сценарії: кілька споживачів, падіння споживача під час обробки, перезапуск брокера (
docker restart), нерозподілене чи відхилене повідомлення; стан черг показати у вебконсолі. - Продемонструвати роботу програми викладачеві, пояснити програмний код і відповісти на контрольні питання.