Cloud computing Design pattern Translation (iv): Competing consumers pattern (consumer competition)

Simply put, this pattern enables multiple parallel consumer to process messages received in the same channel, allowing the system to process a large number of messages concurrently to optimize the throughput of the system, improve the scalability and availability of the system, and balance the load.

Context and Problem

In general, an application running in the cloud usually needs to handle a large number of requests. A more general technique is to implement a message system to process individual requests asynchronously, rather than synchronizing each request in a synchronous manner. In addition, this strategy enables the business logic not to block when a request is being processed.

There are a number of reasons why the system is processing a huge change in the amount of requests being processed during the system's operation. Sudden user activity or the aggregation of messages to multiple system users can cause some unexpected (large) loads. The system may handle a huge amount of messages during peak times but only a few messages in other time periods, and the logic for handling different messages can vary greatly. For these reasons, if only one message consumer is used in the system (that is, the application that handles the message), then the consumer is likely to be overwhelmed by massive messages at peak times, or the entire messaging system will be too overloaded and directly paralyzed. To solve this problem, you can start multiple consumer instances in the system, but in this case you must coordinate these consumer instances to ensure that each message is only received and processed by one of them, as well as load balancing, to avoid one of the consumer become the bottleneck of the whole system.

Solution

The solution to the above problem is to use Message Queuing as the communication medium between the user program (that is, the producer of the message) and the message consumer. The user program encapsulates the call request into a message queue, consumer the message from the message queue and processes it. This method enables consumer in the same consumer pool (which contains a bunch of consumer instances) to handle requests from any user program.

This solution has the following benefits:

1. This design enables systems with fixed load levels to handle user requests with varying pressures. Message Queuing is quite similar to a buffer between the user program and the consumer, helping to reduce the impact of pressure fluctuations on the stability and responsiveness of the user program and consumer.

2. This design can help improve system reliability. Assuming that the user program is connected directly to the consumer rather than using this pattern (introducing Message Queuing) and does not regulate the consumer, the request is likely to be lost or failed when the consumer is having a problem. However, in this mode the user program does not send the message to a specific consumer, but a bunch of consumer on the message queue side of the message, in addition, when the message fails, it will not cause user program blocking.

3. With this pattern, there is no need for too much complex coordination between multiple consumer or between user programs and consumer, and Message Queuing itself guarantees that messages are delivered at least once.

4. This design is very easy to expand. The number of consumer can be arbitrarily increased or decreased according to the pressure of the request.

5. This design improves the resiliency of the system if the message queue being used supports transactional reads (each message is and will only be taken once). If a consumer reads and processes a message as a step in a transactional operation, when it takes the steps to execute after a message is fetched, Message Queuing can guarantee that the message will remain in the queue and be duplicated again by the other consumer.

Issues and Considerations

Here are a few things to look at when considering how to implement this pattern:

1. Message order: In scenarios where multiple consumer rob messages, the order in which consumer obtains messages is not guaranteed and is not necessarily associated with the order in which the messages are created. In the system design, the message processing process is designed to be idempotent, which can eliminate the effect of the message processing order on the processing result.

2. System resiliency: If the system needs to supervise the consumer service and reboot when it fails, it is more necessary to design the operation as Idempotent, which minimizes the impact on the system when the message duplication process occurs.

3. Detecting "poisonous" messages: a malformed message or access to tasks that do not normally use resources can cause consumer to crash. In this case, the system needs to avoid this message re-reflow into the message system, and capture the message/task exception information for future analysis and repair.

4. Result processing: Consumer the logic of processing messages is completely decoupled from the business logic that generates the message and is not communicated in a direct manner. If the consumer processing result must be sent back to the producer of the source message, then the result must be stored in a container that can be accessed on both sides, and the system will provide a flag indicating that the data processing is complete to prevent one party from accessing incomplete information.

5. Message system Extensibility: In a large-scale data processing scenario, a single message queue can easily be overwhelmed by a large amount of messages and become a bottleneck for the overall system performance. At this point, consider partitioning the entire message system (distributed), where the producer of the message only sends messages in its own partition, or multiple message queues can be combined to add a layer of load balancing over them.

6. Ensure the reliability of the messaging system: a reliable messaging system needs to ensure that when an application inserts a message into the message system, the message is never lost (even if it fails), which is a precondition for the principle "guarantee that every message is delivered at least once".

Cloud computing Design pattern Translation (iv): Competing consumers pattern (consumer competition)