Dù đã nêu nhiều điểm cần cân nhắc ở bài trước, mình vẫn thấy Redlock là thuật toán có giá trị. Nó vừa hữu ích trong thực tế, vừa là điểm bắt đầu để tìm hiểu cách tư duy về hệ thống phân tán.

Theo kinh nghiệm của mình, những hạn chế lý thuyết của Redlock hiếm khi gây thảm họa trong thực tế. Lý do là kỹ sư chọn Redis thường không đặt cược mọi thứ vào nó. Họ xem Redis là công cụ nhanh nhưng vẫn có thể lỗi, dùng làm cache hoặc rate limiter. Với cách nghĩ đó, họ sẽ bổ sung biện pháp bảo vệ như unique constraint ở database, idempotency key và thao tác an toàn khi retry. Những tình huống lỗi Kleppmann mô tả là có thật, nhưng hệ thống vẫn có thể chịu được nếu không giả định mọi thứ luôn hoàn hảo.

Dài quá lười đọc: Redis là hệ thống AP, không phải CP, nên không đảm bảo strong consistency. Với những trường hợp có nhiều thao tác đồng thời, bạn cần lường trước khả năng xảy ra data race khi dùng Redis. Nếu cần đảm bảo chặt chẽ, hãy cân nhắc hệ thống có strong consistency như etcd hoặc ZooKeeper.

Lock trên một Redis instance duy nhất

Ở bài trước, chúng ta đã tìm hiểu cách cài đặt distributed lock bằng một Redis instance. Bài đó đã trả lời câu hỏi nếu client crash thì sao?, nhưng còn bỏ ngỏ một câu hỏi quan trọng: nếu chính Redis gặp sự cố thì sao?

Lưu ý: Ví dụ code trong bài dùng Go, nhưng các khái niệm cũng áp dụng được với những ngôn ngữ khác.

Tại sao cần lock?

Thử tưởng tượng hai người cùng rút tiền từ một tài khoản ngân hàng. Nếu không đồng bộ đúng cách, cả hai có thể đọc cùng một số dư, tự trừ khoản tiền mình rút rồi ghi kết quả lại. Khi đó xảy ra lost update: một lần rút tiền coi như biến mất khỏi số dư.