Bàn về hai phương pháp khóa dữ liệu phổ biến là Record Locking và Optimistic Locking (khóa bi quan và khóa lạc quan)

Bàn về hai phương pháp khóa dữ liệu phổ biến là Record Locking và Optimistic Locking (khóa bi quan và khóa lạc quan)

Tin ngắn hàng ngày dành cho bạn
  • Bắt đầu kỳ nghỉ tết rồi nên mình cũng không đăng bài nữa. Hẹn gặp lại các bạn qua tết nha 😁

    » Xem thêm
  • Tiếp tục về jj. Đang thắc mắc là nó mới thế liệu có ai làm mấy phần mềm dạng GUI cho dễ nhìn chưa. Kiểu giống như git thì có quá nhiều rồi không đếm xuể.

    May quá, tác giả tổng hợp lại luôn rồi Community-built tools around Jujutsu 🥳

    » Xem thêm
  • Turso thông báo rằng họ đang viết lại SQLite bằng Rust. Thế là lại có thêm một bằng chứng nữa cũng cố cho câu nói Rust đang "tái định nghĩa" lại nhiều thứ.

    Nhưng nguyên nhân sâu xa mới thú vị. Tại sao họ lại làm vậy? Ai cũng biết SQLite là nguồn mở, ai cũng có thể tạo bản sao (fork) để chỉnh sửa lại theo ý mình. Lẽ nào nhóm của Turso không thích hoặc không tin vào C - vốn là ngôn ngữ dùng để cấu thành SQLite.

    Mình xin kể chuyện một chút. Turso là một bên cung cấp dịch vụ máy chủ cơ sở dữ liệu dựa trên SQLite, họ đã thực hiện một vài tùy chỉnh trên bản sao của SQLite để phục vụ cho mục đích của mình, gọi nó là libSQL. Họ "hào phóng" cho cộng đồng đóng góp thoải mái.

    Quay trở lại SQLite là mã nguồn mở chứ không phải là đóng góp mở. Chỉ có một nhóm người đứng đằng sau duy trì mã nguồn này, và họ không tiếp nhận yêu cầu kéo (pull request) từ những người khác. Đồng nghĩa mọi thay đổi hoặc tính năng đều là của nhóm người này tạo ra. Có vẻ như SQLite rất phổ biến nhưng cộng đồng không thể làm điều mà họ muốn là đóng góp cho sự phát triển của nó.

    Chúng ta biết rằng hầu hết ứng dụng mã nguồn mở thường đi kèm với một thư mục "tests" với các bài kiểm tra rất nghiêm ngặt. Điều đó giúp cho sự cộng tác trong phát triển trở nên dễ dàng hơn. Nếu muốn chỉnh sửa hoặc thêm một tính năng mới, trước hết bạn cần phải đảm bảo sự thay đổi vượt qua được tất cả bài kiểm tra. Nhiều thông tin cho rằng SQLite không công khai bộ kiểm tra này. Điều này vô tình gây khó khăn cho những ai muốn chỉnh sửa mã nguồn. Vì họ không chắc chắn rằng liệu triển khai mới của mình có phù hợp với những tính năng cũ hay không.

    tursodatabase/limbo là dự án viết lại SQLite bằng Rust đã nhắc đến ở đầu bài. Họ nói rằng nó hoàn toàn tương thích với SQLite và nguồn mở hoàn toàn. limbo đang trong giai đoạn hoàn thiện. Chúng ta hãy chờ xem kết quả trong tương lai thế nào nhé. Bài viết chi tiết tại Introducing Limbo: A complete rewrite of SQLite in Rust.

    » Xem thêm

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.

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ể.

Cao cấp
Hello

Bí mật ngăn xếp của Blog

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.

Bình luận (0)

Nội dung bình luận...
Bấm hoặc cuộn mạnh để sang bài mới