Установка кластера Redis , заснованого на Redis і представляє повний набір Java – об’єктів і сервісів, які необхідні для створення розподілених додатків. В рамках проекту розвиваються дві гілки: x. Код проекту написаний на мові Java і поставляється під ліцензією Apache . У версіях 0 та 0 з’явилися черги з підтримкою пріоритизації, а також map і set структури підтримують шардінг даних в кластері. Щоб відповісти на це питання ці продукти треба порівняти. На перший погляд одна перевага у редіссона все ж є. Він заснований на Redis, підтримка якого є у безлічі хмарних сервісів таких як Aliyun, Amazon Elasticache, RedisLabs, Azure Redis Cache.
Тобто хмара дає вам повний managed – сервіс на Redis і позбавляє вас клопоту супроводу та обслуговування всього кластера. Почитайте ту ж статтю “Moving from Hazelcast to Redis”, на яку вони дають посилання. Там пояснюється причина по якій його використовують. Пам’ятаю, коли в Hazel з’явилися Near Cache, в перших стабільних (. ) релізах він спочатку падав з Exception, потім тек по пам’яті — мене це тоді дуже засмутило. Було дуже весело, коли наш міні – кластер раптово після оновлення почав падати кожні добу, інколи вночі, з OutOfMemory. Заткнули, звичайно, через авторестарт на час — благо zero – downtime в тому місці був не сверхкритичен, і можна було не відкочуватися, але було сумно.
Тим більше, що звичайні юніт – та інтеграційні тести такого не ловлять. Натомість ще раз довело, що перед тим як оновлювати/ додавати бібліотеку в mission critical частини системи потрібно хоча б обкатати її з тиждень або місяць на менш критичних “собаках”. А ось що Hazelcast, який як би працює в першу чергу з пам’яттю, не відловив витік пам’яті при простому включення (без шаманства і налаштувань) опції, яку вони піарили в release notes — було сумно. Якраз, по-моєму, після цього випадку вирішили в цьому компоненті з Hazelcast злазити. Правда, тоді в користь свого велосипеді на map – ах і lucen – ах (раптово. В java світі для простих завдань все є навіть в SE. Навіщо тягнути це в жабу, неясно.
