Interface idempotency solutions

In programming, the operation is idempotent characteristics affecting any are repeatedly produced with the same execution time impact. Idempotent function refers to a function that the same results can be obtained using the same parameters are repeatedly performed. These functions do not affect the system status, do not worry Repeat will cause the system to change. For example getIdCard () function and setTrue () function is idempotent functions.

Idempotent in my understanding there is an operation to be performed regardless of how many times, and the effect of the returned results are the same.

A typical operation of such a power as: the number of record 5 A field set to 0. This operation is performed regardless of how many times are idempotent.

Typically a non-idempotent operations such as: the number of record 5 A field of this operation is obviously an increase is not idempotent.

Idempotent program

1. query: Select is a natural idempotent operations.

Queried once and query times, in the case of the same data, the results of the query are the same.

2. Delete: Delete operation is idempotent, delete one and delete all the data several times removed.

Since the action is generally directed, such as to delete data id, if the id exists in the database the corresponding record, the record is deleted; if the id does not exist in the database, the corresponding record, deleting is performed by the recording operation, but no delete substantially to record it, but there will not be other side effects.

But if the delete operation has a return value, the result may return will be different, such as a return value of this record after deleting a record, if you delete the data does not exist (already deleted the first time the request is deleted a), the value returned is empty.

3. unique index: dirty data can be effectively prevented by establishing a new unique index on a field in a database table.

For example, there is a special order form, this special order form is associated with a user table, the business is set up for each user can create a special order, which means in this special order table can have a record associated with the user. So this time we can make a unique index for the user associated with this particular field on the order form, to special order to limit the number of records in the table associated with a user's unique constraint is inserted through the database. Thus, when the second request to insert a particular user associated with the orders table recorded in a special order, and the database will be rolled back insert being given, it ensures idempotent.

4.Token checking mechanism: before the operation to check Token, in order to prevent duplicate submission page.

Is achieved by Session Token on principle, of course, can be achieved by Redis. When a client requests a page, the server will become a Mr globally unique Token, then placed into the Session Token or Redis which then sends the Token to the client (typically configured by Hidden form or in the browser cache). And so the next time a client submits a request, Token will be submitted along with the form to the server. When the authentication by the first server, they will be the Session Token value update or delete, when the user resubmit, judgment is the second verification failure, the requested operation will not be repeated. This is because the form submitted by the user in the Token has not changed, but the server side of the Session Token has changed or does not exist.

5. pessimistic lock: lock when acquiring data acquisition.

select * from yanggb where id = 'huangq' for update;

Generally used when using pessimistic locking with accompanying transactional data lock time can be very long, the need to use the actual situation.

Also note that, id field must be the primary key or unique index, otherwise the result may cause the lock table to deal with them will be very troublesome.

6. optimistic lock: do update version number or other restrictions by state field.

Unlike pessimistic locking lock table for a long time, but in the optimistic locking lock table update data that moment, other times not lock table. So optimistic pessimistic locking lock, in most scenarios efficiency will be higher. Optimistic locking achieve a variety of ways, by version or other status conditions.

id	name	age	version
1	yanggb	18	1

Such as adding a version number to the field in the business table, before a call if you want to update the interface of age, you need to check his version number, then call interface time to bring the version number.

Distributed ensure the interface in the interface in idempotency (added in the updated version of the SQL conditional):

update user set age = 21, version = version + 1 where id = 1 and version = 1;

In this way, multiple submissions of the request, because the version number (version) are the same, because after a successful version has a +1, then subsequent requests since version do not correspond, will not be executed for the first time requested to perform.

7. Distributed Lock: Token check at another angle.

In a distributed system, then build a globally unique index would be more difficult, such as the uniqueness of the field there is no way to determine. This time can introduce a distributed lock, insert data in business systems through third-party systems (Redis or Zookeeper) before or update data, you need to obtain a distributed lock before you can do the operation, after the operation is completed to release the lock. In fact, this is the single multi-threaded system which locks the idea of introducing a system of multiple scenes, the idea is to solve the distributed system.

Important: a long flow processing requirements can not be performed concurrently, may be (user ID + suffixes) distributed lock acquired before the process performed according to a flag, acquires the lock will fail when the execution of other processes, i.e. the same time only the flow able to have a successful execution, execution is completed, release distributed lock (third-party systems to provide a distributed lock).

8.select + insert: a simple but stupid way.

For some concurrency is not high back-end systems, or some task JOB, in order to support power, and support for the implementation repeat, a simple approach that can be taken is to first query records to the table, according to some key data in order to determine whether executed, business processes and then judge it.

It should be noted that the core high concurrent processes do not use this method because you want to query over data (think about why you would want to put the data in Redis), too low performance.

9. idempotent state machine: optimistic locking another angle.

In the design of the documents related to business or business-related tasks, it will certainly involve state machine (state change diagram). Simple to understand, is to have a state of the field of business documents above, the status change will occur under different circumstances, there is a finite state machine in general. At this time, if the state machine is already in the next state, this time to a previous state of change, in theory, can not be changed, so, ensure that the power of finite state machines and so on. Note: The class of business documents such as orders, there is a long state of circulation, we must deeply understand the state machine, system design capabilities to improve the business of great help.

to sum up

The concept of power and other distributed, highly concurrent or JavaEE concepts are not related, that affect only care about whether the operation is performed repeatedly produced with the first performance is consistent.

In fact, to do idempotency, as long as starting from the design interface and is not designed any non-idempotent operation can be. There is a demand for instance, when the user clicks agree, the number of +1 endorse the answer. Chan directly modify the user point table (answer id, Points of praise) point number (+1) praise is obviously not idempotent. This scenario can be changed: When the user clicks agree, thumbs up to the user table (answer id, user id) add a record, and then to ensure that there is only endorse the answer table by creating a unique index on the user id field a record of a user point of praise, the final amount agreed by the answer to the statistics agreed with table by count out. Of course, the actual design of the system would not be so, but here I did not think of a better example. It sounds simple, but doing it really hard, ha ha ha.

In short Idempotence should be a qualified programmer of a gene, in the design of the system, is the primary consideration, especially as the money to pay all the money involved in the treasure system, Internet banking or financial companies, both efficient and also to ensure that the data is accurate, can not appear more than chargeback, and more play money and other issues, it will difficult to handle, the user experience is not good.