Java – can I schedule messages using a custom algorithm instead of using rabbit MQ for looping?

I am using the looping function of rabbitmq to send messages among multiple consumers, but I can only receive one message at a time

My problem is that my message represents a task. I want to have a local session on my consumer I know which messages belong to which session in advance, but I don't know what is the best method (or what method?) to use the algorithm I specify to make rabbitmq send to consumers

I don't want to write my own choreography service because it will become a bottleneck. I don't want my producers to know which consumers will receive their news, because I will lose the ability to use rabbits

Is there a way for rabbit MQ to send messages to consumers based on predefined algorithms / rules instead of looping?

Clarification: I have written several microservers in different languages, and each service has its own work We use protobuf messages to communicate with each other I give each new message a UUID If the consumer receives a message, it can create a response message from it (this may not be the correct term because the producer and consumer are decoupled and they don't know each other), and the UUID is copied to the new message This forms a data conversion pipeline, and the "process" is identified by UUID (ProcessId) My problem is that it is possible that I have multiple working consumers. If I saw it before, I need a worker to adhere to a UUID I need it because

>Each process may have a local status > after the process is completed, I want to clean up the local status > the microserver may receive multiple messages from the same process. I need to distinguish which message belongs to which process

Because rabbitmq distributes tasks among workers who use loops, I can't force my process to work I have several considerations:

Producers are decoupled from consumers, so direct information is not a choice > the number of workers is not constant (a load balancer may start a new instance of work)

If there is a solution that does not involve changing the loop algorithm and does not break my constraints, it is also possible!

Solution

If you don't want to choreograph the business, you can try this topology:

For simplicity, I assume that your ProcessId is used as the routing key (in the real world, you might want to store it in the header and use header exchange)

Incoming messages will be accepted by the received exchange (type: direct), where the alternative exchange property is set to point to no session exchange (fan out)

This is what the rabbitmq document says in "substitution transaction":

(we are particularly interested in the use cases here)

Each consumer will create its own queue and bind it to the incoming exchange, using the ProcessId of the session known so far as the bound routing key

In this way, it will only receive messages from interested sessions

In addition, all consumers will be bound to a shared sessionless queue

If a message with a previously unknown ProcessId comes in, it will not register a specific binding with incoming exchange, so it will be rerouted to no session exchange = > no session queue and sent to one of the consumers in the usual (circular) manner

The consumer will then register a new binding for it using the incoming exchange (i.e. start a new "session") so that all subsequent messages will then be obtained using this ProcessId

Once the session ends, it will have to delete the corresponding binding (that is, close the session)