Improve consumer message sequence and idempotence

[yang-xiaodong]

In subscribe method, CAP needs to add these two features.

[ah-its-andy]

Can you describe simply the solution you are working with to improve idempotence?

[yang-xiaodong]

@standardcore
In version 2.0, I have wapped the message content with Message class, Message object provider a Id property used to be guarantee message sequence, in consumer method we can check the Id whether it has been processed or not.

[yang-xiaodong]

This feature will be given to the user to ensure.

[yang-xiaodong]

CAP does not implement idempotent for several reasons: The following are the receiving end

• 1. The message was successfully written, but the execution of the Consumer method failed.

There are many reasons why the Consumer method fails. I don't know if the specific scene is blindly retrying or not retrying is an incorrect choice.
For example: If the consumer is the debit service, if the execution of the deduction is successful, but the failure to write the debit log, the CAP will judge the consumer execution failure, and try again. If the client does not guarantee idempotency, the framework will retry it, which will inevitably lead to serious consequences for multiple deductions.

• 2. the implementation of the Consumer method succeeded, but received the same message

The scenario here is also possible. If the Consumer has been successfully executed at the beginning, but for some reason, such as the Broker recovery, and received the same message, the CAP will consider this a new after receiving the Broker message. The message will be executed again by the Consumer. Because it is a new message, the CAP cannot be idempotent at this time.

• 3. the current data storage mode can not be idempotent

Since the table of the CAP message is deleted after 1 hour for the successfully consumed message, if the historical message cannot be idempotent. Historically, it means that if the broker has maintained or manually processed some messages for some reason.

• 4. Industry practices

Many event-driven frameworks require users to ensure idempotent operations, such as ENode, RocketMQ, etc...

From an implementation point of view, CAP can do some less stringent idempotence, but strict idempotent cannot.