Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

What are the comprehensive knowledge points of Redis

2025-04-01 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >

Share

Shulou(Shulou.com)05/31 Report--

This article mainly introduces the Redis comprehensive knowledge points of what the relevant knowledge, the content is detailed and easy to understand, the operation is simple and fast, has a certain reference value, I believe you read this Redis comprehensive knowledge points what articles will have a harvest, let's take a look at it.

Introduction to Redis

Redis is completely open source and free, complies with BSD protocol, and is a high-performance key-value database.

Redis and other key-value cache products have the following three features:

Redis supports data persistence, so you can save the data in memory on disk and load it again when you restart it.

Redis not only supports simple key-value type data, but also provides storage of data structures such as list,set,zset,hash.

Redis supports data backup, that is, data backup in master-slave mode

Redis advantage

Extremely high performance-Redis reads 110000 times per second and writes 81000 times per second.

Rich data types-Redis supports Strings, Lists, Hashes, Sets and Ordered Sets data type operations for binary cases.

Atomicity-all operations of Redis are atomic, meaning either successful execution or failure to execute at all. A single operation is atomic. Multiple operations also support transactions, that is, atomicity, wrapped by MULTI and EXEC instructions.

Other features-Redis also supports publish/subscribe notifications, key expiration and other features.

Redis data type

Redis supports 5 data types: string (string), hash (hash), list (list), set (collection), zset (sorted set: ordered collection)

String

String is the most basic data type of redis. One key corresponds to one value.

String is binary secure. That is, the string of redis can contain any data. Such as jpg images or serialized objects.

The string type is the most basic data type of redis, and the value of the string type can store up to 512 MB.

Understanding: string is like a map in java, a key corresponds to a value

127.0.0.1 set hello world OK 6379 > get hello "world"

Hash

Redis hash is a collection of key-value pairs. Redis hash is a mapping table for key and value of type string, and hash is particularly suitable for storing objects.

Understanding: think of hash as a collection of key-value. You can also think of it as a hash that corresponds to multiple string.

Different from string: string is a key-value key-value pair, while hash is multiple key-value key-value pairs.

/ / hash-key can be regarded as the name of a collection of key-value pairs. Sub-key1: value1, sub-key2: value2, Sub-key3: value3 these three key pairs 127.0.0.1 hset hash-key sub-key1 value1 6379 > hset hash-key sub-key1 value1 (integer) 1 127.0.0.1 hset hash-key sub-key1 value1 6379 > hset hash-key sub-key2 value2 (integer) 1 127.0.1 hset hash-key sub-key1 value1 6379 > hset hash-key sub-key3 value3 (integer) 1 / / get all the key pairs in hash-key this hash 127.0.0.1 hset hash-key sub-key1 value1 6379 > hgetall hash-key 1) "sub-key1" 2) "value1" 3) "sub-key2" 4) "value2" 5) "sub-key3" 6) "value3" / / Delete the sub-key2 key value in the hash hash-key: 127.0.0.1value2 6379 > hdel hash-key sub-key2 (integer) 1 127.0.0.1 value2 6379 > hget hash-key sub-key2 (nil) 127.0.0.1 value2 6379 > hget hash-key sub-key1 " Value1 "127.0.0.1 value1 6379 > hgetall hash-key 1)" sub-key1 "2)" value1 "3)" sub-key3 "4)" value3 "

List

The Redis list is a simple list of strings sorted in the order in which they are inserted. We can add elements to the left or right side of the list.

127.0.0.1 rpush list-key v1 (integer) 1 127.0.0.1 rpush list-key v2 (integer) 2 127.0.0.1 rpush list-key 6379 > rpush list-key v1 (integer) 3 127.0.1 rpush list-key 6379 > rpush list-key 0-1 1) "v1" 2) "v2" 3) "v1" 127.0.1 "V2" 3) "v1" 127.0.1 "rpush list-key v2" 127.0.0.1 : 6379 > lpop list (nil) 127.0.0.1 lpop list-key "v1" 127.0.0.1 lpop list-key 6379 > lrange list-key 0-11) "v2" 2) "v1"

We can see that list is a simple collection of strings, which is not much different from the list in Java, except that the list here stores strings. The elements in the list are repeatable.

Set

The set of redis is an unordered collection of string types. Collections are implemented through hash tables, so the complexity of adding, deleting, and searching is all O (1).

127.0.0.1 sadd v1 (integer) 1 127.0.0.1 sadd v2 (integer) 1 127.0.0.1 sadd 6379 > sadd K1 v3 (integer) 1 127.0.0.1 sadd v1 (integer) 0127.0.0.1 sismember K1) "v3" 2) "v2" 3) "v1" 127.0.0.1 > 127.0.0.1 > sismember K1 k4 (integer) 0 127.0.0.1 integer > sismember K1 v1 (integer) 1 127.0.0.1 integer 6379 > srem K1 v2 (integer) 1 127.0.0.1 integer 6379 > srem K1 v2 (integer) 0 127.0.1) > smembers K1 1) "v3" 2) "v1"

There is a difference between set in redis and set in java.

Redis's set is a key corresponding to multiple string types of value, and it is also a collection of string types, but unlike redis's list, string collection elements in set cannot be duplicated, but list can.

Zset

Redis zset, like set, is a collection of elements of type string, and the elements within the collection cannot be repeated.

The difference is that each element of zset is associated with a score of type double. Redis sorts the members of the collection from small to large by scores.

The element of zset is unique, but the score can be repeated.

127.0.0.1 member1 (integer) 1 127.0.0.1 member0 (integer) 0 127.0.1 withscores 1) "member1" 2) "728" 3) "member0" 4) "982" 127.0.1 withscores 6379 > zrangebyscore zset-key 0800 Withscores 1) "member1" 2) "728" 127.0.0.1 zrem zset-key member1 > zrem zset-key member1 (integer) 1 127.0.0.1 > zrem zset-key member1 (integer) 0 127.0.1 > zrange zset-key 0-1 withscores 1) "member0" 2) "982"

Zset is sorted according to the size of the score.

Publish and subscribe

Generally, Redis is not used for message publishing and subscription.

Brief introduction

Redis publish subscription (pub/sub) is a mode of message communication: the sender (pub) sends the message and the subscriber (sub) receives the message.

Redis clients can subscribe to any number of channels.

The following figure shows the relationship between the channel channel1 and the three clients that subscribe to the channel-client2, client5, and client1:

It is enough to learn Redis.

When a new message is sent to channel channel1 through the PUBLISH command, the message is sent to the three clients that subscribe to it:

It is enough to learn Redis.

Example

The following example demonstrates how publish subscriptions work. In our example, we created a subscription channel named redisChat:

127.0.0.1 purl 6379 > SUBsCRIBE redisChat Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "redisChat"

Now, let's reopen a redis client, then post the message twice on the same channel redisChat, and the subscriber can receive the message.

127.0.0.1 PUBLISH redisChat send message 6379 > PUBLISH redisChat "hello world" (integer) 1 # subscriber's client displays as follows: 1) "message" 2) "redisChat" 3) "send message" 1) "message" 2) "redisChat" 3) "hello world"

Business

Redis transactions can execute more than one command at a time, and the server does not execute command requests from other clients during command execution.

Multiple commands in a transaction are sent to the server at once rather than one by one, which is called pipelining, which can reduce the number of network communications between the client and the server to improve performance.

The simplest way to implement a transaction in Redis is to surround the transaction operation with MULTI and EXEC commands.

Bulk operations are cached in queues before sending EXEC commands.

After receiving the EXEC command, enter the transaction execution, any command execution in the transaction fails, and the rest of the command is still executed. That is to say, Redis transactions do not guarantee atomicity.

During transaction execution, command requests submitted by other clients are not inserted into the transaction execution command sequence.

A transaction goes through the following three stages from start to execution:

Start the business.

Order to join the team.

Execute the transaction.

Example

The following is an example of a transaction, which starts a transaction with MULTI, then queues multiple commands into the transaction, and finally triggers the transaction by the EXEC command to execute all the commands in the transaction:

Redis 127.0.0.1 in 6379 > MULTI OK redis 127.0.0.1 QUEUED redis 6379 > SET book-name "Mastering C++ in 21 days" QUEUED redis 127.0.1 days > GET book-name QUEUED redis 127.0.0.1 QUEUED redis 127.0.1 days > SADD tag "C++"Programming"Mastering Series" QUEUED redis 127.0.1 days 6379 > SMEMBERS tag QUEUED redis 127.0.1 OK 1) OK 2) "Mastering C++ in 21 days" 3) (integer) 3 4) 1) "Mastering Series" 2) "C++" 3) "Programming"

The execution of a single Redis command is atomic, but Redis does not add any mechanism to maintain atomicity on the transaction, so the execution of the Redis transaction is not atomic.

A transaction can be understood as a packaged batch execution script, but a batch instruction is not an atomized operation, and the failure of an intermediate instruction will not cause a rollback of the previously done instruction, nor will it cause subsequent instructions not to be done.

This is the description on the official website From redis docs on transactions:

It's important to note that even when a command fails, all the other commands in the queue are processed-Redis will not stop the processing of commands.

For example:

Redis 127.0.0.1 redis 7000 > multi OK redis 127.0.0.1 redis 7000 > set an aaa QUEUED redis 127.0.0.1 set an aaa QUEUED redis 7000 > set b bbb QUEUED redis 127.0.1 Veg7000 > set c ccc QUEUED redis 127.0.1 Vega 7000 > exec 1) OK 3) OK

If you fail at set b bbb, set a has succeeded and will not be rolled back, and set c will continue to execute.

Redis transaction command

The following table lists the commands related to redis transactions:

Serial number command and description:

1. DISCARD cancels the transaction and discards all commands within the transaction block.

2. EXEC executes commands within all transaction blocks.

3. MULTI marks the beginning of a transaction block.

4. UNWATCH cancels the WATCH command to monitor all key.

5. WATCH key [key...] Monitor one (or more) key, and if the key (or these) is altered by other commands before the transaction is executed, the transaction will be interrupted.

Persistence

Redis is a memory database, in order to ensure that the data will not be lost after a power outage, the data in memory needs to be persisted to the hard disk.

RDB persistence

All the data at a certain point in time is stored on the hard disk.

You can copy a snapshot to another server to create a server copy with the same data.

If the system fails, the data since the last snapshot is lost.

If the amount of data is large, the snapshot will be saved for a long time.

AOF persistence

Add a write command to the end of the AOF file (append only file).

Using AOF persistence requires setting synchronization options to ensure that write commands are synchronized to disk files.

This is because writing to a file does not immediately synchronize the contents to disk, but is first stored in a buffer, and then it is up to the operating system to decide when to synchronize to disk.

Option synchronization frequency always every write command synchronizes eyerysec synchronizes once a second no lets the operating system decide when to synchronize

The always option severely degrades the performance of the server

The everysec option is appropriate to ensure that only a second or so of data will be lost when the system crashes, and that Redis performing a synchronization per second has almost no effect on the server.

The no option does not bring much improvement to server performance and increases the amount of data lost when the system crashes.

As the number of server write requests increases, the AOF file becomes larger and larger. Redis provides a feature that rewrites AOF and removes redundant write commands from AOF files.

Copy

Make one server a slave to another by using the slaveof host port command.

A slave server can have only one master server, and master master replication is not supported.

Connection process

The master server creates a snapshot file, the RDB file, which is sent to the slave server, and uses a buffer to record the write commands executed during the transmission.

After the snapshot file is sent, it begins to send write commands stored in the buffer from the server.

Discard all old data from the server, load the snapshot file from the master server, and then accept write commands from the master server.

Each time the master server executes a write command, it sends the same write command to the slave server.

Master-slave chain

As the load increases, the master server cannot quickly update all the slave servers, or reconnecting and resynchronizing the slave servers will cause the system to overload.

To solve this problem, you can create a middle tier to share the replication work of the primary server. The server in the middle layer is not only the slave server of the top server, but also the master server of the lowest server.

Sentinel

Sentinel (Sentinel) can listen to the servers in the cluster and automatically select a new master server from the slave server when the master server goes offline.

Slice

Slicing is a method of dividing data into multiple parts, which can store the data in multiple machines. This method can achieve linear performance improvement when solving some problems.

Suppose there are four Redis instances R0, R1, R2, R3, and many keys user:1, user:2, … There are different ways to select an instance in which a specified key is stored

The simplest is range fragmentation, for example, user id is stored in instance R0 from 0 to 1000, user id is stored in instance R1 from 1001 to 2000, and so on. However, this requires the maintenance of a mapping range table, which is expensive to maintain.

The other is hash slicing. Use the CRC32 hash function to convert the key to a number, and then model the number of instances to know the stored instance.

According to the location where sharding is performed, it can be divided into three sharding methods:

Client fragmentation: the client uses algorithms such as consistent hashing to determine which node should be distributed to.

Proxy sharding: sends the client's request to the agent, which forwards it to the correct node.

Server shard: Redis Cluster.

This is the end of the article on "what are the Comprehensive knowledge points of Redis". Thank you for reading! I believe you all have a certain understanding of "what are the comprehensive knowledge points of Redis". If you want to learn more knowledge, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Database

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report