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.
The above mentioned some usage scenarios for Redis, so there are many other options for solutions to these scenarios, such as caching with Memcache, Session sharing can also be implemented with MySql, and message queues can be implemented with RabbitMQ, so why do we have to use Redis?
Fast, fully memory-based, implemented in C. The network layer uses epoll to solve high concurrency problems, and the single-threaded model avoids unnecessary context switching and contention conditions. Note: single threaded just means processing client requests with one request on this module of network requests, like persistence it will restart a thread/process to do that
Redis has 8 data types, but the main types used are String, Hash, List, Set, and SortSet, all of which are key-value based. Each data type provides a very rich set of commands for most needs, and you can create new commands yourself (with atomicity) via lua scripts if you have special needs.
In addition to the rich data types offered, Redis also provides personalized features like slow query analysis, performance testing, Pipeline, transactions, Lua custom commands, Bitmaps, HyperLogLog, Publish/Subscribe, Geo, and more.
Redis code is open source in GitHub, the code is very simple and elegant, anyone can eat through its source code; it is also very simple to compile and install, there are no system dependencies; there is a very active community, a variety of client language support is also very complete. In addition it supports transactions (not used), persistence, master-slave replication making high availability, distributed possible.
As a developer, we can't let it be a black box for what we use, we should go deeper into it and become more knowledgeable and familiar with it. Today it briefly touches on Redis usage scenarios and why you chose Redis over others. Next time, a summary of the internal data structure of Redis and the time complexity of common commands.