HurriCache: как мы подружили строгую типизацию с RESP‑коннектором

Спустя некоторое время экспериментов с HurriCache я пришёл к важному выводу: чтобы существующие проекты могли попробовать решение с минимумом изменений, нужен способ быстрого входа без переписывания кода.

Строгая типизация в HurriCache — осознанный выбор. Мы явно создаём скаляры (целые числа, числа с плавающей точкой, байтовые массивы) и контейнеры (List, Vector, Queue, OrderedSet, HashSet, SortedMap, HashMap) без ленивого приведения типов. Это даёт предсказуемость поведения и контроль над памятью, но повышает порог входа: нельзя просто взять и «подставить» HurriCache вместо Redis, не меняя семантику работы с данными.

Чтобы решить эту проблему, мы добавили RESP‑коннектор, совместимый с Redis‑клиентами. И сразу столкнулись с фундаментальными различиями моделей данных: то, что в Redis «просто строка», в HurriCache требует явного типа и стратегии создания.

Первые сложности: две модели данных — два мира

Главная проблема при внедрении RESP‑коннектора оказалась фундаментальной: модели данных Redis и HurriCache устроены принципиально по‑разному. Чтобы коннектор работал с моделью данных HurriCache нам пришлось потрудится в преобразовании моделей данных и разработать достаточно неплохой подход.

Основная задача RESP коннектора — не пытаться сделать из HurriCache очередной форк Redis, а дать разработчикам попробовать HurriCache через привычное RESP API при этом не потерять плюсы строгой типизации HurriCache, которые продолжают работать нативно через GRPC

Решение оказалось компромисом между ограниченым ленивым созданием объектов и строгим созданием. «Ленивость» была добавлена только в отдельные места, что позволило сохранить преимущества строгой типизации, но позволило RESP коннектору комфортно работать с HurriCache ядром. Это позволило:

• Сохранить преимущества строгой типизации в ядре

• Дать RESP‑коннектору возможность работать с ядром: для совместимых команд тип можно однозначно вывести, и ленивое создание здесь не порождает неопределённости.

• Не размывать гарантии системы: если команда требует поведения, которое противоречит строгой типизации (например, неявное приведение типов), она отклоняется с понятным кодом ошибки, причем система ведет себя одинаково как с точки зрения GRPC так и со стороны RESP API

Что получилось в итоге: принципы работы RESP‑коннектора

После анализа самых частых команд Redis мы реализовали RESP‑коннектор, руководствуясь чёткими принципами, которые сохраняют гарантии HurriCache:

Принцип строгой интерпретации типов.

Если создаваемое значение похоже на число (целое или с плавающей точкой), оно трактуется как скаляр соответствующего типа. Если это не число — значение считается байтовым массивом (byte array), и любые попытки трактовать его иначе отклоняются с ошибкой.

Единый контейнер для совместимости.

В HurriCache есть несколько типов контейнеров (List, Vector, Queue), но для совместимости мы используем Vector как универсальный контейнер. Он поддерживает как random access, так и операции, похожие на очередь.

Ограниченный функционал по дизайну.

Задача RESP‑коннектора — дать возможность интеграции, а потом принять решение о миграцмм, а вовсе не дублировать весь Redis API в HurriCache. Поэтому расширенные возможности (например, распределённые блокировки) оставлены в gRPC‑интерфейсе. RESP остаётся «чистым» коннектором с базовым функционалом и не более того

Осознанные границы несовместимости.

Некоторые различия в интерфейсе все же присутствуют, например:

• OrderedSet: HurriCache допускает одинаковые ключи с разным весом, а Redis — нет.

• Вес элемента: в HurriCache вес — uint64_t, в Redis — double.

В таких случаях коннектор преобразует double в uint64_t и не пытается быть настоящим Redis.

Через неделю работы был реализован полноценный RESP‑коннектор который позволил HurriCache быть немного Redis Friendly

Тестирование: совместимость и производительность

Для тестирования RESP‑коннектора мы выбрали два независимых вектора проверки:

1. Функциональная совместимость — насколько поведение HurriCache соответствует ожиданиям Redis‑клиентов.

2. Производительность — как накладные расходы на трансляцию типов и ограниченный ленивый режим влияют на QPS и задержки.

Проверка совместимости

Для тестирования совместимости мы использовали репозиторий resp-compatibility — стандартный набор тестов, который проверяет поведение сервера по спецификации RESP и сравнивает его с Redisами от 4.0 до современных версий.

Результаты: коннектор прошёл 50% всех тестов на совместимость с Redis 4.0 — 7.0. В плане реализованых команд совместимость больше 80%, здесь важно понимать, что эта цифра отражает не «качество реализации», а границы совместимости: мы не эмулируем семантику, которая противоречит строгой типизации HurriCache, а реализуем именно коннектор.

При этом все реализованные команды вели себя в точности как Redis 7.0 — в рамках заявленных ограничений (запрет неявных преобразований, отличия в OrderedSet и так далее). Это значит, что типовые сценарии (SET/GET, базовые операции над списками и множествами) работают предсказуемо, а «несовместимые» кейсы явно отклоняются с понятными кодами ошибок — так, чтобы разработчик мог быстро понять причину.

Производительность

Чтобы оценить влияние RESP‑коннектора на производительность, мы использовали redis‑benchmark в условиях, приближённых к реальным нагрузкам:

• Объём данных: 1 млн ключей,

• размер значения — 512 Б.

• Нагрузка: 100 клиентов.

• Без пайплайнинга: в реальных сценариях пайплайнинг встречается не всегда, и важно было проверить поведение при обычных последовательных запросах.

Интерпретация результатов:

• Скорость сопоставима или выше даже с трансляцией типов. Это говорит о том что архитектура работает так как ожидалось

• Стабильность хвоста. Максимальная задержка GET у HurriCache — всего 1.35 мс против 5.5 мс у Redis.

• Изоляция накладных расходов. Так как HurriCache многопоточный то это позволяет распределять нагрузки на нужные ядра процессора. RESP коннектор не влияет на основной путь обработки и не конкурирует с ядром HurriCache

Где можно попробовать

Если хочется быстро поднять HurriCache и протестировать RESP‑коннектор есть готовые Docker‑образы:

• docker.io/alexaborisov/fastcache-standalone-noavx512:latest — версия без AVX‑512. Подойдёт для большинства сред, включая те, где расширенные инструкции недоступны.

• docker.io/alexaborisov/fastcache-standalone:latest — полная версия с поддержкой AVX‑512 (если инфраструктура позволяет).

Обе версии регулярно обновляются, так что latest — это всегда актуальная сборка.

Клиенты (C++, Java, Go, Python) доступны в моём профиле(habr) — можно сразу подключить привычный стек и проверить типовые сценарии.

Если планируете пилот на кластере из нескольких нод — напишите в комментариях или в личку. Обсудим конфигурацию (3–4 ноды, мониторинг, лимиты по воркерам), чтобы подобрать оптимальный вариант под ваши сценарии и SLA.