I have an ASP.NET Web application which utilizes Redis (via the totally awesome StackExchange.Redis) as a cache store.

I am also using Redis pub/sub to invalidate these cache entries when they needed to be refreshed (read: cache long, refresh as needed). However, i have been noticing that if the publishers wrote too fast, the web application (subscriber) could not keep up with the messages and the socket connection to Redis would become blocked causing no reads to complete (note: this may not be the reason for the socket being blocked, but I drew this conclusion after removing pub/sub from my web application, and the problem dissipated)

Side note: i have left the PreserveAsyncOrder option to it's default (true), but i'm thinking i could make this false since i don't care about the order of the messages?

To give you an idea of how this all works, on startup (only once) the web app:

  • Creates connection to Redis (single ConnectionMultiplexer)
  • Subscribes to a bunch of events

Then, background components publish messages to Redis (say at most 1 or 2 a second), which causes the web app to update (not delete) the cached entry, for example adding an item to a pre-existing set.

My questions:

  • Am i mis-using Redis pub/sub here? (should i be using queues for example? or just simply naturally expire the items?)
  • How can one make use of SubscribeAsync in a web context, since this should seemingly be done once at startup, and startup lifecycles are typically static?
  • Can someone point me to examples of using StackExchange.Redis as a pub/sub system in a ASP.NET web context? (maybe i'm doing something wrong in my code)

Any guidance would be much appreciated.

Thanks!

Related posts

Recent Viewed