The latest Redis7 notes of the power node-Redis overview

[Power node] Redis entry to advanced tutorial, the latest and most complete redis cache tutorial on the whole network, redis encyclopedia

1 Overview of Redis

1.1 Introduction to Redis

Redis, Remote Dictionary Server, remote dictionary service, is a log-type, NoSQL open-source memory database written in ANSI C language, supporting network, memory-based and persistent, and providing APIs in multiple languages.
The reason why Redis is called a dictionary service is because Redis is a key-value storage system. There are many value types that support storage, including String (string), List (linked list), Set (collection), Zset (sorted set -- ordered set) and Hash (hash type), etc.
Proficiency in using and operating Redis has become an essential skill for development and maintenance personnel.

1.1.1 NoSQL

NoSQL ("non-relational", "Not Only SQL") generally refers to non-relational databases. With the rise of Internet web2.0 websites, traditional relational databases are unable to handle web2.0 websites, especially ultra-large-scale and high-concurrency SNS-type web2.0 purely dynamic websites, and many insurmountable problems have emerged. The non-relational database has developed very rapidly due to its own characteristics. The emergence of NoSQL database is to solve the challenges brought by multiple data types of large-scale data collections, especially the big data application problems.

1.1.1.1 Key-value store database

A key-value pair like a Map. A typical representative is Redis.

1.1.1.2 Column store database

A relational database is a typical row store database. The problem is that the data stored by row occupies continuous storage space at the physical level, which is not suitable for mass data storage. Column-based storage can realize distributed storage, which is suitable for mass storage. A typical representative is HBase.

1.1.1.3 Document database

It is a combination of NoSQL and relational data, most like NoSQL for relational databases. A typical representative is MongoDB.

1.1.1.4 Graph database

A database used to store a node relationship, such as describing the relationship between different people. A typical representative is Neo4J.

1.2 The purpose of Redis

The scenario where Redis is most used in production is data caching. That is, the data queried by the client from the DBMS is first written into Redis, and no matter which client needs to access the data later, it can directly read the data in Redis, which not only reduces the RT, but also reduces the pressure on the DBMS.

According to the synchronization between the data cached by Redis and the data in the DBMS, the cache can generally be divided into two types: real-time synchronous cache and phased synchronous cache.
Real-time synchronization cache means that after the data in the DBMS is updated, the relevant data stored in the Redis cache will be cleared immediately, so that when there is another access request for the data, the latest data must be obtained from the DBMS first, and then Then write to Redis.
Periodic synchronization cache means that the data in the Redis cache is allowed to be incompletely consistent with the data in the DBMS for a period of time. And this time period is the expiration time of the cached data.

1.3 Redis features

There are many technologies and middleware that can be used for caching, such as the second-level cache and Memched that come with MyBatis. Only products that do caching in production will choose Redis almost without exception, because it has many features that other products do not have.

  • Extremely high performance: the Redis read speed can reach 110,000 times/s, and the writing speed can reach 80,000 times/s. It only has such high performance because of the following reasons: (1) All operations of Redis occur in memory. (2) Redis is developed in C language. (3) The source code of Redis is very fine (combining performance and elegance).

  • Simple and stable: Redis has few source codes. The early version only has about 2w lines. Starting from version 3.0, the cluster function has been added, and the code has changed to about 5w lines.

  • Persistence: Data in Redis memory can be persisted in two ways: RDB and AOF.

  • Highly available cluster: Redis provides a highly available master-slave cluster function to ensure system security.

  • Rich data types: Redis is a key-value storage system. There are many types of value that support storage, including String (string), List (linked list), Set (collection), Zset (sorted set -- ordered set) and Hash (hash type), etc., as well as BitMap, HyperLogLog, Geospatial type.

  • BitMap: Generally used for binary statistics of large amounts of data.

  • HyperLogLog: It is Hyperlog Log, which is used to perform deduplication statistics on logs with a huge amount of data.

  • Geospatial: Geospatial, which is mainly used for geographic location-related calculations.

  • Powerful functions: Redis provides data expiration function, publish/subscribe function, simple transaction function, and also supports Lua script extension function.

  • Wide range of client languages: Redis provides a simple TCP communication protocol, and programming languages ​​can easily access Redis. Therefore, many open source communities and large companies have developed Redis clients in many languages.

  • Support ACL permission control: the previous permission control is very clumsy. Since Redis6, the ACL module has been introduced, which can customize different user permissions for different users.
    | ACL, Access Control List, access control list, is a fine-grained rights management strategy, which can control rights for any user or group. At present, most Unix systems and Linux 2.6 versions already support ACL. Zookeeper already supports ACL.
    Unix and Linux systems use the UGO (User, Group, Other) permission control strategy by default, which is a coarse-grained permission management strategy. |
    | — |

  • Support multi-threaded IO model: The previous version of Redis used a single-threaded model, and it supports a multi-threaded model since version 6.0.

1.4 IO model of Redis

Redis客户端提交的各种请求是如何最终被Redis处理的?Redis处理客户端请求所采用的处理架构,称为Redis的IO模型。不同版本的Redis采用的IO模型是不同的。

1.4.1 Single-threaded model

对于Redis 3.0及其以前版本,Redis的IO模型采用的是纯粹的单线程模型。即所有客户端的请求全部由一个线程处理。


Redis's single-threaded model uses multiplexing.

| There are three common multiplexing algorithms for multiplexers: select model, poll model, and epoll model.

  • The selection algorithm of the poll model: the polling algorithm is used. This model has a delay in the ready processing of the client.

  • The selection algorithm of the epoll model: the callback method is adopted. According to the different processing methods after the ready event occurs, it can be divided into LT model and ET model.
    |
    | — |

    To submit a request to Redis, each client needs to establish a socket connection with Redis and register an event with the event distributor. Once this event occurs, it indicates that the connection is ready. Once the connection is ready, the event dispatcher will perceive it, and then obtain the request sent by the client through the connection, and will be processed by the unique thread bound to the event dispatcher. If the thread is still processing multiple tasks, the task is written into the task queue and waits for the thread to process.
    It is only called an event dispatcher because it will hand over tasks to different event handlers according to different ready events.

1.4.2 Mixed threading model

Since Redis 4.0, multi-threading elements have been added to Redis. The single-threaded model is still used to process client requests, but for some operations that are time-consuming but do not affect the response to the client, they are processed by other threads in the background. For example, persistence, rewrite of AOF, cleaning of invalid connections, etc.

1.4.3 Multithreading model

Redis version 6.0 is the real multi-threaded model. Because it uses a multi-threaded model for the processing of client requests.

The "multithreading" in the multithreaded IO model is only used to accept and parse client requests, and then write the parsed requests to the task queue. The processing of specific tasks (commands) is still handled by the main thread. In this way, users do not need to consider thread safety issues, transaction control, or the execution order of commands such as LPUSH/LPOP.

1.4.4 Summary of Advantages and Disadvantages

1.4.4.1 Single-threaded model

  • Advantages: high maintainability and high performance. There is no concurrent reading and writing, so there is no uncertainty in the execution order, no thread switching overhead, no deadlock problem, and no locking/unlocking overhead for data security.
  • Disadvantages: Performance will be affected, and since a single thread can only use one processor, it will cause processor waste.

1.4.4.2 Multithreading Model

  • Advantages: It combines the advantages of multi-threading and single-threading, avoiding all their shortcomings
  • Cons: The model doesn't display underwhelming. If you have to find its shortcomings, it is not a "multithreading" in the true sense, because the thread that actually handles the "task" is still a single thread. Therefore, it also has some impact on performance.

おすすめ

転載: blog.csdn.net/f5465245/article/details/130841968