Producers-ApsaraMQ for RocketMQ(RocketMQ)-阿里云帮助中心

This topic describes producers in ApsaraMQ for RocketMQ. It covers their definition, role in the messaging model, internal attributes, version compatibility, and usage recommendations.

Definition

A producer is a runtime entity in ApsaraMQ for RocketMQ that builds and sends messages to the server.

Producers are typically integrated into business systems. They package business data into ApsaraMQ for RocketMQ messages and send them to the server.

A producer defines the following delivery behaviors:

Transmission mode: A producer can set the message transmission mode using an API operation. ApsaraMQ for RocketMQ supports synchronous and asynchronous transmission. For more information, see Message transmission modes.
Transactional behavior: ApsaraMQ for RocketMQ supports transactional messages. For these messages, the producer must perform transaction checks to ensure eventual consistency. For more information, see Transactional messages.

Producers and topics have a many-to-many relationship. A single producer can send messages to multiple topics. Therefore, in platform-based scenarios, you do not need to create a producer for each topic. A single topic can also receive messages from multiple producers. This design allows for horizontal scaling and disaster recovery for producers.

生产者主题关联

Model relationship

The following figure and steps illustrate the role and data flow of a producer in the ApsaraMQ for RocketMQ domain model: 生产者

Producers produce and send messages to the ApsaraMQ for RocketMQ broker.
The ApsaraMQ for RocketMQ broker stores the messages in the queue that is specified by the topic in the order in which the messages are received.
Consumers obtain and consume messages from the ApsaraMQ for RocketMQ broker based on the specified subscriptions.

Internal attributes

Client ID

Definition: A unique identifier for a producer client that distinguishes it from other producers. A client ID is globally unique within a cluster.
Value: The client ID is automatically generated by the ApsaraMQ for RocketMQ software development kit (SDK). It is used for operations and maintenance (O&M) tasks, such as viewing logs and locating issues. You cannot change the client ID.

Communication parameters

Endpoint (required): the address that is used by a client to access the ApsaraMQ forRocketMQ broker. The endpoint is used to identify the cluster on the broker.
You must configure an endpoint in the specified format. We recommend that you use a domain name instead of an IP address to prevent hotspots from failing to be migrated during node changes.
Identity authentication (optional): the credentials that are used to verify the identity of the client.
This parameter is required only when the identity authentication feature is enabled on the broker.
Request timeout period (optional): the timeout period for client requests. For information about the valid values of the request timeout period parameter, see Parameter limits.

Prebound topic list

Definition: The list of destination topics to which an ApsaraMQ for RocketMQ producer sends messages. This list serves the following main purposes:
- Transactional messages (Required): In transactional message scenarios, when a producer recovers from a fault or restart, it must check the topics of transactional messages for uncommitted transactions. This prevents business delays caused by old, uncommitted transactional messages.
- Non-transactional messages (Recommended): During producer initialization, the server checks the access permissions and validity of the destination topics based on the prebound topic list. This check occurs before the application starts.
  If this list is not set, or if the destination topics for subsequent messages change dynamically, ApsaraMQ for RocketMQ performs a dynamic check on the destination topics.
Constraint: For transactional messages, you must set the prebound topic list and provide a transaction checker.

Transaction checker

Definition: In the transactional message mechanism of ApsaraMQ for RocketMQ, a producer must implement the transaction checker interface. This ensures eventual consistency for transactions in abnormal scenarios. For more information, see Transactional messages.
When you send transactional messages, you must configure the transaction checker along with the prebound topic list.

Send retry policyDefinition: The retry policy for a producer when a message fails to be sent. For more information, see Message sending retry mechanism.

Version compatibility

Starting from ApsaraMQ for RocketMQ V5.x, producers are anonymous. You do not need to manage producer groups. For server-side versions 3.x and 4.x, you can discard existing producer groups without affecting your business.

Usage recommendations

Do not create many producers in a single process

In ApsaraMQ for RocketMQ, producers and topics have a many-to-many relationship. A single producer can send messages to multiple topics. Therefore, you should reuse producers as much as possible and avoid creating a separate producer for each topic.

Do not create and destroy producers frequently

A producer in ApsaraMQ for RocketMQ is a reusable underlying resource, similar to a database connection pool. Do not create a producer each time you send a message and then destroy it afterward. This practice generates many short-lived connection requests on the server and severely affects system performance.

Correct example

Producer p = ProducerBuilder.build();
  for (int i =0;i<n;i++)
    {
      Message m= MessageBuilder.build();
      p.send(m);
    }
p.shutdown();

Incorrect example

for (int i =0;i<n;i++)
  {
    Producer p = ProducerBuilder.build();
    Message m= MessageBuilder.build();
    p.send(m);
    p.shutdown();
  }