Closed singgihsuryop closed 1 year ago
Yep, that's absolutely fine and not uncommon. However, if you're using server version 6 or above, you will - after the next release - also be able to achieve this by opting into RESP3 mode - whereby pubsub can use the same connection (this is a protocol variant introduced in V6)
Thanks @mgravell
In production environment, I use 3 node master and 3 node replicas. It listed that 1 pod needs 3 client connection (1 conn for PubSub and 2 conn for Normal type).
Here's the client lists. (pod name - client type - address) If I decide to use RESP3 mode, will it be used just single connection? and why it need 2 connections for normal client.
The 2 connections is because of how the redis protocol works - in RESP2 (the older protocol), "normal" messages (commands you've issued, and the server's reply to those) and pub/sub messages (out-of-band, happen randomly) cannot share a connection, because of how out-of-band messages work. If you want details, read the RESP2 specification.
RESP3 allows the two types to coexist. So: RESP3 allows SE.Redis to use 1 connection instead of 2. I don't know why you're seeing 3, though. I wonder if one of those is not SE.Redis, but something else.
OK, will find out what's the other connection used for. I use Microsoft.Extensions.Caching.StackExchangeRedis, probably there are configuration missed. Thanks
Currenly I use StackExchange.Redis 2.4.4 and I only use redis for cache the API response. Redis is run in a linux server with Standalone Mode in development environment and Cluster Mode in Production environment. I notice that the client name are doubled (with different ClientType. Normal and PubSub). Here's printed Client Name and Type in redis standalone mode.
When I add
{ "SUBSCRIBE", null }
to config map, the PubSub client is disappeared. I knew redis has maximum connected clients of 10000. Since we expect to have a lot of apps running in kubernetes pods, is it save to unsubscribe or disable this pubsub feature?Thanks