http://redis.io/topics/data-types-intro
The data structures are all addressed by string keys.
Redis can persist this heap to disk, and load it again, so you get a measure of durability, but the typical use case is for data you can afford to lose - caches, metrics, some kinds of events, etc.
Redis's key non-functional strengths are speed and robustness. Operations people love it because you stick it in production and it just quietly keeps on working without needing attention or setting your CPU on fire.
To my mind, any project should have PostgreSQL as its first data store. But it should probably have Redis as its second, when it finally has some data that needs to be changed or accessed so fast that PostgreSQL can't keep up.
(Kafka is third)
It simply means that the key-value store is directly loaded into the memory (RAM) and is available for fast access, but the data is retained (persistent) even after the application is closed.
It is usually used as cache store, queuing messages to communicate with different processes locally or distributed.
Its data structure cover a good part of what you'd need with generic data structures, which makes Redis an easy way to do the logic of, say, List intersection of friends common between multiple people, sorted set of goods ranked by their amount, all of this shared with other processes.
Redis also offers pubsub capabilities in two forms:
- A standard PUB/SUB couple which does what you think it does
- Blocking pop on a list for a client, and a push for another client, which will "wake up" the first one with the value.
It's a very versatile swiss knife.
It can be used for caching, queues and for applications with volatile data.