Sử dụng lock là một phương pháp đơn giản nhưng rất hữu ích khi mà các tiến trình khác nhau trong nhiều môi trường phải vận hành và chia sẻ các tài nguyên theo cách đồng bộ. Tuy nhiên, quản lý lock như thế nào lại là một bài toán không đơn giản.
Redis có đầy đủ các tính năng mà ta có thể sử dụng như một công cụ quản lý lock trong hệ thống phân tán, và Redis Lab cũng đưa ra một giải thuật mà họ gọi là Redlock để quản lý lock khi sử dụng Redis.
Redis Lab đưa ra ba tiêu chí tối thiểu để sử dụng lock phân tán một cách hiệu quả:
-
Safety property: Loại trừ lẫn nhau. Tại bất kì thời điểm nào thì chỉ có duy nhất một client được phép giữ lock.
-
Liveness property A: Giải phóng deadlock. Một tài nguyên không được phép bị lock mãi mãi, ngay cả khi một client đã lock tài nguyên đó nhưng bị treo hoặc gặp sự cố.
-
Liveness property B: Tính chịu lỗi: Nếu phần lớn các node Redis vẫn đang hoạt động thì client vẫn có thể nhận và giải phóng lock.
Cách đơn giản nhất khi sử dụng Redis để lock một tài nguyên đó là tạo ra một key. Key này thường được tạo có giới hạn thời gian tồn tại bằng cách sử dụng tính năng expire của Redis, vì vậy nó sẽ đảm bảo lock luôn luôn được giải phóng. Khi một máy client cần giải phóng tài nguyên thì chỉ cần xóa bỏ key đã tạo.
Bề ngoài thì rất hợp lí, nhưng có một vấn đề lớn ở đây. Chuyện gì sẽ xảy ra nếu Redis master bị ngừng hoạt động? Đơn giản, hãy chuyển sang sử dụng slave! Thoạt nghe thì điều này không có gì sai, nhưng việc này lại không thể thực hiện được. Chính điều này dẫn đến tiêu chí Loại trừ lẫn nhau không được triển khai vì Redis không đồng bộ.
Ví dụ sau giải thích tại sao sử dụng slave lại không được:
- Client A nhận lock ở master.
- Master bị treo trước khi đồng bộ
keysangslave. - Slave bây giờ được chuyển thành master.
- Client B nhận lock trên cùng tài nguyên với client A đang giữ lock. Vì vậy tính loại trừ đã bị vi phạm!
Trước khi cố gắng tìm cách vượt qua những giới hạn đã được mô tả ở trên, ta hãy kiểm tra tính đúng đắn của giải pháp trong một trường hợp đơn giản xem sao:
SET resource_name my_random_value NX PX 30000 Câu lệnh trên sẽ chỉ thiết đặt một key (NX option) nếu nó chưa tồn tại, với expire time là 30,000 ms (PX option). Key này được thiết lập giá trị là "myrandomvalue". Giá trị này phải là duy nhất trong tất cả client và tất cả yêu cầu tạo lock.
Về cơ bản thì sử dụng giá trị ngẫu nhiên là để có thể giải phóng lock theo cách an toàn, bằng tập lệnh gửi cho Redis: chỉ xóa key nếu nó tồn tại và giá trị đang lưu trữ bởi key đó phải giống với giá trị mà client mong đợi. Điều này được thực hiện bằng cách sử dụng Lua script sau đây:
if redis.call("GET", KEYS[1]) == ARGV[1] then
return redis.call("DEL", KEYS[1])
else
return 0
endĐiều này rất quan trọng để có thể tránh được việc xóa một lock đã được tạo bởi một client khác. Ví dụ, một client nhận lock, chặn một số hoạt động với thời gian lâu hơn thời gian tồn tại của lock đó, và sau đó xóa lock, trong khi thời điểm này lock đó đã được một client khác giữ. Chỉ sử dụng DEL sẽ không an toàn vì client này có thể xóa lock của một client khác đang giữ.
Ta đã tìm hiểu qua cách nhận và giải phóng một lock trên một instance đơn lẻ. Bây giờ, giả định là ta sẽ có N=5 Redis master, và các node này hoàn toàn độc lập với nhau, được đặt trên các máy khác nhau.
Để nhận lock, một client thực hiện các thao tác sau:
- Nhận thời gian hiện tại theo đơn vị mili giây.
- Cố gắng tạo lock tuần tự trong tất cả N instance, sử dụng cùng một tên
keyvà giá trị ngẫu nhiên cho tất cả instance. Trong suốt bước 2, khi thiết đặt lock trong mỗi instance, client sử dụng một timeout nhỏ hơn so với tổng thời gian tự động giải phóng lock để tạo lock. Ví dụ, nếu thời gian giải phóng lock tự động là 10 giây, thì timeout có thể nằm trong khoảng 5-50 ms. Việc này ngăn chặn client cố gắng kết nối với một Redis node bị treo trong một thời gian dài: nếu một instance không sẵn dùng, ta nên thử kết nối với instance tiếp theo càng sớm càng tốt. - Client sẽ phải tính toán xem bao nhiêu thời gian đã trôi qua để nhận được lock bằng cách sử dụng thời gian hiện tại đã lấy được từ bước 1. Nếu và chỉ nếu client nhận được lock trong phần lớn các instance (ít nhất là 3), và tổng thời gian trôi qua để có được lock ít hơn thời gian hiệu lực của lock, lock đó sẽ được nhận.
- Nếu lock đã được nhận, thời gian hiệu lực thực sự của nó chính là thời gian hiệu lực khởi tạo ban đầu trừ đi thời gian trôi qua trong lúc tạo lock, như đã được tính trong bước 3.
- Nếu client không thể nhận được lock vì một vài lí do (hoặc nó không thể tạo lock trên
N/2 + 1instance, hoặc thời gian hiệu lực là số âm), nó sẽ cố gắng unlock trên tất cả instance (ngay cả những instance mà nó cho rằng vẫn chưa tạo được lock).
Thuật toán này giả định thời gian trong mọi tiến trình phải xấp xỉ nhau và với cùng tốc độ
Khi một client không thể nhận được lock, nó nên cố gắng thử lại sau một thời gian trễ ngẫu nhiên để tránh không đồng bộ hóa nhiều client đang cố gắng tạo lock cho cùng một tài nguyên và trong cùng một thời điểm (điều này có thể dẫn đến tình trạng split-brain, thiếu nhất quán về dữ liệu, dữ liệu bị chồng chéo lên nhau, không client nào tạo được lock). Như vậy, một client nếu nhanh hơn sẽ lấy được lock trong phần lớn các Redis instance, đây là một cách nhìn khác dẫn của tình trạng split-brain, vì vậy lí tưởng nhất là client nên cố gắng gửi các lệnh SET đến N instance trong cùng một thời điểm bằng phương pháp ghép kênh.
Điều này nhấn mạnh tầm quan trọng của việc giải phóng lock ngay khi có thể khi client thất bại tạo lock trong phần lớn các instance.
Giải phóng lock không có gì phức tạp, chỉ việc giải phóng lock trong tất cả các instance cho dù client không biết là lock đó có được tạo trên một instance cụ thể nào hay không.
Chúng ta có thể thử trong các kịch bản khác nhau.
Giả sử, một client có thể nhận được lock trong phần lớn các instance. Tất cả instance sẽ cùng chứa một key với thời gian tồn tại giống nhau. Tuy nhiên, key này được thiết lập ở những thời điểm khác nhau, vì vậy key này cũng sẽ hết hạn ở những thời điểm khác nhau. Trong tường hợp xấu nhất là key đầu tiên được thiết lập ở thời điểm T1, và key cuối cùng được thiết lập ở thời điểm T2, ta vẫn chắc chắn được rằng key đầu tiên sẽ có thời gian tồn tại nhỏ nhất MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT. Tất cả những key khác sẽ hết hạn sau, vì vậy chúng ta chắc chắn rằng các key sẽ đồng thời được thiết lập với thời gian này.
Trong suốt khoảng thời gian này, phần lớn các key đã được thiết lập, một client khác sẽ không thể tạo lock vì N/2+1 lệnh SET NX không thể thành công nếu N/2+1 key đã tồn tại. Vì vậy nếu một lock được tạo, thì nó không thể được tạo lại trong cùng một thời điểm.
Tuy nhiên, chúng ta cũng muốn đảm bảo rằng nhiều client đang cố gắng tạo lock trong cùng một thời điểm không thể thành công đồng thời.
Nếu một client đã tạo lock trong phần lớn các instance sử dụng một thời gian bằng, hoặc lớn hơn thời gian hiệu lực tối đa, thì nó sẽ quyết định lock này không hợp lệ và sẽ unlock các instance đó. Vậy chúng ta chỉ cần xem xét trường hợp client có thể lock phần lớn các instance trong thời gian ít hơn thời gian hiệu lực. Trong trường hợp này, nhiều client có thể tạo được lock trên N/2+1 các instance ở cùng một thời điểm (với thời gian khi kết thúc ở bước 2) chỉ khi thời gian để tạo lock trong phần lớn các instance lớn hơn thời gian TTL, làm cho lock đó không hợp lệ.
