Nếu Redis là Single Threaded, thì tại sao lại cần cơ chế Khóa.
Redis thực sự (hầu hết) là một luồng nhưng cần phải khóa khi nhiều máy khách cố gắng làm những việc khác nhau ở khoảng cách thời gian liền kề. Việc khóa được thảo luận trong RiA là về chính xác điều đó - đảm bảo rằng chỉ một máy khách / chuỗi thực hiện một tác vụ cụ thể hoặc đảm bảo rằng các bản cập nhật không bị lỗi.
Đây là một ví dụ tại sao bạn cần khóa bất chấp tính đơn luồng của Redis:giả sử bạn có một giá trị trong Redis, một số chẳng hạn được lưu trữ trong một khóa có tên foo . Mã ứng dụng của bạn đọc số đó (GET foo ), thực hiện một cái gì đó nó (tức là thêm 1) và viết nó trở lại (SET ). Khi bạn chạy mã của mình trong một chuỗi duy nhất, đây sẽ là cách nó trông như thế này:
App Redis
|---- GET foo ---->|
|<------ 1 --------|
| |
| thinking... |
| |
|--- SET foo 2 --->|
|<----- OK --------|
Bây giờ, hãy xem điều gì sẽ xảy ra khi hai ứng dụng khách thử làm điều này:
App 1 Redis App 2
|---- GET foo ---->| |
|<------ 1 --------|<--- GET foo -----|
| |------- 1 ------->|
| thinking... | |
| | thinking...|
|--- SET foo 2 --->| |
|<----- OK --------|<--- SET foo 2 ---|
| |------ OK ------->|
Tại đây, bạn có thể thấy ngay điều gì đã xảy ra mà không cần khóa, mặc dù máy chủ (chủ yếu) là một luồng - thay vì 3, foo Giá trị của là 2. Khi bạn thêm nhiều chuỗi / máy khách / ứng dụng hơn, mọi thứ có thể trở nên tồi tệ và sai nghiêm trọng khi nhiều người viết cố gắng sửa đổi dữ liệu mà không có sự phối hợp (tức là khóa).
Khóa lạc quan chỉ là một trong những cách để làm điều đó, mà Redis cung cấp tích hợp sẵn thông qua WATCH cơ chế. Tuy nhiên, đôi khi, sự lạc quan - mặc dù bản chất dễ dàng và vui vẻ - không phải là giải pháp phù hợp, vì vậy bạn sẽ cần triển khai các cơ chế tốt hơn / nâng cao / khác biệt để ngăn chặn các điều kiện chủng tộc. Có thể cho rằng những ổ khóa như vậy có thể được triển khai ngay cả bên ngoài Redis, nhưng nếu bạn đã sử dụng nó thì bạn cũng nên quản lý ổ khóa của mình trong đó.
