Message Queuing (MQ) has many application scenarios, such as message publishing and subscription, decoupling between upstream and downstream systems. One typical use of MQ is to buffer traffic, helping to shave peaks and fill valleys.
How do upstream and downstream systems usually communicate?
There are two common communication methods:
- Direct Call: Through an RPC framework, the upstream system directly calls the downstream system.
- MQ Push: The upstream system sends messages to the MQ, and the MQ pushes the messages to the downstream system.
Can these methods cache traffic or achieve peak shaving and valley filling?
No. Whether using "direct calls" or "MQ push", both have a drawback: the downstream message receiver cannot control the traffic arriving at their system. If the upstream system doesn’t limit the speed, it could overwhelm the downstream system.
Example: Double 11 Shopping Festival Scenario
- Upstream system: Initiates the order placing operation.
- Downstream system: Completes the following business logic (inventory check, inventory freeze, balance check, balance freeze, order generation, balance deduction, inventory deduction, transaction generation, balance thaw, inventory thaw).
The upstream order placing operation is simple, sending 10,000 requests per second. The downstream logic is complex, processing only 2,000 requests per second. If the upstream system sends requests without throttling, it could overwhelm the downstream system, causing a system crash.
How to prevent overwhelming the downstream system?
To avoid the system crash, there are two common optimization strategies:
- Buffering at the upstream queue, limiting the rate of requests sent.
- Buffering at the downstream queue, limiting the rate of execution.
However, both solutions introduce additional business complexity. Any system requiring traffic buffering will need to incorporate similar mechanisms. This is a universal pain point that requires a generic solution.
Can MQ Achieve Traffic Buffering?
Yes, but it requires a small modification. To achieve traffic buffering with MQ, the MQ-server push mode can be upgraded to MQ-client pull mode. In this mode, the MQ-client, based on its processing capacity, pulls a batch of messages from the queue at regular intervals or in batches. The client then implements flow control, protecting itself from being overwhelmed. This is a generic feature provided by MQ, so no changes to the upstream or downstream systems are needed.
What Happens if the Upstream System Sends Too Much Traffic?
If the upstream system sends excessive traffic, the pull mode provided by MQ can indeed protect the downstream system by enabling it to pull messages at a controlled pace. But this raises the question: Will messages accumulate in the MQ queue?
In pull mode, the downstream MQ-client can fetch messages in batches. However, to maximize throughput, the downstream system needs to be optimized. For example, batch writes can be used to improve processing efficiency.
Conclusion
- MQ-client pull mode enables periodic or batch message pulling, which helps smooth out traffic, offering self-protection for the downstream system (this is the job of MQ).
- To increase overall throughput, the downstream system must implement optimizations such as batch processing (this is the job of the message receiver).
Why can't refunds be processed on Double 11? Because for the entire transaction process, only the first half is completed. The second half, involving the MQ, is still stored in the database, waiting for the downstream systems to process it.
Top comments (0)