Why use Redis
I recently read Redis Development and Operations, which was very good. Here's a little organization of knowledge from the book to facilitate your own review of the entire Redis system to check for gaps in relevant knowledge.
I'll organize the book in five points. - Why Redis: an introduction to Redis usage scenarios and the reasons for using Redis. - A summary of common Redis commands: including a time complexity summary with data structures used by specific data types within Redis. - Advanced features of Redis: including persistence, replication, sentinels, introduction to clustering. - Understanding Redis: Understanding memory, blocking; this part is very important, all the previous presentations can be the art, here should belong to the part of the Word. (b). - Development Tips: mainly a summary of some development practices, including cache design and common pitfalls.
Let's kick off the first part of this by taking a fresh shot at Redis.
This series is based on: redis-3.2.12
In the interview, often asked to compare the advantages and disadvantages of Redis and Memcache, I personally do not think that the two do not fit together, one is a non-relational database can not only do cache can also do other things, one is only used to do cache. We are often asked to compare the two, mainly also because the most widespread application scenario for Redis is Cache. So what exactly does Redis do? And what can't you do?
Caching, which is without a doubt the most well-known use case for Redis today. (a) Very effective in improving server performance again.
The rankings, which would be very cumbersome if done with a traditional relational database, are very easy to handle with Redis' SortSet data structure.
The calculator/rate-limiter, using the atomic self-increasing operation in Redis, we can count the number of similar user likes, user visits, etc. If such operations are done with MySQL, frequent reading and writing will bring considerable pressure; a typical scenario for the rate-limiter is to limit the frequency of a user's access to an API, commonly used when snapping up a purchase, to prevent users from clicking like crazy to bring unnecessary pressure.
Good friend relationship, using some commands for sets, such as find intersection, merge, difference, etc. It can be easy to take care of some common friends, common hobbies and such functions.
Simple message queues, in addition to Redis' own publish/subscribe model, we can also use Lists to implement a queue mechanism, e.g.: arrival notifications, mail delivery and other requirements that do not require high reliability, but will bring very high DB pressure, and can be completely decoupled asynchronously using Lists.
Session sharing, to PHP for example, the default Session is saved in the server file, if it is a cluster service, the same user over may fall on different machines, which will lead to frequent user login; using Redis to save Session, regardless of the user fell on that machine can get the corresponding Session information.
Redis feels like it can do an exceptional amount of things, but it's not a panacea, and the right place to use it is half the battle. If misused it may lead to instability of the system, higher costs and other problems.
For example, using Redis to hold basic user information, although it can support persistence, its persistence scheme does not guarantee absolute data landing and may also bring down Redis performance because persisting too often increases the pressure on the Redis service.
The simple summary is that the volume of data is too large, the frequency of data access is very low business are not suitable for the use of Redis, data will be too large to increase the cost, access frequency is too low, save in memory is a pure waste of resources.