The so-called transaction means that multiple instructions are either all executed or not executed at all. A transaction can execute multiple commands at a time, which is essentially a set of commands. All commands of a transaction will be serialized and executed in sequence The insertion of other commands is not allowed, and stoppering is not allowed.

effect

Store many instructions in a queue, and execute a series of instructions one-time, sequentially and exclusively

Database transactions vs redis transactions

common command

Commonly used commands for transactions are as follows:

We introduce and use specific instructions in detail:

Case 1: Normal execution

MULTI // transaction start
set ...
EXEC // execute

Case 2: Abandoning the transaction

MULTI // transaction start
set ...
DISCARD // abandon transaction

Situation 3: All sitting together

If one of the instructions in the transaction has a syntax error, all instructions will not be executed

MULTI // transaction start
set k1 // syntax compilation failed
EXEC // execute

Situation 4: Bad creditor

In a group of transactions, the instruction syntax itself has no errors, but it does not conform to the specific specification of the instruction syntax, and then an error is reported in the last exec. At this time, only the instruction that reported the error is not executed, and all other instructions are executed.

MULTI // transaction start
incr k1 // syntax compiles successfully, but execution fails
EXEC // execute

Case 5: watch monitoring

First clarify a few concepts:

Optimistic lock: 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 you will not lock it , but when updating, you will judge whether others have it during this period. to update this data. Optimistic lock strategy: the submitted version must be greater than the current version of the record to perform the update

Pessimistic lock: Pessimistic lock (Pessimistic Lock), as the name suggests, is very pessimistic. Every time you go to get the data, you think that others will modify it, so every time you get the data, you will lock it, so that others will block if they want to get the data until it gets the lock.

CAS: Similar to JUC's CAS

In redis, watch provides the function of CAS, and its detailed instructions are as follows:

watch

normal circumstances:

Initialize key values (k1 and balance keys), first monitor and then enable multi to ensure that the two key changes are within the same transaction
watch k1 //lock

multi //open transaction

set k1 ninini //Modify the value of k1 for the first time

set k1 owowowo //Modify the value of k1 for the second time

Since k1 is modified within a transaction, even if k1 has a watch lock, the operation is still successful

Jamming situation:

The watch command is an implementation of optimistic locking. Redis will detect whether the data has been changed when it is modified. If it is changed, the execution will fail.

unwatch

give up monitoring

summary:

Once the watch monitoring lock added before exec is executed, it will be cancelled.

When the client connection is lost (such as exiting the connection), everything is unmonitored

Summarize

Open Start
a transaction with MULTI
Enqueue
Enqueue multiple commands into the transaction, these commands will not be executed immediately, but placed in the transaction queue waiting to be executed
Execute
the transaction is triggered by the EXEC command

pipeline

Introduction of interview questions and origin of questions

Origin of the problem

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

1. The client sends commands to the server in four steps (sending commands→command queuing→command execution→returning results), and monitors the Socket return, usually in blocking mode to wait for the server to respond.

2 The server processes the command and returns the result to the client.

The above two steps are called: Round Trip Time (referred to as RTT, the time for data packets to and from both ends), at the bottom of the question note

If you need to execute a large number of commands at the same time, you have to wait for the response of the previous command before executing it. Not only is there more RTT (Round Time Trip), but also frequently calls the system IO, sends network requests, and requires redis to call multiple times The read() and write() system methods, the system method will transfer the data from the user state to the kernel state, which will have a relatively large impact on the process context, and the performance is not very good, o(╥﹏╥)o

concept

The pipeline (pipeline) can send multiple commands to the server at one time. After the server finishes processing in sequence, it will return the results 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. The pipeline is to solve the RTT return, only pack the command once and send it, without any impact on the entire Redis execution (in a word, the pipeline is an optimization measure for batch processing, similar to Redis's native batch processing command (mset / mget) )

Case presentation

Summarize

Pipeline and native batch

Native batch commands are atomic (such as: mset, mget), and pipeline is nonatomic

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

publish subscribe

concept

is a message communication pattern:

The sender (PUBLISH) sends the message

Subscribers (SUBSCRIBE) receive messages and can implement message delivery between processes

Redis can implement the function of message middleware MQ, and realize the guidance and distribution of messages through publishing and subscribing

Function

The Redis client can subscribe to any number of channels, similar to our WeChat follow multiple public accounts

Publish/subscribe is actually a lightweight queue, but the data will not be persisted, and it is generally used to process asynchronous messages with high real-time performance

Common commands

SUBSCRIBE channel [channel] // Subscribe to multiple channels
PUBLISH channel message // Publish information to a channel
PSUBSCRIBE pattern [pattern...] // Subscribe in batches according to the pattern, subscribe to one or more that match the given pattern (support * number?
PUSUB CHANNELS // A list of active channels PSUUB
NUMSUB channel [channel...] // How many subscribers a certain channel has
PUBSUB NUMPAT // Only count the ones executed by the PUBSCRIBE command, and return to the client The number of unique patterns the client is subscribed to
UNSUBSCRIBE channel [channel...] // unsubscribe from
PUNSUBSCRIBE pattern [pattern...] // unsubscribe from all channels with the given pattern

Summarize

advantage

Redis can implement the function of message middleware MQ, and realize the guidance and distribution of messages through publish and subscribe. (But it is not recommended to use, professional things are left to professional tools MQ, kafka, RabbitMQ)

shortcoming

Published messages cannot be persisted in the Redis system. Therefore, subscription must be performed first, and then wait for the message to be published. If the message is published first, the message will be discarded directly because there are no subscribers

As long as the message is sent, the message is sent and lost immediately for the publisher. No matter whether it is received, there is no ACK mechanism, and the successful consumption of the message cannot be guaranteed.

The above shortcomings make the Pub/Sub mode of Redis like a small toy, which is almost useless in the production environment. For this reason, Redis5.0 version adds a stream data structure, which not only supports multicast, but also supports data persistence. More powerful than Pub/Sub

[redis basics] transaction|pipeline|publish-subscribe

affairs

concept

effect

Database transactions vs redis transactions

common command

Case 1: Normal execution

Case 2: Abandoning the transaction

Situation 3: All sitting together

Situation 4: Bad creditor

Case 5: watch monitoring

Summarize

pipeline

Introduction of interview questions and origin of questions

concept

Case presentation

Summarize

publish subscribe

concept

Common commands

Summarize

Guess you like