Hazelcast, который смог: как получить молниеносный ответ на сотни запросов в секунду / Прохор Крылов

• Прохор, бэкенд-разработчик в компании Самокат, рассказывает о внедрении и использовании Hazelcast.  

• Самокат занимается ритейлом, логистикой и маркетплейсом, имеет более 500 микросервисов.  

• Цель - быстрое обслуживание пользователей, что требует использования кэша для оптимизации запросов.  

• Обсуждение типовой обработки запроса и роли кэша.  

• Проблемы с балансировкой запросов и использованием кэша в микросервисной архитектуре.  

• Варианты решения: вынесенный кэш, распределенный кэш, и их плюсы и минусы.  

• Популярные решения: Redis, Hazelcast, Patchter, и другие.  

• Сравнение Redis и Hazelcast: плюсы и минусы, поддержка и производительность.  

• Выбор решения на основе опыта разработчиков и инфраструктуры.  

• Использование комьюнити-версии Hazelcast.  

• Различия между версиями и их особенности.  

• Важность кластерного режима и работы внутри Java-приложений.  

• Hazelcast используется в 50+ сервисах для обработки пользовательских запросов.  

• Хранение данных в кэше, включая попытки логина, заказы, склады и рекомендации.  

• Проблемы и сложности, с которыми столкнулись при внедрении и использовании Hazelcast.  

• Проблема: несколько подов одного сервиса не обнаруживают друг друга.  

• Решение: добавить зависимость в класс хозекаст губернетос для обнаружения.  

• В версиях выше пятой зависимость предоставляется из коробки.  

• Сложность: модификация структуры данных в кэше.  

• Решение: делать новые поля опциональными при миграции.  

• Проблемы: ошибки при записи в не-наличные переменные.  

• Поддержка репликации данных на новую и старую версии.  

• Подходы: написание стерализатора, переименование кэша, добавление поля как налоб.  

• Проблемы: необходимость тестирования и проверки.  

• Проблема: поддержка только в интерпрайс-версии.  

• Решения: использование разных кубернетов, постепенное раскатывание, канареечные релизы.  

• Ограничения: необходимость ручного вмешательства и ограничения.  

• Проблема: отсутствие мониторинга в комьюнити-версии.  

• Решение: получение статистики по примитивам и создание графиков.  

• Необходимость доработки для управления кэшами.  

• Комьюнити-версия хозел каста жизнеспособна при правильной работе.  

• Необходимость создания API для управления и мониторинга.  

• Важность самостоятельного изучения документации и оценки трудностей.  

• Компания быстро росла и не могла вернуться к Redis.  

• Пришлось учиться работать с существующими подходами и структурами данных.  

• В перспективе компания использует Redis.  

• Компания не планирует контрибьюцию в Open Source.  

• Планируется развивать наработки в рамках аккаунта на GitHub.  

• В будущем планируется выложить свои решения для использования другими.  

• Ранее выкатка новой версии сервиса занимала 1-2 дня.  

• С ростом компании увеличилось количество бюрократии, что увеличило время.  

• В каждом инстансе хранится полный слепок данных.  

• Хозелкаст позволяет создавать распределенный кэш.  

• Объем данных распределяется между инстансами.  

• Хозелкаст используется как отдельно стоящий сервис и внутри инстансов.  

• Проводилось тестирование для измерения накладных расходов.  

• Разницы в производительности между использованием Хозелкаста и без него не обнаружено.  

• Хозелкаст может поднять два независимых сервиса при развале кластера.  

• Обнаружение проблем с репликацией данных происходит автоматически.  

• Хозелкаст определяет мастер-инстанс, но не является точкой входа.  

• Объем кэша зависит от развертывания и репликации данных.  

• При длительной вставке большого объема данных другой инстанс может замедлиться.  

• Проблемы возникают при объеме данных более 32 ГБ.  

• Изначально не планировалось покупать Enterprise-версию.  

• Компания была готова к доработкам и не рассматривала покупку Enterprise-версии.  

• Лучший вопрос будет выбран для белых пакетиков спонсоров.