1

I've heard a lot of positive about Redis but have not used it myself. Now I want to add a cache layer for my web app to reduce the DB load, and I suppose Redis is fine for this.

But I don't clearly understand who should populate Redis with data and keep it in synch with the DB. If I need to create some service for this, then obviously it will contain some caching logic. If so, why can't this new service store the cache data itself? Then, if I add some access API to this new service, it will be able to process cache requests from clients itself. Why would I use Redis at all in this case?

2

If your service is hosted on a single machine, chances are that in-memory caching will have a better performance and will be easier to implement.

On the other hand, there are three situations where local caching is not enough:

  • As soon as your service starts to be hosted on multiple servers, which is the case for most services hosted in production, you may need to implement either centralized¹ or distributed² caching in order for your services to share the same cache.

    In this case, if your language/framework/infrastructure doesn't already have the feature (such as AppFabric in Microsoft community), Redis appears an excellent alternative.

    Note that in the same way, you may have a system installed on a single machine, but written in multiple programming languages. If different parts of the system need to access the same cache entities, you may either create the caching service yourself, or do it the easy way and let Redis do the job.

  • Redis has much more features than ordinary cache systems. Have you seen the list of Redis commands? Instead, most caching systems are limited to three actions: add, get, remove, and to expiration options. For instance, what about DECRBY? Most caching libraries I've used don't even have the ability to increment/decrement values, which makes them a poor choice for counters, for example.

    If you need those additional features, Redis is obviously a solution to your needs.

  • In large scale environments, system administrators may need to be able to properly configure the caching servers (as well as properly chose the hardware for the particular needs of caching). Having a common caching service such as Redis means that those system administrators may learn it well and focus on its configuration, given that it can then be used from services written in any programming language.


¹ In centralized caching, all clients access the same caching service (which, internally, can use failover as well) which handles all the data and its invalidation.

² In distributed caching, each client stores cached entities. When an entity is changed or removed, the action should be dispatched to all the nodes to ensure consistency.

  • But what about populating Redis with data and keeping it in synch with the DB? Should I create an app for this anyway? I suppose anyway there should be someone who loads data to Redis and checks that it hasn't expired. – hank Jun 3 '15 at 8:13
  • @hank: your app uses Redis as it would use any caching service. It is your app which is in charge of controlling what is stored in Redis and for how long, how the content expires, and how is it refreshed. Redis won't magically connect by itself to your database. – Arseni Mourzenko Jun 3 '15 at 9:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.