The use of idempotent and high concurrency in e-commerce system

In the Java Web project development, often hear in order system generation orders, to do idempotent control and concurrency control, special to this part of the content to summarize, in the high concurrency scenario, the code level needs to implement concurrency control; but idempotent, in fact, is more of a system interface to the external commitment, Committing a single request and multiple requests will return the same data. Idempotent will be expounded from idempotent in higher algebra, idempotent in HTTP and idempotent in order generation system, and concurrency control provides distributed locks and other methods to implement code for concurrent scenarios.

First, idempotent idempotence [' A?d?mpo?t?ns]

1. Interpretation of the concept of idempotent idempotence in advanced algebra:

Monocular operation, X is any number within a set, if f (x) =f (f (x)) is satisfied, then we call the F operation to be idempotent (idempotent). For example, in a real number, an absolute value operation is an example: ABS (a) =abs (ABS (a)).

binocular operation, X is an arbitrary number in a set, F is the operator if it satisfies f (x,x) =x, the premise of the F operation is that all two parameters are the same as x, then we also call the F operation to be idempotent. For example, in a real number, a function that asks for the maximum value of two numbers: Max (x,x) = X, and Boolean algebra, the logical operation "and", "or" are also idempotent operations, as they conform to and (0,0) = 0, and (1), or (0,0) = 0, OR (= 1).

in the application of idempotent to software development, some deeper understanding is needed, and I understand the following: Mathematics deals with arithmetic and numerical values, and in the process of program development, objects and functions are often handled. But we can't simply understand that arithmetic is a function in a mathematical power, and a value is an object. If the person object has two attributes weight and age, all function can only operate on one of these properties. So from this level we can understand that the function is only idempotent to an attribute of the object that the function operates on, rather than to an entire object that has an operational power.

Person {Private intweight; Private intAge ; //is a power-equal function     Public voidSetage (intv) {          This. Age =v; }    //not idempotent functions     Public voidIncreaseage () { This. age++; }     //is a power-equal function     Public voidSetweight (intv) {          This. weight=v+10;//intentionally add 10 catty!!    }}

It is also important to clarify that the concepts expressed by idempotent are concerned with mathematical calculations and numerical values, and do not mention the security of the numerical values. as above the person's setage function, there are two kinds of case is not idempotent concern, but the program development but must be concerned about:

• Two threads simultaneous invocation of
• Because age is impossible to decrement from business, if the previous call setting is 30 years old, the latter call becomes 10 years old or more outrageous-1 years old

Idempotent is the system's interface to the external commitment (rather than implementation), the commitment as long as the invocation of the interface succeeds, the external multiple calls to the system's impact is consistent . An interface declared as Idempotent will assume that an external call failure is the norm, and that there must be retries after the failure. so the restful design measures idempotent and security as two different indicators to measure post,put,get,delete operations. Therefore, post is not idempotent, put get delete is idempotent, that is, in the POST request to generate orders, we want to do idempotent control. If an AJAX request is an example of a POST request, if the POST request is called multiple times, it inserts multiple records into the table, it is obvious that the POST request is not idempotent, so the idempotent control is controlled by our program.

Idempotent in 2.HTTP protocol

The popularity of SOA and restful API interfaces in the project requires the support of the Application Layer HTTP protocol, the current project structure: Web API + RIA (Rich Internet applications), Web API focused on delivering business services, RIA focuses on user interface and interaction design, and the division of labor in two areas is more clear. just as the simple Java language does not imply high-quality Java programs, the simple HTTP protocol does not imply high-quality web APIs. To design a high-quality web API, you need to understand the characteristics of distributed systems and HTTP protocols in depth . The idempotent is defined in the HTTP1.1 specification.

 for a single request.

From the definition point of view, the power of the HTTP method means that one and more requests for a resource should have the same effect. Idempotent is a very important concept in the design of distributed system, and the distributed nature of HTTP also determines its important position in HTTP. For example, there is a business logic that assumes that there is a remote API (which can be HTTP or not) that takes money from the account, and we temporarily define the interface:

BOOL Withdraw (account_id, amount)

The semantics of the withdraw is to deduct amount amount from the account_id account, and if the deduction succeeds returns true, the account balance is reduced amount, and if the deduction fails, the account balance is not changed. It is worth noting that, compared with the local environment, we cannot easily assume the reliability of the distributed environment . A typical case is that the withdraw request has been properly handled by the server, but the server side's return result has been discarded due to the network and other reasons, causing the client to be unable to know the processing result. If it is on the Web page, some inappropriate design may make the user think that the last operation failed, and then refresh the page, which led to the withdraw was called two times, the account was also deducted one more money. As shown in the following:

The solution to this problem is to use distributed transactions to ensure transactional withdraw functionality by introducing middleware that supports distributed transactions . The advantage of distributed transactions is that the caller is simple and the complexity is given to the middleware to manage. The disadvantage is that the architecture is too heavyweight, easy to be tied to a particular middleware, not conducive to the integration of heterogeneous systems; On the other hand, distributed transactions, while guaranteeing the acid nature of transactions, do not provide the assurance of performance and availability.

Another, more lightweight solution is idempotent design. We can turn withdraw into idempotent by some techniques, such as:

int create_ticket () bool Idempotent_withdraw (ticket_id, account_id, amount)

The semantics of the create_ticket is to obtain a server-side generated unique token of processing number, which will be used to identify subsequent operations. The difference between Idempotent_withdraw and withdraw is that a token is associated, and a token represents an operation that is processed at most once, and each call returns the result of the first invocation. In this way, the Idempotent_withdraw is idempotent, and the client can safely call it multiple times. that is, multiple clicks on the submission, with the submission of the service side generated tokens, due to multiple submissions with the same token, so the service side for the same token of the post orders, at most will only be processed once, so the indirect implementation of idempotent control .

A complete money-fetching process in a power-based solution is decomposed into two steps: 1. Call Create_ticket () to get token;2. Call Idempotent_withdraw (token, account_id, amount). Although Create_ticket is not idempotent, but in this design, its impact on the state of the system can be ignored, plus Idempotent_withdraw is idempotent, so any step due to network and other reasons such as failure or timeout, the client can retry until the results are obtained. 2 is shown below:

Compared to distributed transactions, power design has the advantage of being lightweight, easy to adapt to heterogeneous environments, and performance and usability. In some applications where performance requirements are high, idempotent design is often the only option.

1. The HTTP get method is used to obtain resources and should not have side effects, so it is idempotent. For example: GET http://www.bank.com/account/123456, does not change the state of the resource, whether the call or n times have no side effects. Note that the emphasis here is on the same effect as n times, not the same as the result of each get. Get http://www.news.com/latest-news This HTTP request may get different results each time, but it does not produce any side effects, and is therefore sufficient to be idempotent.
2. The HTTP Delete method is used to delete resources with side effects, but it should satisfy idempotent. For example: Delete http://www.forum.com/article/4231, call once and n times to the system side effect is the same, that is, the deletion of the post ID 4231; therefore, the caller can call or refresh the page multiple times without worrying about causing an error.
3. It is easy to confuse HTTP post and put. The difference between post and put is easy to think of as "post means creating resources, put means updating resources"; in fact, both can be used to create resources, the more essential difference is idempotent. This is defined in the HTTP specification for post and put:

The POST method is used to request the origin server accept the entity enclosed in the request as aNewSubordinate of the resource identified
By the Request-uri in the request-line ... If A resource have been created on the origin server, the response should is 201 (created) and contain
An entity which describes the status of the request and refers to theNewresource, and a location header. The PUT method requests that the enclosed entity is stored under the supplied Request-uri. If The Request-uri refers to an already existing resource,
The enclosed entity should is considered as a modified version of the one residing on the origin server. If The Request-uri does not a
Existing resource, and that URI is capable of being defined as aNewResource by the requesting user agent, the origin server can create the resource with that URI.

The URI corresponding to the post is not the resource itself, but the recipient of the resource. For example, the semantics of post http://www.forum.com/articles is to create a post under Http://www.forum.com/articles, and the HTTP response should include the status of the post and the URI of the post. Two times the same post request creates two resources on the server side with different URIs, so the Post method is not idempotent. The URI for the put is the resource itself to be created or updated. For example, the semantics of PUT http://www.forum/articles/4231 is to create or update a post with ID 4231. The side effects of multiple put on the same URI are the same as a put, so the put method is idempotent. The forum website prevents repetitive postings and order generation using power-equal control of token mode.

3. Summary

in an e-commerce system, frequently asked questions: how can I prevent duplicate submissions of Post requests? the HTTP POST operation is neither secure nor idempotent. When we repeatedly submit the form because of repeated refresh of the browser, the same post request is issued multiple times, causing the remote server to repeatedly create the resource. Therefore, for e-commerce applications, the first corresponding back-end WebService must be idempotent, the second server receives a POST request, after the successful operation must jump to another page, so that even if the user refresh the page, will not repeat the submission of the form .

Second, high concurrency

1. Definition of distributed locks

Distributed locks are a way to control the simultaneous access of shared resources between distributed systems. In distributed systems, it is often necessary to coordinate their actions. If different systems or different hosts of the same system share one or a group of resources, then access to these resources often requires mutual exclusion to prevent mutual interference to ensure consistency, in this case, you need to use a distributed lock. Distributed locks are a very useful primitive in many environments and are an effective way to share resources between disparate systems or different hosts of the same system. As in the e-commerce system, it is necessary to guarantee the effective operation thread of an important thing (order, account, etc.) within the whole distributed system, and only one at a time. For example, the trading center has n servers, the order center has m servers, how to ensure the same payment processing of an order, one account of the same recharge operation is atomic.

Common implementations of Distributed lock services are: Memcache zookeeper Redis Chubby hazelcast.

2. Distributed lock Implementation

Distributed lock is often used in distributing applications, mainly to solve the problem of distributed resource access conflict. Traditional lock reentrantlock is problematic when it comes to implementation, Reentrantlock lock and unlock requirements must be on the same thread, and in distributed applications, lock and unlock are two unrelated requests, so certainly not the same thread, This results in the inability to use Reentrantlock.

Report:

1. What is the RESTful API interface?

Http://www.ruanyifeng.com/blog/2014/05/restful_api.html

Http://www.cnblogs.com/zhengyun_ustc/archive/2012/11/17/topic2.html

Http://www.cnblogs.com/j2eetop/p/4612437.html

Http://www.cnblogs.com/weidagang2046/p/exception-handling-principles.html

Http://www.cnblogs.com/orange1438/p/4637776.html

The use of idempotent and high concurrency in e-commerce system