redis-3.redis's message subscription, pipeline, transaction, modules, bloom filter and cache LRU

Posted by linfidel on Sat, 19 Feb 2022 06:15:41 +0100



Beer theory, for example, there are 24 bottles of beer in the store. You can't take one bottle home and drink another. You need to find a box to carry the beer home together
The buffer mechanism can also be understood in this way to avoid calling back and forth

A request / response server can handle new requests even if the old requests have not been responded to. This allows multiple commands to be sent to the server without waiting for a reply, which is read in the last step.
This is pipelining, a technology widely used for decades. For example, many POP3 protocols have been implemented to support this function, which greatly speeds up the process of downloading new mail from the server.
Redis has long supported pipelining technology, so no matter what version you are running, you can use pipelining to operate redis.

The cold start of redis can be preloaded through it

[root@admin vmuser]# nc localhost 16379
keys *
-NOAUTH Authentication required.
auth 123456
keys *
set k1 hello

Log in to redis cli at this time> get k1

Use pipes to insert redis values as \ n splits
The following $3 means a width of 3 is 100

[root@admin vmuser]# echo -e "auth 123456\n set k2 99\n incr k2\n get k2" | nc localhost 16379

Pub/Sub publish subscription

help @pubsub

  PSUBSCRIBE pattern [pattern ...]
  summary: Listen for messages published to channels matching the given patterns
  since: 2.0.0

  PUBLISH channel message
  summary: Post a message to a channel
  since: 2.0.0

  PUBSUB subcommand [argument [argument ...]]
  summary: Inspect the state of the Pub/Sub subsystem
  since: 2.8.0

  PUNSUBSCRIBE [pattern [pattern ...]]
  summary: Stop listening for messages posted to channels matching the given patterns
  since: 2.0.0

  SUBSCRIBE channel [channel ...]
  summary: Listen for messages published to the given channels
  since: 2.0.0

  UNSUBSCRIBE [channel [channel ...]]
  summary: Stop listening for messages posted to the given channels
  since: 2.0.0

Server> PUBLISH ooxx hello
(integer) 0

client> SUBSCRIBE ooxx
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "ooxx"
3) (integer) 1

At this time, the client cannot obtain the data. The server needs to re execute publish, and the client can obtain the data of the server only after maintaining it

If you want to see the previous records, if you insert them into the database, it will become very expensive for everyone to check from the database

It can be used like this, but what if client1 goes to publish and client2 does not receive the message, but the sorted set receives the message and caches it?

Solution: start different redis to receive subscription messages, some for pushing to users, some for sending to kafka, and then store them in the database for consumption


redis transaction is actually very simple, not as complex as mysql, because the author designed it for fast reading

help @transactions

  summary: Discard all commands issued after MULTI
  since: 2.0.0

  EXEC -
  summary: Execute all commands issued after MULTI
  since: 1.2.0

  summary: Mark the start of a transaction block
  since: 1.2.0

  summary: Forget about all watched keys
  since: 2.2.0

  WATCH key [key ...]
  summary: Watch the given keys to determine execution of the MULTI/EXEC block
  since: 2.2.0

First of all, the original concept is that redis is a single process. If client1 and client2 initiate transactions at the same time, how to deal with them at this time
client1 is green
client2 is yellow

If the Yellow client2's exec arrives at redis first, execute client2 first. When executing client1, whose exec arrives first, execute whose first

Add a watch to use. If the key of redis has changed, the following operations will not be performed. For example, the get key of client1 will not be operated

              Open transaction> MULTI
OK> set k1 aaa
QUEUED> set k2 bbb
              Submit> exec
1) OK
2) OK

client1 starts the transaction first, but the commit exec is behind client2. At this time, it gets null> MULTI
OK> get k1
QUEUED> exec
1) (nil)

client2 finally starts the transaction and submits exec in advance> MULTI
OK> del k1
QUEUED> exec
1) (integer) 1> 


client 1 transaction is not under operation, so it is nil> WATCH k1
OK> get k1
QUEUED> keys * 
QUEUED> exec
(nil)> MULTI
OK> keys *
QUEUED> set k1 sdfsfds
QUEUED> exec
1) (empty array)
2) OK> get k1

Why does Redis not support roll back

If you have experience in using relational database, you may find it a little strange that "Redis does not roll back when the transaction fails, but continues to execute the remaining commands".
The following are the advantages of this approach:
Redis commands will only fail because of the wrong syntax (and these problems cannot be found when joining the queue), or the command is used on the wrong type of key: that is, from a practical point of view, the failed commands are caused by programming errors, which should be found in the development process, not in the production environment.
Because there is no need to support rollback, Redis's internal can remain simple and fast.
There is a view that Redis's handling of transactions will cause bug s. However, it should be noted that under normal circumstances, rollback cannot solve the problems caused by programming errors. For example, if you want to add 1 to the value of the key through the INCR command, but accidentally add 2, or perform INCR on the wrong type of key, rollback cannot deal with these situations.


Similar to the mode of others in the game, you can use it to play

Click in. The hot bloom of redis is right here


Point a small house into the description

Topics: Database Redis Cache