Първо, нека поговорим за стража.
Sentinel управлява отказоустойчивостта, не конфигурира Redis за HA. Това е важно разграничение. Второ, диаграмата, която публикувахте, всъщност е лоша настройка - не искате да стартирате Sentinel на същия възел като възлите Redis, които управлява. Когато загубите този хост, губите и двата.
Що се отнася до "Прахосване на ресурси ли е?" зависи от вашия случай на употреба. Нямате нужда от три Redis възела в тази настройка, имате нужда само от два. Три увеличава вашето съкращаване, но не е задължително. Ако имате нужда от добавено съкращаване, това не е загуба на ресурси. Ако нямате нужда от излишък, тогава просто стартирате един екземпляр на Redis и го наречете добър – тъй като изпълнението на повече ще бъде „загубено“.
Друга причина за стартиране на две подчинени би била разделянето на четенията. Отново, ако имате нужда от него, няма да е загуба.
Що се отнася до „Има ли по-добър начин за пълно използване на наличните ресурси?“ не можем да отговорим на това, тъй като е твърде зависимо от вашия специфичен сценарий и код. Това означава, че ако количеството данни за съхраняване е „малко“ и скоростта на команди не е изключително висока, не забравяйте, че не е необходимо да отделяте хост на Redis.
Сега за „Клъстерирането на Redis алтернатива ли е на Redis Sentinel?“. Наистина зависи изцяло от вашия случай на употреба. Redis Cluster не е HA решение - това е решение за множество записващи/по-големи от ram. Ако целта ви е само HA, тогава тя вероятно няма да е подходяща за вас. Redis Cluster има ограничения, особено около операциите с няколко клавиша, така че не е непременно проста операция „просто използвайте клъстер“.
Ако смятате, че разполагането с три хоста, работещи с Redis (и три работещи Sentinel), е разточително, вероятно ще държите Cluster за още повече, тъй като изисква повече ресурси.
Въпросите, които сте задали, вероятно са твърде обширни и основани на мнение, за да оцелеят, както са написани. Ако имате конкретен случай/проблем, който решавате, моля, актуализирайте го, за да можем да предоставим конкретна помощ и информация.
Актуализация за подробности:
За правилно управление на отказ във вашия сценарий бих използвал 3 сентинела, единият работи на вашия JBoss сървър. Ако имате 3 JBoss възела, тогава използвайте по един на всеки. Щях да имам Redis pod (главен+подчинен) на отделни възли и да оставя Sentinel да управлява превключването при отказ.
Оттам нататък става въпрос за свързване на JBoss/Jedis, за да използва Sentinel за своята информация и управление на връзката. Тъй като не ги използвам, бързо търсене се оказва, че Jedis имат поддръжка за това, просто трябва да го конфигурирате правилно. Някои примери, които намерих, са в Търсене на пример за джедаи със Sentinel и https://github.com/xetorthio/jedis/issues/725, които говорят за JedisSentinelPool е маршрутът за използване на басейн.
Когато Sentinel изпълни отказ, клиентите ще бъдат прекъснати и джедаите (трябва ли?) ще се справят с повторното свързване, като попитат Sentinels кой е текущият господар.
