Transaction là gì ? Các dạng transaction

Transation là gì là một trong những từ khóa được search nhiều nhất google về chủ đề biên Transaction là gì. Trong bài viết này, chúng ta sẽ cùng tìm hiểu về chủ đề “Transaction là gì ? Các dạng transaction”

Transaction là gì ? Các dạng transaction

Có rất nhiều định nghĩa khác nhau về transaction, xin mạn phép đưa ra một định nghĩa dưới đây.

Transaction là một tiến trình xử lý có xác định điểm đầu và điểm cuối, được chia bé dại thành các operation (phép thực thi) , tiến trình được thực thi một cách tuần tự và độc lập những operation đó theo luật lệ hoặc tất cả đều thành đạt hoặc một operation thất bại thì toàn bộ tiến trình thất bại. Nếu việc thực thi một operation nào đó bị fail (hỏng) đồng nghĩa với việc dữ liệu phải rollback (trở lại) trạng thái ban sơ.

Như vậy, xét một cách chung nhất, transaction không phải là thuật ngữ gắn với business chi tiết nào cũng không phải là thuật ngữ chỉ gắn chặt vào data storage (bao gồm cả RDBMs – cơ sở dữ liệu quan hệ). Transaction là một thuật ngữ chung nhất design cho một tiến trình xử lý trong phần mềm với các đòi hỏi được vạch ra hàm chứa trong định nghĩa.

Ví dụ: giản đơn nhất là tiến trình setup phần mềm hoặc gỡ bỏ ứng dụng có thể coi là một transaction. Việc setup được phân thành những bước, làm tuần tự từ đầu đến cuối, nếu toàn thể các bước thực thi thành đạt đồng nghĩa với việc tiến trình setup hoặc gỡ bỏ ứng dụng thành đạt và ngược lại, một phép thất bại thì tiến trình phải rollback lại tức sẽ không có bất cứ đổi mới nào trên máy tính (ghi file, sửa những registry,…)

Chúng ta cần để ý đến 5 nhân tố chính để xác định có phải là một transaction hay không?

1. Tiến trình xử lý cần xác định chính xác điểm đầu và điểm cuối, tức khi nào được coi là khai mạc, khi nào được coi như kết thúc, không có sự nhập nhằng ranh giới.

2. Tiến trình phải được chia bé dại thành các operation – phép thực thi đến mức không thể chia bé dại hơn.

3. Thực thi một cách tuần tự những operations. Có hai quy tắc chính yếu là từ đầu đến cuối (trái thanh lịch phải hoặc trên xuống dưới) và từ trong ra ngoài. Việc thực thi những operation là độc lập, không có chuyện đang thực thi operation A lại quay lịch sự thực thi operation B rồi mới quay lại thực thi operation A tiếp.

4. Nguyên lý “either all occur, or nothing occurs” hoặc tất cả các operation đều thực thi thành đạt thì tiến trình mới được coi là thành công. Nếu chỉ một operation thực thi thất bại thì coi như toàn thể transaction là thất bại.

5. Nếu transaction thất bại thì toàn thể dữ liệu (dữ liệu nói chung, thực sự có thể trong memory, file trên đĩa cứng, dữ liệu trên thiết bị ngoại vi, dữ liệu trong cơ sở dữ liệu quan hệ,…) phải quay về (rollback) trạng thái ban sơ. Nghĩa là dữ liệu tạo mới phải bị xóa, sửa thì phải thay đổi lại đúng những gì trước khi sửa, dữ liệu lỡ xóa thì phải khôi phục lại,…

Kiểu của transaction

những kiểu transaction khác biệt được phân biệt bằng việc chia các operation như ra sao. Có hai kiểu (mô hình) transaction– transaction models là:

1. Flat Transaction – ngang hàng: Việc chia những operation là ngang hàng nhau

Thực thi các operation là tuần tự từ trái lịch sự phải hoặc từ trên xuống dưới.

2. Nested Transaction – lồng nhau: các operation lồng nhau

Việc thực thi những operation dựa theo nguyên tắc từ trong ra ngoài. Như vậy khi nhìn đến hình vẽ chúng ta thấy những operation ở dạng này có vẻ phụ thuộc vào nhau nhưng khi thực thi thì là độc lập theo luật lệ operation trong thực thi xong thì mới đến operation ngoài.

ACID properties trong transaction.

Mô hình ACID được gắn chặt với cơ sở dữ liệu quan hệ. Tuy nhiên, xét về transaction nói chung, chúng ta cũng thực sự có thể áp dụng các thuộc tính này vào. Xin được chú ý những đặc điểm của ACID chi tiết dưới đây.

Atomicity – tính đơn vị: Một transaction xác định ranh giới của nó rất , tức xác định điểm bắt đầu và kết thúc của tiến trình. Như vậy thực sự có thể coi nó như một đơn vị thực thi và đơn vị thực thi này thực hiện theo nguyên tắc “all or nothing”. Nghĩa là nếu một thành phần nào đó trong transaction thực thi hỏng (fail) thì đồng nghĩa với việc không có gì xảy ra tức không có gì thay đổi về mặt dữ liệu.

Consistency – nhất quán: Dữ liệu nhất quán với transaction ở lúc bắt đầu và kết thúc. Nhất quán ở transaction là strong consistency. Để tìm hiểu kỹ hơn về tính nhất quán, xin đọc lại bài viết NoSQL.

Isolation – độc lập: Nếu hai transaction thực thi cùng lúc thì phép tắc thực thi là thực thi độc lập. Nghĩa là một transaction không thể “nhìn thấy” một transaction khác. “Không nhìn thấy” ở đây là không tác động lẫn nhau, chủ yếu đuối trên dữ liệu.

Durability – bền vững: Dữ liệu của transaction sau khi thực thi xong được cố định, chính thức và bền vững. Nghĩa là các thay đổi đã được cố định, không có chuyện có thể chuyển lại trạng thái dữ liệu lúc trước khi thực hiện transaction.

Rủi ro khi thực thi transaction

Có ba loại rủi ro chính khiến việc thực thi một transaction thực sự có thể bị fail.

1. Việc thực thi operation bị hỏng: rõ ràng việc này sẽ dẫn tới transaction bị hỏng. điều đó đã được quy định  trong định nghĩa về transaction.

2. Vấn đề về phần cứng và mạng: việc phần cứng hoặc mạng có vấn đề trong thời điểm đang thực thi transaction sẽ dẫn đến tiến trình xử lý thất bại.

3. các vấn đề với dữ liệu dùng chung: Đây là vấn đề khó nhất. rõ ràng data là một tài nguyên dùng chung, do đó sẽ có những nguy cơ mà transaction gặp gỡ phải khi xử lý dữ liệu dùng chung này. Ta sẽ lưu ý kỹ hơn dưới đây.

Như chúng ta đã biết, phần mềm viết ra là để xử lý dữ liệu, 2 operations (phép) chính yếu của phần mềm với dữ liệu là đọc và ghi (read và write) trong đó phép write lại được chia nhỏ thành 3 operations bé dại hơn là insert (thêm mới), update (sửa), delete (xóa).

Dữ liệu là một tài nguyên dùng chung, nếu như có nhiều tiến trình xử lý đồng thời làm những phép trên dữ liệu sẽ diễn ra những rủi ro: write-write, write-read,… việc dữ liệu ghi cùng thời điểm dẫn tới hỏng dữ liệu hoặc dữ liệu đọc ra không đồng nhất với dữ liệu mới ghi vào,… sẽ đề cập kỹ hơn trong phần tiếp theo dưới đây.

Transaction Isolation Levels

Như đã đề cập ở trên, isolation – tính độc lập là một thuộc tính transaction tránh được những rủi ro do phải chung chạ data với những tiến trình xử lý khác. Khi có đồng thời 2 tiến trình xử lý trở lên, chúng ta sẽ thực sự có thể sẽ mắc phải database anomalies – cơ sở dữ liệu khác lại ( còn gọi là read phenomena – vấn đề đọc hoặc isolation problems) với 3 loại chính:

Dirty reads xảy ra khi transaction A tiến hành phép write với dữ liệu, transaction B tiến hành đọc dữ liệu sau khi A hoàn thành phép write. Tuy nhiên vì một nguyên nhân gì đó, transaction A không commit được, do đó sự đổi mới phép write không được chấp nhận, dữ liệu rollback lại trạng thái lúc đầu, khi đó dữ liệu của B sẽ thành ra dirty – bẩn.

Nonrepeatable reads xảy ra khi transaction A tiến hành phép read trên dữ liệu, sau đó transaction B làm phép write thực hiện dữ liệu đổi mới, lần kế tiếp A lại tiến hành phép read với chính dữ liệu. Như vậy, 2 lần đọc của A thấy dữ liệu không nhất quán (consistency) trên cùng một bản ghi.

Phantom reads là rủi ro xảy ra với lệnh read có điều kiện (chẳng hạn mệnh đề where trong sql). Transaction A đọc được một số X dữ liệu thỏa mãn điều khiếu nại 1, transaction B tiến hành phép write sinh ra một lượng Y dữ liệu thỏa mãn điều kiện , A tính toán lại với điều khiếu nại 1 thấy bổ sung thêm một lượng Y dữ và tổng dữ liệu giữa 2 lần trở lên không đồng nhất.

Như vậy, để tránh được các trường hợp của database anomalies chúng ta cần phải locks data – khóa dữ liệu, không cho những tiến trình xử lý khác thực hiện các operations trên dữ liệu khi transaction hiện thời đang làm việc và việc khóa này sẽ được mở (giải phóng) ở cuối transaction. Có 3 loại lock khác nhau gồm write locks, read locks, rang locks và isolation levels chỉ ra những mức độ locks khác biệt trên dữ liệu hay nói một cách khác là mức độ “ẩn” khác nhau của một transaction với những transactions khác đang thực thi ở cùng lúc. Dưới đây là danh sách isolation levels:

Serializable: Đây là mức cao nhất của isolation levels, đảm bảo read và write locks. Trong trường hợp phép read có mệnh đề điều kiện, Serializable cũng cần đòi hỏi range lock để tránh phantom reads.

Repeatable Reads: là mức thấp hơn Serializable có read và write locks nhưng không cần đến range locks. Với hoàn cảnh này, phantom reads có thể diễn ra.

Read committed: Chỉ bao gồm write locks, như vậy read committed chỉ đảm bảo dirty reads là không xảy ra.

Read uncommitted: Mức thấp nhất trong isolation levels trong đó cả ba dirty reads, nonrepeatable reads, phantom reads đều có thể xảy ra.

Nguồn tham khảo