Redis gebruikt een dict , dezelfde structuur als voor sleutels, om kanaalabonnementen op te slaan, zowel per klant als voor alle klanten (houdt een hash per abonnement bij met een lijst van geabonneerde klanten), dus het is tot 2^32 kanaalabonnementen in totaal.
Het gebruikt een lijst om patroonabonnementen per klant op te slaan, dus het wordt theoretisch alleen beperkt door het beschikbare knooppuntgeheugen.
Over het algemeen kunt u echter oneindig veel kanalen hebben. Zie een kanaal als een label wanneer een bericht wordt gepubliceerd. Berichten worden nooit opgeslagen. Wanneer het bericht wordt gepubliceerd, zoekt Redis naar de klanten die op dat kanaal zijn geabonneerd en test voor elk patroonabonnement. Het kanaal bestaat echt alleen terwijl het bericht wordt gepubliceerd.
Omdat er patroonabonnementen zijn, zijn er onbeperkt 'logische' kanalen.
Alleen in evenementenmeldingen hebben we 2^32 * databases * belangrijke gebeurtenistypen mogelijke 'logische' kanalen.
Het aantal abonnees en uitgevers wordt beperkt door de maxclients instelling, standaard 10.000. Er is geen beperking voor abonnees en uitgevers, maar de maximale limiet voor klanten (verbindingen) is van toepassing.
Zoals aangegeven door @Roman zijn er bufferbeperkingen, maar dit heeft vooral betrekking op doorvoer (berichtverwerking).