Za prvé, pojďme mluvit o strážci.
Sentinel spravuje převzetí služeb při selhání, nekonfiguruje Redis pro HA. Je to důležitý rozdíl. Za druhé, diagram, který jste zveřejnili, je ve skutečnosti špatné nastavení – nechcete spouštět Sentinel na stejném uzlu jako uzly Redis, které spravuje. Když ztratíte tohoto hostitele, ztratíte oba.
K otázce "Je to plýtvání zdroji?" záleží na vašem případu použití. V tomto nastavení nepotřebujete tři uzly Redis, potřebujete pouze dva. Tři zvyšuje vaši redundanci, ale není to nutné. Pokud potřebujete dodatečnou redundanci, pak to není plýtvání zdroji. Pokud nepotřebujete redundanci, stačí spustit jedinou instanci Redis a nazvat ji dobrou – protože spouštění dalších by bylo „zbytečné“.
Dalším důvodem pro spuštění dvou otroků by bylo rozdělení čtení. Opět, pokud to potřebujete, nebylo by to zbytečné.
K otázce "Existuje lepší způsob, jak plně využít dostupné zdroje?" na to nemůžeme odpovědět, protože je to příliš závislé na vašem konkrétním scénáři a kódu. To znamená, že pokud je množství dat k uložení "malé" a rychlost příkazů není příliš vysoká, pak pamatujte, že nemusíte věnovat hostiteli Redis.
Nyní k „Je shlukování Redis alternativou k Redis sentinelu?“. Opravdu záleží zcela na vašem případu použití. Redis Cluster není řešení HA - je to řešení s více zapisovači/větší než ram. Pokud je vaším cílem pouze HA, pravděpodobně pro vás nebude vhodná. Redis Cluster přichází s omezeními, zejména pokud jde o operace s více klíči, takže se nemusí nutně jednat o přímočarou operaci „použijte pouze cluster“.
Pokud si myslíte, že mít tři hostitele na Redisu (a tři na Sentinelu) je plýtvání, budete pravděpodobně držet Cluster ještě více, protože vyžaduje více zdrojů.
Otázky, které jste položil, jsou pravděpodobně příliš široké a založené na názorech, než aby přežily tak, jak byly napsány. Pokud máte konkrétní případ/problém, který řešíte, aktualizujte jej, abychom vám mohli poskytnout konkrétní pomoc a informace.
Aktualizace pro podrobnosti:
Pro správnou správu převzetí služeb při selhání ve vašem scénáři bych zvolil 3 strážce, jeden běžící na vašem serveru JBoss. Pokud máte 3 uzly JBoss, použijte jeden na každém. Měl bych modul Redis (master+slave) na samostatných uzlech a přepnutí při selhání bych nechal řídit strážce.
Odtud je otázkou zapojení JBoss/Jedis k použití Sentinelu pro jeho správu informací a připojení. Protože je nepoužívám, objeví se rychlé vyhledávání, že Jedis pro to má podporu, stačí to správně nakonfigurovat. Některé příklady, které jsem našel, jsou na Hledání příkladu Jedisů se Sentinelem a https://github.com/xetorthio/jedis/issues/725, které hovoří o JedisSentinelPool je cestou pro použití bazénu.
Když Sentinel provede převzetí služeb při selhání, klienti budou odpojeni a Jedisové se (měli?) postarat o opětovné připojení tak, že se Sentinelů zeptají, kdo je aktuální master.