2010-04-08 38 views
7

Tôi đang đọc một bài viết về khung phân tích Gizzard được phát hành gần đây của twitter (http://engineering.twitter.com/2010/04/introducing-gizzard-framework-for.html). Nó đề cập rằng tất cả các hoạt động ghi phải là idempotent để đảm bảo độ tin cậy cao.Làm thế nào để viết idempotent hoạt động ghi?

Theo wikipedia, "Hoạt động không cần thiết là các hoạt động có thể được áp dụng nhiều lần mà không thay đổi kết quả." Nhưng, IMHO, trong trường hợp Gizzard, các hoạt động viết idempotent phải là những hoạt động trong đó chuỗi không quan trọng.

Bây giờ, câu hỏi của tôi là: Làm thế nào để tôi làm cho hoạt động viết idempotent?

Điều duy nhất tôi có thể tưởng tượng là phải có số phiên bản được đính kèm với mỗi lần viết. Ví dụ: trong hệ thống blog, mỗi blog phải có $ blog_id$ nội dung. Ở cấp ứng dụng, chúng tôi luôn viết nội dung blog như thế này write ($ blog_id, $ content, $ version). $ version được xác định là duy nhất ở cấp ứng dụng. Vì vậy, nếu một ứng dụng đầu tiên cố gắng đặt một blog thành "Xin chào thế giới" và thứ hai muốn nó là "Tạm biệt", thì viết là không có giá trị. Chúng tôi có hai thao tác ghi như vậy:

write($blog_id, "Hello world", 1); 
write($blog_id, "Goodbye", 2); 

Hai hoạt động này được cho là thay đổi hai bản ghi khác nhau trong DB. Vì vậy, không có vấn đề bao nhiêu lần và những gì trình tự hai hoạt động này được thực hiện, kết quả là như nhau.

Đây chỉ là sự hiểu biết của tôi. Nêu tôi sai vui long chân chỉnh tôi.

Trả lời

3

Bạn hoàn toàn đúng. Các hoạt động độc lập của bản thân có thể chỉ cung cấp một mẫu giải quyết xung đột - "Ghi lần cuối thắng". Đó là một giải pháp khả thi nếu viết của bạn không thể sắp xếp lại theo thời gian. Nếu có thể, bạn nên cung cấp thông tin bổ sung để tự động giải quyết xung đột. Và ý tưởng của bạn không phải là mới. Trong trường hợp chung, nó được gọi là vector clocks.

Chúng tôi sử dụng giải pháp xung đột dựa trên phiên bản trong một trong các hệ thống của chúng tôi thu thập lịch sử thay đổi của các đối tượng trong hệ thống của chúng tôi. Khách hàng gửi thông tin trạng thái và phiên bản đầy đủ cho mô-đun lịch sử (không đồng bộ). Mô-đun lịch sử sau đó có thể sắp xếp lại trạng thái đối tượng theo cách chính xác và chỉ lưu đồng bằng trong lưu trữ liên tục. Hạn chế duy nhất là khách hàng nên sử dụng một số loại kiểm soát đồng thời khi thực hiện thay đổi đối tượng (optimistic locking là phương pháp rất tốt nếu bạn theo dõi phiên bản trạng thái đối tượng).

2

Bạn có ý tưởng đúng. Đặt một giá trị cụ thể là không có giá trị, bởi vì nếu bạn thực hiện thao tác đó nhiều lần, bạn sẽ có kết quả tương tự. Viết không idempotent cổ điển là một phụ thêm, bởi vì sự lặp lại sẽ dẫn đến nhiều bản sao được nối thêm.

Ngoài ra, hãy xem điều này previous stackoverflow question.

Các vấn đề liên quan