In the existing project, there is a need to push messages for millions of stores at the same time. It is necessary to design a message push center system for special message push
- Push messages to millions of stores
- Support websocket on the agent side to push messages in real time to inform customer service of matters needing attention
- The challenge is to design a general message push platform to support message push of other business lines
Design and Implementation
Prepare to push material
- Import message recipient data
- Select conditions to pull the data of message recipients from each business line
Point 1: importing the data of the message receiver can support excel import, and then go to each business line to pull the complete user ID. the imported data needs to be submitted to the service or stored in the database in pages
Second point: select the conditions to pull the message receiver data from each business line. First drop the task and task information in the database. It will be difficult to pull millions of stores synchronously from the business line. After design, the sequential message is used for delivery MQ for self-production and self-sale.
Design sequential consumption MQ to pull store data by customer service screening conditions
The system adopts the natural support mode of rocketmq to ensure the sequential delivery (message queue selector), in which the principle can be referred toThis article。
Limit the number of threads consumed to ensure the self-protection of services in the case of large data consumption
Using this method will lead to the performance degradation of MQ. If there is a large amount of data and high concurrent consumption, the throughput of MQ service will decline. Therefore, in order to prevent the collapse of MQ service and there are not many such data, the number of consumption threads of this topic can be limited.
Consumption MQ message starts to pull store data
Through the task information delivered by MQ, pull the conditions selected by the user to pull the data of the message receiver to be sent from each business line (at this stage, only the store needs to be pulled). After pulling the store data, all push materials are ready. At this time, users can click to start sending or make an appointment to send.
Problems in pulling store data online
Because the conditions stored in the message push center are user filtering conditions, and these conditions are enumeration values, there is no way to go to the index when obtaining store data. If you check through these conditions and the amount of data meeting these conditions is small, it will lead to full table scanning and call interface timeout, which can reach 8 seconds online.
Each business line can pull data from the database through the cursor every time, then put it into redis to filter the qualified data according to the conditions, and then return it. In this way, the problem of interface timeout can be solved.
Two push strategies need to be supported, MQ push and multi-threaded push
Use multi threads to push, pull the receiver’s data from the database page, and execute the task of sending messages to the thread pool according to the submitted tasks. After the messages are sent, the number of messages sent is returned, and the asynchronous execution results of threads are obtained by blocking in the way of future.
Push all message recipients to MQ for self production and sale, and push messages to the recipient after consumption to MQ
The push platform has realized the push function of large amount of data. In the later planning, the push of websocket and other push methods will be designed.