Apache RocketMQ ACL 2.0 new upgrade

[Live broadcast preview] Will large models replace programmers? "

Author: Tu Zhong

introduction

As a popular distributed messaging middleware, RocketMQ is widely used in various large-scale distributed systems and microservices. It plays important roles in asynchronous communication, system decoupling, peak-shaving and valley-filling, and message notification. With the evolution of technology and the expansion of business scale, security-related challenges have become increasingly prominent, and access control of messaging systems has become particularly important. However, RocketMQ's existing ACL 1.0 version is no longer able to meet future development. Therefore, we launched the RocketMQ ACL 2.0 upgraded version to further improve the security of RocketMQ data. This article will introduce the new features, working principles, and related configurations and practices of RocketMQ ACL 2.0.

Upgraded background

ACL 1.0 pain points

The authentication and authorization process of RocketMQ ACL 1.0 is shown in the figure above. During use, there are the following pain points:

IP whitelisting to bypass access control : In standard security practices, IP whitelisting is often used to restrict clients from accessing resources only from specific IPs or IP ranges. However, in ACL 1.0, the IP whitelist is abnormally used as a means to bypass authentication verification, deviating from the security intent of standard practice. This design deviation may cause potential security risks, especially in public network scenarios where multiple clients share the same IP, which may cause unauthorized IP addresses to bypass normal access control checks on the cluster. data to access.

Lack of fine-grained control of management APIs : RocketMQ provides more than 130 management and control APIs, supporting cluster configuration, metadata management of Topic and Group, as well as operations such as message query and site reset. These operations involve the processing of sensitive data and affect the stability of the system. Therefore, it becomes critical to accurately define the scope of accessible APIs and data based on different user roles or responsibilities. However, ACL 1.0 only supports 9 APIs, including Topic, Group metadata, and Broker configuration. The remaining APIs may be used by attackers to attack the system and steal sensitive data. In addition, implementing access control for so many management APIs requires a lot of coding work with the existing design and increases the risk of things being missed when new APIs are added.

Lack of access control between cluster components : RocketMQ architecture covers multiple key components such as NameServer, Broker master-slave node, and Proxy. Currently, the key permission verification mechanism is missing for mutual access between these components. Therefore, once you build a Broker slave node or Proxy component outside the cluster, you can bypass the existing security mechanism and access and obtain sensitive data in the cluster. This will undoubtedly have a huge impact on the data security of the system and the stability of the cluster. threats.

Characteristics and principles

ACL 2.0 new features

RocketMQ ACL 2.0 solves the problems in ACL 1.0 and also brings six major new features, as follows:

Fine API resource permission definition : ACL 2.0 defines all resources in the RocketMQ system, including clusters, namespaces, topics, and consumer groups, to achieve independent access control for all types of resources. In addition, it brings all APIs into the scope of permission control, covering various operations including message sending and receiving, cluster management, metadata, etc., ensuring that strict permission control is imposed on any operation of all resources.

Multiple matching modes for authorized resources : In a cluster environment with many resources, authorizing each resource one by one will bring complicated configuration processes and management burdens. Therefore, ACL 2.0 introduces three flexible matching modes: exact match, prefix match, and wildcard match. These modes allow users to quickly make unified settings based on the naming conventions and structural characteristics of resources, simplify permission management operations, and improve configuration efficiency.

Support access control between cluster components : Since all resource types and API operations are included in the access control system, connections and access between components within the cluster are also subject to permission control, including Leader election between Broker master and slave, and data replication. process, as well as data access from Proxy to Broker, etc. This can effectively avoid potential data leakage issues and risks to system stability, and enhance the security and reliability of the entire cluster.

Separation of user authentication and authority verification : By decoupling the two key modules of authentication and authorization, the system can provide flexible options such as "only authentication without authentication" to adapt to the needs of various scenarios. In addition, the two components can evolve and develop independently, thus giving birth to various authentication methods and advanced authentication methods.

Balance between security and performance : When ACL is enabled, each request from the client must go through a complete authentication and authorization process. This ensures system security, but also introduces performance overhead. In ACL 2.0, stateless authentication and authorization strategies and stateful authentication and authorization strategies are provided to meet two different security and performance requirements: extreme security requirements and security controllable but performance priority.

Flexible and extensible plug-in mechanism : In the current market, there are multiple implementations of authentication methods, and authorization methods also have customization requirements for different scenarios. Therefore, ACL 2.0 has designed a plug-in framework to define and abstract interfaces at different levels to support future expansion of authentication and authorization and allow users to customize and implement corresponding solutions according to their own business needs.

access control model

Role-based access control (RBAC) and attribute-based access control (ABAC) are the two main methods in the access control system. RocketMQ ACL 2.0 integrates these two methods to create a more flexible and powerful access control system.

RBAC is a role-based access control model that allocates permissions through roles. RocketMQ ACL 2.0 divides user roles into super users (Super) and normal users (Normal). Super users have the highest level of permissions and can access resources without authorization, which simplifies permission dependence during cluster initialization and daily operation and maintenance. question. Ordinary users need to be granted corresponding permissions before accessing resources, which is suitable for on-demand access to resources in business scenarios.

ABAC is an attribute-based access control model that expresses access control policies through multi-dimensional attributes such as users, resources, environments, operations, etc. RocketMQ ACL 2.0 provides this flexible access control mechanism for ordinary users. Help administrators implement more refined access control to resources based on business needs, user responsibilities and other factors.

In the security system, authentication and authorization play different roles respectively. RocetMQ ACL 2.0 separates authentication and authorization into modules. This ensures that both components perform their duties and reduces the complexity of the system. Authentication services are dedicated to verifying the legitimacy of user identities, while authorization services focus on managing user permissions and access control. This division not only makes the code easier to manage, maintain and expand, but also provides users with flexibility in use. Depending on the needs, users can choose to enable authentication or authorization services separately, or they can choose to enable both at the same time. This enables RocketMQ ACL to meet the rapid deployment of simple scenarios and adapt to strict security requirements in complex environments.

Authentication

Authentication is a security mechanism designed to verify the authenticity of the person who initiates the access request. It is used to ensure that only those legitimate authenticated users or entities can access protected resources or perform specific operations. Simply put, authentication is answering the question "Who are you?" before a resource or service is accessed.

RocketMQ ACL 2.0 version maintains the same authentication mechanism as ACL 1.0, that is, AK/SK-based authentication method. This method mainly uses symmetric encryption technology to verify the client's identity, ensuring that sensitive authentication information (such as passwords) will not be transmitted in clear text on the network, thus improving the overall authentication security.

agent model

In order to improve the access control and permission management of the RocketMQ system, ACL 2.0 has made the following improvements and extensions to the principal model:

1. Abstraction of unified subject model: In order to realize access control and permission management of different entities, a unified subject interface is designed to allow multiple instances in the system to serve as subjects for resource access. As one of the subjects accessing resources, the user implements the subject's interface according to this model. This provides expansion capabilities for permission adaptation to new entity types in the future.

2. Role classification and permission granting:

Super user : In order to simplify the management process, the super user is automatically granted all permissions without the need for separate configuration, thus simplifying system initialization and daily operation and maintenance management.
Ordinary users : Ordinary users’ permissions require explicit authorization. ACL 2.0 provides relevant permission management tools that can grant appropriate permissions to ordinary users based on the organization's policies and security requirements.

3. Support user status management: In order to deal with possible security risks, such as user password leakage, ACL 2.0 provides user enabling and disabling functions. When a security incident occurs, the user status can be disabled to quickly stop the bleeding, thereby preventing illegal access.

Certification process

Client process:

When constructing an RPC request, the client checks whether the username and password are set. If not configured, the client sends the request directly;
If configured, the preset encryption algorithm is used to encrypt the request parameters and generate the corresponding digital signature (Signature).
Append the username and Signature to the request and send it to the server for authentication.

Server-side process:

After receiving the request, the server first checks whether authentication is turned on. If it is not turned on, it will pass without verification; if it is turned on, it will go to the next step.
The server parses and assembles the parameters related to the request authentication and obtains information including user name and Signature.
Query user-related information in the local database through the user name. If the user does not exist, then the processing will be returned as None; if the user exists, then proceed to the next step.
Obtain the user password, use the same encryption algorithm to encrypt the request to generate a Signature, and compare it with the Signature passed by the client. If the two are consistent, the authentication is successful. If they are inconsistent, the authentication fails.

Authorization

Core idea

Authorization is a security mechanism designed to determine whether an access requester has the permission to operate on a specific resource. In short, authorization is about answering the question "who performed what operations on which resources under what circumstances" before the resources are accessed.

Based on the "Attribute-based Access Control (ABAC)" model, RocketMQ ACL 2.0 covers the following series of core concepts. In system implementation, the following concepts will be used as guidance to complete the design and implementation of the entire rights management and authorization mechanism.

permission model

The core concept of the attribute-based access control (ABAC) model, ACL 2.0 has carefully designed the permission model. The key points are as follows:

Backward-compatible permissions policy : By default, ACL 2.0 only matches and checks user-defined permissions. If no match is found, it is deemed that there is no permission to access the resource. However, considering that in ACL 1.0, there is a default permission setting, which allows the default determination of "no permission access" and "with permission access" for unmatched resources. Therefore, we have implemented compatibility with the default permission policy to ensure seamless migration from ACL 1.0 to ACL 2.0.

Flexible resource matching mode : In terms of resource types, ACL 2.0 supports cluster, namespace, topic, consumer group and other types, which are used to control access to different types of resources. . In terms of resource names, three modes of exact matching (LITERAL), prefix matching (PREFIXED), and wildcard matching (ANY) are introduced to facilitate users to quickly set unified access rules based on the naming specifications and structures of resources and simplify permissions. manage.

Fine resource operation types : In terms of message sending and consumption interfaces, they are defined as PUB and SUB operations respectively. In terms of cluster and resource management interfaces, five operations are defined: CREATE, UPDATE, DELETE, LIST, and GET. Through this refinement of operation types, it can help users to simplify the understanding and configuration of operations without having to worry about specific interface definitions at the resource operation level.

Solid access environment verification : In terms of the environment for requesting access, ACL 2.0 adds verification of the IP source of the client's request. This verification is controlled at the level of each resource and can accurately control each resource. The IP source can be a specific IP address or an IP segment to meet IP access control at different granularities and add a solid line of defense to system security.

Authorization process

Client process:

When the client constructs an RPC request, it constructs the interface input parameters for this call, and the interface corresponds to the operation definition behind the permissions.
The client sets the resource information for this visit in the interface input parameters, and then passes parameters such as user and resource to the server.

Server-side process:

After receiving the request, the server first checks whether authorization is turned on. If it is not turned on, it passes without verification; if it is turned on, it goes to the next step.
The server parses and assembles the authorization-related parameters in the request. These data include user information, accessed resources, operations performed, and the requested environment.
Query user related information in the local data storage through the user name. If the user does not exist, an error will be returned; if the user exists, go to the next step.
Determine whether the current user is a super user. If it is a super user, the request will be passed directly without authorization check. If it is an ordinary user, go to the next step for detailed authorization check.
Obtain the relevant authorization policy list based on the user name, match the resources, operations, and environment requested this time, and sort them according to priority.
Decisions are made based on the authorization policy with the highest priority. If the authorization policy allows the operation, authorization success will be returned. If the operation is denied, a no permission error will be returned.

Analysis of authorization parameters

In ACL 2.0, the parsing of authorization-related parameters (including resources, operations, etc.) is optimized based on the operation type and request frequency.

Hard coded analysis

For interfaces such as message sending and consumption, the parameters are relatively complex, and the request frequency is relatively high. Taking into account the convenience and performance requirements of parsing, hard-coding is used for parsing.

Annotation analysis

For a large number of management and control interfaces, the workload of hard coding is huge, and the frequency of calling these interfaces is low and the performance requirements are not high. Therefore, annotations are used for analysis to improve coding efficiency.

Permission policy priority

In terms of permission policy matching, because it supports fuzzy resource matching mode, the same resource may correspond to multiple permission policies. Therefore, a priority mechanism is needed to determine which set of permission policies is ultimately used.

Assume that the following authorization policy is configured, and the matching situation of the above priority resources is as follows:

Authentication and authorization strategy

Due to security and performance trade-offs and considerations, RocketMQ ACL 2.0 provides two strategies for authentication and authorization: stateless authentication and authorization strategy (Stateless) and stateful authentication and authorization strategy (Stateful).

无状态认证授权策略（Stateless）：在这种策略下，每个请求都会经过独立的认证和授权过程，不依赖于任何先前的会话和状态信息。这种严格的策略可以保证更高级别的安全保证。对权限进行变更，可以更加实时的反应在随后的请求中，无需任何等待。然而，这种策略在高吞吐的场景中可能会导致显著的性能负担，如增加系统 CPU 的使用率以及请求的耗时。

Stateful authentication and authorization strategy (Stateful) : Under this strategy, under the same client connection, the same resource and the same operation, the first request will be fully authenticated and authorized, and subsequent requests will not be repeatedly authenticated and authorized. Authorization. This method can effectively reduce performance and reduce request time, and is especially suitable for scenarios with high throughput. However, this strategy may introduce security compromises, and changes to permissions may not take effect in real time.

When choosing between these two strategies, the security requirements and performance requirements of the system need to be weighed. If the system has high security requirements and can tolerate a certain performance loss, then the stateless authentication and authorization strategy may be a better choice. On the contrary, if the system needs to handle a large number of concurrent requests and security requirements can be relaxed to a certain extent, then a stateful authentication and authorization strategy may be more suitable. During actual deployment, decisions should also be made based on specific business scenarios and security requirements.

Plug-in mechanism

In order to adapt to the continuous development of authentication methods in the future and meet users' customized needs for specific scenarios, RocketMQ ACL 2.0 provides flexibility and scalability in multiple aspects.

Extension of authentication and authorization policies : By default, RocketMQ ACL 2.0 provides stateless authentication and authorization policies (Stateless) and stateful authentication and authorization policies (Stateful) to meet the security and performance requirements of most users. However, better strategies can still be explored in the future to strike a balance between security and performance.

Expansion of authentication and authorization methods : Currently, in terms of authentication, there are many mature implementations on the market. RocketMQ currently only implements one of them. It is reserved through plug-in capabilities, and more can be easily introduced in the future. Authentication mechanism. In terms of authorization, RocketMQ implements a set of mainstream authorization methods based on the ABAC model to adapt to a wide range of user needs. But it also provides plug-in capabilities to facilitate the adaptation of more solutions that fit future development.

Orchestration of authentication and authorization processes : Based on the chain of responsibility design pattern, RocketMQ ACL 2.0 flexibly orchestrates its default authentication and authorization processes. Users can extend or rewrite these responsibility chain nodes to customize authentication and authorization logic for their specific business scenarios.

Extension of user and permission storage : RocketMQ uses RocksDB by default to store user and permission data locally on the Broker node. However, by implementing predefined interfaces, users can easily migrate this data to any third-party service or storage system, thereby optimizing their architectural design and operational efficiency.

Audit log

Audit logs are used to record and monitor all access control operations related to authentication and authorization. Through the upgrade log, we can track every access request to ensure the reliability and security of the system. At the same time, it also helps troubleshoot problems, perform safe upgrades, and meet compliance requirements.

RocketMQ ACL 2.0 supports audit logs related to authentication and authorization. The format is as follows:

Authentication log

# 认证成功日志
[AUTHENTICATION] User:rocketmq is authenticated success with Signature = eMX/+tH/7Bc0TObtDYMcK9Ls+gg=.

# 认证失败日志
[AUTHENTICATION] User:rocketmq is authenticated failed with Signature = eMX/+tH/7Bc0TObtDYMcK9Ls+xx=.

Authorization log

# 授权成功日志
[AUTHORIZATION] Subject = User:rocketmq is Allow Action = Pub from sourceIp = 192.168.0.2 on resource = Topic:TP-TEST for request = 10.

# 授权失败日志
[AUTHORIZATION] Subject = User:rocketmq is Deny Action = Sub from sourceIp = 192.168.0.2 on resource = Topic:GID-TEST for request = 10.

Configuration and use

Deployment architecture

In terms of deployment architecture, RocketMQ provides two deployment forms, namely storage and computing integrated architecture and storage and computing separated architecture.

Integrated storage and computing architecture

In the RocketMQ integrated storage and computing architecture, the Broker component assumes both computing and storage responsibilities, provides external services, and receives access requests from all clients. Therefore, the Broker component plays an important role in authentication and authorization. In addition, the Broker component is also responsible for the maintenance and storage of metadata related to authentication and authorization.

Storage and calculation separation architecture

In RocketMQ's storage and calculation separation architecture, the storage is handled by the Broker component, and the calculation is handled by the Proxy component. All external requests are served by the Proxy. Therefore, the authentication and authorization of requests are undertaken by the Proxy component. Broker is responsible for metadata storage and provides required authentication and authorization metadata query and management services for the Proxy component.

Cluster configuration

Authentication configuration

parameter list

If you want to enable the authentication function on the server side, the relevant parameters and use cases mainly include the following:

Broker configuration

authenticationEnabled = true
authenticationProvider = org.apache.rocketmq.auth.authentication.provider.DefaultAuthenticationProvider
initAuthenticationUser = {"username":"rocketmq","password":"12345678"}
innerClientAuthenticationCredentials = {"accessKey":"rocketmq","secretKey":"12345678"}
authenticationMetadataProvider = org.apache.rocketmq.auth.authentication.provider.LocalAuthenticationMetadataProvider

Proxy configuration

{
  "authenticationEnabled": true,
  "authenticationProvider": "org.apache.rocketmq.auth.authentication.provider.DefaultAuthenticationProvider",
  "authenticationMetadataProvider": "org.apache.rocketmq.proxy.auth.ProxyAuthenticationMetadataProvider",
  "innerClientAuthenticationCredentials": "{\"accessKey\":\"rocketmq\", \"secretKey\":\"12345678\"}"
}

Authorization configuration

parameter list

If you want to enable the authorization function on the server side, the relevant parameters and use cases mainly include the following:

Broker configuration

authorizationEnabled = true
authorizationProvider = org.apache.rocketmq.auth.authorization.provider.DefaultAuthorizationProvider
authorizationMetadataProvider = org.apache.rocketmq.auth.authorization.provider.LocalAuthorizationMetadataProvider

Proxy configuration

{
  "authorizationEnabled": true,
  "authorizationProvider": "org.apache.rocketmq.auth.authorization.provider.DefaultAuthorizationProvider",
  "authorizationMetadataProvider": "org.apache.rocketmq.proxy.auth.ProxyAuthorizationMetadataProvider"
}

how to use

Command line usage

User Management

Regarding the management of ACL users, the relevant interface definitions and use cases are as follows.

Interface definition

Use Cases

# 创建用户
sh mqadmin createUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p rocketmq
# 创建用户，指定用户类型
sh mqadmin createUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p rocketmq -t Super
# 更新用户
sh mqadmin updateUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq -p 12345678
# 删除用户
sh mqadmin deleteUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq
# 查询用户详情
sh mqadmin getUser -n 127.0.0.1:9876 -c DefaultCluster -u rocketmq
# 查询用户列表
sh mqadmin listUser -n 127.0.0.1:9876 -c DefaultCluster
# 查询用户列表，带过滤条件
sh mqadmin listUser -n 127.0.0.1:9876 -c DefaultCluster -f mq

ACL management

Regarding the management of ACL authorization, the relevant interface definitions and use cases are as follows.

Interface definition

Use Cases

# 创建授权
sh mqadmin createAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*,Group:* -a Pub,Sub -i 192.168.1.0/24 -d Allow
# 更新授权
sh mqadmin updateAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*,Group:* -a Pub,Sub -i 192.168.1.0/24 -d Deny
# 删除授权
sh mqadmin deleteAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq
# 删除授权，指定资源
sh mqadmin deleteAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*
# 查询授权列表
sh mqadmin listAcl -n 127.0.0.1:9876 -c DefaultCluster
# 查询授权列表，带过滤条件
sh mqadmin listAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq -r Topic:*
# 查询授权详情
sh mqadmin getAcl -n 127.0.0.1:9876 -c DefaultCluster -s User:rocketmq

Client use

Regarding the use of ACL, ACL 2.0 and ACL 1.0 are used in the same way without any difference. Please refer to the official case for details.

message sending

ClientServiceProvider provider = ClientServiceProvider.loadService();
StaticSessionCredentialsProvider sessionCredentialsProvider = 
  new StaticSessionCredentialsProvider(ACCESS_KEY, SECRET_KEY);
ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
    .setEndpoints(ENDPOINTS)
    .setCredentialProvider(sessionCredentialsProvider)
    .build();
Producer producer = provider.newProducerBuilder()
    .setClientConfiguration(clientConfiguration)
    .setTopics(TOPICS)
    .build();

Message consumption

ClientServiceProvider provider = ClientServiceProvider.loadService();
ClientConfiguration clientConfiguration = ClientConfiguration.newBuilder()
    .setEndpoints(ENDPOINTS)
    .setCredentialProvider(sessionCredentialsProvider)
    .build();
FilterExpression filterExpression = new FilterExpression(TAG, FilterExpressionType.TAG);
PushConsumer pushConsumer = provider.newPushConsumerBuilder()
    .setClientConfiguration(clientConfiguration)
    .setConsumerGroup(CONSUMER_GROUP)
    .setSubscriptionExpressions(Collections.singletonMap(TOPIC, filterExpression))
    .setMessageListener(messageView -> {
        return ConsumeResult.SUCCESS;
    })
    .build();

Expansion and migration

Expansion

If you want to expand a Broker while the cluster is running, you need to synchronize all metadata to the new Broker. ACL 2.0 provides corresponding copy user and copy authorization interfaces to support this operation.

Interface definition

Use Cases

# 拷贝用户
sh mqadmin copyUser -n 127.0.0.1:9876 -f 192.168.0.1:10911 -t 192.168.0.2:10911
# 拷贝授权
sh mqadmin copyAcl -n 127.0.0.1:9876 -f 192.168.0.1:10911 -t 192.168.0.2:10911

migrate

If you are already using ACL 1.0 and want to seamlessly migrate to ACL 2.0, corresponding solutions are also provided. You only need to make the following configurations.

Configuration definition

Enable the following configuration in the Broker's configuration file:

migrateAuthFromV1Enabled = true

Special Note

After enabling the above configuration, execution will be automatically triggered during Broker startup. This migration function will write the user permission information in ACL 1.0 into the corresponding storage structure of ACL 2.0.

Users and permissions that do not yet exist in ACL 2.0 will be added automatically by the system. The migration function will not overwrite existing users and permissions to avoid overwriting any modifications that have been made in ACL 2.0.

The IP whitelist in ACL 1.0 is used to bypass access control checks and does not match the behavior of ACL 2.0, so it will not be migrated to ACL 2.0. If you have already used the relevant capabilities, please complete the transformation before migrating.

Planning and Summary

planning

The future planning of RocketMQ ACL may be reflected in the following two aspects:

Rich authentication and authorization extensions : There are rich authentication and authorization solutions on the market, and other storage or computing products also adopt various implementation methods. In order to keep up with the development trends of the industry, RocketMQ ACL will also strive to innovate in the future to meet broader and changing customer needs. At the same time, we will continue to deepen research and develop better authentication and authorization strategies to achieve the ideal balance between security and performance.
Visual user permission operations : Currently, users and permissions can only be configured in ACL through command line tools, which is not user-friendly enough. In the future, we hope to provide a clear and easy-to-use visual management interface on RocketMQ Dashboard, thereby simplifying the configuration process and lowering the technical threshold for management. On the other hand, the existing Dashboard has not yet integrated the ACL access control system, which will also be incorporated in the future to provide users with access rights to operate various resources on the Dashboard.

Summarize

RocketMQ ACL 2.0 has undergone brand-new upgrades in terms of model design, scalability, security and performance. It is designed to provide users with refined access control while simplifying the permission configuration process. Everyone is welcome to try the new version and apply it in the production environment. We look forward to everyone's feedback, discussion, and participation in the community to jointly promote the growth and technological progress of the RocketMQ community. Welcome to join the Apache RocketMQ China Developers DingTalk Group. (Group number: 21982288)

Related Links:

[1] RocketMQ Chinese learning website ttps://rocketmq-learning.com

[2] Cloud message queue RocketMQ https://www.aliyun.com/product/rocketmq