09/09/2026
This commit is contained in:
commit
2df362489a
44
ТЗ.txt
Normal file
44
ТЗ.txt
Normal file
|
|
@ -0,0 +1,44 @@
|
||||||
|
1. Наименование системы
|
||||||
|
|
||||||
|
"MiniStore" — многопоточный in-memory key-value сервер с текстовым протоколом.
|
||||||
|
|
||||||
|
2. Предметная область
|
||||||
|
|
||||||
|
Системы кэширования и хранения данных типа "ключ-значение" (как Redis/Memcached) широко используются для ускорения доступа к часто запрашиваемым данным в высоконагруженных приложениях (веб-сайты, API, сессии пользователей). Задача — разработать упрощённый аналог, демонстрирующий базовые принципы работы таких систем: конкурентный доступ к данным, обработка множества сетевых подключений, простая коммуникация по протоколу.
|
||||||
|
|
||||||
|
3. Постановка задачи
|
||||||
|
|
||||||
|
Разработать сервер, который:
|
||||||
|
|
||||||
|
принимает TCP-подключения от произвольного числа клиентов одновременно;
|
||||||
|
хранит данные в оперативной памяти в виде пар "ключ-значение";
|
||||||
|
поддерживает базовый набор команд (SET, GET, DEL, возможно EXISTS, KEYS);
|
||||||
|
корректно обрабатывает конкурентный доступ к данным без потери целостности;
|
||||||
|
выдерживает нагрузочное тестирование с измерением производительности (запросов/сек, задержка).
|
||||||
|
4. Функциональные требования
|
||||||
|
|
||||||
|
FR1: Клиент подключается по TCP и отправляет текстовые команды
|
||||||
|
FR2: SET key value — сохранить пару
|
||||||
|
FR3: GET key — вернуть значение или "не найдено"
|
||||||
|
FR4: DEL key — удалить пару
|
||||||
|
FR5: Поддержка множества одновременных клиентских подключений
|
||||||
|
FR6 (опционально): TTL (время жизни ключа), персистентность на диск
|
||||||
|
5. Нефункциональные требования
|
||||||
|
|
||||||
|
NFR1: Сервер должен выдерживать не менее N одновременных подключений (например, 1000+) — конкретное число уточняется на этапе тестирования
|
||||||
|
NFR2: Среднее время ответа на запрос — не более X мс под нагрузкой
|
||||||
|
NFR3: Отсутствие гонок данных (data race) при конкурентном доступе
|
||||||
|
NFR4: Устойчивость к некорректным командам (не должен падать)
|
||||||
|
6. Технологический стек
|
||||||
|
|
||||||
|
Язык: Rust
|
||||||
|
Асинхронный рантайм / сеть: tokio (обработка TCP-соединений)
|
||||||
|
Хранилище: in-memory, HashMap внутри Arc<Mutex<>> или DashMap (конкурентная хэш-таблица) — обсудим на этапе архитектуры
|
||||||
|
База данных: не требуется (хранение только в памяти); опционально — простая сериализация на диск (serde + JSON/бинарный формат) для персистентности
|
||||||
|
Тестирование нагрузки: собственный скрипт-клиент на Rust, либо готовый инструмент (redis-benchmark-подобный самописный, либо wrk/hey если сервер получит HTTP-обвязку)
|
||||||
|
7. Результат (deliverables)
|
||||||
|
|
||||||
|
Исходный код сервера
|
||||||
|
Простой клиент для ручной проверки (или инструкция по подключению через netcat/telnet)
|
||||||
|
Скрипт нагрузочного тестирования
|
||||||
|
Отчёт с замерами производительности (RPS, latency при разном числе потоков/подключений)
|
||||||
Loading…
Reference in a new issue