Personal understanding of the Redis pub/sub mechanism in the practical application scene

The pub/sub mechanism of Redis is very similar to the observer design pattern in 23 design patterns. But Redis is more portable and simple to implement for this mechanism, without the complicated logic consideration of the observer pattern and only needs to be implemented through two Redis client configuration channel, so it only makes the message "Publish" and "subscribe" the implementation, The situation encountered in the actual handling of such scenarios is not considered at all.

data reliability is not guaranteed
A REDIS-CLI post message n a REDIS-CLI accept message. The release of the message is stateless, that is, when the message is published, the REDIS-CLI is aware of whether the message is accepted, whether it is lost during transmission, that is, the message is "lost" to the publisher.

Scalability Too bad

It is not possible to speed up the consumption of data written by the publisher by increasing the consumer, and if the publisher publishes a lot of messages, data congestion is consumed in the channel waiting to be consumed. The longer the blocking time, the greater the risk of data loss (a network or server instability can result in data loss)

High resource consumption

In Pub/sub, the message Publisher does not need to monopolize a redis link, while the consumer needs to occupy a single redis link, and in Java it is not allowed to separate a thread to handle the consumer. This scenario generally corresponds to these multiple consumers, at this time there is a high resource consumption.

For several deficiencies, you can use JMS to implement this functionality if you need to consider them in your project. JMS provides a variety of enterprise-class features such as persistence/durability of messages. If you still want to use Redis to implement and do some data persistence operations, you can simulate them by Redis according to the JMS features. The subscribe end first adds a "Subscriber ID" to a set set that holds the active subscription, and the Subscriber ID marks each unique subscriber, for example: Sub:email,sub:web. This set is called the "Active Subscriber Collection" Subcribe-side open subscription operation and creates a list of "Subscriber ID" key data structures based on Redis, which stores all the messages that have not been consumed. This list is called the Subscriber Message Queuing publish end: After each message is published, the publish end needs to traverse the active Subscriber collection and append the message to the Subscriber message queue in turn. So far, we can basically guarantee that every message we publish will be persisted in each Subscriber message queue. Subscribe end, each receive a subscription message, after consumption, you must delete your own "subscriber Message Queue" header of a record. When the subscribe is started, if you find that your own subscriber message queue has a residual record, you will first consume the records and then subscribe.

Code I realized tomorrow in the posted out, sleep first tonight. Good night.