This is the seventh day of my participation in the August More text Challenge. For details, see:August is more challenging

This chapter focuses on advanced applications of Redis, such as message queues based on a publis-subscribe model with less stringent requirements; For example, the transaction management of multiple Redis instructions is carried out to improve efficiency

My Redis series, interested friends can also come to see

Redis Quick Start – Installation and configuration

Redis – Common Data Structures and Usage (1)

Redis – Common Data Structures and Usage (part 2)

Publish and subscribe

Just like we all follow a wechat subscription number, subscription number he updates the article, automatically to all the people who follow him to push this article

Relevant command

pubsub subcommand [argument [argument …]]

View the subscription and publishing system status

127.0.0.1:16379> pubsub channels
(empty list or set)
Copy the code

subscribe channel [channel …]

Subscribe to a given channel or channels

127.0.0.1:16379> SUBSCRIBE channel-1
Reading messages... (press Ctrl-C to quit)
1"Subscribe" # command2) "channel-1"# subscribe3) (integer) 1# Number of successful subscriptionsCopy the code

psubscribe pattern [pattern …]

Subscribe to one or more channels that fit a given pattern

Details of the pattern? The value must match a wildcard character (*). Any character from 0 to N is matchedCopy the code

Message subscriber

The subscription satisfies the expression a? A, B * B

127.0.0.1:16379> PSUBSCRIBE a? a b*b Reading messages... (press Ctrl-C to quit)1) "psubscribe"
2) "a? a"3) (integer) 1
1) "psubscribe"
2) "b*b"
3) (integer) 2
Copy the code

Message push side

127.0.0.1:16379> publish aa 'hello'
(integer) 0
127.0.0.1:16379> publish aba 'hello'
(integer) 1
127.0.0.1:16379> publish abba 'hello'
(integer) 0
127.0.0.1:16379> publish bb 'hello'
(integer) 1
127.0.0.1:16379> publish bab 'hello'
(integer) 1
127.0.0.1:16379> publish baab 'hello'
(integer) 1
Copy the code

The subscriber receives a push message. Procedure

1) "pmessage" # Message type2) "a? A "# matches the channel rule3) "ABA" # Actual matching channel4"Hello" # received message -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --1) "pmessage"
2) "b*b"
3) "bb"
4) "hello"
---------------------------------
1) "pmessage"
2) "b*b"
3) "bab"
4) "hello"
---------------------------------
1) "pmessage"
2) "b*b"
3) "baab"
4) "hello"
Copy the code

publish channel message

Sends information to the specified channel

# Message push side, like channel-2Send message, push failed, there is no client listening to this pipeline127.0.0.1:16379> PUBLISH channel-2 hello
(integer) 0--------------------------- # Message push side, like channel-1The message was sent. Push succeeded127.0.0.1:16379> PUBLISH channel-1 hello
(integer) 1# Client listening to pipe received message127.0.0.1:16379> SUBSCRIBE channel-1
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "channel-1"
3) (integer) 1
1) "message"
2) "channel-1"
3) "hello"
Copy the code

unsubscribe [channel [channel …]

Unsubscribe from all channels in a given mode

punsubscribe [pattern [pattern …]]

Unsubscribe from all channels in a given mode

Note: If an attempt is made to send a message to an unlistened channel, 0 is returned, indicating false

Related commands can be summarized as:

The client subscribes to a specific channel (SUBSCRIBE) or according to an expression (psubscribe)

The client sends a single message to a specific channel

The client unsubscribs to a specific channel, or unsubscribs to a channel based on an expression

Sample code summary

Usage scenarios

The most common use scenario is to replace MQ

The alternative here is that systems that do not accept the introduction of MQ will become more complex, less maintainable, and will not be strict about the receipt and consumption of messages, allowing for the risk of message loss. After all, MQ will provide a mechanism for message confirmation to ensure that every message is consumed

Here, in contrast to mainstream RabbitMQ:

  • Redis: Lightweight, low latency, high concurrency, low reliability;
  • Rabbitmq: heavyweight, highly reliable, asynchronous, no real-time guarantee

Redis transactions

introduce

Perhaps the first reaction of many people is that Redis transactions should be similar to Spring transactions. In fact, they are completely different

A Redis transaction, or more realistically, a batch execution of a Redis command, has the following features:

  • Commands contained in a transaction are executed sequentially and are not interrupted by commands from other clients
  • During the execution of a transaction command, if one of the intermediate commands fails, the transaction will not be interrupted, the executed commands will not be rolled back, and the subsequent commands will continue to be executed

The execution flow of a standard transaction:

  1. Start a transaction (using the command MULTI)
  2. The command team
    1. The operation command of redis is not executed immediately and is queued first
    2. Optional operation: DISCARD the current transaction, clear the transaction queue, use the instruction DISCARD
  3. Execute a transaction (using the instruction EXEC)

Note: The point at which a Redis transaction succeeds or fails depends only on whether the exec instruction is executed

Relevant command

multi

Marks the start of a transaction block

exec

Execute all the commands in the transaction block

discard

Cancel the transaction, abandon execution of all commands in the transaction block

watch key [key…]

Listen for one or more keys, and if this or these keys are changed by another command before the transaction is executed, the transaction will be interrupted

Excerpts from official documents

Why does Redis not support rollback?

If you know relational databases, the Redis transaction mechanism may seem a little strange.

Commands in a Redis transaction are allowed to fail, but Redis will continue executing other commands instead of rolling back all commands.

There are two reasons for this:

  • The Redis command fails in only two situations:
  • It only fails when the syntax is incorrect (not checking the syntax when the command is typed).
  • Key data type mismatch to execute: This error is actually a programming error that should be tested during development, not production.
  • Internal Redis implementation is simple and efficient because there is no need to roll back.

Redis isn’t very friendly when it comes to bugs, but it’s important to note that rolling back doesn’t solve bugs.

For example, a rollback is not helpful in cases where a 2 is added to logic that needs a 1, or the key type of the operation is wrong.

Given that no one can avoid programmer errors, and that such errors rarely make it into production, we opted for the simpler and more efficient approach of not supporting error rollback.