“Bài viết gốc đăng tải tháng 3 năm 2015 tại ObjectRocket.com/blog”
Redis® là một công cụ tuyệt vời, và cộng đồng công nghệ yêu thích nó! Nó đã đi một chặng đường dài từ việc là một dự án cá nhân nhỏ của Antirez đến trở thành tiêu chuẩn ngành cho lưu trữ dữ liệu trong bộ nhớ (in-memory data storage). Cùng với đó đến một tập hợp thực hành tốt nhất để sử dụng Redis đúng cách. Trong bài viết này, chúng tôi khám phá mười mẹo nhanh về việc sử dụng Redis chính xác.
1. Ngừng sử dụng KEYS
Được, có thể la mắng bạn không phải cách tốt để bắt đầu bài viết. Nhưng đây có thể là điểm quan trọng nhất. Quá thường xuyên, tôi nhìn vào instance Redis, kéo lên commandstats nhanh, và thấy một KEYS chói lọi nhìn thẳng vào mặt tôi. Với sự công平, từ góc độ lập trình, việc có pseudocode tương tự như sau có vẻ hợp lý:
for key in 'keys *': doAllTheThings() Nhưng khi bạn có, nói, 13 triệu key, mọi thứ sẽ chậm lại. Vì KEYS là O(n) nơi n là số key trả về, độ phức tạp của bạn bị ràng buộc bởi kích thước database. Ngoài ra, trong suốt toàn bộ hoạt động này, bạn không thể chạy bất cứ điều gì khác đối với instance của bạn.
Là một sự thay thế, hãy xem SCAN, cho phép bạn quét qua database của bạn theo từng phần thay thế. Điều này hoạt động trên iterator nên bạn có thể dừng và tiếp tục khi bạn thấy phù hợp.
2. Tìm ra cái gì đang làm chậm Redis
Vì Redis không có log chi tiết nhất, thường khó để truy tìm chính xác cái gì đang xảy ra bên trong instance của bạn. May mắn Redis cung cấp cho bạn tiện ích commandstat để hiển thị chi tiết tương tự ví dụ sau:
127.0.0.1:6379> INFO commandstats # Commandstats cmdstat_get:calls=78,usec=608,usec_per_call=7.79 cmdstat_setex:calls=5,usec=71,usec_per_call=14.20 cmdstat_keys:calls=2,usec=42,usec_per_call=21.00 cmdstat_info:calls=10,usec=1931,usec_per_call=193.10 Điều này cho bạn phân tích tất cả lệnh, bao nhiêu lần bạn đã chạy chúng, và số microsecond để thực thi (tổng và trung bình mỗi lần gọi). Để reset, chạy CONFIG RESETSTAT, và bạn có một bảng mới hoàn toàn.
3. Dùng Redis-Benchmark làm baseline, không phải chân lý tuyệt đối
Salvatore, người tạo ra Redis, đã nhấn mạnh: “Test Redis làm GET/SET giống như test Ferrari xem nó tốt đến đâu khi lau gương khi trời mưa.” Nhiều lần, mọi người đến hỏi tôi tại sao kết quả Redis-Benchmark của họ kém hơn tối ưu. Nhưng chúng ta phải tính đến nhiều yếu tố khác nhau, như:
- Hạn chế phía client
- Khác biệt phiên bản
- Test đang diễn ra
Redis-Benchmark cung cấp baseline tuyệt vời để đảm bảo redis-server của bạn hoạt động bình thường, nhưng nó không bao giờ nên được coi là một load test thực sự. Load test cần phản ánh cách ứng dụng của bạn hoạt động trong môi trường càng gần production càng tốt.
4. Hashes là người bạn tốt nhất của bạn
Mời hashes ăn tối. Ăn uống sung sướng với hashes. Bạn sẽ ngạc nhiên tại hạnh phúc chúng mang lại nếu bạn chỉ cho chúng cơ hội. Tôi đã thấy quá nhiều cấu trúc key như sau trước đây:
foo:first_name foo:last_name foo:address Trong ví dụ đó, foo có thể là username cho user, và mỗi dòng đó là một key riêng biệt. Điều này thêm khoảng trống cho lỗi và thêm key không cần thiết vào hệ thống. Thay vào đó, hãy xem xét hash. Bất ngờ bạn chỉ có một key:
127.0.0.1:6379> HSET foo first_name "Joe" (integer) 1 127.0.0.1:6379> HSET foo last_name "Engel" (integer) 1 127.0.0.1:6379> HSET foo address "1 Fanatical Pl" (integer) 1 127.0.0.1:6379> HGETALL foo 1) "first_name" 2) "Joe" 3) "last_name" 4) "Engel" 5) "address" 6) "1 Fanatical Pl" 127.0.0.1:6379> HGET foo first_name "Joe" 5. Đặt TTL (Time To Live)!
Khi nào có thể, hãy tận dụng key hết hạn. Ví dụ hoàn hảo là lưu trữ thứ gì đó như temporary authentication key. Khi bạn lấy auth key, dùng OAUTH làm ví dụ, bạn thường nhận được thời gian hết hạn. Khi bạn đặt key, đặt nó với cùng expiration, và Redis dọn dẹp cho bạn! Không còn cần KEYS để lặp qua tất cả những key đó.
6. Chọn chính sách xuất (eviction policy) phù hợp
Trong khi chúng ta nói về dọn dẹp key, hãy chạm đến eviction. Khi instance Redis của bạn đầy, Redis cố gắng evict key. Tùy thuộc vào use case, chúng tôi mạnh mẽ khuyến nghị volatile-lru — giả sử bạn có key hết hạn. Nếu bạn chạy cái gì đó như cache và không có expiry set, bạn có thể xem xét allkeys-lru. Chúng tôi khuyên bạn nên xem các tùy chọn có sẵn tại đây.
7. Nếu Dữ Liệu Của Bạn Quan Trọng, Hãy Đặt Trong try/except
Nếu dữ liệu tuyệt đối quan trọng phải đến instance Redis của bạn, tôi mạnh mẽ khuyến nghị đặt try/except. Vì hầu hết mọi người cấu hình Redis client để fire-and-forget, bạn nên luôn lập kế hoạch cho khi key không thực sự đến database. Độ phức tạp này thêm vào cuộc gọi Redis của bạn là gần như không có gì trong trường hợp này, và bạn có thể đảm bảo dữ liệu quan trọng của bạn đến nơi nó nên ở.
8. Đừng ngập một instance
Khi nào có thể, hãy chia workload giữa nhiều instance Redis. Redis Cluster có sẵn từ phiên bản 3.0.0. Redis Cluster cho phép bạn tách key giữa các tập primary và secondary cho trước dựa trên key range. Bạn có thể tìm phân tích đầy đủ về magic đằng sau Redis Cluster tại đây. Và nếu bạn tìm tutorial, không cần tìm đâu xa. Bạn có thể tìm nó tại đây. Bạn có thể tìm bài viết tuyệt vời về partitioning dữ liệu trên trang web redis.io.
9. Nhiều core = hiệu suất tốt hơn, đúng không?!
Sai. Redis là tiến trình single-threaded và sẽ, tối đa, tiêu thụ hai core nếu bạn bật persistence. Trừ khi bạn dự định chạy nhiều instance trên cùng host — hy vọng chỉ cho dev testing, trong trường hợp đó — bạn không nên cần hơn hai core cho một instance Redis.
10. HA tất cả mọi thứ!
Redis Sentinel hiện đã được test rất kỹ, và nhiều user đã chạy nó trong production (Rackspace ObjectRocket bao gồm). Nếu bạn phụ thuộc nhiều vào Redis cho ứng dụng của bạn, bạn cần xem xét giải pháp high availability (HA) để giữ bạn online. Tất nhiên, nếu bạn không muốn tự quản lý tất cả đó, Rackspace ObjectRocket cung cấp platform HA của chúng tôi với hỗ trợ 24×7. Hãy thử một lần.
Tìm hiểu thêm về Dịch Vụ DBA của Rackspace.
Sử dụng tab Phản Hồi để đưa ra bình luận hoặc đặt câu hỏi. Bạn cũng có thể nhấp vào Sales Chat để trò chuyện ngay và bắt đầu cuộc hội thoại.
Nhấp vào đây để xem Điều Khoản Dịch Vụ Đám Mây Rackspace.