What is Idempotence
HTTP / 1.1 is defined to be idempotent are: primary and multiple requests for a resource a resource itself should have the same result (except for the network timeout issues). In other words, any of its multiple executions were carried out with the same impact once the impact of the resource itself produced right.
We should focus on a few points:
idempotency not just one (or more) requests no adverse effects on resources (such as querying a database operation, no additions and deletions, and therefore does not have any impact on the database).
Idempotent the first time also includes a request for resources to produce side effects, but many subsequent requests will not produce adverse effects on resources.
Idempotent concern is whether the side effects after repeated requests for resources generated, rather than focusing on results.
Network timeouts and other issues, not idempotent discussion.
Idempotence is a system service outside a commitment (and not achieve), as long as the commitment to a successful call interface, multiple calls to external impact on the system is consistent. Declared idempotent service call fails think outside the norm, and there must be retried after a failure.
Need Idempotence under what circumstances
Business development, often encounter the case of duplicate submission, either because of network problems can not receive the results of the request to re-initiate the request, or the operation of the front end jitter caused by repeated submission. In the trading system, payment system which has caused repeated submit questions particularly evident, for example:
The user clicks on a number of consecutive APP submitting an order, the background should produce only one order;
Initiate a payment request to the payment of treasure, due to network problems or system BUG retransmission, Alipay should only be deducted once the money. Obviously, a statement of power and other services believe that the presence of an external caller will be called multiple times, in order to prevent the occurrence of multiple calls to external data system state changed many times, the service is designed to power and so on.
Idempotent and anti-replay discrimination
The above examples of problems encountered by small and medium-out, but the case of duplicate submission, and service idempotent original intention is different. Filed in the case of repeating the first request has been successful, human multiple operations, resulting in power does not satisfy the requirements of multiple services change state. The power situation, and more are using the first request does not know the results (such as time-out) or in exceptional cases of failure to initiate multiple requests, the purpose of the request was successful many times confirmed for the first time, but not because of multiple requests the change of state occurs several times.
The need to ensure Idempotence under what circumstances
To SQL, for example, there are three scenarios below, only the third scenario requires developers to use other strategies to ensure idempotency:
SELECT col1 FROM tab1 WHER col2 = 2, no matter how many times will not change the execution state, is a natural idempotent.
UPDATE tab1 SET col1 = 1 WHERE col2 = 2, no matter how many times the successful implementation of the state are the same, and therefore power and other operations.
UPDATE tab1 SET col1 = col1 + 1 WHERE col2 = 2, the results of each execution will change, this is not idempotent.
Why idempotency design services
Idempotent so that the client can handle simple logic, but at the expense of service logic is complicated. Idempotent services to meet the needs to contain at least two points in the logic:
First, go to a query on the implementation of the state, if not then considered to be the first request
Before changing the status of the service business logic to ensure that anti-logic duplicate submission
Idempotent inadequate
Idempotent to simplify the client logic, the logic and has increased the cost of the service provider, if necessary, the specific need for the scene analysis, so in addition to the special operational requirements, as far as possible not to provide an interface idempotent.
Adds additional control idempotent business logic, complicated business functions;
The serial to parallel execution of the functions performed, the efficiency is reduced.
Ensure idempotent strategy
Idempotent need to ensure that only business by a single number. That same single business number that is with a business. Using this unique number to ensure that business units, and performs the processing logic behind the same effects of multiple single number service is consistent. Below to cover, for example, in the case without considering the concurrent realization idempotent is simple: ① first check to see if the order has already been paid, ② if you have paid off, then return to the successful payment; if not paid, payment procedures, modifications order status to 'paid'.
Strategies to prevent duplicate submission
To ensure the above-described embodiment is idempotent two steps, the first step ② ① dependent step of the query result, can not guarantee atomicity. The following will appear in the case of high concurrency: Second request comes in the case of the first request step ② order status has not changed to 'paid status' of. Since it came to this conclusion, the remaining problems will be simple: to query and change the lock status of the operation, will operate in parallel instead of serial operation.
Optimistic locking
If only update existing data, it is not necessary to conduct business lock, use optimistic locking design table structure, usually done by version optimistic locking, so can guarantee the efficiency of the implementation, but also ensures that power and so on. For example: UPDATE tab1 SET col1 = 1, version = version + 1 WHERE version = # version # However, the presence of optimistic locking failure is often said that the ABA problem, but if the version is the version has been growing since it will not appear ABA Case. If the version is not a version increment, we can add a timestamp to ensure timestamp field will not be updated, you can verify the consistency of the time stamp. You may think so. Suppose we have two threads, the first thread to get the version, the second thread also taken to the version. Then the first thread updated version at the same time to carry out operations increased, even if this second thread to perform the update, it will not operate to, because the version has changed.
Anti-heavy table
Use orderNo order number as a unique index to the table weight, is inserted into a data table according to the weight of the order number for each request. The first payment request to query the order status, order of course not paid, payment operations, whether successful or not, after the implementation of the update order status is success or failure, delete data de-duplication table. Because the subsequent orders inserted a unique index table fails, it returns the operation fails, the request completion (success or failure) of the first up. As can be seen the heavy anti-lock function is a function table.
By way of a unique index, for, when the same data, only the index table to the insertion of the error is reported.
Example:
create a test table
CREATE TABLE `test03` (
`id` INT(11) ,
`uid` INT(11) DEFAULT NULL);Create a unique index
ALTER IGNORE TABLE test03 ADD UNIQUE INDEX id_uid(id,uid);Inserting data again, we found that the same data can not be inserted
INSERT INTO test03(id,uid) VALUES (1,1),(1,2),(1,1),(1,2),(1,1);In fact, this way and redis way below the almost formal, and faster way below.
Distributed Lock
Anti-weight table used herein may be used in place of distributed lock, such as Redis. Orders initiate a payment request, the payment Key cache system will check whether the existence of the order number to Redis, if not present, the order number to increase as the Key Redis. Check your order payment has been paid, if not then pay for it, delete Key the order number after complete the payment. Redis done by a distributed lock, only this Order Order payment request is completed, the next request to come in. Compared to the heavy table, put concurrent done cache more efficient. The same ideas, the same time can only be completed once the payment request.
token token
This mode is divided into two phases: phase and the application token payment phase. The first phase, to be submitted prior to entering the order page, you need to initiate orders based on user information system to apply for a token payment system request token payment system will save the Redis cache, pay for the second stage. The second stage, took the order system to apply to the token payment request is initiated, the presence of the token payment system will check Redis, if present, represents the first payment request is initiated, delete the cache after the token start paying logic processing; if the cache It does not exist, indicate illegal request. In fact here is a token keepsake, payment system based on token confirm that you are your mother's child. Lack of interaction is needed between the two systems, processes complex than described above.
Pay Buffer
The payment request orders are quickly followed, then a quick single buffer pipeline. Subsequent use of the data processing pipeline in the asynchronous task to filter out payment orders to be repeated. The advantage is synchronous asynchronous transfer, high throughput. Is insufficient to pay can not return results in a timely manner, we need to monitor the follow-up results are returned asynchronously to pay.
RestfulApi Idempotence Detailed
We should pay attention to idempotent is resource-oriented. The HTTP GET method may return each time to get different content, but does not affect resources.
GET method
HTTP GET method for access to resources, no matter how many times interface calls, the results will not change, it is idempotent. Just query data, change will not affect the resources, so we think it idempotent.
POST method
HTTP POST method is a non-idempotent method, because multiple calls, will have a new resource. Because it would affect the resource itself, each call will have a new resource to produce, and therefore does not meet the idempotency.
PUT method
Because it directly replace a substantial portion of the data to the server resources, many times we call it, it will only have a impact, but have the same result as the HTTP method, which satisfies the idempotency.
Delete method
HTTP DELETE method to delete the resource, the resource will be deleted. Called once and repeatedly affect the same resources, is also satisfied idempotent.
So for restful, only the post is not satisfied.