[A] The benefits of the task queue---> loose coupling: Producers and consumers do not need to know the details of each other's implementation, only the description format of the task is agreed. This enables producers and consumers to be written by different teams using different programming languages. ---> Easy to scale: consumers can have multiple, and can be distributed across different machines. You can easily reduce the load on a single server. [II] using Redis to implement a simple task queue (producer consumer model)---> Implement queues based on the storage structure of the list type---> Producer commands: Lpush key value[value ...] Rpush key Value[value ...] ---> Consumer command: Rpop key or Brpop key timeout, lpop key or Blpop key Timeout---> Block consumer command: timeout is 0 o'clock, do not set time-out, wait until Interest. If you set a number, the unit is seconds. [III] using REDIS to implement the priority queue (producer consumer model)---> Set up multiple task queues, producers prioritize tasks, send tasks to different queues---> consumers subscribe to multiple queues, order of queues: from high to low priority, from left to right. ---> Results: Every time a consumer takes a message, it is taken from the left to the right. The task in the lower priority queue is consumed before the task in the high priority queue is consumed. Example: [four] using Redis to implement the publish subscription model (broadcast model)---> publishers to the Channel in Redis Publish a message x, all subscribers to the channel can get this message x---> Publisher command: PUBLISH Channel message---> Subscriber command: SUBSCRIBE Channel [channel]--->publish command post a message, the return value represents the number of subscribers subscribed to the message. If 0 is returned, the message will not persist and will disappear if it is an unattended subscription. The subscriber subscribed to the channel in a timely fashion, and could not subscribe to historical messages previously published by the publisher. ---> After the subscribe command is executed, the client enters the subscription state. Clients in this state cannot use commands other than the Subscribe,unsubscribe,psubscribe,punsubscribe four commands that are part of the publish subscription mode. Otherwise an error will be---three values are returned after the >subscribe command executes. The first value is the type of the message. UnderThe message type is different, the second, and the third value is different (1) the message type contains =>subscibe, which represents the feedback information for the subscription success. The second value is the channel name for which the subscription succeeds, and the third value is the number of channels subscribed to by the current client. =>message, this type of reply is our top concern and it means receiving a message. The second value indicates the channel name that generated the message, and the third value is the content of the message =>unsubscribe. This type of reply indicates a successful unsubscribe to a channel, the second value corresponds to the channel name, and the third value is the number of channels subscribed to by the current client. When this value returns 0 o'clock, the current client exits the subscription state. You can then perform other commands that are not "publish subscription" mode. [v] Publish subscription model: Subscribe to rules by rule---> syntax for subscription channels by rules
Symbol |
Meaning |
? |
Match one character |
* |
Match any of the characters (including 0) |
[] |
Match any of the characters between parentheses, and you can use the "-" symbol to represent a range. such as [a-z][1-9] |
matches the character X, which is used to escape symbols. If you match "?" You need to use \? |
---> Command format: Pusbscribe Channelpattern[channelpattern ...] ---> Return value of four values. (1) Pmessage: Indicates that the channel received through the Pusbscribe command subscription. (2) Channelpattern: Indicates that the wildcard character is used when subscribing (3) ChannelName: The channel command that represents the actual message received (4) Messagecontext: Indicates the content of the message received---> You can subscribe to a channel repeatedly using the Pusbscribe command. For example, the client executes. Pusbscribe Chanel.? Channel.? * Then this time to send a message to CHANNEL.2, the subscribing client will receive two messages. Also if the client uses Pusbscribe channel.10 channel.? * Subscribe to messages. The message is sent to channle1.10, and the subscribing client receives two messages. But the message type is two kinds of message together pmessage. [VI] Publish subscription model: Unsubscribe from the rules---> by matching the unsubscribe command format: punsubscribe [pattern [pattern ...]] UNSUBSCRIBE command format for---> Direct subscriptions: unsubscribe [Channel [channel ...]] ---> Use the punsubscribe command only to unsubscribe from the Psubscribe command subscription rule. Channels that are subscribed directly through the Subscribe command are not affected---> the same unsubscribe command does not affect the channels subscribed to the Psubscribe command. ---> Error-prone point: the command rule that matches a symbol is not expanded when a rule is punsubscribe by a command. For example: with Punsubscribe * is unable to unsubscribe channel.*. Instead, you must use Punsubscribe channel.* to unsubscribe channel.*
Redis (10) The function of Redis to implement message middleware