Hai khách hàng có thể cùng có bản ghi số 17. Nếu cache chỉ dùng khóa customer:17, một kết quả đã lưu có thể được trả sai phạm vi. Cache nhiều tenant phải giữ đúng ranh giới dữ liệu cả khi cache hit lẫn cache miss, và cả sau khi người dùng bị đổi quyền.
Key prefix là cấu trúc, không phải toàn bộ phân quyền
Microsoft mô tả mô hình cache chia sẻ và cache riêng từng tenant. Với cache chia sẻ, ứng dụng chịu trách nhiệm phân tách dữ liệu; tiền tố tenant giúp tổ chức khóa nhưng không tự thay thế kiểm quyền. Nếu mọi request vẫn có thể tự chọn tenant_id tùy ý, một convention tên khóa đẹp không ngăn truy cập sai.
Lấy tenant từ ngữ cảnh đã xác minh và kiểm quyền đối tượng trước khi trả dữ liệu. Khi kết quả thay đổi theo người dùng hoặc phạm vi quyền, key cần thể hiện phân vùng tương ứng hoặc thiết kế cache ở tầng dữ liệu không chứa phần cá nhân hóa. Không dùng một bản HTML đã chứa thông tin riêng như cache chung cho toàn tenant.
Ma trận thử cache hit và cache miss
| Ngữ cảnh | Tình trạng cache | Kết quả mong đợi |
|---|---|---|
| A được phép xem bản ghi 17 | Miss rồi hit | Cùng dữ liệu được phép |
| B có bản ghi 17 riêng | Khóa A đã nóng | Không nhận dữ liệu A |
| Người dùng A bị thu hồi quyền | Cache còn hạn | Không nhận bản cũ vượt quyền |
| A đổi phạm vi xem | Hit phiên bản cũ | Quyền hiện tại vẫn được thực thi |
Ví dụ giả định: cùng mã, khác khách hàng
Tenant A và B đều có item 17. Khóa minh họa có thể gồm tenant, loại thực thể, item và phiên bản định dạng. Nhưng key chỉ được tạo từ ngữ cảnh hợp lệ; không lấy tenant từ tham số chưa kiểm tra. Nếu dữ liệu còn phụ thuộc quyền xem giá, cần quyết định lưu dữ liệu chung rồi lọc theo quyền hay tách key theo scope. Không đưa thông tin riêng tư trực tiếp vào tên key.
Quyền đổi trước khi TTL hết
TTL giới hạn tuổi dữ liệu nhưng không phải chính sách thu hồi quyền. Khi người dùng mất quyền, request sau đó vẫn phải bị chặn dù cache còn nóng. Cần chốt cách invalidation cho dữ liệu thay đổi và cách kiểm quyền độc lập với tuổi cache. Khi xóa cache theo tenant, phạm vi lệnh phải được kiểm chứng để không xóa nhầm dữ liệu bên khác.
Cũng cần đánh giá tài nguyên chia sẻ. Tách key không tách CPU hoặc bộ nhớ; một tenant tải nặng vẫn có thể làm chậm tenant khác. Chọn cache riêng khi yêu cầu cô lập phù hợp, cân nhắc chi phí và vận hành, không coi đó là lựa chọn mặc định cho mọi hệ thống nhỏ.
Tiêu chí bàn giao hữu ích hơn tỷ lệ cache hit
- Convention key và các trường ngữ cảnh được tin cậy phải được mô tả.
- Ca đổi tenant, đổi người dùng và thu hồi quyền phải có kết quả mong đợi.
- Không log dữ liệu nhạy cảm chỉ để giải thích cache hit.
- Phân biệt lỗi dữ liệu cũ với lỗi truy cập sai phạm vi.
Các ca trên là đề xuất, không phải kết quả bảo mật đã được kiểm thử. Với phần mềm dùng chung cho nhiều đơn vị, hãy chốt ma trận quyền trước khi tối ưu cache. Một hệ thống nhanh hơn nhưng trả sai dữ liệu không phải cải thiện có thể nghiệm thu.
Nguồn tham khảo và giới hạn
Microsoft: Multitenancy and Azure Managed Redis (đọc ngày 13/10/2026). Các biểu mẫu và tình huống trong bài là hướng dẫn biên tập hoặc ví dụ giả định; không phải kết quả kiểm thử, dữ liệu khách hàng hay cam kết năng lực đã triển khai. Cách áp dụng cần đối chiếu nền tảng và quyền thực tế.
