Redis hiện đang rất hot trong cộng đồng công nghệ. Nó đã trải qua một chặng đường dài từ việc trở thành một dự án cá nhân nhỏ của Antirez, trở thành một tiêu chuẩn công nghiệp về lưu trữ dữ liệu bộ nhớ. Cùng với đó là một loạt các phương pháp hay nhất mà hầu hết mọi người có thể đồng ý để sử dụng Redis đúng cách. Dưới đây, chúng ta sẽ khám phá 10 mẹo nhanh để sử dụng Redis đúng cách.
1. DỪNG SỬ DỤNG PHÍM *
Được rồi, vì vậy có thể quát tháo bạn không phải là cách tuyệt vời để bắt đầu bài viết này. Nhưng đó có thể là điểm quan trọng nhất. Tôi thường xuyên nhìn vào một phiên bản redis, kéo bảng lệnh nhanh lên và thấy một KEYS chói lọi đang nhìn chằm chằm vào tôi. Công bằng mà nói, xuất phát từ quan điểm lập trình, sẽ có ý nghĩa nếu có một mã psuedocode thực hiện một số việc như:
for key in 'keys *':
doAllTheThings()Nhưng khi bạn có 13 triệu chìa khóa, mọi thứ sẽ chậm lại. Vì KEYS là O (n) trong đó n là số lượng khóa được trả về, độ phức tạp của bạn bị ràng buộc bởi kích thước dbs. Ngoài ra, trong toàn bộ hoạt động này, không có gì khác có thể được chạy đối với phiên bản của bạn.
Thay vào đó, hãy kiểm tra SCAN cho phép bạn cũng… quét qua cơ sở dữ liệu của mình theo từng bước thay thế. Điều này hoạt động trên một máy tương tác, do đó bạn có thể dừng lại và tiếp tục khi bạn thấy phù hợp.
2. Tìm hiểu điều gì đang làm giảm tốc độ của Redis
Vì Redis không có nhật ký chi tiết nhất, nên thường khó theo dõi chính xác những gì đang diễn ra bên trong phiên bản của bạn. May mắn thay, Redis cung cấp cho bạn tiện ích commandstat để hiển thị cho bạn điều này:
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 cung cấp cho bạn bảng phân tích về tất cả các lệnh, số lần chúng đã được chạy, số micro giây nó cần để thực thi (tổng số và trung bình trên mỗi cuộc gọi)
Để đặt lại điều này, chỉ cần chạy CONFIG RESETSTAT và bạn đã có một phương tiện chặn hoàn toàn mới.
3. Sử dụng Redis-Benchmark làm cơ sở, không phải chân lý phúc âm
Salvatore, người tạo ra Redis đã nói một cách thông minh:“Để kiểm tra Redis thực hiện GET / SET giống như thử nghiệm một chiếc Ferrari để kiểm tra xem nó có tốt như thế nào trong việc lau gương khi trời mưa”. Rất nhiều lần mọi người đến gặp tôi thắc mắc tại sao kết quả Redis-Benchmark của họ kém hơn mức tối ưu. Nhưng chúng ta phải tính đến nhiều yếu tố khác nhau, chẳng hạn như:
- Chúng tôi có thể gặp phải những hạn chế nào về phía khách hàng?
- Có sự khác biệt trong cách lập phiên bản không?
- Các bài kiểm tra đang được thực hiện có liên quan đến những gì ứng dụng sẽ hoạt động không?
Redis-Benchmark cung cấp một đường cơ sở tuyệt vời để đảm bảo máy chủ redis của bạn không hoạt động bất thường, nhưng nó không bao giờ được coi là một “thử nghiệm tải” thực sự. Các bài kiểm tra tải cần phản ánh cách ứng dụng của bạn hoạt động và từ một môi trường gần với quá trình sản xuất nhất có thể.
4. Hashes là người bạn tốt nhất của bạn
Mời băm vào bữa tối. Rượu và bữa ăn tối băm. Bạn sẽ ngạc nhiên về hạnh phúc mà họ có thể mang lại nếu bạn chỉ cho họ cơ hội. Tôi đã thấy một quá nhiều cấu trúc chính như thế này trước đây:
foo:first_name
foo:last_name
foo:addressTrong ví dụ trên, foo có thể là tên người dùng cho một người dùng và mỗi một trong số đó là một khóa riêng biệt. Điều này tạo thêm chỗ cho các lỗi và thêm các chìa khóa không cần thiết vào màn hình gập. Thay vào đó, hãy xem xét một hàm băm. Đột nhiên, bạn chỉ có một khóa:
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 đó!
Bất cứ khi nào có thể, hãy tận dụng các khóa hết hạn. Một ví dụ hoàn hảo là lưu trữ một cái gì đó như khóa xác thực tạm thời. Khi bạn truy xuất khóa xác thực — hãy sử dụng OAUTH làm ví dụ — bạn thường được cung cấp thời gian hết hạn. Khi bạn đặt khóa, hãy đặt khóa với cùng thời hạn sử dụng và Redis sẽ dọn dẹp giúp bạn! Không cần KEYS * lặp lại tất cả các phím đó nữa, hả?
6. Lựa chọn chính sách trục xuất phù hợp
Trong khi chúng ta đang nói về chủ đề dọn dẹp chìa khóa, hãy cùng đề cập đến vấn đề trục xuất. Khi phiên bản Redis của bạn đầy, Redis sẽ cố gắng loại bỏ các khóa. Tùy thuộc vào trường hợp sử dụng của bạn, tôi thực sự khuyên bạn nên dùng biến động-lru — giả sử bạn có các khóa sắp hết hạn. Nếu bạn đang chạy thứ gì đó giống như bộ nhớ cache và không có bộ hết hạn, bạn có thể xem xét allkeys-lru. 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 thử / Ngoại trừ
Nếu dữ liệu được đưa vào phiên bản Redis của bạn là cực kỳ quan trọng, thì tôi thực sự khuyên bạn nên thử / ngoại trừ. Vì hầu hết tất cả các ứng dụng Redis đều được định cấu hình thành "fire-and-forget", nên luôn cần cân nhắc khi nào một khóa không thực sự xuất hiện trong cơ sở dữ liệu. Trong trường hợp này, sự phức tạp được thêm vào lệnh gọi redis của bạn không là gì cả và bạn có thể đảm bảo dữ liệu quan trọng của mình sẽ đến đúng vị trí của nó.
8. Đừng lũ lụt một trường hợp nào
Bất cứ khi nào có thể, hãy chia nhỏ khối lượng công việc giữa nhiều phiên bản Redis. Kể từ phiên bản 3.0.0, Redis Cluster hiện đã có sẵn. Redis Cluster cho phép bạn phá vỡ các khóa giữa các bộ chủ / nô lệ nhất định dựa trên phạm vi khóa. Có thể tìm thấy toàn bộ thông tin về ma thuật đằng sau Cluster tại đây. Và nếu bạn đang tìm kiếm một hướng dẫn, thì không cần tìm đâu xa. Nếu phân cụm không phải là một tùy chọn, hãy xem xét không gian tên và phân phối khóa của bạn giữa nhiều trường hợp. Bạn có thể tìm thấy một bài viết tuyệt vời về phân vùng dữ liệu của bạn trên trang web redis.io tại đây.
9. Nhiều lõi hơn =Tốt hơn, phải không ?!
Sai. Redis là một quá trình đơn luồng và tối đa sẽ tiêu thụ hai lõi nếu bạn đã bật tính năng bền bỉ. Trừ khi bạn có kế hoạch chạy nhiều phiên bản trên cùng một máy chủ — hy vọng chỉ để thử nghiệm nhà phát triển trong trường hợp đó! —Bạn sẽ không cần nhiều hơn hai lõi cho một phiên bản Redis.
10. HA All the Things!
Redis Sentinel hiện đã được thử nghiệm rất tốt và nhiều người dùng đã chạy nó trong phiên bản sản xuất (bao gồm ObjectRocket!). Nếu bạn đang phụ thuộc nhiều vào Redis cho ứng dụng của mình, thì bạn cần xem xét giải pháp HA (tính khả dụng cao) để giúp bạn luôn trực tuyến. Tất nhiên, nếu bạn không muốn tự mình quản lý tất cả những điều đó, ObjectRocket cung cấp nền tảng HA của chúng tôi với hỗ trợ 24 × 7 cho nhu cầu của bạn, hãy thử.