50 năm sau, liệu two-phase locking vẫn là điều tốt nhất chúng ta có thể làm?

• Bài viết này thảo luận về khái niệm Two-Phase Locking (2PL), một cơ chế kiểm soát đồng thời phổ biến được phát minh cách đây khoảng 50 năm.
• 2PL cung cấp các mức cô lập mạnh hơn như Serializability và Opacity, và được dùng cho các giao dịch trên nhiều mục dữ liệu.
• Tác giả nhấn mạnh rằng sự đơn giản của 2PL và các mức cô lập mạnh là những ưu điểm chính của nó.
• Tuy nhiên, 2PL có nhược điểm là khả năng mở rộng khi đọc kém và hiện tượng tiến triển live-lock.
• Tác giả giới thiệu Two-Phase Locking Starvation-Free (2PLSF), một cơ chế kiểm soát đồng thời mới nhằm giải quyết các vấn đề của 2PL.
• 2PLSF sử dụng khóa reader-writer tốt hơn và cung cấp các giao dịch không bị đói tài nguyên, là hình thức tiến triển chặn mạnh nhất.
• 2PLSF hiệu quả trong việc giải quyết một số loại xung đột nhất định, nên vẫn có thể mở rộng ngay cả khi xuất hiện một số xung đột.
• Tác giả kết luận rằng 2PLSF là một cải tiến lớn so với 2PL, và ví sự khác biệt này như giữa búa máy và cuốc chim.
• Bài viết có kèm các liên kết tới bài báo học thuật và mã nguồn về thuật toán 2PLSF để tham khảo và tìm hiểu thêm.

[GN⁺]

Ý kiến trên Hacker News

• Bài viết bàn về two-phase locking (2PL) và mức độ còn phù hợp của nó sau 50 năm kể từ khi lần đầu được phát triển.
• Một người bình luận cho biết mình là người mới với chủ đề này và đang tìm một giải pháp nhất quán dễ triển khai cho kiến trúc microservice phân tán.
• Cũng người bình luận đó chia sẻ mã Python để kiểm thử tính bất định trong môi trường multiprocessing đa luồng.
• Một người bình luận khác đề xuất trước tiên nên cân nhắc liệu có thực sự cần thuật toán khóa hay không, đồng thời gợi ý xử lý theo lô các yêu cầu để giảm đồng thời và khóa.
• Có câu hỏi được đặt ra về việc cách tiếp cận mới này so sánh ra sao với Serializable Snapshot Isolation (SSI), vốn được quảng bá như một phiên bản cải tiến của 2PL.
• Một người bình luận đề xuất Hacker News cần có chính sách mới yêu cầu mọi liên kết được đăng phải dùng HTTPS.
• Một liên kết tới bài báo về 2PLSF của tác giả, trong đó lập luận rằng đây là điều 2PL lẽ ra phải là ngay từ đầu, đã được chia sẻ.
• Có đề xuất thêm hàng đợi ngẫu nhiên để cải thiện khả năng mở rộng của các thao tác nguyên tử.
• Có câu hỏi được đặt ra về việc trong cách tiếp cận Wait-Or-Die, liệu có cần lấy và gắn thêm transaction ID hay không, đồng thời gợi ý dùng thread ID hoặc số ngẫu nhiên thay thế.
• Một người bình luận cho biết họ không hiểu hình cuối cùng về cây AVL nới lỏng trong bối cảnh transaction chỉ đọc.
• Có câu hỏi được đặt ra về khả năng áp dụng 2PL trong bối cảnh các lệnh gọi API liên kết lỏng lẻo.
• Một người bình luận nêu ra rằng phần lớn transaction ghi cần các lượt đọc nhất quán trên nhiều đối tượng có mức cạnh tranh cao, nhưng thao tác ghi thực tế thường chỉ trên một hoặc hai đối tượng, và đặt câu hỏi liệu 2PL có giải quyết được điều này hay không.