When using a MySQL database, if it’s a shopping site you have to take into account flash sales, panic buying, message sending and other cases where simultaneous access to the database causes congestion and ends up crushing the database. How can we effectively do some handling in the program and in MySQL to cope with it?
The answer is: put the HTTP requests into a high-speed in-memory queue, then split and process the data in the queue according to certain rules. When a user sends a request, we can delay it by 2s for that user, and so on.
If you are sending notification-type messages, the user base is large and you can’t send them all at once, so you need to queue them up for sending; delay the message-sending operations while giving priority to active users (that is, asynchronous operations), reasonably spreading the load on the server.
Advantages of asynchronous operations: simple deployment — most scheduling can be done with MySQL’s built-in stored procedures and timers — and the server deployment is simple and easy to migrate.
Disadvantages: it doesn’t work well for large data volumes or for handling tens of millions of messages. It cannot cope with scenarios that demand very high real-time performance. As for HTTP queues, Kingsoft has an internally open-sourced HTTPSQL that moves the queue out of MySQL and into an in-memory database, with a dedicated process responsible for queue operations while clients read and write through socket requests. There is also a lightweight in-memory message queue, ZeroMQ, which transfers messages through its API.
