Producers - ApsaraMQ for RocketMQ - Alibaba Cloud Documentation Center

This topic describes the concept of producers in ApsaraMQ for RocketMQ. It also describes the role of producers in the messaging model, producer attributes and compatibility, and some usage notes of working with producers.

Definition

A producer in ApsaraMQ for RocketMQ is a functional messaging entity that creates messages and sends them to the server.

A producer is typically integrated on the business system and serves to encapsulate data as messages in ApsaraMQ for RocketMQ and send the messages to the server. For more information about messages, see Messages.

The following message delivery elements are defined on the producer side:

Transmission mode: A producer can specify the message transmission mode in an API operation. ApsaraMQ for RocketMQ supports synchronous transmission and asynchronous transmission. For more information, see Models.
Transactional behavior: ApsaraMQ for RocketMQ supports transactional messages. Producers are involved in transactional checks to ensure eventual consistency of transactions. For more information, see Transactional messages.

Producers and topics have a many-to-many relationship. A producer can send messages to multiple topics, and a topic can receive messages from multiple producers. This many-to-many relationship facilitates performance scaling and disaster recovery.

Producers and topics

Model relationship

The following figure shows the role of producers in the messaging model of ApsaraMQ for RocketMQ.

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: the identity of a producer client. This attribute is used to distinguish between different producers. A client ID is globally unique within a cluster.
Value: The client ID is automatically generated by ApsaraMQ for RocketMQ SDKs. It is mainly used for O&M purposes such as log viewing and problem locating. The client ID cannot be modified.

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 Limits on parameters.

Prebound topic list

Definition: the list of topics to which a producer of ApsaraMQ for RocketMQ sends messages. Prebound topics provide the following benefits:
- Transactional messages: The prebound topic list attribute must be specified for transactional messages. In transactional messaging scenarios, when a producer recovers from a fault or is restarted, the producer checks whether a transactional message topic contains uncommitted transactional messages. This prevents latency caused by uncommitted transactional messages in the topic after the producer sends new messages to the topic.
- Non-transactional messages : The server checks the access permissions and validity of the destination topics based on the list of prebound topics during producer initialization, instead of performing the check after the application is started. We recommend that you specify the prebound topic list attribute for non-transactional messages.
  If the prebound topic list attribute is not specified for non-transactional messages or destination topics are changed, ApsaraMQ for RocketMQ dynamically checks and identifies destination topics.
Limit: For transactional messages, prebound topics must be specified and used together with a transaction checker.

Transaction checker

ApsaraMQ for RocketMQ uses a transactional messaging mechanism that requires a producer to implement a transaction checker to ensure eventual consistency of transactions. For more information, see Transactional messages.
When a producer sends transactional messages, a transaction checker must be configured and used together with prebound topics.

A delivery retry policy specifies how a producer retries the delivery of messages upon a failed message delivery attempt. For more information, see Message sending retry.

Compatibility

Starting from ApsaraMQ for RocketMQ version 5.x, producers are anonymous, and producer groups are discontinued. For Message Queue for Apache RocketMQ version 3.x and version 4.x, existing producer groups can be discontinued, without affecting your business.

Usage notes

We recommend that you limit the number of producers on individual processes.

In ApsaraMQ for RocketMQ, producers and topics provide a many-to-many form of communication. A single producer can send messages to multiple topics. We recommend that you create and initialize the minimum number of producers that your business scenarios require, and reuse as many producers as you can. For example, in a scenario that requires message delivery to multiple topics, you do not need to create a producer for each topic.

We recommend that you do not create and destroy producers on a regular basis.

The producers of ApsaraMQ for RocketMQ are underlying resources that can be reused, like the connection pool of a database. You do not need to create producers each time you send messages or destroy the producers after you send messages. If you regularly create and destroy producers, a large number of short connection requests are generated on the broker. This imposes a high level of load on your system.

Example of correct usage

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

Example of incorrect usage

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