Українська
Завдання
Відповідно до номера свого варіанта виконайте завдання обраного рівня складності.
Варіанти
Варіант 1. Банківські рахунки
1. Початковий рівень. Створити застосунок Orleans (силос і клієнт в одному процесі) із зерном рахунку IAccountGrain (ключ – номер рахунку) з методами Deposit, Withdraw, GetBalance; клієнт виконує операції, введені з клавіатури у форматі «рахунок операція сума», і виводить баланс.
2. Базовий рівень. Створити силос і окремий клієнт Orleans для банку: зерно рахунку зберігає баланс та історію операцій через IPersistentState у Redis, переказ між рахунками відхиляє від’ємні суми й перевищення балансу з повідомленням клієнту; після перезапуску силосу клієнт виводить ті самі баланси.
3. Високий рівень. Створити застосунок Orleans bank із зернами банківських рахунків (баланс, поповнення, зняття, переказ) з командами silo [--redis], transfer від до сума, stress --accounts N --transfers M та опцією --help. Режим stress виконує M випадкових одночасних переказів між N рахунками, перевіряє незмінність загальної суми й виводить таблицю «рахунки – переказів/с – сума до/після» для N = 1, 10, 100; помилки – у потік помилок, коди завершення 0/1/2.
Варіант 2. Кошик інтернет-магазину
1. Початковий рівень. Створити застосунок Orleans із зерном кошика (ключ – ім’я користувача) з методами «додати товар», «вилучити товар», «вміст»; клієнт виконує команди з клавіатури й виводить вміст кошика та суму.
2. Базовий рівень. Створити застосунок Orleans, у якому зерно кошика резервує товари в зернах товарів (ключ – артикул, стан – залишок) і реєструє нагадування: якщо кошик не змінювався заданий час, резерви знімаються, а клієнт отримує повідомлення в журналі силосу.
3. Високий рівень. Створити застосунок Orleans shop із зернами кошиків (ключ – користувач) і товарів (залишок, резерви) з двома силосами в кластері на Redis і клієнтом з командами add, remove, checkout, --help. Кошик резервує товари, стан кошиків і товарів та нагадування зберігаються в Redis; перевірити, що після аварійної зупинки одного силосу кошики й резерви не губляться, і вивести звіт «кошик – товари – сума – силос».
Варіант 3. Ігрове лобі
1. Початковий рівень. Створити застосунок Orleans із зерном кімнати, до якої гравці приєднуються за іменем; коли в кімнаті 4 гравці, зерно виводить повідомлення «гру розпочато» і список гравців.
2. Базовий рівень. Створити застосунок Orleans з [StatelessWorker]-зерном підбору суперників за рейтингом і зернами кімнат: кімната після третього гравця запускає таймер відліку 5 с, а події кімнати публікує в потік Orleans, на який підписаний клієнт.
3. Високий рівень. Створити застосунок Orleans lobby для ігрового лобі (зерна кімнат, до яких приєднуються гравці, і зерна гравців) з командами silo і bots --count N --games M, опцією --help. Боти одночасно входять у кімнати, грають партії з випадковим переможцем, зерна гравців зберігають статистику й рейтинг Ело; вивести таблицю топ-10 гравців, кількість ігор і середній час очікування в лобі.
Варіант 4. Цифрові двійники IoT
1. Початковий рівень. Створити застосунок Orleans із зерном датчика (ключ – ідентифікатор), яке приймає показники температури й повертає мінімум, максимум і середнє; клієнт надсилає 20 випадкових показників для трьох датчиків.
2. Базовий рівень. Створити застосунок Orleans, у якому зерна датчиків передають агреговані показники зерну будинку, а зерно будинку раз на 5 с таймером виводить таблицю кімнат із середньою температурою й позначкою перевищення порогу.
3. Високий рівень. Створити застосунок Orleans twins із зернами-двійниками датчиків температури (агрегують показники) і будинків з командами silo --redis і simulate --houses H --sensors S --seconds T, опцією --help. Імітовані датчики надсилають показники, нагадування позначає датчики, що мовчать понад 1 хв, стан зберігається в Redis; вивести кількість показників/с, список несправних датчиків і метрики активацій у дашборді Aspire.
Варіант 5. Чат-кімнати
1. Початковий рівень. Створити застосунок Orleans із зерном чат-кімнати, яке зберігає останні 20 повідомлень; клієнт надсилає повідомлення, введені з клавіатури, і виводить історію кімнати.
2. Базовий рівень. Створити застосунок Orleans, у якому зерно кімнати публікує нові повідомлення в потік Orleans (провайдер у пам’яті), а кілька підписаних клієнтів-учасників в одному процесі виводять їх; учасник, що приєднався пізніше, спочатку отримує історію.
3. Високий рівень. Створити чат на Orleans chat із зернами кімнат (історія повідомлень) і користувачів, силосом і клієнтом в окремих процесах, командами join кімната ім’я, /rooms, /leave, опцією --help. Історія кімнат зберігається в Redis, зерно користувача пам’ятає кімнати, повідомлення доставляються учасникам через потоки Orleans; вивести статистику повідомлень за кімнатами після завершення.
Варіант 6. Складський облік
1. Початковий рівень. Створити застосунок Orleans із зерном товару (ключ – артикул) з методами «надходження», «резервування» і «залишок»; резервування понад залишок відхиляється з повідомленням.
2. Базовий рівень. Створити застосунок Orleans, у якому 50 одночасних клієнтських задач резервують той самий товар, а зерно гарантує відсутність перепродажу; стан зберігається в Redis, а програма виводить кількість успішних і відхилених резервувань.
3. Високий рівень. Створити застосунок stock, у якому той самий стан товару змінюють зерно Orleans і окрема програма, що пише безпосередньо в Redis, і продемонструвати InconsistentStateException (конфлікт ETag). Реалізувати повтор операції з перечитуванням стану, опцію --help і звіт «спроб – конфліктів – успішних».
Варіант 7. Онлайн-аукціон
1. Початковий рівень. Створити застосунок Orleans із зерном лота, що приймає ставки (ім’я, сума) лише більші за поточну й повертає лідера; клієнт вводить ставки з клавіатури.
2. Базовий рівень. Створити застосунок Orleans, у якому зерно лота після першої ставки запускає таймер завершення (30 с, продовжується на 10 с після кожної ставки) і по завершенні публікує переможця в потік; клієнти-учасники імітують ставки й виводять події.
3. Високий рівень. Створити застосунок Orleans auction із зернами лотів (приймають лише ставки, більші за поточну) з силосом на Redis і клієнтом з командами create лот ціна хв, bid лот сума, watch, опцією --help. Завершення лотів виконують нагадування (переживають перезапуск силосу), стан лотів зберігається; вивести звіт про продані лоти (переможець, ціна) та кількість ставок.
Варіант 8. Електронне голосування
1. Початковий рівень. Створити застосунок Orleans із зерном голосування, яке приймає голос (виборець, варіант) лише один раз від кожного виборця й повертає поточні підсумки.
2. Базовий рівень. Створити застосунок Orleans, у якому [StatelessWorker]-зерно приймає голоси, перевіряє формат і передає їх зерну підсумків; 10 000 одночасних голосів від клієнта підраховуються без втрат, а програма виводить підсумки й час.
3. Високий рівень. Створити застосунок Orleans vote для електронного голосування (кожен виборець голосує один раз) з командами silo, load --voters N і results, опцією --help. Зерна дільниць агрегують голоси й раз на секунду передають їх зерну підсумків; порівняти пропускну здатність з одним зерном підсумків і з агрегацією (таблиця «схема – голосів/с») і перевірити відсутність повторних голосів.
Варіант 9. Таблиця рекордів гри
1. Початковий рівень. Створити застосунок Orleans із зерном таблиці рекордів, яке приймає результат гравця й повертає топ-10; клієнт додає 100 випадкових результатів і виводить таблицю.
2. Базовий рівень. Створити застосунок Orleans із зернами регіональних таблиць (ключ – регіон) і зерном світової таблиці, яке таймером раз на 2 с збирає топ-100 з регіонів; вивести обидві таблиці.
3. Високий рівень. Створити застосунок Orleans leaderboard із зернами регіональних таблиць рекордів і світової таблиці (топ гравців за результатами) з командами silo --redis, load --players N --regions R, top регіон, опцією --help. Виміряти кількість результатів/с для 1, 4 і 16 регіональних зерен, зберегти таблиці в Redis і вивести таблицю вимірювань.
Варіант 10. Бронювання готелів
1. Початковий рівень. Створити застосунок Orleans із зерном номера готелю (ключ – номер), яке бронює номер на задану дату, якщо він вільний; клієнт вводить бронювання з клавіатури.
2. Базовий рівень. Створити застосунок Orleans, у якому 100 одночасних запитів бронюють 10 номерів на ту саму дату; зерна номерів гарантують відсутність подвійного бронювання, а програма виводить звіт відмов і список гостей.
3. Високий рівень. Створити застосунок Orleans hotel для бронювання номерів (зерна номерів без подвійного бронювання на дату, зерно готелю шукає вільний номер) з силосом на Redis і клієнтом з командами book, cancel, list дата, опцією --help. Неоплачені бронювання скасовуються нагадуванням; вивести заповненість готелю за датами.
Варіант 11. Бібліотечні видачі
1. Початковий рівень. Створити застосунок Orleans із зернами книг і читачів: видача книги можлива, якщо вона на місці й у читача менше 5 книг; клієнт виконує команди видачі й повернення.
2. Базовий рівень. Створити застосунок Orleans, у якому зерно книги веде чергу очікування: коли книгу повертають, вона резервується для першого в черзі, а зерно читача отримує повідомлення, що виводиться в журнал.
3. Високий рівень. Створити застосунок Orleans library із зернами книг (на місці чи видана, черга очікування) і читачів (не більше 5 книг) з силосом на Redis і клієнтом з командами take, return, queue, overdue, опцією --help. Нагадування позначають прострочені видачі, стан переживає перезапуск силосу; вивести звіт боржників.
Варіант 12. Каршеринг
1. Початковий рівень. Створити застосунок Orleans із зерном автомобіля зі станами «вільний», «в оренді», «обслуговування»; клієнт орендує й повертає автомобілі командами з клавіатури.
2. Базовий рівень. Створити застосунок Orleans, у якому зерно оренди нараховує вартість похвилинно таймером і через нагадування попереджає про перевищення запланованого часу повернення; стан автомобілів зберігається в Redis.
3. Високий рівень. Створити застосунок Orleans carsharing із зернами автомобілів (вільний, в оренді, обслуговування) і оренд (похвилинна вартість) з кластером із двох силосів на Redis і клієнтом-симулятором --cars N --users U, опцією --help. Перевірити, що після аварійної зупинки силосу жодна оренда не загубилася, і вивести звіт «автомобіль – поїздок – виручка».
Варіант 13. Лічильники відвідувань сайтів
1. Початковий рівень. Створити застосунок Orleans із зерном лічильника сторінки (ключ – URL), яке збільшує лічильник і повертає його значення; клієнт імітує 1000 відвідувань п’яти сторінок.
2. Базовий рівень. Створити застосунок Orleans, у якому «гаряча» сторінка отримує 100 000 одночасних відвідувань: порівняти одне зерно лічильника й схему з [StatelessWorker], що накопичує локальні суми й передає їх раз на 100 мс, та вивести час обох схем.
3. Високий рівень. Створити застосунок Orleans hits із зернами лічильників відвідувань сторінок (ключ – URL) з командами silo --redis і load --pages P --rate R (імітація відвідувань), опцією --help. Лічильники зберігаються в Redis пакетно (раз на секунду); вивести таблицю «сторінка – відвідувань» і пропускну здатність та пояснити, скільки відвідувань може загубитися при аварії силосу.
Варіант 14. Турнірна сітка
1. Початковий рівень. Створити застосунок Orleans із зернами матчів (ключ – «раунд-номер»), які приймають результат і повертають переможця; клієнт вводить результати чвертьфіналів.
2. Базовий рівень. Створити застосунок Orleans, у якому зерно матчу після введення результату передає переможця зерну наступного раунду, а зерно турніру виводить оновлену сітку на 8 учасників.
3. Високий рівень. Створити застосунок Orleans tournament для турнірної сітки на 16 учасників (зерна матчів приймають результат і передають переможця в наступний раунд) з силосом на Redis і командами create учасники.txt, result матч рахунок, bracket, опцією --help. Сітка відновлюється після перезапуску силосу, некоректні результати відхиляються; вивести сітку й шлях чемпіона.
Варіант 15. Моніторинг теплиць
1. Початковий рівень. Створити застосунок Orleans із зерном теплиці, яке таймером раз на секунду генерує показники температури й вологості та зберігає останні 10; клієнт виводить їх.
2. Базовий рівень. Створити застосунок Orleans, у якому зерна теплиць порівнюють показники з порогами, введеними клієнтом, і публікують тривоги в потік Orleans; клієнт виводить тривоги з часом і значенням.
3. Високий рівень. Створити застосунок Orleans greenhouse для моніторингу теплиць (зерна теплиць таймером генерують температуру й вологість і порівнюють їх з порогами) з командами silo --redis --otel і monitor, опцією --help. Пороги зберігаються в Redis, тривоги рахуються метрикою OpenTelemetry й відображаються в дашборді Aspire; вивести підсумок тривог за теплицями.
Варіант 16. Обмеження частоти запитів
1. Початковий рівень. Створити застосунок Orleans із зерном обмежувача (ключ – клієнт), яке дозволяє не більше 10 запитів за секунду; клієнт надсилає 30 запитів і виводить дозволені й відхилені.
2. Базовий рівень. Створити застосунок Orleans з обмежувачем за алгоритмом ковзного вікна для кожного клієнта й трьох клієнтів з різною частотою запитів; вивести таблицю «клієнт – дозволено – відхилено».
3. Високий рівень. Створити застосунок Orleans ratelimit із зерном обмежувача частоти запитів для кожного клієнта з командами silo і load --clients N --rps R --limit L (L запитів за секунду), опцією --help. Порівняти алгоритми фіксованого вікна, ковзного вікна й маркерного кошика, вивести точність обмеження та затримку перевірки для кожного.
Варіант 17. Диспетчер ліфтів
1. Початковий рівень. Створити застосунок Orleans із зерном ліфта, яке приймає виклики на поверхи й таймером переміщується на один поверх за секунду, виводячи поточний поверх.
2. Базовий рівень. Створити застосунок Orleans, у якому зерно будівлі розподіляє виклики між трьома зернами ліфтів за найменшою відстанню; вивести журнал руху та середній час очікування.
3. Високий рівень. Створити застосунок Orleans elevators, у якому зерна ліфтів таймером переміщуються на поверх за секунду, а зерно будівлі розподіляє виклики, з командою simulate --floors F --lifts L --calls N і опцією --help. Порівняти дві стратегії розподілу викликів (найближчий ліфт і найменш завантажений), вивести таблицю «стратегія – середнє очікування – максимальне очікування» і перевірити, що жоден виклик не загубився.
Варіант 18. Робочий процес заявок
1. Початковий рівень. Створити застосунок Orleans із зерном заявки зі станами «створена», «погоджена», «виконана», «відхилена»; недопустимі переходи відхиляються з повідомленням.
2. Базовий рівень. Створити застосунок Orleans, у якому зерно заявки виконує сагу з трьох кроків у зернах сервісів (резерв бюджету, резерв обладнання, призначення виконавця), а при збої кроку викликає компенсації попередніх; вивести журнал кроків.
3. Високий рівень. Створити застосунок Orleans workflow, у якому зерно заявки виконує сагу з трьох кроків у зернах сервісів (резерв бюджету, резерв обладнання, призначення виконавця) з компенсаціями при збої, з силосом на Redis і командами submit, status, inject-fault крок, опцією --help. Стан саги зберігається після кожного кроку, і після перезапуску силосу незавершені саги продовжуються; вивести звіт «заявка – стан – компенсації».
Варіант 19. Симулятор CAP
1. Початковий рівень. Створити консольну програму, що моделює три репліки ключ–значення: запис оновлює всі доступні репліки, читання повертає значення з випадкової; користувач вмикає й вимикає «розділення мережі» для однієї репліки і бачить застарілі читання.
2. Базовий рівень. Створити консольну програму-симулятор із режимами CP (запис вимагає більшості реплік) і AP (запис на доступні репліки, злиття «останній запис перемагає» після відновлення); вивести для обох режимів частку відмов і застарілих читань під час розділення.
3. Високий рівень. Створити застосунок capsim, що моделює репліковане сховище ключ–значення в режимах CP (запис вимагає більшості реплік) і AP (запис на доступні репліки, злиття «останній запис перемагає»), з опціями --replicas N, --mode cp|ap, --partition початок:тривалість, --ops K, --help. Програма моделює розділення мережі на дві частини, рахує відмови, застарілі читання й записи, втрачені при злитті, будує CSV для графіка й виводить таблицю порівняння режимів.
Варіант 20. Кворумна реплікація
1. Початковий рівень. Створити консольну програму, яка для N = 5 реплік і введених W та R перевіряє умову R + W > N і моделює 1000 операцій, виводячи кількість застарілих читань.
2. Базовий рівень. Створити консольну програму, що для N від 3 до 7 перебирає всі пари W і R та виводить таблицю «N – W – R – застарілих читань – відмов при відрізаних f репліках».
3. Високий рівень. Створити застосунок quorum, що моделює кворумну реплікацію ключ–значення з N репліками, з опціями --n, --w, --r, --latency мін:макс, --down f (відрізані репліки), --help. Кожна репліка має випадкову затримку, координатор чекає W або R найшвидших відповідей; вивести медіану й 99-й перцентиль затримки та частку застарілих читань для різних конфігурацій і CSV-файл.
Варіант 21. Вибір лідера
1. Початковий рівень. Створити консольну програму, у якій 5 вузлів-задач обмінюються хартбітами через канали, а при зупинці лідера вузол з найбільшим номером оголошує себе новим лідером (алгоритм «забіяки»).
2. Базовий рівень. Створити консольну програму зі спрощеним вибором лідера Raft: терми, випадкові таймаути 150–300 мс, голосування більшістю; вивести журнал виборів після зупинки лідера.
3. Високий рівень. Створити застосунок raftsim, що моделює вибір лідера за Raft (терми, випадкові таймаути, голосування більшістю) для вузлів-задач з обміном повідомленнями через канали, з опціями --nodes N, --kill, --partition вузли, --seconds T, --help. Змоделювати розділення мережі на більшість і меншість, показати, що лідер може бути лише в більшості, і вивести кількість виборів і час без лідера.
Варіант 22. Детектор відмов
1. Початковий рівень. Створити консольну програму, у якій вузли надсилають хартбіти раз на 200 мс, а монітор вважає вузол мертвим після 1 с тиші й виводить подію відмови.
2. Базовий рівень. Створити консольну програму з вузлами, що мають випадкову затримку й втрату хартбітів, та порівняти детектори з таймаутами 0,5, 1 і 2 с: кількість хибних спрацювань і час виявлення справжньої відмови.
3. Високий рівень. Створити застосунок detector, що моделює вузли з хартбітами (випадкова затримка й втрата пакетів) і монітор відмов, з опціями --nodes, --loss P, --jitter мс, --detector timeout|phi, --help. Реалізувати детектор за таймаутом і фі-накопичувальний детектор, вивести таблицю «детектор – поріг – хибних спрацювань – час виявлення» і CSV.
Варіант 23. Circuit breaker для сервісу погоди
1. Початковий рівень. Створити консольну програму, яка викликає імітований сервіс погоди (іноді кидає виняток) з трьома повторами й експоненційною затримкою та виводить кожну спробу.
2. Базовий рівень. Створити програму з конвеєром Microsoft.Extensions.Resilience (повтор, запобіжник, таймаут) для імітованого сервісу погоди з режимами «норма», «повільно», «збій» і вивести зміни стану запобіжника.
3. Високий рівень. Створити застосунок weather, що викликає імітований ненадійний сервіс погоди (частка збоїв --failure-rate, повільних відповідей --slow-rate) N разів (--requests N), опція --help. Застосунок порівнює три конфігурації (без захисту, лише повтори, повтори й запобіжник circuit breaker) і виводить таблицю «конфігурація – успішних – середня затримка – звернень до сервісу».
Варіант 24. Векторні годинники
1. Початковий рівень. Створити консольну програму з трьома процесами-задачами, які обмінюються повідомленнями через канали й ведуть векторні годинники; вивести годинник кожної події.
2. Базовий рівень. Створити консольну програму-чат із трьома учасниками, де повідомлення доставляються з випадковою затримкою, а отримувач показує їх лише в причинному порядку, використовуючи векторні годинники.
3. Високий рівень. Створити застосунок vclock, у якому процеси-задачі обмінюються повідомленнями через канали з випадковою затримкою й ведуть векторні годинники, з опціями --processes N, --messages M, --delay мін:макс, --help. Програма доставляє повідомлення в причинному порядку, визначає пари паралельних (конкурентних) подій і виводить кількість затриманих повідомлень і таблицю подій з годинниками.
Варіант 25. Реплікований лічильник CRDT
1. Початковий рівень. Створити консольну програму з G-Counter (лічильник лише для збільшення) на трьох репліках: кожна збільшує свою частку, після злиття всі показують однакову суму.
2. Базовий рівень. Створити консольну програму з PN-Counter на трьох репліках, які незалежно збільшують і зменшують значення та обмінюються станом у випадковому порядку; перевірити, що злиття комутативне, асоціативне й ідемпотентне.
3. Високий рівень. Створити застосунок crdt з опціями --replicas N, --ops K, --partition, --help, що реалізує G-Counter, PN-Counter і OR-Set, моделює розділення мережі й після відновлення виводить стан реплік і час збіжності.
Варіант 26. Ідемпотентні платежі
1. Початковий рівень. Створити застосунок Orleans із зерном рахунку, у якому платіж має ідентифікатор, а повторний платіж з тим самим ідентифікатором не списує гроші вдруге.
2. Базовий рівень. Створити застосунок Orleans, у якому клієнт надсилає платежі з повторами при імітованій втраті відповіді (30 %), а зерно рахунку зберігає оброблені ідентифікатори в стані; вивести кількість спроб і підсумковий баланс.
3. Високий рівень. Створити застосунок Orleans payments із зерном рахунку, що зараховує платежі ідемпотентно за ідентифікатором, з силосом на Redis і клієнтом --payments N --loss P (повтори при імітованій втраті відповіді), опцією --help. Ідентифікатори зберігаються з терміном життя, дублікати виявляються й після перезапуску силосу; вивести звіт «надіслано – спроб – дублікатів – баланс».
Варіант 27. Розклад лікарів
1. Початковий рівень. Створити застосунок Orleans із зерном лікаря (ключ – прізвище), яке записує пацієнта на вільний 20-хвилинний слот дня й повертає розклад.
2. Базовий рівень. Створити застосунок Orleans, у якому 50 одночасних пацієнтів записуються до трьох лікарів; жоден слот не займається двічі, а відхилені пацієнти отримують найближчий вільний слот.
3. Високий рівень. Створити застосунок Orleans clinic із зернами лікарів (запис пацієнтів на вільні 20-хвилинні слоти без подвійного займання) з силосом на Redis і командами book, cancel, schedule лікар дата, опцією --help. Нагадування записують у журнал повідомлення за годину до прийому, розклад переживає перезапуск; вивести завантаженість лікарів.
Варіант 28. Трекінг посилок
1. Початковий рівень. Створити застосунок Orleans із зерном посилки (ключ – номер ТТН), яке зберігає історію статусів з часом; клієнт додає статуси й виводить історію.
2. Базовий рівень. Створити застосунок Orleans, у якому зерна відділень передають посилки одне одному, а зерно посилки публікує зміну статусу в потік, на який підписаний клієнт-одержувач.
3. Високий рівень. Створити застосунок Orleans parcels для трекінгу посилок (зерно посилки зберігає історію статусів, зерна відділень передають посилки) з кластером із двох силосів на Redis і симулятором --parcels N, опцією --help. Історія зберігається в Redis, клієнт запитує статус під час аварійної зупинки силосу з повторами; вивести середній час доставки між відділеннями.
Варіант 29. Модель акторів на каналах
1. Початковий рівень. Створити консольну програму з актором-банківським рахунком на Channel<T> без Orleans: повідомлення «поповнити», «зняти», «баланс» (ask через TaskCompletionSource).
2. Базовий рівень. Створити консольну програму з системою акторів на каналах: реєстр акторів за іменем, надсилання повідомлень за адресою і переказ між двома рахунками без блокувань; перевірити 10 000 одночасних переказів.
3. Високий рівень. Створити застосунок actors із системою акторів на Channel<T> без Orleans (актори банківських рахунків, перекази повідомленнями) і актором-наглядачем, який перезапускає дочірні актори після винятку (стратегія «нехай падає»), з опціями --actors N, --messages M, --help. Порівняти пропускну здатність з версією рахунків на lock і вивести таблицю.
Варіант 30. Навантажувальний тест кластера
1. Початковий рівень. Створити застосунок Orleans із простим зерном луни й клієнтом, який виконує 10 000 послідовних викликів та виводить середню затримку.
2. Базовий рівень. Створити застосунок Orleans із зернами луни (повертають отримане значення) і клієнтом, який виконує виклики до 1, 10 і 1000 різних зерен з 1, 16 і 64 одночасних задач і виводить таблицю «зерен – задач – викликів/с – медіана затримки».
3. Високий рівень. Створити застосунок Orleans loadtest із зерном луни з командами silo N і run --grains G --tasks T --seconds S (T задач протягом S секунд викликають G зерен), опцією --help. Порівняти кластер з одного й двох силосів на Redis, вивести пропускну здатність, медіану й 99-й перцентиль затримки та CSV для графіка.
Порядок виконання та захисту роботи
- Опрацювати теоретичні відомості та приклади розв’язання завдань.
- Для свого варіанта скласти перелік зерен (інтерфейс, ключ, стан, провайдер збереження), схему викликів між зернами й клієнтом, таймери та нагадування; для завдань про CAP і відмовостійкість – модель вузлів, реплік і відмов.
- Якщо завдання потребує стійкого стану чи кластера, запустити Redis у Docker Desktop:
docker run -d --name redis -p 6379:6379 redis:8.8 redis-server --appendonly yes. - Створити в JetBrains Rider рішення .NET 10 з проєктами інтерфейсів, зерен, силосу й клієнта (або один проєкт, де силос і клієнт працюють в одному процесі) і реалізувати завдання обраного рівня.
- Перевірити сценарії: одночасні виклики одного зерна, перезапуск силосу, для кластера – аварійну й коректну зупинку силосу; переглянути метрики в дашборді Aspire.
- Продемонструвати роботу програми викладачеві, пояснити програмний код і відповісти на контрольні питання.