[Enhancement] Optimization of Prioritizing Original Sender in Transactional Message Checkbacks

[CLFutureX]

Before Creating the Enhancement Request

• I have confirmed that this should be classified as an enhancement rather than a bug/feature.

Summary

In the current transactional message mechanism, after the sender proactively checks the transaction status once and receives an "unknown" result, subsequent status checks are initiated by the broker. The broker selects an available connection from the same producer group to perform the check, using a round-robin strategy that prioritizes active and available connections.

Motivation

When selecting a connection, priority should be given to the original sender’s connection. This approach offers the following advantages:

Local State Validation: The transaction status can be directly determined from the sender’s local cache during the check, avoiding the need to query distributed caches or databases.
Example: The localTrans collection in org.apache.rocketmq.example.transaction.TransactionListenerImpl demonstrates this optimization.
Reduced Overhead: Minimizes network and I/O costs associated with distributed state queries.

Describe the Solution You'd Like

The expectation is that when the broker checks the transactional message, it can know which producer sent the message and give priority to calling back the original producer of the message.

Therefore, the entire modification involves three steps:

1. Message marking and passing: Use the clientId as the message identifier and record it in the extended field when the producer sends the message.

2. Mark acquisition: When the broker checks the transactional message, extract the sender's mark from the extended field.

3. Connection selection: When selecting a connection, adjust the connection selection strategy: prioritize the original-sender & writable & active > writable & active > original-sender & active > active.

Describe Alternatives You've Considered

1

Additional Context

1

[yx9o]

Hi, the Message marking and passing mentioned here is only for transaction messages or all messages.

[CLFutureX]

Hi, the Message marking and passing mentioned here is only for transaction messages or all messages.

It is only for transaction messages, because it mainly targets the scenario of the transaction message callback client.

[CLFutureX]

@RongtongJin @lizhimins hey，please take a view