amazon-web-services - Use of redis cluster vs standalone redis

Question

I have a question about when it makes sense to use a Redis cluster versus standalone Redis.

Suppose one has a real-time gaming application that will allow multiple instances of the game and wish to implement real time leaderboard for each instance. (Games are created by communities of users).

Suppose at any time we have say 100 simultaneous matches running.

Based on the use cases outlined here :

https://d0.awsstatic.com/whitepapers/performance-at-scale-with-amazon-elasticache.pdf

https://redislabs.com/solutions/use-cases/leaderboards/

https://aws.amazon.com/blogs/database/building-a-real-time-gaming-leaderboard-with-amazon-elasticache-for-redis/

We can implement each leaderboard using a Sorted Set dataset in memory.

Now I would like to implement some sort of persistence where leaderboard state is saved at the end of each game as a snapshot. Thus each of these independent Sorted Sets are saved as a snapshot file.

I have a question about design choices:

1. Would a redis cluster make sense for this scenario ? Or would it make more sense to have standalone redis instances and create a new database for each game ?

As far as I know there is only a single database 0 for a single redis cluster.(https://redis.io/topics/cluster-spec) In that case, how would one be able to snapshot datasets for each leaderboard at different times work ?

https://redis.io/topics/cluster-spec

From what I can see using a Redis cluster only makes sense for large-scale monolithic applications and may not be the best approach for the scenario described above. Is that the case ?

Or if one goes with AWS Elasticache for Redis Cluster mode can I configure snapshotting for individual datasets ?

标签： amazon-web-servicesredisaws-elasticache

Answer 1

You are correct, clustering is a way of scaling out to handle really high request loads and store tons of data.

It really doesn't quite sound like you need to bother with a cluster. I'd quite be very surprised if a standalone Redis setup would be your bottleneck before having several tens of thousands of simultaneous players.

If you are unsure, you can probably mock some simulated load and see what it can handle. My guess is that you are better off focusing on other complexities of your game until you start reaching quite serious usage. Which is a good problem to have. :)

You might however want to consider having one or two replica instances, which is a different thing.

Secondly, regardless of cluster or not, why do you want to use snap-shots (SAVE or BGSAVE) to persist your scoreboard?

If you want to have individual snapshots per game, and its only a few keys per game, why don't you just have your application read and persist those keys when needed to a traditional db? You can for example use MULTI, DUMP and RESTORE to achieve something that is very similar to snapshotting, but on the specific keys you want.

It doesn't sound like multiple databases is warranted for this.

Multiple databases on clustered Redis is only supported in the Enterprise version, so not on ElastiCache. But the above mentioned approach should work just fine.