Что такое HurriCache

HurriCache это распределенная key-value база данных с поддерожкой как простых типов ключ значение так и конейнеров, блокировок, работы с atomics и многое другое. HurriCache может работать как standalone так и в кластере. В данной статье не буду сравнивать ее ни с каким либо продуктом, просто расскажу о том что умеет решение а остальные выводы пускай сделают пользователи.

Архитектура HurriCache

В основе HurriCache лежит кастомная, сильно оптимизированная Partitioned Hash Map. Целью оптимизации было избавится от некоторых факторов непредсказуемости, например рехэшинг. Сама по себе операция рехэшинг не является проблемой, но в случае если у вас задача отдавать данные максимально быстро то вставка данных которая привела к рехэшингу драматически увеличит latency системы из за того что рехэшинг произошел под блокировкой, и остальные потоку обязаны подождать некоторое время. Кастомный Partitioned Hash Map лишен рехэшинга и HurriCache может быть собран под пользователя с разными уровнями настроек. Сейчас по умолчанию Partitioned Hash Map 134217728 элементов. Количество элементов можно увеличить конфигурационно, но по умолчанию минимум 134 миллиона будет достаточно для 1й ноды. Прообразом служила Partitioned Hash Map absl::flat_hash_map но к сожелению у нее были серьезные недостатки и от нее пришлось отказаться. Partitioned Hash Map максимально использует SIMD-инструкции. Остальные внутренние детали реализации структуры данных являются коммерческой тайной.

Архитектурная схема узлов и взаимодействия

Описание компонентов:

SmartClient: это клинтский SDK который обеспечивает взаимодействие между HurriCache и приложением. Он включает клиенты для работы как с кластером, так и со standalone-нодой. В кластерной конфигурации SmartClient связывается с Coordinator Server, получая данные о топологии кластера и маршрутизации. Кроме того, SmartClient управляет механизмами Fallback и Rerouting. Важно отметить, что HurriCache не поддерживает Relay - ситуацию, когда SmartClient обращается к неверной ноде. В таком случае он повторно отправляет запрос на правильную ноду, используя данные, полученные от сервера, который указывает корректный маршрут.
HurriCache Server: это реализация самого сервера HurriCache.
Replication Server: это репликации данных внутри кластера HurriCache.

Почему маршрутизация вынесена на сторону клиента а не делается Relay

От настоящего Relay было решено отказаться из‑за влияния на производительность. Если бы HurriCache перенаправлял данные в корректную ноду, это вело бы к избыточному потреблению ресурсов: на один запрос задействовались бы два потока - один на ноде, куда изначально пришёл запрос, и второй - на целевой ноде. При высокой нагрузке такой подход заметно увеличил бы трафик между нодами HurriCache, что могло бы замедлить репликацию данных и общую производительность кластера.

Вместо этого HurriCache возвращает короткий ответ с адресом корректной ноды. При этом сам механизм определения маршрута не вызывает блокировок в ядре HurriCache - его можно считать практически бесплатным в плане потребления ресурсов.

Поддерживаемые типы данных и операции в HurriCache

Базовые Key-Value операции (Скаляры)
- createKeyValue: Создание новой пары "ключ-значение". Здесь имеется ввиду именно создание, а не обновление. Если ключ существует то метод вызовет ошибку.
- getValue: Чтение значения по ключу.
- getAndDeleteValue: Атомарное чтение и последующее удаление объекта за один запрос
- updateValue: Явное обновление только существующего значения. Если ключ не существует то метод вызовет ошибку
- remove: Удаление любого существующего объекта. Может не сработать если объект заблокирован пользователем.
Контейнеры: HurriCache поддерживает привычные контейнеры которые всем хорошо знакомы:
- Set: Упорядоченные (OrderedSet) и неупорядоченные (HashSet).
- Map: Упорядоченные (OrderedMap) и неупорядоченные (HashMap).
- List: Связный список (Linked List).
- Vector: Массив (Array List).
- Queue: Очередь FIFO.

HurriCache предоставляет достаточно богатое API которые позволяют решать большинство задая. Пречислю основные:

createContainer создать контейнер. Здесь имеется ввиду именно создание, а не чтото другое. В метод можно передать начальные значения для всех видов контейнеров.
getContainer прочитать содержимое контейнера. В случае больших контейнеров использовать апи с осторожностью так как это может привести к определенным последствиям
getSize получить размер объекта, применимо и к скалярам.
getTail/getHead/getAndRemoveFront/getAndRemoveTail/getAndRemoveElementAtPosition/getElementAtPosition разнообразные способы доступа к элементам контейнера. Не все контейнеры поддерживают подобные апи. Детали есть в кокументации к коду и контракту API.

У всех API контейнеров есть метод как get так и getAndDelete и Delete. Это значит что действия с контейнерами можно совершать атомарно.

Отдельно хотелось отметить Ordered контейнеры в них вес является uint64_t это говорит о том что вес можно указать очень гибко даже можно указать его как миллисекунда, для организации упорядоченой по времени очереди используя OrderedSet

Атомики: HurriCache поддерживает атомарны счетчики и большинство операций которые есть в std::atomic
- atomicLoad
- atomicLoadAndDelete
- atomicCreate
- atomicStore
- atomicExchange
- atomicAdd
- atomicSub
- atomicOr
- atomicAnd
- atomicXor
- atomicCompareAndSet

Важное уточнение атомики возвращают старое значение, которое было до операции, это связано с тем что таков изначальный контракт.

Блокировки: HurriCache поддерживает возможность разделять данные по клиентам (ClientId), клиент может заблокировать данные на чтение, запись и сделать монопольный доступ.
TTL: HurriCache позволяет задать время жизни объекта. Через TTL объект будет недоступен для пользователя и в последствие удален. TTL применим к любым объектам, даже внутри контейнеров (в разработке сейчас и работает не везде)

Результаты тестов и производительность

Чтобы проверить реальную производительность HurriCache под нагрузкой, была проведена серия стресс-тестов.

Конфигурация тестового стенда:

HurriCache конфигурация: 1-нодовая конфигурация (Single Node), 8 worker потоков
CPU: Intel Core i9-11900K (11th Gen) @ 3.50GHz (8 ядер / 16 потоков)
RAM: 128 GB DDR4 (двухканальный режим)
Сеть: loopback (127.0.0.1) — тест измеряет чистую производительность движка и gRPC-стека без ограничений физической сети
Размер данных: Ключ — 150 байт, Значение — 500 байт

Тип операции	Результат
Чтение (Read) (32 потока по 100000 записей каждый)	до 85000 RPS
Запись (Write) (32 потока по 100000 записей каждый)	до 80000 RPS
Запись (Update) (32 потока по 100000 записей каждый)	до 80000 RPS
Запись (Delete) (32 потока по 100000 записей каждый)	до 80000 RPS
Атомики	~100000 RPS
Смешанный тест (20% Create / 60% Read / 20% Update) (32 потока по 100000 записей каждый)	80 000 – 100 000 RPS (доп. порог ошибок до 15%) Заложена самим тестом
Vector index access (от 16 до 500000 элементов) (32 потока по случайному индексу)	~80000 RPS
Queue/List many consumers/many producers (8 потоков consumer и producer)	до 50000 RPS на на каждую задачу.
Queue drain test (8 потоков consumer)	до 80000 RPS на 8 потоков чтения
Ordered set, create with order test (16 потоков consumer)	до 100000 RPS на 16 потоков insert
Задержка репликации на 3х нодовом кластере под трафиком (75 000 RPS на 1 ноду, распределение трафика равномерное по нодам)	около 10ms.

Потенциальные потребители функционала

HurriCache разрабатывался под жёсткие требования телеком-отрасли - систем OCS, где от задержки списания средств зависит пропуск трафика в реальном времени. Позже фокус проекта расширился: теперь он охватывает более широкий спектр high-load систем, которые сталкиваются с ограничениями традиционных in-memory хранилищ на многоядерных серверах.

Система ориентирована на инженеров и архитекторов, которым нужны экстремальные показатели пропускной способности (RPS) и строгое соблюдение SLA по задержкам.

1. Телеком, Системы Чарджинга
- В телеком-отрасли, в системах чарджинга, возникает проблема: нужно за миллисекунды атомарно проверять и списывать баланс абонента во время звонков или сессий передачи данных. Задержки могут привести к некорректной тарификации или обрыву связи. Это особенно актуально для 5G, где предъявляются высокие требования к времени ответа NCHF.
- HurriCache предлагает решение: благодаря нативным lock-free атомикам и предсказуемой задержке система может обрабатывать высококонкурентные транзакции чарджинга прямо в памяти, минимизируя риск блокировки потоков.
High-Load и AdTech сервисы
- High‑load и AdTech‑сервисы (рекламные движки и Real‑Time Bidding) сталкиваются с экстремальными требованиями к скорости обработки: нужно обслуживать миллионы аукционов в секунду и отвечать в пределах миллисекунд. Непредсказуемый рост задержек(p99 latency spikes) становится критичным - они могут возникать из‑за фоновых операций или блокировок в хранилище и приводят к пропуску ставок и прямым убыткам.
- Решение HurriCache базируется на Partitioned HashMap с предсказуемым профилем задержек и аппаратным ускорением (SIMD, prefetch). Это обеспечивает стабильный RPS без задержек и длинельных блокировках хранилища (для выполнения rehash требуется заблокировать мэпу (или кусок мэпы). При rehash все потоки (включая Read операции) будут ждать окончания операции на этом куске памяти которая еще будет достаточно дорогой с точки зрения памяти и срыва конвеера процессора, так как данные необходимо инвалидировать).
Финансовый сектор, Финтех и Торговые платформы
- Финансовый сектор, финтех и торговые платформы предъявляют строгие требования к выполнению атомарных операций - при этом важно избегать дополнительных накладных расходов. В традиционных решениях условная логика (например, операции CAS, списание или начисление лимитов, работа с балансами) зачастую реализуется через Lua‑скрипты. Такой подход имеет существенный недостаток: скрипты выполняются в блокирующем режиме, что снижает общий throughput системы.
- HurriCache решает эту задачу за счёт аппаратных атомиков и операций над ними atomicCompareAndSet, atomicAdd и atomicExchange. Они дают возможность применять распределённые lock‑free алгоритмы и структуры данных, обеспечивая производительность на уровне примерно 100 K RPS на одну ноду.
Gamedev
- Проблема: в игровых системах постоянно возникает острая конкуренция за изменение состояния - будь то параметры персонажей, данные игровых комнат или активные сессии. При этом все обновления должны происходить в реальном времени, а одновременный доступ множества потоков к одним и тем же объектам нередко приводит к конфликтам и ошибкам согласованности.
- Решение HurriCache: система предоставляет встроенную поддержку гранулярных блокировок (READ_LOCK, WRITE_LOCK) на уровне отдельных объектов. В сочетании с нативной поддержкой Multi‑tenancy это позволяет надёжно и изолированно управлять состоянием игроков из параллельных потоков/процессов - без потери производительности и с гарантией корректности данных.
Проекты с вертикальным масштабированием In‑Memory‑инфраструктуры
- Проблема: современные серверы оснащаются 64 и более ядрами CPU, однако многие in‑memory‑решения не умеют полноценно задействовать такой вычислительный потенциал. В результате значительная часть ресурсов остаётся невостребованной, а попытки компенсировать это запуском множества мелких инстансов лишь усложняют эксплуатацию и снижают общую эффективность инфраструктуры.
- Решение HurriCache: предоставляет возможнось сконфигурировать CPU пиннинг и количество worker потоков. Это позволяет эффективно использовать ресурсы современных серверов

Модель распространения, лицензирование и поддержка HurriCache

HurriCache использует модель Open‑Core / Commercial: ядро системы и клиентские библиотеки существуют в разных правовых режимах, что даёт гибкость и для сообщества, и для корпоративных клиентов.

Исходный код и участие сообщества

Ядро (серверная часть) остаётся проприетарным — это нужно, чтобы защитить уникальные алгоритмы in‑memory структур данных, на которых строится высокая производительность и предсказуемые задержки.

Клиентские SDK (SmartClient) полностью открыты. Мы активно приглашаем сообщество участвовать в развитии: можно добавлять поддержку новых языков, дорабатывать логику роутинга, оптимизировать сетевой стек и делиться интеграциями.

Редакции и лицензии

Single‑Node (Community / Developer Edition)

Формат: готовый Docker‑образ, не требующий сложной настройки.
Лицензия: бесплатная, подходит для коммерческого и некоммерческого использования.
Возможности: полноценный движок без искусственных лимитов по RPS, числу потоков или объёму памяти.
Ограничения: запрещены реверс‑инжиниринг и перепродажа в виде SaaS‑сервиса.

Cluster / Enterprise Edition

Формат: Helm‑чарты, приватный Docker Registry, нативные пакеты под корпоративные Linux‑дистрибутивы. Доступны кастомные сборки под требования заказчика.
Лицензия: коммерческая (расчёт по нодам, ядрам или кластеру).
Функционал: автоматическая репликация (Replication Server), динамическая маршрутизация, балансировка шардов и миграция данных (Coordinator Server).

Поддержка

Community Support (для Single‑Node и Open Source SDK)
Поддержка осуществляется через GitHub Issues. Баги и предложения обрабатываются в порядке очереди - без жёсткого SLA по срокам. Вариант оптимален для экспериментов, нагрузочных тестов и самостоятельной интеграции.

Платная поддержка
Если нужны приоритетные доработки, новый функционал или помощь с внедрением - даже для Single‑Node‑версии - можно заключить партнёрское соглашение с платной поддержкой. Команда HurriCache поможет с интеграцией решения, подберёт подходящие паттерны использования и подскажет, как выстроить архитектуру под ваши нагрузки.

Enterprise Support (для кластерных версий)
Предоставляется выделенный канал связи и гарантированный SLA на реакцию и поставку исправлений. В пакет входят архитектурные консультации, помощь с внедрением, анализ задержек и оптимизация клиентского кода — то, что критично при высоких нагрузках и строгих SLA.

Где попробовать

Если хотите протестировать HurriCache у себя, собрать метрики или проверить поведение под нагрузкой:

Java Client (SmartClient SDK): https://github.com/hurricache/hurricache-java-client
Python client https://github.com/hurricache/hurricache-python-client

Single‑Node Docker‑образ:

docker pull docker.io/alexaborisov/fastcache-standalone:26.34
docker pull docker.io/alexaborisov/fastcache-standalone:latest

Образы регулярно обновляются с учётом новых оптимизаций. Буду благодарен за любой фидбек, баг‑репорты и контрибьюты в репозитории клиентских библиотек — особенно по новым языкам и сценариям использования. Версия образа 26.34 значит 26 - год 34 - номер недели.

Обратите внимание - HurriCache требует поддержки AVX512 инструкций.
Без них не запустится.

Без AVX512 инструкций

docker pull alexaborisov/fastcache-standalone-noavx512:26.35
docker pull alexaborisov/fastcache-standalone-noavx512:latest

API контракт находится внутри

docker run --rm --entrypoint cat docker.io/alexaborisov/fastcache-standalone:26.34 /app/cache.proto

Работаем над созданием клиентов на других языках

Анатомия HurriCache