Review Transaction trong sql có các thuộc tính thường được viết tắt là acid nghĩa là gì?
Kinh Nghiệm về Transaction trong sql có những thuộc tính thường được viết tắt là acid nghĩa là gì? 2022
Lê Hữu Kông đang tìm kiếm từ khóa Transaction trong sql có những thuộc tính thường được viết tắt là acid nghĩa là gì? được Update vào lúc : 2022-07-22 15:44:02 . Với phương châm chia sẻ Bí quyết Hướng dẫn trong nội dung bài viết một cách Chi Tiết 2022. Nếu sau khi đọc nội dung bài viết vẫn ko hiểu thì hoàn toàn có thể lại Comment ở cuối bài để Mình lý giải và hướng dẫn lại nha.
Bài viết được sự được cho phép của tác giả Nguyễn Hữu Khanh
Nội dung chính- Các tính chất của TransactionCấu trúc transactionMột số vấn đề xuất hiện khi có hai transaction cùng hoạt độngVideo liên quan
Khái niệm transaction trong database là một khái niệm quan trọng mà tất cả những lập trình viên nên biết chính bới tất cả chúng ta sẽ thao tác rất nhiều với khái niệm này. Trong nội dung bài viết này, mình xin trình bày với những bạn về khái niệm này!
Để dễ tưởng tượng, mình xin lấy một ví dụ như sau: tất cả chúng ta đang thao tác với một ứng dụng bên ngân hàng nhà nước, ứng dụng này còn có một tính năng đó là chuyển tiền Một trong những tài khoản ngân hàng nhà nước với nhau, ví dụ chuyển tiền cho tài khoản A sang tài khoản B. Đây là một tính năng mà quá trình xử lý sẽ gồm 2 bước:
Tuyển database lương cao mê hoặc trên TopDev
Tuyển dụng IT lương cao nhiều ngành nghề
- Thứ nhất là trừ tiền trong tài khoản A
Và bước thứ hai là cộng tiền vào tài khoản B.
Rõ ràng, như những bạn thấy, đây là một quá trình nếu gọi là thành công thì bắt buộc 2 bước trên phải thành công, hoặc nếu thất bại thì bắt buộc 2 bước trên cũng phải thất bại luôn. Nếu chỉ một trong 2 bước trên thành công hoặc thất bại thì tất cả chúng ta sẽ gặp vấn đề ngay. Và tất cả chúng ta khi xây dựng ứng dụng cũng phải đảm bảo 2 điều kiện trên.
Đây đó đó là ý tưởng chính của khái niệm transaction trong database. Trong database, một transaction là một tập hợp những thao tác mà ở đó hoặc là những thao tác đó được thực hiện thành công, hoặc là không một thao tác nào được thực hiện thành công cả. Khi những bạn suy nghĩ về transaction trong database, những bạn hãy tưởng tượng nó là “hoặc là tất cả hoặc là không gì hết”.
Ở đây, tất cả chúng ta có một chữ viết tắt ACID (Atomicity, Consistency, Isolation, Durability) định nghĩa những tính chất của một transaction trong database.
Trong số đó:
- Atomicity: tính chất này thể hiện khái niệm “hoặc là tất cả hoặc là không gì hết”. Toàn bộ tiến trình được thực hiện trong một transaction nếu thành công thì phải thành công tất cả, nếu thất bại thì tất cả cũng phải thất bại. Nếu một transaction thành công thì tất cả những thay đổi phải được lưu vào database. Nếu thất bại thì tất cả những thay đổi trong transaction đó phải được rollback về trạng thái ban đầu.
Trong ví dụ của tớ, rõ ràng khi đã trừ tiền trong tài khoản A thì bắt buộc việc cộng tiền vào tài khoản B phải xảy ra. Còn không thì không còn gì xảy ra hết, đã không trừ tiền trong tài khoản A thì chắc như đinh rồi, việc cộng tiền vào tài khoản B cũng không xảy ra.
- Consistency: tài liệu từ thời điểm start transaction với lúc kết thúc phải nhất quán.
Trong ví dụ của tớ thì, nếu đã trừ 10$ trong tài khoản A thì trong tài khoản B phải được cộng 10$.
- Isolation: nếu tất cả chúng ta có nhiều transaction cùng một lúc thì phải đảm bảo là những transaction này xảy ra độc lập, không tác động lẫn nhau trên tài liệu.
Trong ví dụ của tớ, giả sử cùng môt lúc xảy ra 2 transaction như trên thì rõ ràng tất cả chúng ta không xác định được trạng thái của tài khoản A và tài khoản B sau khi thực hiện cùng 1 lúc. Mà điều này thì rất nguy hiểm.
- Durability: điều này còn có nghĩa tài liệu sau khi thực hiện transaction sẽ không thay đổi nếu tất cả chúng ta gặp vấn đề gì đó liên quan đến database.
Ví dụ sau khi chuyển tiền vào tài khoản B thành công thì dù database có gặp bất kể vấn đề gì thì tài khoản B vẫn đảm bảo đã nhận đủ 10$.
Bài viết gốc được đăng tải tại huongdanjava.com
Có thể bạn quan tâm:
Hôm nay tôi muốn đưa bạn tất cả trở lại cho một trong những thắc mắc phỏng vấn về cơ rất độc đáo mà tôi thấy thường xuyên sử dụng trong những buổi phỏng vấn. Tôi đã từng viết về tính chất ACID này. Trong sự nghiệp của tôi, tôi đã thấy nó trong Hàng trăm cuộc phỏng vấn. Một trong những dịch vụ phổ biến nhất của tôi là giúp mọi người với những thắc mắc phỏng vấn và câu những trả lời. Tôi thường quan sát thấy khi phỏng vấn hết những thắc mắc để hỏi và suy nghĩ của những thắc mắc tiếp theo, họ thường hỏi thắc mắc về thuộc tính ACID của những cơ sở tài liệu.
Câu hỏi: ACID là gì trong cơ sở tài liệu?
Trả lời:
ACID (viết tắt của Atomicity, Consistency, Isolation, Durability) là một khái niệm cơ sở tài liệu mà những Chuyên Viên thường tìm kiếm khi đánh giá những cơ sở tài liệu và kiến trúc ứng dụng. Đối với một cơ sở tài liệu đáng tin cậy tất cả bốn thuộc tính cần đạt được.
Atomicity là một đề xuất tất cả hoặc không còn gì. Tính chất này đảm nói rằng khi một thanh toán giao dịch thanh toán liên quan đến hai hay nhiều xử lý, hoặc là tất cả những xử lý được thực hiện hoặc không còn xử lý được thực hiện.
Consistency đảm nói rằng một thanh toán giao dịch thanh toán không bao giờ được thông qua cơ sở tài liệu của bạn trong tình trạng dở dang. Tính chất này, hoặc là tạo ra toàn bộ trạng thái mới hoặc rollback tất cả những xử lý để về trạng thái ban đầu, nhưng không bao giờ thông qua cơ sở tài liệu trong trạng thái dở dang.
Isolation giữ thanh toán giao dịch thanh toán tách rời nhau cho tới lúc chúng đã hoàn tất. Tính chất này đảm nói rằng hai hoặc nhiều thanh toán giao dịch thanh toán không bao giờ được trộn lẫn với nhau, tạo ra tài liệu không đúng chuẩn và không phù hợp.
Durability đảm nói rằng cơ sở tài liệu sẽ theo dõi những thay đổi cấp phép trong một cách mà những sever hoàn toàn có thể phục hồi từ một sự kết thúc không bình thường. Tính chất này đảm nói rằng trong trường hợp thất bại hay dịch vụ khởi động lại những tài liệu có sẵn trong trước khi gặp lỗi.
Các tính chất ACID của cơ sở tài liệu được mô tả trong ISO / IEC 10.026-1: 1992 phần 4. Ghi số này nếu bạn muốn gây ấn tượng với người phỏng vấn với kiến thức và kỹ năng của bạn. Bạn biết rằng anh ta sẽ hỏi thắc mắc này, tốt hơn sẵn sàng để trả lời thắc mắc này đúng chuẩn và gây ấn tượng với anh ấy / cô ấy.
Trích nguồn từ: (://blog.sqlauthority.com/2022/04/10/acid-properties-database-interview-question-week-066/)
Transaction là một tiến trình xử lý có xác định điểm đầu và điểm cuối, được chia nhỏ thành những 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 nguyên tắc hoặc tất cả đều thành công 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 tài liệu phải rollback (trở lại) trạng thái ban đầu.
Các tính chất của Transaction
Một transaction đòi hỏi phải có 4 tính chất ACID. ACID là viết tắt của cụm từ Atomicity (nguyên tử), Consitency (nhất quán), Isolation (Cô lập), và Durability (Lâu bền). Đây là những thuộc tính mà mọi transaction đều được đảm bảo bởi SQL Server.
- Atomicity: Mọi thay đổi về mặt tài liệu phải được thục hiện trọn vẹn khi transaction thực hiện thành công hoặc không còn bất kì sự thay đổi nào về mặt tài liệu nếu có xẩy ra sự cố.
Consistency: Sau khi một transaction kết thúc thì tất cả tài liệu phải được nhất quán dù thành công hay thất bại.
Isolation: Các transaction khi đông thời thực thi trên khối mạng lưới hệ thống thì không còn bất kì ảnh hưởng gì tời nhau.
Durability: Sau khi một transaction thành công thì tác dụng mà nó tạo ra phải bền vững trong cơ sở tài liệu mặc dầu khối mạng lưới hệ thống có xẩy ra lỗi.
Cấu trúc transaction
Một transaction được định nghĩa nhờ vào:
- BEGIN TRANSACTION: Bắt đầu một transaction
SAVE TRANSACTION: Đánh dấu vị trí trong transaction(điểm đánh dấu)
ROLLBACK TRANSACTION: Quay lui lại đầu transaction hoặc điểm đánh dấu trước đó trong transaction.
COMMIT TRANSACTION: Đánh dấu điểm kết thúc của một transaction, khi câu lệnh này thực thi nghĩa là transaction thực hiện thành công.
ROLLBACK WORK: Quay lui lại đầu transaction.
COMMIT WORK: Đánh dấu kết thúc transaction.
Một số vấn đề xuất hiện khi có hai transaction cùng hoạt động và sinh hoạt giải trí
Cùng một lúc, DB hoàn toàn có thể được truy cập bởi nhiều clients. Nếu những clients cùng truy xuất vào một phần tài liệu, thì sẽ nảy sinh những vấn đề liên quan đến tình trạng tranh chấp.Để xử lý và xử lý những vấn đề tranh chấp nêu trên, hệ quản trị cơ sở tài liệu cần sử dụng những phương thức khóa, nhờ vậy mà khi có tranh chấp xảy ra hệ quản trị cơ sở tài liệu hoàn toàn có thể quyết định transaction nào được thực hiện và transaction nào phải chờ.
Transaction 1 Transaction 2 Nhận xét Đọc Đọc Không có tranh chấp Đọc Ghi Xảy ra tranh chấp Ghi Đọc Xảy ra tranh chấp Ghi Ghi Chỉ được cho phép có đúng 1 transaction được ghi trên đơn vị tài liệu tại thuở nào điểmTrong môi trường tự nhiên thiên nhiên truy xuất đồng thời, hoàn toàn có thể xảy ra một số trong những vấn đề như sau:
- Mất tài liệu update (Dirty Write)
- Tình trạng này xảy ra khi có nhiều hơn nữa một giao tác cùng thực hiện update trên 1 đơn vị tài liệu. Khi đó, tác dụng của giao tác update thực hiện sau sẽ đè lên tác dụng của thao tác update trước.
- Đọc tài liệu chưa commit (Uncommitted data, Dirty read)
- Xảy ra khi một giao tác thực hiện đọc trên một đơn vị tài liệu mà đơn vị tài liệu này đang bị update bởi một giao tác khác nhưng việc update không được xác nhận.
- Giao tác đọc không thể lặp lại (Unrepeatable data)
- Tình trạng này xảy ra khi một giao tác T1 vừa thực hiện xong thao tác đọc trên một đơn vị tài liệu (nhưng chưa commit) thì giao tác khác (T2) lại thay đổi (ghi) trên đơn vị tài liệu này. Điều này làm cho lần đọc sau đó của T1 không hề nhìn thấy tài liệu ban đầu nữa.
- Là tình trạng mà một giao tác đang thao tác trên một tập tài liệu nhưng giao tác khác lại chèn thêm những dòng tài liệu vào tập tài liệu mà giao tác kia quan tâm.
Giải pháp xử lý
- Thực hiện cơ chế Transaction và cơ chế khóa. Một transaction khi muốn update bất kể bản ghi nào, sẽ phải giữ lock cho bản ghi đó, lock này chỉ được trả lại sau khi transaction đã commit hoăc bị rollback. Nếu lock của bản ghi đang bị giữ bởi transaction khác, transaction hiện tại sẽ phải đợi cho tới khi lock đó được trả lại.
Trước khi transaction đọc hoặc sửa đổi tài liệu, nó cần phải bảo vệ và tránh ảnh hưởng của những transaction khác đang sửa đổi cùng tài liệu.
Transaction yêu cầu khóa tài liệu đang dùng.
Có nhiều Mode khóa rất khác nhau phụ thuộc vào mức độ phụ thuộc tài liệu của transaction.
Sẽ không còn transaction nào được cấp khóa nếu gây xung đột với mode khóa đã được cấp trên cùng tài liệu cho một transaction khác trước đây đó.
Nếu transaction yêu cầu một mode khóa xung đột , DBMS sẽ bắt transaction này tạm dừng cho tới lúc transaction trước đó được giải phóng.
Tất cả những khóa sẽ được giải phóng khi transaction hoàn thành xong.
Hầu hết những DBMS đa người tiêu dùng đều tự động thực thi những thủ tục khóa.
Lock Manager có trách nhiệm gán và tạo chủ trương khóa cho những transaction.
Khi nên phải sử dụng câu lệnh SQL, query processor sẽ xác định tài nguyên nào được truy xuất, loại khóa nào cần dùng, thiết lập mức độ cô lập (Isolation level) cho transaction. Kế đến query processor yêu cầu một khóa phù hợp từ lock manager. Lock Manager sẽ cấp khóa nếu không còn xung đột.
Tài liệu tham khảo https://kipalog.com/posts/DB-Transaction https://techmaster/posts/26316/transaction-la-gi
Post a Comment