From 2df362489ae1f86e0782b0939f01f37d380a5cae Mon Sep 17 00:00:00 2001 From: David Date: Wed, 9 Sep 2026 16:42:24 +0500 Subject: [PATCH] 09/09/2026 --- ТЗ.txt | 44 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) create mode 100644 ТЗ.txt diff --git a/ТЗ.txt b/ТЗ.txt new file mode 100644 index 0000000..d985ced --- /dev/null +++ b/ТЗ.txt @@ -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> или DashMap (конкурентная хэш-таблица) — обсудим на этапе архитектуры +База данных: не требуется (хранение только в памяти); опционально — простая сериализация на диск (serde + JSON/бинарный формат) для персистентности +Тестирование нагрузки: собственный скрипт-клиент на Rust, либо готовый инструмент (redis-benchmark-подобный самописный, либо wrk/hey если сервер получит HTTP-обвязку) +7. Результат (deliverables) + +Исходный код сервера +Простой клиент для ручной проверки (или инструкция по подключению через netcat/telnet) +Скрипт нагрузочного тестирования +Отчёт с замерами производительности (RPS, latency при разном числе потоков/подключений) \ No newline at end of file