Redis --- transaction & pipeline

Table of contents

1. What is the transaction of Redis?

1.1 The difference between Redis and relational database transactions

 2. How to play Redis transactions?

 2.1 Normal execution:

 2.2 Abandoning the transaction

 2.3 All sitting together

 2.4 Bad creditors

 2.5 watch monitoring

3. Pipeline

3.1 Why is the concept of pipeline introduced? Let's first look at an interview question

3.2 What are pipelines?

 3.3 Demonstration of the use of the pipeline

3.4 Pipeline Summary

---

1. What is the transaction of Redis?

• Multiple commands can be executed at one time, which is essentially a collection of commands. All commands in a transaction will be serialized,  serialized and executed in sequence without being inserted by other commands, and blocking is not allowed
• In a queue, execute a series of commands one-time, sequentially and exclusively

1.1 The difference between Redis and relational database transactions

 2. How to play Redis transactions?

Common commands:

 2.1 Normal execution:

 2.2 Abandoning the transaction

 2.3 All sitting together

 2.4 Bad creditors

 2.5 watch monitoring

In order to ensure its high performance, if redis uses pessimistic locking when locking, then its performance will definitely be affected. When using it, it uses optimistic locking.

 Optimistic Lock (Optimistic Lock), as the name suggests, is very optimistic. Every time you go to get the data, you think that others will not modify it, so it will not be locked , but when updating, you will judge whether others have updated it during this period. data.

Optimistic lock strategy: the submitted version must be greater than the current version of the record to perform the update

Normal: It means that there is no stoppage

It is equivalent to simply locking and unlocking.

 There are stoppers:

 Small supplement:

When EXEC is executed, all monitoring locks will be canceled, and when the client connection is lost, monitoring locks will also be canceled. (It can be understood as preventing deadlock)

3. Pipeline

3.1 Why is the concept of pipeline introduced ? Let's first look at an interview question

How to optimize the performance bottleneck caused by frequent command round trips?

• Redis is a TCP service based on client-server model and request/response protocol. A request follows these steps:

  • The client sends commands to the server in four steps (sending commands→command queuing→command execution→returning results), and monitors the Socket return, usually waiting for the server to respond in blocking mode
  • The server processes the command and returns the result to the client.
  • Round Trip Time (referred to as RTT, the time for data packets to and from both ends)

• If a large number of commands need to be executed at the same time, it is necessary to wait for the response of the previous command before executing it. Not only is there more RTT (Round Time Trip), but also the system IO is frequently called. Sending network requests requires redis to call multiple reads at the same time. () and write() system methods, the system method will transfer data from user mode to kernel mode, which will have a relatively large impact on the process context, and the performance is not very good.

• Use pipelines to solve

As we can see above, if the server goes back and forth with the client many times, it will take a lot of RTT time. We can use pipelines to improve this.

The principle of the pipeline is to pack multiple pieces of data at one time, and then the server only needs to give us a reply result. This mset k1 v1, k2 v2, k3, v3, it should be noted that mset is far from replacing the role of the pipeline, because mset can only be used for the string type, if there are multiple types , it must be a pipeline .

3.2 What are pipelines?

The pipeline can send multiple commands to the server at one time.

• After the server finishes processing in sequence, it will return the result at one time through a response, and reduce the round-trip delay time by reducing the number of communications between the client and redis .
• The principle of pipeline implementation is queue , and the first-in-first-out feature ensures the order of data.

 3.3 Demonstration of the use of the pipeline

 With the pipeline, we can also solve some problems at work: the boss asks you to insert 10w pieces of data into redis, we can write 10 files, and then insert them in 10 batches, so we can test the performance of redis

3.4 Pipeline Summary

Pipeline and native batch

• Native batch commands are atomic (such as: mset, mget), pipeline is non-atomic

• Native batch commands can only execute one type of command at a time, and pipeline supports batch execution of different commands

• The native batch command is implemented by the server, while the pipeline needs to be completed by the server and the client

Pipeline vs. Transaction

• Transactions are atomic, pipelines are not
• The pipeline sends multiple commands to the server at one time, and the transaction is sent one by one. The transaction will only be executed after receiving the exec command, and the pipeline will not
• Executing a transaction will block the execution of other commands, while executing commands in a pipeline will not

• Pipeline Considerations
  • The instructions buffered by the pipeline will only be executed sequentially, and atomicity is not guaranteed. If an exception occurs during execution, subsequent instructions will continue to be executed.
  • The number of commands assembled using the pipeline should not be too large, otherwise the client may be blocked for too long when the amount of data is too large, and the server is also forced to reply to a queue reply, which takes up a lot of memory