Việc chuyển 300 rupee từ Asha sang Ben cần hai lần cập nhật: trừ đi một tài khoản và thêm vào tài khoản kia. Nếu hệ thống giữa chúng bị lỗi, tiền sẽ biến mất. Giao dịch SQL tồn tại để biến điều đó thành không thể, bằng cách coi cả hai bước là một đơn vị.

Trong hướng dẫn này, chúng tôi xem xét các cam kết, hoàn tác và lỗi trên một bảng tài khoản nhỏ. Chúng tôi đã chạy các ví dụ đó trong SQLite và số dư được hiển thị là từ lần chạy đó. Các lệnh cơ bản giống nhau trên các cơ sở dữ liệu, nhưng hành vi khóa và cách ly khác nhau rất nhiều, vì vậy chúng tôi chỉ ra nơi để kiểm tra tài liệu cơ sở dữ liệu của riêng bạn.

Giao dịch là gì?

Giao dịch là một chuỗi gồm một hoặc nhiều câu lệnh SQL mà cơ sở dữ liệu xử lý như một thao tác logic đơn lẻ. Đây là bảng của chúng tôi:

CREATE TABLE accounts (
  id INT PRIMARY KEY,
  owner TEXT,
  balance INT CHECK (balance >= 0)
);

INSERT INTO accounts VALUES (1, 'Asha', 1000), (2, 'Ben', 200);

Ràng buộc CHECK là quy tắc mà số dư không bao giờ có thể xuống dưới 0, quy tắc này chúng ta sẽ sử dụng sau. Lưu ý rằng cú pháp để bắt đầu giao dịch khác nhau: SQLite và PostgreSQL chấp nhận BEGIN, MySQL cũng có START TRANSACTION và SQL Server sử dụng BEGIN TRANSACTION.

Bên ngoài một giao dịch rõ ràng, hầu hết các cơ sở dữ liệu đều sử dụng autocommit, trong đó mỗi câu lệnh được lưu ngay khi nó kết thúc. Oracle là một ngoại lệ đáng chú ý, bởi vì phiên đó vẫn ở trong giao dịch cho đến khi bạn cam kết.

CAM KẾT: làm cho nó vĩnh viễn

BEGIN;
UPDATE accounts SET balance = balance - 300 WHERE id = 1;
UPDATE accounts SET balance = balance + 300 WHERE id = 2;
COMMIT;

-- Asha | 700
-- Ben  | 500

Cho đến khi COMMIT chạy, những thay đổi này chỉ là tạm thời. Khi nó trả về thành công, cơ sở dữ liệu đảm bảo rằng chúng được lưu. Tổng số trên cả hai tài khoản vẫn ở mức 1200, đó là toàn bộ mục đích của bài tập.

ROLLBACK: hủy bỏ mọi thứ

ROLLBACK hoàn tác mọi thứ kể từ khi giao dịch bắt đầu:

BEGIN;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
SELECT owner, balance FROM accounts;
-- Asha | 600   (visible inside this transaction)
-- Ben  | 500

ROLLBACK;
SELECT owner, balance FROM accounts;
-- Asha | 700   (back to where it was)
-- Ben  | 500

Việc khôi phục cũng tự động xảy ra nếu kết nối bị ngắt hoặc máy chủ gặp sự cố trước khi bạn thực hiện, do đó giao dịch đã hoàn thành một nửa sẽ không tồn tại được.

Khi một tuyên bố thất bại

Đây là một trường hợp thực tế hơn. Asha cố gắng gửi 5000 nhưng tài khoản không giữ được. Khoản ghi có cho Ben chạy trước và sau đó khoản ghi nợ phá vỡ quy tắc CHECK:

BEGIN;
UPDATE accounts SET balance = balance + 5000 WHERE id = 2;
UPDATE accounts SET balance = balance - 5000 WHERE id = 1;
-- error: CHECK constraint failed: balance >= 0

ROLLBACK;

-- Asha | 700
-- Ben  | 500

Nếu không có giao dịch, Ben sẽ giữ lại 5000 và sổ sách sẽ sai. Hãy lưu ý một chi tiết quan trọng: một tuyên bố không thành công không phải lúc nào cũng tự hủy giao dịch. Ví dụ: trong SQLite và MySQL, các câu lệnh trước đó có thể vẫn đang chờ xử lý, do đó mã của bạn phải đưa ra lệnh khôi phục. Thay vào đó, PostgreSQL đánh dấu toàn bộ giao dịch là bị hủy bỏ và từ chối các báo cáo tiếp theo cho đến khi bạn quay lại.

Trong mã ứng dụng, luôn ghép nối giao dịch với việc xử lý lỗi. Đây là ý tưởng trong Python và hướng dẫn của chúng tôi về Xử lý ngoại lệ Python giải thích cú pháp:

try:
    conn.execute("BEGIN")
    conn.execute(debit_sql, values)
    conn.execute(credit_sql, values)
    conn.execute("COMMIT")
except Exception:
    conn.execute("ROLLBACK")
    raise

Điểm lưu

Điểm lưu trữ đánh dấu một vị trí bên trong giao dịch, do đó bạn chỉ có thể hoàn tác một phần công việc:

BEGIN;
UPDATE accounts SET balance = balance - 50 WHERE id = 1;
SAVEPOINT bonus;
UPDATE accounts SET balance = balance + 999 WHERE id = 2;
ROLLBACK TO bonus;
UPDATE accounts SET balance = balance + 50 WHERE id = 2;
COMMIT;

-- Asha | 650
-- Ben  | 550

Phần thưởng 999 đã được hoàn tác, trong khi phần còn lại của giao dịch vẫn được tiếp tục và cam kết. Điều này rất hữu ích cho các bước tùy chọn trong một quá trình dài.

Thuộc tính ACID được giải thích

Tính nhất quán thường bị hiểu lầm. Cơ sở dữ liệu chỉ thực thi các quy tắc bạn khai báo, chẳng hạn như các ràng buộc và khóa ngoại. Nó sẽ không ngăn mã của bạn chuyển sai số tiền. Độ bền thường đạt được nhờ nhật ký ghi trước, trong đó các thay đổi được ghi lại một cách an toàn trên đĩa trước khi cam kết được xác nhận.

Điều gì xảy ra với các giao dịch đồng thời?

Chúng tôi đã mở hai kết nối tới một tệp SQLite. Người đầu tiên bắt đầu giao dịch và cập nhật một hàng từ 1 lên 2 mà chưa cam kết. Đây là những gì kết nối thứ hai nhìn thấy:

Connection B reads:   1                     -- no uncommitted data
Connection B writes:  database is locked    -- it has to wait
(A commits)
Connection B reads:   2                     -- now it sees the change

SQLite chỉ cho phép một người ghi tại một thời điểm, điều này đơn giản hơn cơ sở dữ liệu máy chủ, nơi nhiều giao dịch có thể ghi các hàng khác nhau cùng một lúc. Nhưng nguyên tắc là như nhau: các phiên khác sẽ không thấy những thay đổi không được cam kết trong cài đặt thông thường và các lần ghi xung đột phải chờ. Trong thử nghiệm của chúng tôi, chúng tôi đặt kết nối thứ hai dừng ngay lập tức thay vì chờ đợi, do đó lỗi xuất hiện ngay lập tức.

Đọc bất thường

Khi các giao dịch chồng chéo, một số vấn đề nhất định có thể xảy ra. Tiêu chuẩn SQL xác định những điều này theo những gì một giao dịch có thể quan sát được:

Một vấn đề khác là mất bản cập nhật. Hai phiên đọc số dư 100, mỗi phiên thêm 10 và mỗi phiên ghi 110. Một bản cập nhật thực sự đã biến mất khi câu trả lời phải là 120.

Các mức cô lập SQL

Mức cô lập cho phép bạn đánh đổi tính nghiêm ngặt để lấy tính đồng thời. Đây là những gì tiêu chuẩn SQL cho phép ở mỗi cấp độ:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

Cú pháp và hành vi chính xác phụ thuộc vào cơ sở dữ liệu của bạn. Các giá trị mặc định cũng khác nhau: PostgreSQL và SQL Server sử dụng chế độ đọc cam kết, trong khi InnoDB của MySQL sử dụng chế độ đọc lặp lại. Một số cơ sở dữ liệu đưa ra những đảm bảo mạnh mẽ hơn mức yêu cầu của tiêu chuẩn hoặc coi cấp độ này như cấp độ khác. Ví dụ: trong PostgreSQL, đọc hoạt động không được cam kết giống như đọc đã cam kết. Luôn đọc tài liệu cơ sở dữ liệu của bạn trước khi dựa vào một hành vi cụ thể.

Bế tắc

Sự bế tắc xảy ra khi hai giao dịch, mỗi giao dịch giữ một khóa mà giao dịch kia cần. Giao dịch A khóa hàng 1 và muốn hàng 2, trong khi giao dịch B khóa hàng 2 và muốn hàng 1. Cả hai đều không thể tiếp tục.

Các cơ sở dữ liệu như PostgreSQL, MySQL và SQL Server phát hiện điều này và hủy một giao dịch do lỗi. Đó là hành vi bình thường và ứng dụng của bạn nên được chuẩn bị cho điều đó. Để giảm tình trạng bế tắc, hãy luôn cập nhật các hàng theo thứ tự nhất quán, chẳng hạn như ID tài khoản thấp nhất trước, giữ giao dịch ngắn gọn và thử lại khi một người được chọn làm nạn nhân.

Các phương pháp hay nhất

• Giữ giao dịch ngắn gọn. Giao dịch dài giữ khóa và chặn người dùng khác.
• Không bao giờ đợi người dùng hoặc API chậm trong giao dịch. Hãy thực hiện công việc đó trước khi bạn bắt đầu hoặc sau đó.
• Luôn xử lý lỗi. Mọi đường dẫn phải kết thúc bằng một cam kết hoặc khôi phục.
• Thêm các ràng buộc. Chúng cung cấp cho cơ sở dữ liệu các quy tắc thực tế để thực thi. Thiết kế bảng tốt cũng hữu ích.
• Sử dụng chỉ mục tốt. Tra cứu nhanh hơn có nghĩa là các khóa được giữ trong thời gian ngắn hơn.
• Hãy cẩn thận khi thử lại. Thử lại khi bế tắc, nhưng hãy đảm bảo rằng một thao tác không thể áp dụng hai lần.
• Kiểm tra tính đồng thời có mục đích. Nhiều lỗi trong số này chỉ xuất hiện khi tải, do đó, chỉ riêng các thử nghiệm tích hợp cơ bản có thể không phát hiện ra chúng.

Lời kết

Các giao dịch biến một số bước rủi ro thành một hoạt động an toàn và ACID mô tả những đảm bảo khiến điều này trở nên đáng tin cậy. Bất cứ khi nào một hành động kinh doanh chạm vào nhiều hàng hoặc bảng, hãy tự hỏi điều gì sẽ xảy ra nếu nó dừng lại giữa chừng. Nếu câu trả lời làm bạn lo lắng, hãy gói nó vào một giao dịch. Để thực hành, hãy mở hai phiên trong cơ sở dữ liệu cục bộ và cố gắng tự tạo ra các điểm bất thường.

Câu hỏi thường gặp

Tiếp tục học hỏi