Background introduction
Distributed, real-time
In the previous chapter, I briefly introduced Our smart home big data basic platform architecture, we know that for some real-time requirements, such as some control commands (sensor switch state, smart car speed) and other information need to be transmitted to the data center in real time, and the data center These data need to be pushed to other subsystems in real time, including computing service platforms and smart device monitoring platforms. In this case, it is equivalent to not the user requesting data, but the server actively pushing data.
But after thinking about it carefully, I found that the above two scenarios are slightly different:
- A series of data such as control commands are pushed to the data center in real time
- The data center is pushed to various subsystems. These subsystems perform their duties and have their own duties.
Under scenario 1, the data center is like a big trash can, but this big The trash can takes the initiative to collect any rubbish.
In Scenario 2, each subsystem is a little headstrong, only doing its own job well, it doesn’t accept everything that has nothing to do with the content of your work. Therefore, the subsystem of scenario 2 needs to inform the data center in advance of its own functions, so that the data center can selectively push the required data to them according to the functions of the subsystem.
So how to solve these two kinds of concrete?
The concept of two scenes
Data access, event distribution
data access
< /p>
The various smart devices in the data acquisition system report the data through the API interface, and the message queue is responsible for the parallel processing and persistence of the data stream. Finally, it is pushed to the data center at a steady speed to be responsible for data processing.
event distribution
Each subsystem acts as an event processor. First, it needs to subscribe to events in the database. The message center uniformly manages the events subscribed by the subsystem. As long as each smart device updates the status of related events, it will immediately Publish events to the message center, and the message center distributes the events to the corresponding event handlers.
Talk about the design pattern
Observer model, producer consumer model, publish-subscribe model< /p>
Publishers + Subscribers = Observer Pattern ? Obviously not! The publish-subscriber model is a model in a distributed scenario.
Their main differences are as follows:
We can see that there is an event forwarder in the publish-subscriber, which acts as a message broker between the publisher and the subscriber to handle the communication between the two. This communication mode guarantees:
- The processing details of publishers and subscribers are shielded:
In Observer mode, Observers know the Subject, and at the same time Subject A record of Observers is also kept. However, in the publisher/subscriber, the publisher and the subscriber do not need to know each other. They just communicate with the help of message queues or agents.
2, Publisher / Subscriber components are loosely coupled.
3. In most cases, publishers/subscribers process messages asynchronously, and the observer mode is mainly implemented in a synchronous manner.
4. The observer mode needs to be implemented in a single application. On the other hand, the publisher/subscriber model enables platform construction.
Reference Materials
The difference between the observer and the publish-subscribe model. https://www.cnblogs.com/viaiu/p/9939301.html
p>
The production consumer model and subscription publishing model under RabbitMQ.https://blog.csdn.net/zwgdft/article/details/53561277
The production consumer model and subscription under Kafka Release mode.https://blog.csdn.net/zwgdft/article/details/54633105https://blog.csdn.net