Hãy tưởng tượng có một công cụ có thể tự động phát hiện các vấn đề về hiệu suất của JPA và Hibernate. Điều đó sẽ không tuyệt vời sao?
Chà, Hypersistence Optimizer là công cụ đó. Và nó hoạt động với Spring Boot, Spring Framework, Jakarta EE, Java EE, Quarkus hoặc Play Framework
Vì vậy, hãy tận hưởng thời gian dành cho những thứ bạn yêu thích hơn là khắc phục các vấn đề về hiệu suất trong hệ thống sản xuất của bạn vào tối thứ Bảy
Bạn có thể kiếm được nguồn thu nhập thụ động đáng kể từ việc quảng bá sách, khóa học, công cụ, đào tạo hoặc đăng ký huấn luyện của tôi
Nếu bạn quan tâm đến việc bổ sung thu nhập của mình, thì hãy tham gia chương trình liên kết của tôi
Giới thiệu
Trong bài viết này, tôi sẽ giải thích sự khác biệt giữa khóa lạc quan và bi quan, cũng như khi nào bạn nên sử dụng một hoặc các chiến lược kiểm soát đồng thời khác
xung đột
Tại khóa học Mạng ở trường đại học, tôi đã học được rằng có hai cách giải quyết xung đột hoặc va chạm
- phát hiện và thử lại, và đó chính xác là những gì thực hiện
- tránh chúng bằng cách chặn các máy phát đồng thời khác, giống như vậy
Xử lý xung đột thực sự giống nhau ngay cả khi sử dụng hệ thống cơ sở dữ liệu
Chúng tôi có thể cho phép xung đột xảy ra, nhưng sau đó chúng tôi cần phát hiện nó khi thực hiện giao dịch của mình và đó chính xác là cách hoạt động của khóa lạc quan
Nếu chi phí thử lại cao, chúng ta có thể cố gắng tránh xung đột hoàn toàn bằng cách khóa, đó là nguyên tắc đằng sau cách thức hoạt động của khóa bi quan
Sự cố cập nhật bị mất
Hãy xem xét sự cố Mất cập nhật bất thường, có thể xảy ra trên bất kỳ cơ sở dữ liệu nào đang chạy ở mức cô lập Đã cam kết đã đọc
Sơ đồ trên minh họa tình huống sau
- Alice đọc số dư tài khoản và giá trị là
50 - Ngay sau đó, Bob thay đổi số dư tài khoản từ
50thành20và cam kết - Giao dịch của Alice vẫn đang diễn ra và nghĩ rằng số dư tài khoản vẫn là
50, cô ấy rút40vì nghĩ rằng số dư cuối cùng sẽ là10 - Tuy nhiên, do giá trị đường viền đã thay đổi, CẬP NHẬT của Alice sẽ khiến số dư tài khoản ở giá trị âm
Lịch trình giao dịch này không thể tuần tự hóa vì nó không tương đương với việc đọc và ghi của Alice, sau đó là đọc và ghi của Bob hoặc Bob thực hiện giao dịch của mình trước, sau đó là Alice thực hiện giao dịch của cô ấy ngay sau đó
Việc đọc và ghi là xen kẽ, và đó là lý do tại sao sự bất thường của Mất cập nhật được tạo ra
khóa bi quan
Khóa bi quan nhằm mục đích tránh xung đột bằng cách sử dụng khóa
Trong sơ đồ trên, cả Alice và Bob sẽ nhận được khóa đọc [chia sẻ] trên hàng của bảng account khi đọc nó
Bởi vì cả Alice và Bob đều giữ khóa đọc [chia sẻ] trên bản ghi account với giá trị định danh là 1, không ai trong số họ có thể thay đổi nó cho đến khi một người giải phóng khóa đọc mà họ có được. Điều này là do thao tác ghi yêu cầu mua lại khóa ghi [độc quyền] và khóa đọc [chia sẻ] ngăn chặn khóa ghi [độc quyền]
Vì lý do này, CẬP NHẬT của Bob chặn cho đến khi Alice giải phóng khóa dùng chung mà cô ấy đã có được trước đó
Khi sử dụng SQL Server, cơ sở dữ liệu sẽ tự động lấy các khóa được chia sẻ khi đọc bản ghi ở mức cô lập Đọc lặp lại hoặc Có thể tuần tự hóa vì SQL Server sử dụng thuật toán 2PL [Khóa hai pha] theo mặc định
MySQL cũng sử dụng khóa bi quan theo mặc định khi sử dụng mức cô lập Serializable và khóa lạc quan cho các mức cô lập ít nghiêm ngặt khác
Khóa lạc quan
Khóa lạc quan cho phép xảy ra xung đột nhưng cần phát hiện xung đột tại thời điểm ghi. Điều này có thể được thực hiện bằng cách sử dụng đồng hồ vật lý hoặc logic. Tuy nhiên, vì đồng hồ logic tốt hơn đồng hồ vật lý khi thực hiện cơ chế kiểm soát đồng thời, nên chúng tôi sẽ sử dụng cột version để nắm bắt thông tin chụp nhanh hàng thời gian đọc
Cột version sẽ được tăng lên mỗi khi câu lệnh CẬP NHẬT hoặc XÓA được thực thi đồng thời được sử dụng để khớp với ảnh chụp nhanh hàng dự kiến trong mệnh đề WHERE
Vì vậy, khi đọc bản ghi account, cả hai người dùng đều đọc phiên bản hiện tại của nó. Tuy nhiên, khi Bob thay đổi số dư account, anh ấy cũng thay đổi phiên bản từ 1 thành 504
Sau đó, khi Alice muốn thay đổi số dư account, câu lệnh CẬP NHẬT của cô ấy sẽ không khớp với bất kỳ bản ghi nào vì giá trị cột phiên bản không còn là 1, mà là 504
Do đó, phương thức CẬP NHẬT 509 sẽ trả về giá trị là 200, nghĩa là không có bản ghi nào bị thay đổi và khung truy cập dữ liệu cơ bản sẽ đưa ra một 201 khiến giao dịch của Alice bị hủy bỏ
Vì vậy, Bản cập nhật bị mất được ngăn chặn bằng cách khôi phục các giao dịch tiếp theo đang hoạt động trên dữ liệu trạng thái
Ngày nay, nhiều hệ thống cơ sở dữ liệu quan hệ sử dụng khóa lạc quan để đảm bảo ACID. Công cụ MySQL của Oracle, PostgreSQL và InnoDB sử dụng MVCC [Kiểm soát đồng thời nhiều phiên bản], dựa trên khóa lạc quan
Vì vậy, trong MVCC, người đọc không chặn người viết và người viết không chặn người đọc, cho phép xung đột xảy ra. Tuy nhiên, tại thời điểm cam kết, công cụ giao dịch phát hiện xung đột và các giao dịch xung đột được khôi phục
Giao dịch cấp ứng dụng
Các hệ thống cơ sở dữ liệu quan hệ đã xuất hiện vào cuối những năm 70 và đầu những năm 80 khi các máy khách kết nối với máy tính lớn thông qua thiết bị đầu cuối. Tuy nhiên, ngày nay, đó không phải là trường hợp khi sử dụng trình duyệt web
Vì vậy, chúng tôi không còn thực hiện đọc và ghi trong ngữ cảnh của cùng một giao dịch cơ sở dữ liệu và Khả năng tuần tự hóa không còn đủ để ngăn chặn Mất cập nhật trong một cuộc hội thoại dài
Chẳng hạn, xem xét chúng tôi có trường hợp sử dụng sau
Khóa bi quan sẽ không giúp chúng tôi trong trường hợp này vì Alice đọc và ghi xảy ra trong các yêu cầu HTTP và giao dịch cơ sở dữ liệu khác nhau
Vì vậy, khóa tối ưu có thể giúp bạn tránh Mất bản cập nhật ngay cả khi sử dụng các giao dịch cấp ứng dụng kết hợp cả thời gian suy nghĩ của người dùng
Nếu bạn thích bài viết này, tôi cá là bạn cũng sẽ thích các Khóa học Sách và Video của tôi
Và có nhiều hơn nữa
Bạn có thể kiếm được một nguồn thu nhập thụ động đáng kể từ việc quảng cáo tất cả những sản phẩm tuyệt vời này mà tôi đã và đang tạo ra
Nếu bạn quan tâm đến việc bổ sung thu nhập của mình, thì hãy tham gia chương trình liên kết của tôi
Phần kết luận
Cả khóa bi quan và lạc quan đều là những kỹ thuật hữu ích. Khóa bi quan phù hợp khi chi phí thử lại một giao dịch rất cao hoặc khi sự tranh chấp lớn đến mức nhiều giao dịch sẽ bị hủy bỏ nếu sử dụng khóa lạc quan
Mặt khác, khóa lạc quan hoạt động ngay cả trên nhiều giao dịch cơ sở dữ liệu vì nó không phụ thuộc vào việc khóa các bản ghi vật lý
Theo dõi @vlad_mihalcea
Chèn chi tiết về cách thông tin sẽ được xử lý
TẢI NGAY
Có liên quan
Loại. Cơ sở dữ liệu, Ngủ đông Thẻ. bất thường, mất bản cập nhật, khóa lạc quan, khóa bi quan, Có thể tuần tự hóa
← Gói tìm nạp mặc định của JPA
Cờ theo dõi bế tắc của SQL Server →
8 Nhận xét về “ Lạc quan so với. Khóa bi quan ”
saiviswateja
Thực sự là một bài viết tốt đẹp
Sẽ chia sẻ điều này trong blog của tôi
vladmihalcea
Chơ để biết thêm
Vít Herain
Cảm ơn vì bài báo
Khóa lạc quan như được mô tả ở đây có khả thi với mức cô lập READ COMMITTED không?
Khi 2 giao dịch đang cạnh tranh cho cùng một hàng thì một trong các giao dịch phải đợi giao dịch kia hoàn thành hoặc khôi phục, điều đó có đúng không? . Mức cô lập nào sau đó nên được sử dụng để khóa lạc quan hoạt động như mong đợi?
Cảm ơn
vladmihalcea
Khóa lạc quan hoạt động tốt với Read Cam kết. Việc chặn duy nhất trong MVCC DB là để ghi và hầu hết các công cụ hiện nay đều sử dụng MVCC. Đọc không khóa theo mặc định trong MVCC
Vít Herain
Vâng, ý tôi là cập nhật cùng một hàng trong hai giao dịch đồng thời, không chỉ đọc nó. Chúng tôi sử dụng AWS Aurora Serverless PostgreSQL và chúng tôi không thể sử dụng khóa lạc quan. Một giao dịch đợi giao dịch kia hoàn thành và vẫn bị kẹt trên “CẬP NHẬT. Ở ĐÂU id = '. '" yêu cầu
Vậy MVCC là lý do tại sao điều này xảy ra?
vladmihalcea
Bạn không thể cập nhật cùng một bản ghi trong nhiều giao dịch. Giao dịch đầu tiên sẽ khóa bản ghi và giải phóng nó sau khi cam kết hoặc khôi phục. Điều này đúng cho cả 2PL và MCCC. Không có nó, bạn sẽ không có Nguyên tử
Hãy xem cuốn sách Tính bền bỉ Java hiệu suất cao của tôi để biết thêm thông tin
https. //vladmihalcea. com/books/hiệu suất cao-java-kiên trì/
Vít Herain
Tôi nghĩ rằng khóa lạc quan mang lại lợi thế là các giao dịch cập nhật cùng một bản ghi được thực hiện mà không cần chờ đợi giao dịch khác có khả năng bị lỗi [cuối cùng không có hàng nào được cập nhật], nhưng lỗi thực sự nhanh do không có chờ đợi. Nhưng bạn nói rằng khóa lạc quan hoàn toàn không mang lại lợi thế này và việc xử lý một số trường hợp chờ đợi là không thể tránh khỏi?
Cảm ơn
vladmihalcea
Khóa lạc quan, như MVCC, mang lại lợi thế là không phải dùng khóa chia sẻ/đọc, đó là trường hợp khóa bi quan hoặc 2PL. Tuy nhiên, khóa độc quyền/ghi là cần thiết cho bất kỳ cơ sở dữ liệu nào muốn cung cấp Nguyên tử. Nếu không, bạn có nguy cơ ghi bẩn khiến không thể khôi phục liên tục
Tôi có một khóa học video về chủ đề này nếu bạn quan tâm đến việc nắm vững mức độ phức tạp của chủ đề
Làm thế nào để tránh khóa bi quan trong chế độ ngủ đông?
Không cần thay đổi cấu trúc thực thể để khóa các hàng cơ sở dữ liệu. Để ngăn các giao dịch khác truy cập vào các hàng hoặc bảng cụ thể, chúng tôi đặt LockModeType trên một truy vấn hoặc khi gọi EntityManager. phương thức tìm . @NamedQuery và EntityManager.Khóa bi quan có thể gây bế tắc không?
Khóa bi quan là khi bạn khóa bản ghi để sử dụng độc quyền cho đến khi bạn hoàn thành bản ghi đó. Nó có tính toàn vẹn tốt hơn nhiều so với khóa lạc quan nhưng yêu cầu bạn phải cẩn thận với thiết kế ứng dụng của mình để tránh Bế tắc .Khóa bi quan hoạt động như thế nào?
Khóa bi quan . Những người dùng khác cố gắng cập nhật hồ sơ này được thông báo rằng một người dùng khác đang tiến hành cập nhật. Những người dùng khác phải đợi cho đến khi người dùng đầu tiên thực hiện xong các thay đổi của họ, do đó giải phóng khóa bản ghi. As soon as one user starts to update a record, a lock is placed on it. Other users who attempt to update this record are informed that another user has an update in progress. The other users must wait until the first user has finished committing their changes, thereby releasing the record lock.