Tóm tắt: Khóa phân tán không thể tự chứng minh một tiến trình vẫn còn quyền sở hữu sau khi bị dừng hoặc mất kết nối.
Thuật ngữ chính: Lease: quyền sở hữu có thời hạn; fencing token: số tăng dần để chặn chủ sở hữu cũ; critical section: đoạn xử lý chỉ cho phép một tiến trình thay đổi.
Bài toán
Một tiến trình có thể bị tạm dừng lâu đến mức Lease hết hạn. Tiến trình khác nhận quyền xử lý, nhưng tiến trình cũ sau đó vẫn chạy tiếp. Tài nguyên đích phải tự từ chối những lần ghi mang quyền sở hữu đã cũ.
Vì sao cách làm đơn giản chưa đủ
Mutual exclusion trong một process khá rõ. Giữa nhiều máy, network delay khiến client không thể chắc mình còn giữ khóa.
Nhiều trường hợp không cần đúng một scheduler. At-least-once scheduling cùng job idempotent có thể đơn giản và an toàn hơn leader election.
Luồng xử lý
yêu cầu lease→Coordinator
cấp fencing token→tiến trình xử lý
xử lý hữu hạn→Resource
từ chối token cũ
Quyết định kiến trúc
Ưu tiên partition quyền sở hữu
Gán aggregate hoặc shard cho một tiến trình xử lý và rebalance rõ ràng để giảm số khóa.
Dùng monotonic fencing
Mỗi lần lấy lease nhận token lớn hơn. Kho lưu trữ so sánh atomically với token cuối.
Giới hạn critical section
Đặt deadline nhỏ hơn lease duration và ngừng nhận sub-work mới khi renewal không chắc chắn.
Phân tích chuyên sâu
Thời gian không phải quyền sở hữu
TTL giới hạn thời gian người khác chờ. Tuy nhiên, clock không thể thu hồi code đang chạy. Kho lưu trữ-side token bịt khoảng trống đó.
khóa không nên che product conflict
Hai người sửa cùng document có thể cần optimistic phiên bản và conflict UX, không phải infrastructure khóa.
Các bước triển khai
- Loại shared quyền sở hữu không cần thiết bằng partitioning hoặc idempotency trước.
- Dùng lease hữu hạn kèm fencing token tăng dần.
- Để protected resource từ chối token nhỏ hơn giá trị cuối đã nhận.
Ví dụ kỹ thuật: Fenced update
lease = coordinator.acquire(resourceId, ttl = 10s)
result = compute(deadline = lease.expiresAt - 2s)
UPDATE resource
SET value = :result, fence = :token
WHERE id = :id AND fence < :tokenkhóa coordinator thành công nhưng ghi không có fencing vẫn chưa đủ. Lý do là người phụ trách cũ bị pause có thể chạy lại.
Các tình huống lỗi cần tính trước
- Stop-the-world pause dài hơn lease.
- Coordinator quorum lỗi và client bất đồng về quyền sở hữu.
- External call dài hoàn tất sau khi lease đã chuyển.
Tín hiệu cần giám sát
| Tín hiệu | Ý nghĩa |
|---|---|
| Lỗi acquire và renew lease | Cho biết contention và sức khỏe coordinator. |
| Số fencing token cũ bị từ chối | Chứng minh stale người phụ trách có xảy ra và được chặn. |
| Thời lượng critical section | Phát hiện khối lượng công việc không còn phù hợp giả định lease. |
Cách kiểm chứng thiết kế
- Pause khóa holder quá TTL rồi cho chạy tiếp.
- Partition holder khỏi coordinator nhưng vẫn nối được kho lưu trữ.
- Chạy nhiều contender và chứng minh chỉ token tăng dần commit.
Kế hoạch triển khai an toàn
Đo critical section hiện tại, thêm idempotency và optimistic phiên bản trước. Sau đó, chỉ dùng fencing cho operation thật sự cần exclusive quyền sở hữu. Giữ công tắc dừng khẩn cấp về safe serial processing.
Checklist trước khi đưa vào vận hành
- Giả định về clock được ghi rõ và giảm tối đa.
- Renewal lỗi phải dừng nhận việc mới trước khi lease hết hạn.
- Operation dài có mốc lưu an toàn thay vì một critical section quá lớn.
Kết luận
khóa điều phối các lần thử. Fencing tại resource mới bảo vệ tính đúng đắn.