Race ConditionRace Condition

lượt thích trên một bài hotlikes on one hot post

1,200/s

lượt thích trên một bài hotlikes on one hot post

lượt cập nhật bị mấtlost updates

0

lượt cập nhật bị mấtlost updates

lần sửa hồ sơ bị xung độtprofile edits that conflict

< 1%

lần sửa hồ sơ bị xung độtprofile edits that conflict

instance API chạy song songAPI instances in parallel

4

instance API chạy song songAPI instances in parallel

Hai người dùng đi qua load balancer tới hai instance API khác nhau, cùng ghi vào một dòng trong PostgreSQL. Khoá trong bộ nhớ của từng instance không thấy nhau, nên việc điều phối phải nằm ở DB. Chọn từng kịch bản để so sánh optimistic locking, read-modify-write và cộng dồn nguyên tử.Two users go through the load balancer to two different API instances and write the same PostgreSQL row. In-memory locks in each instance cannot see each other, so coordination must live in the database. Pick a scenario to compare optimistic locking, read-modify-write and an atomic increment.

1. 1

   Lost update (read-modify-write)Lost update (read-modify-write)

   Đọc giá trị, tính trong code, rồi ghi lại là ba bước tách rời. Hai request xen kẽ nhau sẽ ghi cùng kết quả và một thay đổi biến mất. Với bộ đếm, chuyển phép tính vào SQL: SET like_count = like_count + 1.Reading a value, computing in code and writing it back are three separate steps. Two interleaved requests write the same result and one change disappears. For counters, move the arithmetic into SQL: SET like_count = like_count + 1.

   Unit of Work
2. 2

   Check-then-actCheck-then-act

   “Kiểm tra email chưa tồn tại rồi INSERT” hay “kiểm tra còn hàng rồi trừ kho” đều có khe hở giữa hai bước. Gộp điều kiện vào câu ghi (UPDATE stock SET qty = qty - 1 WHERE id = ? AND qty > 0, rồi kiểm tra số dòng) hoặc để unique constraint quyết định.“Check the email is free, then INSERT” or “check stock, then decrement” both leave a gap between the steps. Fold the condition into the write (UPDATE stock SET qty = qty - 1 WHERE id = ? AND qty > 0, then check the row count) or let a unique constraint decide.

   Unit of Work
3. 3

   Sửa bản ghi qua form: optimistic lockingEditing through a form: optimistic locking

   Người dùng mở form vài phút rồi mới lưu, nên không thể giữ khoá DB suốt thời gian đó. Thêm cột version: client gửi lại version đã đọc, UPDATE … WHERE id = ? AND version = ?; 0 dòng nghĩa là có người sửa trước, trả 409. JPA làm việc này với @Version.A user keeps a form open for minutes before saving, so you cannot hold a DB lock that long. Add a version column: the client sends back the version it read, UPDATE … WHERE id = ? AND version = ?; zero rows means someone saved first, so return 409. JPA does this with @Version.

   Unit of WorkRepository
4. 4

   Dòng tranh chấp cao: pessimistic lockingHighly contended rows: pessimistic locking

   Khi nhiều giao dịch ngắn cùng sửa một dòng và cần đọc trước khi quyết định (chuyển tiền giữa hai ví), SELECT … FOR UPDATE khoá dòng để các giao dịch xếp hàng. Giữ transaction ngắn, khoá theo thứ tự cố định (id nhỏ trước) để tránh deadlock, đặt lock_timeout.When many short transactions modify one row and must read before deciding (moving money between two wallets), SELECT … FOR UPDATE locks the row so they queue. Keep transactions short, lock in a fixed order (lower id first) to avoid deadlocks, and set lock_timeout.

   Read-Write LockUnit of Work
5. 5

   Isolation level không phải phép màuIsolation levels are not magic

   PostgreSQL mặc định READ COMMITTED, không chặn lost update. REPEATABLE READ và SERIALIZABLE báo lỗi 40001 khi phát hiện xung đột, nên ứng dụng phải bắt lỗi và chạy lại cả transaction. MySQL InnoDB ở REPEATABLE READ không báo lỗi lost update theo cách này.PostgreSQL defaults to READ COMMITTED, which does not prevent lost updates. REPEATABLE READ and SERIALIZABLE raise error 40001 on a conflict, so the application must catch it and rerun the whole transaction. MySQL InnoDB at REPEATABLE READ does not report lost updates this way.

   Unit of Work
6. 6

   Race trong bộ nhớ của một processRaces inside one process

   Cache hay bộ đếm dùng chung giữa các thread cũng bị race. Java: synchronized, AtomicLong, ConcurrentHashMap.merge. Go: sync.Mutex, sync/atomic, hoặc để một goroutine sở hữu dữ liệu và nhận lệnh qua channel. Chạy go test -race trong CI. Các khoá này chỉ có tác dụng trong một instance.Caches or counters shared between threads race too. Java: synchronized, AtomicLong, ConcurrentHashMap.merge. Go: sync.Mutex, sync/atomic, or one goroutine owning the data and taking commands over a channel. Run go test -race in CI. These locks only work within a single instance.

   Read-Write Lock

Sửa hồ sơ bằng optimistic locking và trả 409 khi version lệch; thích bài bằng unique constraint cộng với cộng dồn nguyên tử trong SQL.Edit a profile with optimistic locking and return 409 on a version mismatch; like a post with a unique constraint plus an atomic increment in SQL.

@Entity
public class UserProfile {
    @Id private Long id;
    private String displayName;
    private String bio;
    @Version private long version;1
    // getters, setters
}

public interface PostRepository extends JpaRepository<Post, Long> {
    @Modifying
    @Query("update Post p set p.likeCount = p.likeCount + 1 where p.id = :id")2
    int incrementLikes(@Param("id") long id);
}

@Service
@RequiredArgsConstructor
public class ProfileService {
    private final UserProfileRepository profiles;
    private final PostRepository posts;
    private final PostLikeRepository likes;

    @Transactional
    public UserProfile update(long id, ProfileEdit edit) {
        UserProfile p = profiles.findById(id).orElseThrow();
        if (p.getVersion() != edit.version()) {3
            throw new ObjectOptimisticLockingFailureException(UserProfile.class, id);
        }
        p.setDisplayName(edit.displayName());
        p.setBio(edit.bio());
        return p;          // UPDATE … WHERE id = ? AND version = ? at commit
    }

    @Transactional
    public void like(long postId, long userId) {
        if (likes.insertIgnore(postId, userId) == 0) return; // already liked4
        posts.incrementLikes(postId);                          // no read-modify-write
    }
}

@RestControllerAdvice
class ConflictAdvice {
    @ExceptionHandler(ObjectOptimisticLockingFailureException.class)
    ResponseEntity<String> conflict() {
        return ResponseEntity.status(HttpStatus.CONFLICT).body("Reload and try again");
    }
}

var ErrConflict = errors.New("profile was modified by someone else")

func (r *Repo) UpdateProfile(ctx context.Context, e ProfileEdit) error {
	tag, err := r.db.Exec(ctx, `
		UPDATE user_profile
		   SET display_name = $1, bio = $2, version = version + 1
		 WHERE id = $3 AND version = $4`,1
		e.DisplayName, e.Bio, e.ID, e.Version)
	if err != nil {
		return err
	}
	if tag.RowsAffected() == 0 {2
		return ErrConflict // handler maps it to 409
	}
	return nil
}

func (r *Repo) Like(ctx context.Context, postID, userID int64) error {
	return pgx.BeginFunc(ctx, r.db, func(tx pgx.Tx) error {
		tag, err := tx.Exec(ctx,
			"INSERT INTO post_like (post_id, user_id) VALUES ($1, $2) ON CONFLICT DO NOTHING",3
			postID, userID)
		if err != nil || tag.RowsAffected() == 0 {
			return err // nil: already liked
		}
		_, err = tx.Exec(ctx,
			"UPDATE post SET like_count = like_count + 1 WHERE id = $1", postID)
		return err
	})
}

// In-process shared state needs a lock too; run go test -race in CI.
type ViewCounter struct {
	mu sync.Mutex
	n  map[int64]int
}

func (c *ViewCounter) Inc(postID int64) {
	c.mu.Lock()
	defer c.mu.Unlock()
	c.n[postID]++4
}

Mỗi pattern mở bài học tương ứng trong menu Pattern.Each one opens its lesson in the Patterns menu.