How CAS Prevents Data Inconsistency in High‑Concurrency Transactions

Origin

In high‑concurrency distributed environments, queries and updates to data can easily cause consistency problems; this article shares a very simple yet effective optimization method.

1. Business Scenario

The scenario involves purchasing a product while checking and updating a user's balance. The basic flow is:

1) Query the current balance from the database: SELECT money FROM t_yue WHERE uid=$uid (assume the result is $old_money=100).

2) Business logic: buy an 80‑yuan item with a 10% discount.

if($old_money > 80*0.9) $new_money = $old_money - 80*0.9 = 28

3) Update the balance in the database: UPDATE t_yue SET money=$new_money WHERE uid=$uid When concurrency is low, this works fine: starting with 100, buying a 72‑yuan discounted item leaves 28.

2. Potential Issues

In a distributed environment with high concurrency, the "query + update" pattern can easily lead to data inconsistency. An extreme case may occur as follows:

1) Two transactions (business 1 and business 2) simultaneously read the balance as 100.

2) Both calculate their own new balances: business 1 computes 28, business 2 computes 38.

3) Business 1 updates the database to 28, then business 2 updates it to 38.

The result is an inconsistency: the original 100 yuan is reduced by 72 (business 1) and 62 (business 2), leaving only 38 yuan.

3. Problem Cause

High concurrency leads to simultaneous reads (both see 100) and concurrent writes (one writes back 28, the other 38), causing the inconsistency.

4. Reason Analysis

Business 1’s write‑back is correct because the original amount is still 100. Business 2’s write‑back should fail because after business 1’s update the balance is already 28, but the naive update does not check the original value.

5. Simple Solution

When performing the write‑back, add a condition that the original value must still be unchanged. This is the classic Compare And Set (CAS) technique, which reduces read‑write lock conflicts and ensures data consistency.

6. Business Upgrade

To apply CAS, modify the update statement to include the original balance as a condition:

UPDATE t_yue SET money=$new_money WHERE uid=$uid AND money=$old_money

During concurrent execution, only one of the following statements can succeed:

Business 1: UPDATE t_yue SET money=28 WHERE uid=$uid AND money=100 Business 2: UPDATE t_yue SET money=38 WHERE uid=$uid AND money=100 Only one will affect a row (affect rows = 1); the other will affect zero rows, indicating failure.

7. Determining Success or Failure

Check the affected rows count after the update: a value of 1 means the operation succeeded, 0 means it failed.

8. Summary

In high‑concurrency "query‑then‑update" scenarios, using CAS (Compare And Set) solves data consistency problems. Implement it by adding the original value check to the SET statement, ensuring that only one concurrent update can succeed.

Source: Architect’s Road