Research on power-equal and background verification the proposal of whether the same application will be submitted repeatedly within a short time

Research and application of power-equal nature

introduced:
This is the time to make new access to the channel, take the old core. Copy a reform, in the code reread time, found a fun thing, in the application for the piece, need to undergo a step check, the annotation is written, for a short time repeated submission verification. Then I was curious to go in and see what it was. Then after a surprise, the operation inside do is: Take this piece of ID information, use it as a logo to query for the identification of the thread, if there is a return failure, this piece of a short period of time repeatedly submitted, if no return success, This is not repeated for a short period of time, and a thread is created with an ID for the identity and then suspends the thread n milliseconds (counted as repetitive commit time).

There's a big problem here, it means that when a piece enters the system, if a duplicate request verification is required, a new child thread hangs, and we all know that the operation of the thread, whether it is creating a suspend destroy, will require OS switching operations, which is very resource-intensive, Avoid repetitive creation of threads when it is not necessary, and this validation will be performed every time you enter the piece. This is a huge burden on the program we write, so I reflected the problem to the superior and received the task of optimizing the code. After querying the data, it is found that there is a special term used to describe the operation of this validation for a short period of time, which is what I am going to study: idempotent verification. first, the concept of power, etc.

Idempotent (idempotent, idempotence) is a concept of mathematics and computer science, which is common in abstract algebra.
In programming. A idempotent operation is characterized by the effect that any number of executions have on the same effect as one execution. Idempotent functions, or idempotent methods, are functions that can be executed repeatedly with the same parameters and can obtain the same result. These functions do not affect the system state, nor do you have to worry about repeated execution that can cause changes to the system. The complex operation power Guarantee is realized by using the unique transaction number (serial number). "Baidu Encyclopedia"

A power in mathematics means that a number operates on its own, and the result equals himself. The mathematical expression is (f (x)) = f (x): That is, a function or an interface using the same parameters to call once or infinite times, the result is the same .

At the business level, because we are the one party that provides the interface for others to invoke, the caller can send countless pens of the same data (because of bugs) to call your interface, so that when you provide the service, you must perform power operations to control duplicate applications.

In fact, the TCP transport protocol supports idempotent, and he uses a unique serial number as a marker to ensure the power of the data. We are in the application level of power to verify the same time, the need to use a unique serial number for verification, usually we and the docking party agreed to control the number, its characteristics are unique. second, the verification experiment of power equal sex

On the Internet to ensure that the power of the interface is many, the simplest commonly used methods, Select+insert first query for this data, and then data change operations, but this method is obviously inefficient, in high concurrent procedures are not recommended. Then more is optimistic lock and pessimistic lock, the principle of pessimistic lock is to use the form of select for update, this way requires that you select the condition must be a primary key or unique index, otherwise it will lead to lock the table, when you update no one can do table operation. Optimistic lock is only in the updated moment to lock the table, the efficiency is much higher, but to pass through the auxiliary state parameters to verify, such as:
Update table set name= ' name ', version=version+1 where version=version
Because the update will make its version +1 if the two concurrent information on the table operation, the second pen will be due to the version number does not update the failure, which can also guarantee power. Of course, you can use other state control is also feasible, if the best to add a unique index, can significantly improve efficiency.
Normal interaction with other agencies, often the other side will provide the serial number and ensure that the serial number is unique, so as a partner can use the data source + provided by the other side of the serial number as a unique index for power parity check. Iii. Solving Practical problems

Although I have searched for so many data, I find that the idempotent checksum does not solve my actual problem, should be required (may be to share our backstage core expert system pressure, also may be a large number of repeated bugs before), I need to be in the program without involving the database operation, the control of the same person (ID number , these two applications may be different, but as long as one person does not allow continuous operation, in a short period of time can not repeat the request operation. So I thought, set a buffer to solve this problem, the idea is as follows:
set up a hashmap,key to store identity card information, value store the time information of the application when an application submission comes in, the ID information and time information are deposited in map Before the information is deposited in the map, if the key exists in the map, it will determine whether its value and current time exceed the allowable recurrence length, and if so, update the data and return it. Because the number of entry keys may be more, adding a value to the map may cause the map to be very large, the key validation efficiency is poor, so when the map reaches a certain size, it will open a child thread, loop through the values in the map, and delete all keys that differ from the current time to allow repeat commit time.
The implementation code is as follows:

public static final map<string,long> Map = new hashmap<string,long> ();
    public static final long out_time=1000;
    public static final int out_size=100;
        Verify that a short time duplicate request public static Boolean isrepeat (String idnum) {boolean flag =false;
                Check for key if (Map.containskey (Idnum)) {if (System.currenttimemillis ()-map.get (idnum) >out_time) {
            flag= true;
            }else{flag= false;
        }}else{flag= true;
        } map.put (Idnum, System.currenttimemillis ()); When the number is too many to clear if (Map.size () >out_size) {new Thread () {@Override publi c void Run () {for (entry<string, long> entry:MAP.entrySet ()) {if (Sys
                        Tem.currenttimemillis ()-entry.getvalue () >out_time) {Map.Remove (Entry.getkey ());       
                    }}}.start ();
    return flag; }