The idea behind "separate databases" seems to be one that's misunderstood, and I've written about it before here. Having separate databases does not mean separate database server hosts, or even processes. The idea is that the data stored by different applications is isolated. Coming from a background in relational databases (particularly MySQL), this would mean that each applications would have its own schema or database (see this particular Stack Overflow question and its answer for the MySQL terms).
Although my experience with Redis is more limited, my understanding is that this kind of data isolation doesn't exist. If you have a single instance or single cluster, all of the data is available. A single Redis instance doesn't support multiple, isolated databases. If you connect to the instance, you can read any of the key/value pairs stored in Redis. This leads to two solutions - each service having its own Redis instance or Redis cluster or not having the firm data isolation between services.
Having a single Redis instance and using prefixes on the keys seems to be widely supported and this is the approach that I've taken in the past. This approach, although it will allow one microservice to read and write data that belongs to another service, it does lead to a less complex infrastructure and you can handle the key prefixes in the application level to help developers avoid collisions between key names from different services as well as to make it harder to cross boundaries.
The other aspect to microservices is scalability. Although there may be a few reasons why one would choose microservices, the ability to develop, deploy, and scale pieces of a system independently is a common rationale. As such, you would want to scale the databases as well.
Although having a data store for every service may allow you to scale, I haven't been convinced that the infrastructure overhead that this would incur is necessary for scalability or high availability of the data store. The fact that cloud providers (like AWS or Google Cloud Platform) have managed services for various databases and data stores that have provisions for both makes it even more straightforward.
When you are working at a data layer, options such as a read replicas, sharding the data across a cluster, cross-region replication, and appropriate use of caching options are all good solutions for improving the performance of your data stores. I would rather implement these solutions for a single data store and scale up in hardware rather than needing to implement these solutions for multiple data stores.
