Bài 30: Bài tổng hợp: chuyển xu và ghi lịch sử

Sau buổi sinh hoạt, An muốn chuyển một phần xu cho Bình để góp quỹ nhóm. Cô Mai cần nhìn được cả số dư mới lẫn bằng chứng về khoản chuyển. Nếu chỉ sửa số dư, cô không biết vì sao số xu thay đổi. Nếu chỉ ghi lịch sử, hai bạn vẫn nhìn thấy số dư cũ.

Một lần chuyển có bốn thay đổi cần đi cùng nhau

Ta sẽ chuyển 15 xu từ An sang Bình trên dữ liệu mẫu. Sổ biến động (ledger) lưu mỗi lần tăng hoặc giảm bằng một dòng riêng. Trong bảng ledger, cột delta mang dấu: số âm là giảm, số dương là tăng.

Đọc số dư và các dòng lịch sử đang có trước khi chuyển:

SELECT id, name, coins
FROM students
WHERE id IN (1, 2)
ORDER BY id;

An có 120 xu, còn Bình có 90. Sau khi chuyển, số dư của An phải giảm đúng lượng Bình nhận. Bảng lịch sử cũng cần thêm một dòng âm cho An và một dòng dương cho Bình. Bốn thay đổi ấy mô tả cùng một việc, nên không thể chọn chỉ làm một phần.

Các dòng đã có vẫn thuộc lịch sử trước đó. Ta thêm dòng mới thay vì sửa một dòng cũ thành khoản chuyển này. Nếu sửa lịch sử, người đối chiếu sẽ không còn biết lần thay đổi trước đã diễn ra thế nào.

• Số dư người gửi giảm theo lượng chuyển.
• Số dư người nhận tăng cùng lượng đó.
• Lịch sử người gửi thêm một biến động âm.
• Lịch sử người nhận thêm một biến động dương.

Giữ tổng số dư là điều cần kiểm, nhưng chưa đủ. Một lần chuyển thiếu cả hai dòng lịch sử vẫn có thể giữ tổng đúng. Ngược lại, hai dòng lịch sử đối dấu chưa chứng minh số dư đã được cập nhật.

Xác nhận sau khi đã ghi đủ số dư và lịch sử

Giao dịch (transaction) gom những thay đổi liên quan thành một đơn vị. BEGIN mở giao dịch, còn COMMIT xác nhận các thay đổi. Nếu một bước thất bại, ứng dụng phải hủy toàn bộ bằng ROLLBACK thay vì báo thành công một phần.

Ví dụ dùng hai mã lịch sử chưa có là 40 và 41. Các mã người gửi, người nhận đều đã tồn tại, và An có đủ xu. Ta ghi đủ bốn thay đổi rồi mới xác nhận:

BEGIN;
UPDATE students
SET coins = coins - 15
WHERE id = 1;
UPDATE students
SET coins = coins + 15
WHERE id = 2;
INSERT INTO ledger (id, student_id, delta)
VALUES (40, 1, -15), (41, 2, 15);
COMMIT;

Hai dòng cuối có cùng lượng chuyển nhưng trái dấu. Bảng sau câu lệnh hiện lịch sử, nên ta cần đọc thêm số dư để kiểm phần còn lại. Phần thiết lập dưới đây dựng lại đúng lần chuyển vừa mô tả cho bảng đối chiếu kế tiếp:

Đọc số dư sau khi xác nhận lần chuyển:

SELECT id, name, coins
FROM students
WHERE id IN (1, 2)
ORDER BY id;

Hai bạn cùng có 105 xu, còn tổng vẫn là 210. Kết quả này khớp hai biến động mới -15 và 15. Mỗi ví dụ chạy trên bản mẫu riêng, nên khối thiết lập giúp xem trạng thái sau cùng mà không phụ thuộc khối trước.

Thất bại ở bước nào cũng phải hủy cả lần chuyển

Điều kiện thành công là những điều phải đúng trước khi ứng dụng báo đã chuyển. Ngoài đủ xu, người gửi và người nhận phải tồn tại. Mỗi phép cập nhật số dư cần thay đổi đúng một dòng. Câu lệnh hợp lệ về cú pháp vẫn có thể không chọn được ai.

Xem lỗi gõ sai mã người nhận. Câu lệnh này chạy được nhưng không cộng cho người nào:

UPDATE students
SET coins = coins + 15
WHERE id = 99;

Toàn bộ số dư vẫn như ban đầu vì điều kiện không khớp dòng nào. Nếu người gửi đã bị trừ trước đó, tiếp tục xác nhận sẽ làm mất xu. Ứng dụng cần kiểm số dòng thay đổi trong cùng giao dịch rồi hủy khi thiếu người nhận.

Trong ví dụ kế tiếp, ta thử sửa cả số dư và lịch sử nhưng quyết định hủy trước khi xác nhận. Bạn quan sát trạng thái số dư sau khi hủy:

BEGIN;
UPDATE students
SET coins = coins - 15
WHERE id = 1;
UPDATE students
SET coins = coins + 15
WHERE id = 2;
INSERT INTO ledger (id, student_id, delta)
VALUES (40, 1, -15), (41, 2, 15);
ROLLBACK;

An vẫn có 120 và Bình vẫn có 90. Hai dòng vừa thêm cũng bị hủy vì nằm trong cùng giao dịch. ROLLBACK ở đây minh họa đường hủy, chưa phải chương trình tự phát hiện mọi điều kiện thất bại.

Tổng biến động không phải số dư đang có

Biến động ròng (net change) là tổng các lần tăng và giảm trong khoảng lịch sử đang xét. Bạn tính bằng SUM(delta), giữ dấu âm trong phép cộng. Trên lịch sử ban đầu, hãy tổng hợp riêng cho từng học viên:

SELECT student_id, SUM(delta) AS net_change
FROM ledger
GROUP BY student_id
ORDER BY student_id;

Dòng của An có net_change = 10, vì 20 cộng với -10 bằng 10. Đây không phải số dư 120 trong bảng học viên. Muốn dựng số dư cuối, bạn còn cần số dư đầu và toàn bộ lịch sử của khoảng đang tính.

Các bạn chưa có dòng lịch sử không xuất hiện trong phép gom nhóm này. Nếu báo cáo cần đủ mọi học viên, bạn có thể dùng phép nối giữ đủ dòng đã học ở bài 15. Yêu cầu của báo cáo quyết định người chưa có lịch sử cần được hiện hay được bỏ.

Một cặp giá trị đối dấu không đủ để khẳng định chúng thuộc cùng sự kiện. Nhiều người có thể chuyển cùng lượng xu trong cùng ngày. Bảng mẫu chỉ lưu mã dòng, mã người và lượng thay đổi, nên không có thông tin liên kết hai phía.

Gửi lại yêu cầu cần kiểm lần chuyển đã thực hiện

Mạng có thể ngắt sau khi máy chủ xác nhận nhưng trước khi trình duyệt nhận phản hồi. Người dùng bấm lại vì chưa biết kết quả. Nếu máy chủ coi lần gửi lại là lần chuyển mới, số dư tiếp tục đổi dù tổng xu vẫn được bảo toàn.

Tính lũy đẳng (idempotency) giúp cùng mã yêu cầu chỉ gây tác động một lần. Máy chủ lưu mã cùng kết quả trong phạm vi ghi đáng tin cậy. Khi nhận lại mã đó, nó trả kết quả đã lưu thay vì chuyển thêm.

Các kiểm tra phục vụ những mục đích khác nhau:

• Giao dịch giữ các thay đổi cùng thành công hoặc cùng bị hủy.
• Kiểm đủ xu ngăn một người chi quá số đang có.
• Mã yêu cầu giúp nhận ra một lần gửi trùng sau lỗi mạng.

Hai mã lịch sử cố định trong ví dụ không phải hệ thống chống gửi trùng hoàn chỉnh. Chạy lại sẽ gặp trùng khóa, nhưng ứng dụng chưa biết kết quả cần trả cho yêu cầu cũ. Một hệ thống thật cần quy ước mã và lưu kết quả ở máy chủ.

Lỗi thường gặp

Tóm tắt

• Một lần chuyển có lịch sử gồm hai thay đổi số dư và hai biến động đối dấu.
• Chỉ xác nhận sau khi đủ điều kiện và mọi bước ghi thành công.
• Tổng biến động phản ánh một khoảng lịch sử, không tự bằng số dư hiện tại.
• Mã dòng liên tiếp không thay thế liên kết sự kiện chuyển.
• Giao dịch nguyên tử vẫn cần cơ chế chống gửi trùng ở ứng dụng.

Kiểm tra nhanh

Đọc thêm

• SQLite: mở, xác nhận và hủy giao dịch.
• PostgreSQL: các thay đổi trong một giao dịch.