Redis can be used for multiple use cases; some are described here:

• Session cache: One of the most common use cases of Redis is to store sessions, generally as hashes. The reason for this is that user sessions generally have a lot of I/O, since every API request from the user needs the session and often results in some updates. Keeping the sessions in a database is an option, but the performance characteristics don't make for good API performance. Redis is perfect for this use case, since the session information, though important, is not absolutely important. Thus, durability is not that big of a concern.
• Application cache: Redis can serve as an external cache for data that is otherwise in a database. This allows applications to store/access frequently accessed or rarely changing data from the cache and not incur the performance penalty of the usually slower database.
• Distributed lists: If you want to maintain lists, such as like newest items, across multiple application instances, the list data structure of Redis is a perfect fit. LPUSH/RPUSH can be used to push items at the head or tail of the list, respectively. Other commands, such as  LTRIM/RTRIM, can be used to prune the lists.
• Keeping stats: Redis offers easy engineering of distributed counters. The INCRBY command can be used to increment counters atomically, while others, such as GETSET, allow for clearing of counters.
• Queues and Pub/Sub: Redis queues and pub/sub channels can be used to exchange messages, enabling features such as background workers.