1. What is idempotent
Idempotence is a mathematical and computer science concept. In programming, idempotent means that one or more requests for a resource have the same effect. In mathematics, an idempotent function or method is an idempotent function that yields the same result when executed repeatedly using the same method.
2. What is concurrency
Concurrency is the simultaneous execution of multiple computing programs in the same period of time.
2. Idempotent scenarios
There are many idempotent scenarios, such as:
- The front end submits the same form data, and the back end returns only one result
- Once a user initiates a payment, the user should only be charged once, when the system bug or network retransmission, the user should only be charged once
- The SMS message is sent only once. If the same SMS message is sent several times, the user crashes
- You can create business orders only once, not multiple orders
When to consider idempotent tests:
- Retries (network retransmission, intersystem retries, repeated user submission of data: idempotent for both ends)
- Sending messages requires idempotent checking
- Batch jobs
- Cut the library
- Historical Data Migration
3. The way to solve idempotent problems
The only index
Objective: To prevent new dirty data
If you determine that a column contains different values, you can set a unique index for that column. Unique indexes can ensure the uniqueness of data. In many scenarios, the purpose of unique indexes is not to improve access speed, but to avoid data duplication. Create a unique index
CREATE UNIQUE INDEX uni_user_info_pass ON user_info(pass);
Create a unique matching index
CREATE UNIQUE INDEX uni_user_info_pass ON user_info(name,pass);
Pessimistic locking
Pessimistic locking, as the name implies, is very pessimistic. Every time you take data, you think someone else will change it, so every time you take data, you lock it, so that someone else will block it until you get the lock.
Pessimistic locking: Shielding all operations that might violate data, assuming a concurrency conflict occurs
select * from table_name where id='XXX' for update
Note: id is usually a primary key or unique index, otherwise it is a lock table, can cause trouble. Pessimistic locking is generally used together with transactions, and the data locking time may be very long. Select it according to the actual situation
Optimistic locking
Optimistic locking, as the name implies, is very optimistic. Every time you go to get data, you will assume that others will not modify it, so you will not lock it, but when submitting updates, you will determine whether there will be updates during this period. Optimistic locking only locks the table when the data is updated and does not lock the table at other times, so it is more efficient than pessimistic locking.
Optimistic locking: If a conflict occurs, data integrity operations are checked only at commit time
Optimistic locking generally has the following two ways:
This is implemented using the Version logging mechanism, which is the most common implementation of optimistic locking. What is data version? This is to add a version identifier to the data, typically by adding a numeric version field to the database table. When the data is read, the value of the Version field is read together, incrementing the version value with each update of the data. When we submit the update, compare the current version information of the database table with the version value extracted for the first time. If the current version number of the database table is equal to the version value extracted for the first time, it will be updated; otherwise, it is considered as expired data. Use a timestamp. The second way to implement optimistic locking is similar to the first way. The same way is to add a field in the table that needs optimistic lock control. The name does not matter, and the field type is timestamp, similar to the above version. Also check the timestamp of the data in the current database and compare it with the timestamp obtained before the update when the update is submitted. If the timestamp is consistent, it is OK; otherwise, it is version conflict.
update table_xxx set name=#name#,version=version+1 where version=#version#
A distributed lock
The state machine power
Token mechanism
4. Idempotent test concerns
- Requirements: Requirements review focuses on whether product design is idempotent or not
- Business scenario: Have idempotent mechanisms for failure or retry
- Front end: You need to pay attention to the multiple quick clicks of the button, click the submit button twice, click the refresh button, repeat the previous actions using the browser back button, resulting in repeated submission of the form, and repeated submission of the form using the browser history
- Back end: is an idempotent test of the interface, using Postman or JMeter to send multiple requests for the same parameters and see the server response.
5. How to test idempotence using JMeter
Thread Group A Thread Group can be regarded as a virtual user Group. Each Thread in a Thread Group can be regarded as a virtual user
Synchronizing Timer This function is similar to the assembly point of loadrunner
Number of Simulated Users to Groupby: Number of threads released at a time. Timeout in milliseconds: Maximum wait time. If set to 0, the timer will wait until the Number of threads is equal to the value set in “Number of Simultaneous Users toGroup”. If the Timer is longer than 0, the Timer will wait until the Timeout inmilliseconds value (milliseconds) specified in “Number of Simultaneous Users toGroup” is exceeded and the thread is released. The default is 0
The timeout is usually set to either 0 or > number of requests * 1000 / (number of threads/thread load time). The following scenario: Number of request sets =100, number of threads =100, load time =10, according to the figure above number of request sets =100, then timeout > (100*1000/100/10=100).
The concurrent results can be viewed in the View result tree by running concurrent requests