Как стать автором
Обновить

Как в 3 раза снизить затраты на отказоустойчивую инфраструктуру, переехав с Hazelcast на Redis

Уровень сложности Простой
Время на прочтение 10 мин
Количество просмотров 6.1K
Всего голосов 29: ↑28 и ↓1 +27
Комментарии 18

Комментарии 18

В редисе же нельзя обеспечить strong consistency? Чтобы его использовать как некую предБД, например.

В любом распределенном хранилище strong consistency недостижима насколько я знаю. максимум eventual

Вполне достижима. Всего лишь нужны запись/чтение всегда с ведущего узла. И синхронная репликация. А если ведущий узел 1, то и линеаризуемость можно сделать.
Но в редисе вроде как нет возможности включить синхронную репликацию.

P.S. На Хабре это культура такая - мелко подгаживать (зачем?) вместо ответов?

Большое спасибо за статью. Сейчас тоже в полный рост стоим перед выбором подсистемы кэширования. Пока в фаворе Ignite, собственно у нас на нём больше чем один проект уже, но в сторону Redis тоже посматриваем. Вы их случайно не сравнивали "углублённо"? А то про возможности в статье есть но текстом, а вот например результатов тестирования производительность / объём потребляемой памяти нет... А хочется... Потому что не хочется пилить этот стенд самим :)

https://sprytin.notion.site/sprytin/Alfa-Backend-Stories-Redis-b757ed6384f84e00a8ad46133529fac5#01f7055b0e2c4fee97a6c781e21829cb

В ноушене как дополнительный материал оставил табличку со сравнением.

Детально не смотрели и не пилотировали

Почему в сравнении нет нашего отечественного Tarantool'а? Он вроде решает ровно такие же задачи.

Насколько понимаю, Hazelcast и Redis изначально системы разного назначения и объединяет их то, что они в основе своей построены на хранении данных в оперативной памяти, ровно как MSSQL и Mongo объединяет хранение файлов на жестоком диске

Скорее вопрос как так вышло, что был выбран изначально Hazelcast, если все потребности закрывал условный Redis

Вы абсолютно правы. Redis - вообще не "база данных", как утверждает автор. Это "in-memory data structure store". Так что в целом сравнение выглядит немного странно - если изначально нужен был in-memory key-value storage, то выбор хазла изначально был прям скажем неочевиден ))

Особенно порадовала что у Альфы нет денег заплатить за лицензию Hazelcast.

рискну предположить, что деньги-то как раз у Альфы есть. но! лицензию им сейчас никто просто не продаст.

а почему не смотрели в сторону keydb ? у него и с производительностью и с кластеризацией получше

Также можно на dragonfly посмотреть еще - тоже выглядит интересно как замена редису.

А процессы Sentinel запускаются на том же сервере что и процесс с Redis?

Да, все верно.

3 хоста, на хосте редис и сентинель рядом

Спасибо за статью. Осталась пара вопросов:

1. Я не очень понял "А с ним мы уменьшили память до 3 ГБ". Это 3 ГБ на 80 кластеров Redis?? Ведь сравнение вроде бы производится с 40Гб на 80 кластеров Hazelcast.
2. На картинке 7 клиентов - это какой то тестовый Redis который шарится 7-ю микросервисами? В проде каждый инстанс Redis будет только одну db иметь?

  1. 3 гб на 80 кластеров Redis против 40гб на то же количество hazelcast

  2. Там sentinel, Прометеус скраперы и тд

в какой-то момент осознали, что не замечать сколько инцидентов у нас возникает из-за Hazelcast, дальше невозможно

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

Бежали от дефектов падения по OOM (рандомных) самого Hazelcast, частых развалов кластера и потребление большого числа памяти при маленьких кешах.

Решенные задачи отражены в самом посте.
Почему это не получилось сделать на хазеле так же отражено в самом посте и кроме того, подчеркнуто большими буквами даже)

Зарегистрируйтесь на Хабре , чтобы оставить комментарий