Bài viết được sự cho phép của tác giả Tống Xuân Hoài
Vấn đề
Khóa bản ghi trong khi đọc hoặc cập nhật dữ liệu là một việc xảy ra với tần suất tương đối phổ biến. Ví dụ kinh điển cho trường hợp này là bài toán chuyển tiền giữa A và B: Trong khi A đang chuyển cho B một số tiền là x, khi đó chúng ta cần kiểm tra số dư của A, nếu còn đủ tiền thì trừ đi x đồng trong tài khoản rồi cộng thêm x đồng vào tài khoản của B. Đảm bảo rằng tất cả quá trình cộng trừ đó phải thành công thì giao dịch mới hoàn tất, vì nếu một lỗi xảy ra trong khi trừ tiền của A mà chưa cộng vào B hoặc ngược lại thì sẽ gây ra một vấn đề nghiêm trọng về tính chính xác của chương trình.
Ví dụ thứ tự để thực hiện các câu truy vấn trong trường hợp này với PostgreSQL sẽ giống như là:
BEGIN TRANSACTION;
SELECT balance FROM accounts WHERE user = 'A';
// if a > x then...
UPDATE accounts SET balance = balance - x WHERE user = 'A';
UPDATE accounts SET balance = balance + x WHERE user = 'B';
COMMIT;
Hầu hết chúng ta biết được cách giải quyết bài toán này bằng transaction. Tức là khởi tạo một transaction và đảm bảo cả hai quá trình trừ tiền và cộng tiền thành công thì mới công nhận quá trình chuyển tiền thành công và lưu vào cơ sở dữ liệu. Nếu chẳng may 1 trong 2 bị lỗi thì giao dịch thất bại mà chẳng ai bị trừ tiền hay cộng tiền một cách vô lý nữa.
Nhưng trong trường hợp A có thể thực hiện nhiều lệnh chuyển tiền và “gần như cùng một lúc” thì có một vấn đề khác xảy ra. Đó là ở câu lệnh SELECT đầu tiên với mục đích kiểm tra số dư, vì khả năng cao một số lệnh SELECT ra được balance của A trước khi mà đến bước kiểm tra số dư, khi đó chúng đều thỏa mãn a > x và điều gì sẽ xảy ra nếu như tất cả chúng đều thực thi tiếp UPDATE sau đó?
Để giải quyết vấn đề này có nhiều cách. Một trong số đó là khóa bản ghi đang SELECT lại bằng truy vấn SELECT FOR UPDATE, nếu truy vấn sau gặp SELECT trên user A, nó sẽ phải xếp vào hàng đợi cho đến khi truy vấn đầu tiên hoàn thành. Kỹ thuật này gọi là Record Locking, ngoài ra chúng ta còn có thêm một cách khác nữa là Optimistic Locking. Bài viết ngày hôm nay, tôi sẽ nói về hai phương pháp khóa dữ liệu này để xem chúng hoạt động như thế nào, có ưu nhược điểm gì cũng như sử dụng trong trường hợp nào.
Record locking (khóa bi quan)
Record Locking là một kỹ thuật quản lý đồng thời trong cơ sở dữ liệu, trong đó các bản ghi (record) được khóa để đảm bảo tính nhất quán và ngăn chặn các transaction truy cập vào cùng một bản ghi cùng lúc.
Khi một transaction muốn cập nhật hoặc đọc dữ liệu từ một bản ghi, nó sẽ yêu cầu cơ sở dữ liệu khóa bản ghi đó để ngăn chặn các transaction khác truy cập vào. Sau khi transaction thực hiện xong, nó sẽ mở khóa để các transaction khác có thể tiếp tục truy cập.
Ví dụ như trong PostgreSQL, SELECT FOR UPDATE là một cách để khóa những bản ghi mà nó đang truy vấn đến. Bằng cách thay thế:
SELECT balance FROM accounts WHERE user = 'A';
Thành:
SELECT balance FROM accounts WHERE user = 'A' FOR UPDATE;
Ngay lập tức transaction đầu tiên sẽ khóa bản ghi tại user = ‘A’ lại và các transaction sau không thể tiếp tục đọc mà phải đợi một lệnh COMMIT hoặc ROLLBACK được thực hiện thành công thì mới có thể tiếp tục.
Kỹ thuật Record Locking đảm bảo tính nhất quán dữ liệu, tuy nhiên nó có thể dẫn đến tình trạng deadlock. Do đó, việc sử dụng Record Locking cần được cân nhắc kỹ lưỡng để đảm bảo hiệu suất và tính nhất quán dữ liệu cho hệ thống cơ sở dữ liệu. Để hiểu rõ hơn về các loại khóa và deadlock, tôi khuyên bạn nên đọc thêm bài viết Tìm hiểu về các loại Khoá (Explicit Locking) trong PostgreSQL.
Tham khảo việc làm Oracle hấp dẫn trên TopDev
Optimistic Locking (khóa lạc quan)
Optimistic Locking là một phương pháp mà trong đó các transaction sẽ không khóa bất kỳ bản ghi nào mà cho phép nó thực hiện như bình thường. Giống với tên gọi lạc quan, tư tưởng của Optimistic Locking là giả định rằng các transaction đang truy cập vào cùng một bản ghi sẽ không cập nhật dữ liệu cùng lúc, và chỉ một trong số các transaction đó sẽ hoàn thành việc cập nhật dữ liệu.
Khi một transaction muốn cập nhật dữ liệu, nó sẽ không khóa bản ghi để ngăn chặn các transaction khác truy cập vào. Thay vào đó, nó sẽ kiểm tra trạng thái của bản ghi trước khi cập nhật. Nếu trạng thái của bản ghi không bị thay đổi bởi các transaction khác, nó sẽ thực hiện cập nhật bản ghi đó. Ngược lại, nếu phát hiện trạng thái của bản ghi đã bị thay đổi, nó sẽ phải hủy bỏ việc cập nhật.
Để triển khai Optimistic Locking, chúng ta cần thêm một trường để đánh dấu cập nhật, nó có thể là version, updated_at… hay bất kỳ trường dữ liệu nào để mỗi khi cập nhật bản ghi thành công thì cũng sẽ cập nhật cả nó.
Ví dụ trong bảng accounts có thêm trường updated_at là thời gian bản ghi được cập nhật thành công. Chúng ta không cần SELECT FOR UPDATE nữa mà thay vào đó sẽ SELECT ra thêm updated_at.
SELECT balance, updated_at FROM accounts WHERE user = 'A';
Sau đó thực hiện cập nhật “có điều kiện” của updated_at:
UPDATE accounts SET balance = balance - x, updated_at = now() WHERE user = 'A' AND updated_at = updated_at;
Với updated_at là kết quả của truy vấn SELECT trong transaction.
Để giải thích nguyên lý rất đơn giản, vì UPDATE sẽ khóa bản ghi lại trong khi cập nhật dữ liệu cho nên cùng một lúc chỉ có một transaction được phép cập nhật. Các transaction sau đó khi cố gắng cập nhật dữ liệu ở updated_at cũ thì sẽ hoàn toàn không thấy bản ghi nào trùng khớp. Lúc đó chúng ta có thể xử lý tiếp trường hợp này như là một giao dịch thất bại.
Optimistic Locking đơn giản và hiệu quả trong các tình huống mà các transaction cập nhật dữ liệu không xảy ra quá thường xuyên. Tuy nhiên, nó không đảm bảo tính nhất quán dữ liệu hoặc nguy cơ gây ra lỗi nhiều hơn do nó thường được xử lý ở tầng ứng dụng bằng mã lập trình.
Áp dụng trong trường hợp nào?
Vẫn là câu cửa miệng, trước tiên phải nói việc lựa chọn sử dụng Record Locking hay Optimistic Locking phụ thuộc vào từng bài toán cụ thể, vì mỗi phương pháp đều có ưu nhược điểm và ngữ cảnh riêng. Tuy nhiên, bạn có thể dựa vào một số gợi ý dưới đây để tăng khả năng quyết định cho mình.
Sử dụng Record Locking trong trường hợp:
- Tính nhất quán dữ liệu là ưu tiên hàng đầu.
- Các transaction cập nhật dữ liệu thường xuyên hoặc có nhiều transaction cập nhật cùng một bản ghi cùng lúc.
Sử dụng Optimistic Locking trong trường hợp:
- Tính nhất quán dữ liệu không phải là yêu cầu cần thiết và ứng dụng cần tăng hiệu suất và tốc độ thực thi các transaction.
- Các transaction không cập nhật dữ liệu thường xuyên hoặc không có nhiều transaction cập nhật cùng một bản ghi cùng lúc.
Ngoài ra, trong một số trường hợp, có thể kết hợp cả hai kỹ thuật để đạt được một giải pháp tối ưu. Ví dụ: sử dụng Optimistic Locking cho các transaction đọc dữ liệu, và sử dụng Record Locking cho các transaction cập nhật dữ liệu. Điều này giúp tối ưu hóa hiệu suất và tính nhất quán dữ liệu cho hệ thống cơ sở dữ liệu.
Tổng kết
Trong hệ thống cơ sở dữ liệu, có hai phương pháp khóa dữ liệu phổ biến là Optimistic Locking và Record Locking. Trong khi Optimistic Locking giả định rằng các transaction đang truy cập vào cùng một bản ghi sẽ không cập nhật dữ liệu cùng lúc, thì Record Locking lại “nhanh trí” khóa các bản ghi lại để đảm bảo transaction đầu tiên mới có quyền truy cập và ngăn chặn các transaction khác truy cập vào. Mỗi phương pháp đều có những ưu nhược điểm riêng nên cần được áp dụng sao cho phù hợp trong từng bài toán cụ thể.
Bài viết gốc được đăng tải tại 2coffee.dev
Xem thêm:
- Cài đặt Apache Kafka sử dụng Docker Compose
- Cài đặt Apache Kafka sử dụng Docker Compose
- Oracle SQL developer – Top 5 cách dùng thông minh
Xem thêm Việc làm IT hấp dẫn trên TopDev