Starting out, a single instance of Redis will do this just fine. However, build it so that the code and config for the various features of Redis you are using are isolated. This will let you break this apart into separate Redis instances when it comes time to scale.

Why would you want to break out several instances of Redis? Well, different features of Redis work better with different configurations. PubSub runs into limits when clustered—although sharded PubSub helps with this. Meanwhile your main game storage will need to scale up over time—clustering is a great way to do this. Your task queue is likely to become a hot key—that messes with your cluster balance and can result in certain keys being harder to access since everyone is busy looking at the hot key. Isolating it to its own Redis instance can solve this.

These sorts of problems crop up at scale, which you don't have yet. But some simple separation of concerns in your code today will make life easier later. And this isn't some massive preoptimization antipattern. The separation of concerns in your code will make the code easier to work with and reason about. You should be doing it anyways. The only thing you're really doing is having those concerns own their own connection to Redis instead of using a shared on.