1. What is idempotent?

In programming, an idempotent operation is characterized by any number of executions having the same effect as a single execution. An idempotent function, or idempotent method, is a function that can be executed repeatedly with the same parameters and achieve the same results. In layman’s terms: an operation that produces the same effect or returns the same result no matter how many times it is performed.

2. Which common services have idempotent problems?

In our business development process, if we deal with idempotent problem improperly, it will cause dirty data and even cause great loss. I have summarized common idempotent scenarios based on my own business contacts in recent years to share with you.

  • Form submission service
  • Third party payment/refund service
  • MQ related Services
  • Preemption service

3. Specific solutions

3.1 Form submission classes

Form submission business types include form entity submission of client interface, modify button and other design to increase the function of modifying data. This business type requires idempotent processing by both the front and back end developers.

  • The button is grayed out without new edits and cannot be clicked repeatedly
  • Request timer limit
  • Traffic limiting on the back-end interface
  • Database UK (unique index) restriction
  • Token Token, obtain the Token to operate the actual business, otherwise return

3.2 Order payment

The idempotent handling of payment related services is very important, such as repeated orders, callbacks of three-party interfaces, which can cause idempotent problems.

  • Order generation uses the global unique ID scheme, and then combines the database unique index to ensure the uniqueness of the order, and all subsequent businesses need this order number for logical processing.
  • Wechat/Alipay callback may lead to idempotent problems due to network reasons, so we can use the business order number combined with Redis or combined with the transaction order number returned by the three parties for reprocessing, and the processed ones will not be processed again.
  • Concurrency consumption problems are extremely unlikely to occur due to network reasons, and synchronous lock control can be used in the callback logic.
  • Some services can also use version numbers.

3.2MQ message idempotent classes

MQ as asynchronous decoupling middleware is often used in our business development, for example to handle asynchronous logic. But producers and consumers of MQ also have idempotent problems, namely repeated messages, repeated consumption, and so on.

  • To prevent repeated messages, the foregoing reprocessing can be used, or the synchronous sending scheme can be used in combination with actual services to avoid repeated messages and message loss.
  • To prevent repeated consumption, a validation mechanism can be used to determine the consumption status of a message based on its unique identifier, such as an order number.

3.3 take class

The idempotent problem of concurrent scenarios is very easy to occur, and the idempotent processing of such scenarios is also different, because efficiency and consistency should be taken into account. If the requirement of data consistency is not too high, the business scenarios can use the duplicate processing. If the data consistency requirement is very strict, locking mechanism can be adopted, such as optimistic locking and pessimistic locking processing scheme and combined with conventional weight testing method. In a distributed cluster environment, you need to use distributed locks.