Tôi nên làm gì khi khóa lạc quan không hoạt động?

Tôi có kịch bản sau đây:

1. Một người dùng thực hiện một yêu cầu GET/projects/1 và nhận một ETag .
2. Người dùng thực hiện yêu cầu PUT/projects/1 với ETag từ bước # 1.
3. Người dùng thực hiện một yêu cầu PUT khác /projects/1với ETag từ bước # 1.

Thông thường, yêu cầu PUT thứ hai sẽ nhận được phản hồi 412, vì ETag hiện đã cũ - yêu cầu PUT đầu tiên đã sửa đổi tài nguyên, do đó, ETag không khớp nữa.

Nhưng điều gì sẽ xảy ra nếu hai yêu cầu PUT được gửi cùng một lúc (hoặc chính xác là một yêu cầu khác)? Yêu cầu PUT đầu tiên không có thời gian để xử lý và cập nhật tài nguyên trước khi PUT # 2 đến, điều này khiến PUT # 2 ghi đè lên PUT # 1. Toàn bộ quan điểm của khóa lạc quan là để điều đó không xảy ra ...

Cơ chế ETag chỉ định giao thức truyền thông để khóa tối ưu. Trách nhiệm của dịch vụ ứng dụng là thực hiện cơ chế phát hiện các cập nhật đồng thời để thực thi khóa tối ưu.

Trong một ứng dụng thông thường sử dụng cơ sở dữ liệu, bạn thường làm điều này bằng cách mở giao dịch khi xử lý yêu cầu PUT. Bạn thường đọc trạng thái hiện có của cơ sở dữ liệu trong giao dịch đó (để có được khóa đọc), kiểm tra tính hợp lệ Etag của bạn và ghi đè dữ liệu (theo cách sẽ gây ra xung đột ghi khi có bất kỳ giao dịch đồng thời không tương thích nào), sau đó cam kết. Nếu bạn thiết lập giao dịch chính xác, thì một trong những cam kết sẽ thất bại vì cả hai sẽ cố gắng cập nhật cùng một dữ liệu. Sau đó, bạn sẽ có thể sử dụng lỗi giao dịch này để trả về 412 hoặc thử lại yêu cầu, nếu nó có ý nghĩa đối với ứng dụng.

Bạn phải thực hiện cặp sau đây nguyên tử:

• kiểm tra tính hợp lệ của thẻ (tức là cập nhật)
• cập nhật tài nguyên (bao gồm cập nhật thẻ của nó)

Những người khác đang gọi đây là một giao dịch - nhưng về cơ bản, việc thực hiện nguyên tử của hai hoạt động này là điều ngăn cản người này ghi đè lên người kia một cách tình cờ; không có điều này bạn có một điều kiện cuộc đua, như bạn đang chú ý.

Đây vẫn được coi là khóa lạc quan, nếu bạn nhìn vào bức tranh lớn: rằng tài nguyên không bị khóa bởi lần đọc ban đầu (GET) bởi bất kỳ Người dùng hoặc bất kỳ Người dùng nào đang xem dữ liệu, cho dù có ý định cập nhật hay không.

Một số hành vi nguyên tử là cần thiết, nhưng điều này xảy ra trong một yêu cầu (PUT) thay vì cố gắng giữ khóa trên nhiều tương tác mạng; Đây là khóa lạc quan: đối tượng không bị khóa bởi GET nhưng vẫn có thể được cập nhật an toàn bằng PUT.

Cũng có nhiều cách để đạt được sự thực thi nguyên tử của hai hoạt động này - khóa tài nguyên không phải là lựa chọn duy nhất; ví dụ, một luồng nhẹ hoặc khóa đối tượng có thể đủ và phụ thuộc vào kiến ​​trúc và bối cảnh thực thi của ứng dụng của bạn.

Nhà phát triển ứng dụng thực sự kiểm tra Thẻ điện tử và cung cấp logic đó. Đó không phải là phép màu mà máy chủ web làm cho bạn vì nó chỉ biết cách tính E-Tagcác tiêu đề cho nội dung tĩnh. Vì vậy, hãy đưa kịch bản của bạn lên trên và phân tích cách tương tác sẽ xảy ra.

GET /projects/1

Máy chủ nhận được yêu cầu, xác định Thẻ điện tử cho phiên bản này của bản ghi, trả lại yêu cầu đó với nội dung thực tế.

200 - OK
E-Tag: "412"
Content-Type: application/json
{modified: false}

Vì ứng dụng khách hiện có giá trị Thẻ điện tử, nên nó có thể bao gồm điều đó với PUTyêu cầu:

PUT /projects/1
If-Match: "412"
Content-Type: application/json
{modified: true}

Tại thời điểm này, ứng dụng của bạn phải làm như sau:

• Xác minh rằng Thẻ điện tử vẫn đúng: "412" == "412"?
• Nếu vậy, hãy cập nhật và tính toán Thẻ điện tử mới

Gửi phản hồi thành công.

204 No Content
E-Tag: "543"

Nếu một yêu cầu khác xuất hiện và cố gắng thực hiện PUTtương tự như yêu cầu ở trên, lần thứ hai mã máy chủ của bạn đánh giá nó, bạn có trách nhiệm cung cấp thông báo lỗi.

• Xác minh Thẻ điện tử vẫn đúng: "412"! = "543"

Khi thất bại, gửi phản hồi thất bại.

412 Precondition Failed

Đây là mã bạn thực sự phải viết. Thẻ E trên thực tế có thể là bất kỳ văn bản nào (trong giới hạn được xác định trong thông số HTTP). Nó không phải là một con số. Nó có thể là một giá trị băm là tốt.

Để bổ sung cho các câu trả lời khác, tôi sẽ đăng một trong những trích dẫn hay nhất trong tài liệu ZeroMQ mô tả trung thực vấn đề cơ bản:

Để thực hiện các chương trình MT hoàn hảo (và ý tôi là theo nghĩa đen), chúng tôi không cần mutexes, khóa hoặc bất kỳ hình thức giao tiếp liên luồng nào khác ngoại trừ các tin nhắn được gửi qua các ổ cắm ZeroMQ.

Theo "chương trình MT hoàn hảo", ý tôi là mã dễ viết và dễ hiểu, hoạt động với cùng một cách tiếp cận thiết kế trong bất kỳ ngôn ngữ lập trình nào và trên bất kỳ hệ điều hành nào, và quy mô trên bất kỳ số lượng CPU nào có trạng thái chờ không và không có điểm lợi nhuận giảm dần.

Nếu bạn đã dành nhiều năm để học các thủ thuật để làm cho mã MT của bạn hoạt động hoàn toàn, hãy nhanh chóng, với các khóa và ngữ nghĩa và các phần quan trọng, bạn sẽ chán ghét khi bạn nhận ra tất cả chẳng là gì cả. Nếu có một bài học chúng ta đã học được từ hơn 30 năm lập trình đồng thời, đó là: chỉ cần không chia sẻ trạng thái. Giống như hai người say rượu cố gắng chia sẻ bia. Không thành vấn đề nếu họ là bạn tốt. Sớm muộn gì họ cũng sẽ đánh nhau. Và bạn càng thêm say vào bàn, họ càng đánh nhau với bia. Phần lớn bi thảm của các ứng dụng MT trông giống như những trận đánh ở quán rượu.