Sai lầm thường gặp khi làm việc với Redis

Bizfly Cloud

1348

17-06-2022

Redis là hệ thống lưu trữ các key-value có nhiều tính năng và được người dùng ứng dụng rộng rãi. Nó hỗ trợ nhiều cấu trúc dữ liệu cơ bản như HASH, LIST, SET, SORTEDSET, STRING,... và cho phép bạn scripting bằng ngôn ngữ Lua. Tuy nhiên, nhiều người vẫn mắc phải sai lầm khi làm việc với Redis. 

Bài viết dưới đây Bizfly Cloud sẽ chỉ ra 7 sai lầm thường gặp khi làm việc với Redis để bạn có thể hạn chế các sai lầm và tận dụng tối đa lợi ích mà Redis mang lại. 

Không sử dụng mật khẩu cho Redis Instance

Đa số người dùng đều không đặt mật khẩu cho Redis Instance của mình và điều này không tốt đối với phiên bản hiện tại của Redis. Bởi người dùng không cần thay đổi từ file config redis.config hay restart Redis mà vẫn có thể sử dụng CONTEST SET/ CONFIG GET để thay đổi các config (cấu hình) bằng Command (câu lệnh) từ client. 

Việc không đặt mật khẩu sẽ dẫn tới các hệ luỵ nếu Redis Server bị tìm thấy và các hacker bên ngoài sẽ flushing toàn bộ Redis bằng cách sử dụng Config Set/Get để chạy các câu lệnh phức tạp. Vì thế, khi sử dụng Redis, bạn nên cài đặt mật khẩu để hạn chế tối đa các rủi ro.

KEYS

KEYS là điều đầu tiên mà bạn phải học khi bắt đầu sử dụng Redis bởi dữ liệu của Redis được lưu trữ dưới dạng key-value. Thông thường, nhiều người dùng không thực sự hiểu rõ về KEYS của Redis nên sử dụng nó một cách tuỳ tiện. Điều này có thể gây ra nhiều lỗi tiềm ẩn trên Prod mà rất có thể bạn sẽ gặp phải khi đang làm việc với Redis. Dưới đây là một số điểm lưu ý mà bạn cần biết về Redis Keys:

• Redis chạy "Single Thread".
• Redis chỉ có thể chứa tối đa 2^32 key, khoảng 4 tỷ key.
• Mỗi key có dung lượng tối đa là 512Mb.
• O(n) là độ phức tạp thuật toán của KEYS (dùng để tìm kiếm keys khi thoả mãn một pattern với n là tổng số key trong Redis).

Khi bạn tạo một ứng dụng phụ thuộc vào KEYS như dùng Redis làm bản sao của DB, nếu số lượng KEYS không quá lớn thì mọi thứ sẽ rất ổn. Tuy nhiên, theo thời gian, số lượng KEYS sẽ tăng lên rất lớn khiến cho Redis mất nhiều thời gian để tìm kiếm dữ liệu key bởi độ phức tạp của nó là O(n). 

Một nguyên nhân nữa gây ảnh hưởng tới performance của Redis là Redis chạy "single thread" nên trong khi Redis thực thi một truy vấn thì các truy vấn khác sẽ bị blocking (dừng lại) cho tới khi truy vấn kia kết thúc. Do đó, số lượng KEYS càng lớn thì Redis chạy càng chậm. Vì thế bạn nên sử dụng SCAN để giới hạn số lượng KEYS trước mỗi truy vấn, hạn chế cả server bị blocking trong một khoảng thời gian dài với số lượng KEYS lớn trong hệ thống.

HOT KEYS

Bạn cần phân chia dữ liệu cache trên nhiều Node/Shard với hệ thống lớn chạy Redis Cluster nhằm đáp ứng số lượng lớn request trên hệ thống. Mỗi KEY sẽ được phân bố đều trên các Node/Shard dựa vào Data của nó được phân bố ở đâu và việc này được xác định bằng việc băm KEY bằng một hàm băm ổn định. Tuy nhiên, nếu so với phần còn lại (HOT KEYS), một vài KEYS nhỏ được truy vấn quá nhiều sẽ dẫn tới việc một Node/Shard chứa HOT KEYS bị quá tải. Vì thế, việc sharding sẽ không còn ý nghĩa nữa.

Lấy một ví dụ đơn giản, ta có hệ thống Redis chạy Sharding với 99 Node, có 1 Node chứa HOT KEY là "sexy_ladies" chịu tới hàng triệu request / giây. Và đương nhiên, hàng triệu request đó chỉ tập trung một Node duy nhất mà không phải phân tải đều cho 98 Nodes còn lại. Muốn kiểm tra các HOT KEYS, Redis sẽ cung cấp cho bạn tham số - - hot keys như ví dụ sau: $ redis - cli -h localhost -p 6379 - -hot keys. 

Lời khuyên cho bạn là không nên tạo ra một lượng nhỏ các keys được sử dụng thường xuyên như các tham số setting trong hệ thống. Thay vào đó, bạn nên cố gắng phân tán nó ra thành nhiều keys khác nhau và phân chia đều ra từng Node/Shard.

Mở mỗi Connection một request

Với Redis, mỗi một Connection nên được lưu trữ lại trong một khoảng thời gian dài và được sử dụng cho nhiều request cùng lúc vào thời điểm đó. Tuy nhiên, các Developer thường không chú ý tới đặc điểm này mà mỗi request họ sẽ mở một Connection riêng. Điều này có thể không ảnh hưởng gì về mặt kỹ thuật nhưng lại ảnh hưởng khá nhiều tới performance của Redis.

Thay thế Database chính bằng Redis

Redis được thiết kế như một Cached layer nhưng trong một vài dự án, nó lại được sử dụng như một DB chính. Muốn sử dụng Redis như một DB chính, bạn cần thiết lập nhiều config khác nhau để bảo toàn dữ liệu hay tính khả dụng. Bởi với hệ thống Redis, bản chất của nó là một bộ đệm để tăng performance cho hệ thống hay giảm tải cho DB chính. Vì vậy, bạn nên sử dụng cơ chế AOF/snapshotting để backup dữ liệu nhằm đảm bảo tính consistency của Redis và Redis Sentinel để bảo đảm tính sẵn sàng.

Không giới hạn số lượng value trong các kiểu cơ sở dữ liệu dạng hash hay list như ZRANGE, SMEMBERS, LRANGE, HGETALL

Nếu không giới hạn số lượng value trong HGETALL sẽ khiến nó có quá nhiều Key và việc tìm kiếm một value trong HGETALL sẽ trở nên phức tạp hơn. Tương tự với kiểu dữ liệu dạng List như LRANCE hay Sorted Sets/ Sets như SMEMBERS/ZRANGE. Hãy giới hạn số lượng value trong các kiểu cơ sở dữ liệu và không nên chứa quá nhiều value trong một Redis key.

Trên cùng một Redis Instances sử dụng nhiều Database

Redis cung cấp một tính năng phân chia các Database khác nhau trên cùng một Instance và mỗi Redis Instance có nhiều khu Database khác nhau. Số lượng tối đa mà một Redis hỗ trợ trên mỗi Instance là 16 database và có thể sử dụng command SELECT để di chuyển qua các Database khác nhau. Trên mỗi DB, các key-value được lưu trữ một cách độc lập, mỗi key có thể trùng nhau trên mỗi Database. Lời khuyên là bạn không nên sử dụng Numbered Database trên single Redis Instance mà thay vào đó là nên chạy nhiều các Redis Instance một cách độc lập.

Redis mang đến nhiều tính năng vượt trội và tính ứng dụng cao. Tuy nhiên, bạn cần lưu ý để không mắc phải các sai lầm thường gặp khi làm việc với Redis như đã đề cập ở trên.