Laten we eerst de schildwacht praten.
Sentinel beheert de failover, het configureert Redis niet voor HA. Het is een belangrijk onderscheid. Ten tweede is het diagram dat je hebt gepost eigenlijk een slechte setup - je wilt Sentinel niet op hetzelfde knooppunt draaien als de Redis-knooppunten die het beheert. Als je die host verliest, verlies je beide.
Wat betreft "Is het verspilling van middelen?" het hangt af van uw gebruiksscenario. Je hebt geen drie Redis-knooppunten nodig in die opstelling, je hebt er maar twee nodig. Drie verhoogt je redundantie, maar is niet verplicht. Als u de extra redundantie nodig heeft, is dat geen verspilling van middelen. Als je geen redundantie nodig hebt, voer je gewoon een enkele Redis-instantie uit en noem je die goed - want meer uitvoeren zou "verspilling" zijn.
Een andere reden om twee slaven te gebruiken, zou zijn om de reads te splitsen. Nogmaals, als je het nodig hebt, zou het geen verspilling zijn.
Wat betreft "Is er een betere manier om volledig gebruik te maken van de beschikbare middelen?" daar kunnen we geen antwoord op geven, omdat het veel te afhankelijk is van uw specifieke scenario en code. Dat gezegd hebbende, als de hoeveelheid gegevens die moet worden opgeslagen "klein" is en de opdrachtsnelheid niet buitengewoon hoog is, onthoud dan dat u geen host hoeft toe te wijzen aan Redis.
Nu voor "Is Redis-clustering een alternatief voor Redis-sentinel?". Het hangt echt volledig af van uw gebruiksscenario. Redis Cluster is geen HA-oplossing - het is een oplossing met meerdere schrijvers/groter-dan-ram. Als je doel alleen HA is, is het waarschijnlijk niet geschikt voor jou. Redis Cluster heeft beperkingen, met name rond bewerkingen met meerdere toetsen, dus het is niet per se een eenvoudige "gebruik cluster"-bewerking.
Als je denkt dat drie hosts die Redis draaien (en drie die sentinel draaien) verspillend is, zul je Cluster waarschijnlijk zelfs nog meer vinden, omdat het meer middelen vereist.
De vragen die je hebt gesteld zijn waarschijnlijk te breed en op meningen gebaseerd om te overleven zoals ze zijn geschreven. Als je een specifiek geval/probleem hebt dat je aan het uitwerken bent, update dat dan zodat we je specifieke hulp en informatie kunnen geven.
Update voor details:
Voor een goed failoverbeheer in uw scenario zou ik met 3 schildwachten gaan, waarvan één op uw JBoss-server. Als je 3 JBoss-knooppunten hebt, gebruik er dan één op elk. Ik zou een Redis-pod (master+slave) op afzonderlijke knooppunten hebben en de schildwacht de failover laten beheren.
Van daaruit is het een kwestie van JBoss/Jedis aan te sluiten om Sentinel te gebruiken voor zijn informatie- en verbindingsbeheer. Omdat ik die niet gebruik, blijkt snel dat Jedis er de ondersteuning voor heeft, je hoeft het alleen maar correct te configureren. Enkele voorbeelden die ik vond zijn op Zoek naar een voorbeeld van Jedis met Sentinel en https://github.com/xetorthio/jedis/issues/725 die praten over JedisSentinelPool de route zijn voor het gebruik van een zwembad.
Wanneer Sentinel een failover uitvoert, wordt de verbinding met de clients verbroken en zal Jedis de herverbinding (moeten?) afhandelen door de Sentinels te vragen wie de huidige master is.