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)

Threads
  • Ơ buồn cười thật. Ai cũng biết GIF là định dạng ảnh động thường được dùng thay cho video clip để hiển thị các nội dung ngắn trên nền tảng web. GIF tiện hơn các nội dung dạng video là vì nó được hiển thị như một bức ảnh và được hỗ trợ rộng rãi. Cơ mà GIF có dung lượng nặng quá.

    Nói thật nhiều lúc mình có vài cái hành động muốn hiển thị lên web cho mọi người xem, cơ mà định dạng GIF nó nặng với cả cũng không biết cách tối ưu cho nhẹ xuống. Hôm nay lên mạng tìm hiểu xem định dạng nào có khả năng thay thế GIF trong tương lai thì mọi người biết đó là gì không? Là WEBP (webp)!!! Đúng vậy, là định dạng ảnh mà mình đang dùng trên blog lâu nay luôn á, mà giờ mới biết là nó hiển thị được cả ảnh động nữa, hơi quê 😆

    Kết hợp với ffmpeg nữa là chuyển được tất tần tật video clip thành webp được ngay. Để vài nửa ngồi chế lại cái cli một tí là dùng ngon luôn mọi người ạ 🤪

    » Xem thêm
  • Cảm giác như Github Copilot đang cố gắng mở rộng thị trường cho anh em developer á. Mới trước họ ra mắt Github Open Copilot Chat thì mới đây lại thêm cái Using GitHub Copilot in the command line dùng để giải thích hoặc gợi ý lệnh trong terminal.

    Đây, cách dùng rất đơn giản thôi, ví dụ muốn nó giải thích câu lệnh sudo apt-get để làm gì, thì:

    $ gh copilot explain "sudo apt-get"

    Hoặc nhờ nó gợi ý lệnh mong muốn, sử dụng tiếng Việt được luôn nhé (kể cả tiếng Việt không dấu vẫn hiểu 😳)

    $ gh copilot suggest "xoá commit chưa push"

    Mình đã kiểm tra và thấy lệnh ra rất đúng, xịn thật 🤓

    » Xem thêm
  • Github có chương trình học và ôn thi để lấy chứng chỉ "ghim" vào hồ sơ cá nhân. Các chứng chỉ này xoay quanh kỹ năng sử dụng và làm việc thành thạo với git cũng như Github. Nếu bạn muốn học thêm kỹ năng mới đồng thời thu thập thêm badge cho mình thì còn chần chừ gì nữa 👇

    Showcase your expertise with GitHub Certifications

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

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

Xin chào, tôi tên là Hoài - một anh Dev kể chuyện bằng cách viết ✍️ và làm sản phẩm 🚀. Với nhiều năm kinh nghiệm lập trình, tôi đã đóng góp một phần công sức cho nhiều sản phẩm mang lại giá trị cho người dùng tại nơi đang làm việc, cũng như cho chính bản thân. Sở thích của tôi là đọc, viết, nghiên cứu... Tôi tạo ra trang Blog này với sứ mệnh mang đến những bài viết chất lượng cho độc giả của 2coffee.dev.Hãy theo dõi tôi qua các kênh LinkedIn, Facebook, Instagram, Telegram.

Bạn thấy bài viết này có ích?
Không

Bình luận (0)

Nội dung bình luận...