This topic describes common scenarios in which ApsaraMQ for RocketMQ is used to help you better understand how to use ApsaraMQ for RocketMQ in your business.
For example, the business of an Internet e-commerce enterprise covers a variety of aspects such as registration, ordering, inventory, and logistics. The enterprise needs to cope with business peaks during promotional activities such as flash sales, anniversary celebrations, and regular special offers. These activities impose great challenges on the processing capabilities of microservice applications in distributed systems.
As a core component of distributed systems, ApsaraMQ for RocketMQ can help overcome the preceding challenges. For example, ApsaraMQ for RocketMQ can be used to resolve the issue of asynchronous decoupling.
This topic describes how to use ApsaraMQ for RocketMQ to implement the following features in user registration scenarios.
Asynchronous decoupling
Data consistency of distributed transactions
Publishing and subscription of ordered messages
This topic also describes how to use ApsaraMQ for RocketMQ to implement peak-load shifting and cache synchronization of large-scale servers in flash sales and price synchronization scenarios in e-commerce enterprises.
Asynchronous decoupling
Traditional implementation modes
In a common user registration scenario, after a user registers, the system needs to send email and SMS notifications to notify the user that the registration is successful. Traditional implementation of this requirement uses the following modes:
Serial mode
The following figure shows the registration process in serial mode.
The preceding registration process consists of the following steps:
The user enters an account and a password and submits registration information on the registration page. The registration information is written to the registration system.
The registration system sends a request to the email notification system. After the email notification system receives the request, the email notification system sends an email notification to the user.
The email notification system sends a request to the SMS notification system. After the SMS notification system receives the request, the SMS notification system sends an SMS notification to the user.
After all the preceding steps are complete, a registration result is sent to the client and the user can log on with the registered account.
If each step takes 50 milliseconds to complete, the user needs to wait 150 milliseconds on the registration page before the user can log on.
Parallel mode
The following figure shows the registration process in parallel mode.
The preceding registration process consists of the following steps:
The user enters an account and a password and submits registration information on the registration page. The registration information is written to the registration system.
The registration system sends requests to the email notification system and the SMS notification system at the same time. After the two notification systems receive the requests, the email notification system sends an email notification to the user and the SMS notification system sends an SMS notification to the user.
After all the preceding steps are complete, a registration result is sent to the client and the user can log on with the registered account.
If each step takes 50 milliseconds to complete, the user needs to wait 100 milliseconds on the registration page before the user can log on. This is because the email notification and SMS notification are sent to the user at the same time.
The following section describes the implementation of ApsaraMQ for RocketMQ in user registration scenarios.
Asynchronous decoupling
A user can have better experience if the user logs on immediately after the registration system stores the account information of the user. The user does not need to check the SMS and email notifications.
The registration system does not necessarily need to wait for the SMS and email notification systems to send notifications upon successful registration. After data is written to the registration system, the registration system can put the required operations into ApsaraMQ for RocketMQ and immediately return the registration result to the user. The required operations are asynchronously completed in ApsaraMQ for RocketMQ.
The preceding registration process consists of the following steps:
The user enters an account and a password and submits registration information on the registration page. The registration information is written to the registration system.
The registration system sends a message to ApsaraMQ for RocketMQ. ApsaraMQ for RocketMQ immediately sends a response to the registration system. The registration is complete and the user can log on.
The email and SMS notification systems subscribe to the registration message from ApsaraMQ for RocketMQ and send email and SMS notifications to the user. The registration process is complete.
In this case, the user needs to wait until the registration data is written to the registration system and ApsaraMQ for RocketMQ, which takes only 55 milliseconds.
Asynchronous decoupling is a key feature of ApsaraMQ for RocketMQ. This feature is designed to reduce the response time and implement decoupling. This feature is applicable to operations that are time-consuming and do not require immediate responses. The operations can be put into message queues as messages. The message sender and receiver are decoupled by ApsaraMQ for RocketMQ. On the condition that the message format remains unchanged, the message sender and receiver do not communicate with or affect each other.
Data consistency of distributed transactions
In the registration process, users enter registration information on the web page of the registration system while notifications are sent by the email notification system. The data in the two systems must be consistent.
Processing of normal messages
As described in the preceding section, the registration system and the email notification system implement asynchronous processing by using message queues. After registration information is written to the registration system, the registration system sends a message that indicates successful registration to ApsaraMQ for RocketMQ. The email notification system subscribes to the registration message from ApsaraMQ for RocketMQ and sends an email to notify the user of successful registration.
The preceding registration process consists of the following steps:
The registration system initiates registration.
The registration system sends a message that indicates successful or failed registration to ApsaraMQ for RocketMQ.
2.1 If the message is sent to ApsaraMQ for RocketMQ, the process goes to Step 3.
If the message fails to be sent, the email notification system fails to receive the message that indicates successful or failed registration from ApsaraMQ for RocketMQ and the email notification system cannot send an email notification to the user. In this case, the status data in the email notification system is inconsistent with that in the registration system.
The email notification system receives the message that indicates successful registration from ApsaraMQ for RocketMQ.
The email notification system sends an email notification that indicates successful registration to the user.
In this process, the systems are decoupled and the upstream system does not care about the processing result of the downstream system. However, the consistency between the status data in the email notification system and the status data in the registration system is not ensured.
Processing of transactional messages
To ensure status data consistency between different systems, you can use transactional messages provided by ApsaraMQ for RocketMQ.
The preceding registration process consists of the following steps:
The registration system sends a half message to ApsaraMQ for RocketMQ.
1.1 If the half message is sent to ApsaraMQ for RocketMQ, the process goes to Step 2.
1.2 If the half message fails to be sent, the registration system does not register the user but ends the process.
NoteAfter this step, the data in the registration system is consistent with the data in the email notification system.
The registration system starts to register the user.
2.1 If the registration succeeds, the process goes to Step 3.1.
2.2 If the registration fails, the process goes to Step 3.2.
The registration system sends the status of the half message to ApsaraMQ for RocketMQ.
3.1 If the half message is submitted, a message that indicates successful registration is generated and the process goes to Step 4.
3.2 If the half transactional message is rolled back, no message that indicates successful registration is generated and the process ends.
NoteAfter this step, the data in the registration system is consistent with the data in the email notification system.
The email notification system receives the message that indicates successful registration from ApsaraMQ for RocketMQ.
The email notification system sends an email notification that indicates successful registration to the user.
NoteAfter this step, the data in the registration system is consistent with the data in the email notification system.
For more information about distributed transactional messages, see Transactional messages.
Publishing and subscription of ordered messages
Ordered messages in ApsaraMQ for RocketMQ are classified into the following types:
Globally ordered messages: All messages in a specific topic are published and consumed in strict first in, first out (FIFO) order.
Partitionally ordered messages: All messages in a specific topic are partitioned by a sharding key. Messages in the same shard are published and consumed in strict FIFO order. This ensures that one message is consumed by one process.
In user registration scenarios, you can specify user ID as a sharding key for partitioning. Registration messages that are created, updated, or deleted in the same shard must be published and consumed in FIFO order.
For more information about ordered messages, see Ordered messages.
Peak-load shifting
Peak-load shifting is another frequently used feature of ApsaraMQ for RocketMQ. For example, you can use this feature in flash sales or group-buying activities.
In a flash sales or group-buying activity, traffic sharply increases due to large numbers of user requests. After the flash sales application processes huge access traffic, the notification system cannot handle the massive number of calls. In this case, some notifications may be missed due to issues such as system breakdown. To resolve these issues, you can add ApsaraMQ for RocketMQ between the application and the notification system.
The preceding flash sales process consists of the following steps:
Users send a large number of requests to the flash sales processing system.
Based on flash sales processing logic, the flash sales processing system sends requests that meet the flash sales conditions to ApsaraMQ for RocketMQ.
The notification system consumes the flash sales messages from ApsaraMQ for RocketMQ and sends messages that indicate successful purchase to the users.
The users receive the notifications on successful purchase.
Cache synchronization of large-scale servers
During Double 11, each venue has a wide variety of items whose prices may change in real time. In this case, the cache technology cannot meet the requirements for accessing product prices, and the network interface controllers (NICs) of cache servers are fully loaded. Multiple queries of product prices may slow down the opening of venue web pages.
In this case, a broadcasting mechanism is required. Originally, one message is consumed by only one server in a cluster. However, in broadcasting consumption mode of ApsaraMQ for RocketMQ, a message is consumed by all the consumers in the consumer cluster. This way, price information is synchronized to all servers. In this case, the broadcasting mechanism is used in the similar way as the cache feature.
For more information, see Clustering consumption and broadcasting consumption.