Cuộc gọi Pager lúc 2 giờ sáng: Tại sao Redis Single-Node thất bại
Lúc đó là 2:14 sáng. Điện thoại của tôi rung bần bật trên tủ đầu giường. PagerDuty đang gào thét vì API production trả về lỗi 500 với tỷ lệ 90%. Tôi loạng choạng đi tới bàn làm việc, mắt cay xè vì ánh sáng xanh, chỉ để phát hiện instance Redis duy nhất của chúng tôi đã bị OOM (Out of Memory) killer tiêu diệt và biến mất. Vì đó là một node độc lập (standalone), toàn bộ dữ liệu session đã mất sạch. Tôi phải khởi động lại dịch vụ thủ công, đợi 4 phút để file RDB 12GB tải lên và cầu nguyện rằng dữ liệu không bị hỏng.
Nếu bạn đã từng trải qua chuyện này, bạn sẽ hiểu rằng “Single Point of Failure” (Điểm yếu duy nhất) không chỉ là một slide trong bài thuyết trình DevOps. Nó là công thức dẫn đến việc mất ngủ và khiến người dùng thất vọng. Để xây dựng một hệ thống có khả năng phục hồi (resilient), bạn phải vượt qua mô hình instance đơn lẻ. Trong thế giới Redis, điều đó có nghĩa là chọn giữa hai kiến trúc khác biệt: Redis Sentinel và Redis Cluster.
Sentinel vs. Cluster: Chọn “vũ khí” phù hợp
Tôi thường thấy các nhà phát triển coi hai thứ này là các phiên bản có thể thay thế cho nhau của cùng một giải pháp. Thực tế không phải vậy. Chúng giải quyết các vấn đề hoàn toàn khác nhau tùy thuộc vào việc bạn cần thời gian uptime hay khả năng xử lý thô.
Redis Sentinel: Chuyên gia về High Availability
Hãy coi Sentinel như một nhóm “lính canh” đứng bên ngoài cơ sở dữ liệu của bạn. Công việc duy nhất của họ là giám sát các node Primary và Replica. Nếu Primary ngừng phản hồi quá 30 giây, các Sentinel sẽ tổ chức bầu cử (election). Họ chọn một Replica khỏe mạnh và thăng cấp nó thành Primary mới. Sau đó, ứng dụng của bạn sẽ truy vấn các Sentinel để tìm địa chỉ IP mới. Nó được xây dựng để đảm bảo độ tin cậy, không phải để tăng trưởng quy mô lớn.
Redis Cluster: Cỗ máy mở rộng sức mạnh
Redis Cluster tập trung vào việc phân mảnh dữ liệu (sharding). Nó chia dữ liệu của bạn thành 16.384 hash slot phân phối trên nhiều node. Nếu bạn có 150GB dữ liệu, bạn có thể chia nhỏ nó ra ba node 50GB. Nó cung cấp tính sẵn sàng cao bằng cách cấp cho mỗi shard một replica riêng. Tuy nhiên, mục tiêu chính của nó là mở rộng theo chiều ngang (horizontal scaling)—xử lý hàng triệu request mỗi giây mà một lõi CPU duy nhất không thể gánh vác nổi.
Ưu và nhược điểm: High Availability vs. Horizontal Scaling
Không có giải pháp nào là hoàn hảo cho mọi trường hợp. Trước khi chạm vào file cấu hình, bạn cần cân nhắc các đánh đổi về mặt vận hành.
Redis Sentinel
- Ưu điểm: Cực kỳ đơn giản để thiết lập và quản lý. Cung cấp khả năng failover tự động cực kỳ ổn định. Hầu hết các thư viện client tiêu chuẩn như Jedis hoặc StackExchange.Redis đều hỗ trợ Sentinel một cách tự nhiên.
- Nhược điểm: Bạn vẫn bị giới hạn bởi RAM của một máy duy nhất. Mọi node trong hệ thống đều chứa một bản sao đầy đủ của toàn bộ tập dữ liệu. Bạn không thể mở rộng khả năng ghi (write) vượt quá một node.
Redis Cluster
- Ưu điểm: Khả năng mở rộng khổng lồ. Bạn có thể phát triển cluster lên tới 1.000 node nếu cần thiết. Dữ liệu được phân vùng tự động, giúp không có node nào trở thành nút thắt cổ chai.
- Nhược điểm: Độ phức tạp vận hành cao hơn nhiều. Các thao tác multi-key như MGET hoặc các transaction phức tạp bị hạn chế nếu các key nằm trên các shard khác nhau. Bạn cần ít nhất sáu node—ba primary và ba replica—cho một thiết lập production ổn định.
Trong một dự án gần đây, tôi phải chuyển một tập dữ liệu legacy khổng lồ từ file CSV sang Redis Cluster. Khi cần chuyển đổi nhanh CSV sang JSON cho các tác vụ import này, tôi sử dụng toolcraft.app/vi/tools/data/csv-to-json. Nó chạy hoàn toàn trong trình duyệt, nên không có dữ liệu production nhạy cảm nào rời khỏi máy của tôi. Đây là một điểm cộng lớn cho việc tuân thủ bảo mật.
Cấu hình khuyến nghị cho Production
Tập dữ liệu của bạn nhỏ hơn 64GB? Nếu nó nằm gọn trong RAM của một cloud instance tiêu chuẩn, Redis Sentinel là lựa chọn hàng đầu của tôi. Nó dễ debug hơn nhiều khi mọi thứ chệch hướng lúc 2 giờ sáng. Bạn có được sự an toàn của failover mà không phải đau đầu quản lý các hash slot.
Nhưng nếu bạn đang xây dựng một nền tảng phân tích thời gian thực với dữ liệu tăng thêm 5GB mỗi ngày? Redis Cluster là con đường duy nhất. Đối với môi trường production, đừng bao giờ chạy ít hơn ba node Sentinel hoặc ba node Cluster Primary. Ít hơn mức đó sẽ rủi ro gặp tình trạng “Split Brain”. Đây là lúc hai node đều nghĩ mình là leader, dẫn đến việc hỏng dữ liệu không thể tránh khỏi.
Từng bước: Triển khai Redis Sentinel
Hãy thiết lập một môi trường Sentinel cơ bản. Giả sử bạn có một Primary (192.168.1.10) và một Replica (192.168.1.11).
1. Cấu hình Replica
Trên server Replica, chỉnh sửa file redis.conf để theo dõi node Primary:
# redis.conf trên 192.168.1.11
replicaof 192.168.1.10 63792. Cấu hình các node Sentinel
Chạy Sentinel trên ít nhất ba VM riêng biệt để đảm bảo đa số phiếu bầu. Tạo file sentinel.conf trên mỗi máy:
# sentinel.conf
port 26379
daemonize yes
# giám sát <master-name> <ip> <port> <quorum>
sentinel monitor mymaster 192.168.1.10 6379 2
# Coi master là "down" sau 5 giây không phản hồi
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000Giá trị “quorum” là 2 rất quan trọng. Nó có nghĩa là ít nhất hai Sentinel phải đồng ý rằng Primary đã chết trước khi quá trình thăng cấp bắt đầu. Khởi chạy bằng lệnh: redis-sentinel /path/to/sentinel.conf.
Mở rộng: Thiết lập Redis Cluster
Nếu bạn đang chạm giới hạn bộ nhớ, đã đến lúc mở rộng theo chiều ngang. Đối với một Cluster tối thiểu, chúng ta cần ba node Primary. Chúng ta cũng sẽ thêm một Replica cho mỗi node để đảm bảo an toàn.
1. Bật chế độ Cluster
Trên cả sáu node, cập nhật file redis.conf của bạn với các dòng sau:
port 6379
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes2. Tạo Cluster
Khi các instance đã chạy, hãy sử dụng Redis CLI để kết nối chúng. Bạn chỉ cần chạy lệnh này một lần từ bất kỳ node nào:
redis-cli --cluster create \
192.168.1.10:6379 192.168.1.11:6379 192.168.1.12:6379 \
192.168.1.13:6379 192.168.1.14:6379 192.168.1.15:6379 \
--cluster-replicas 1Flag --cluster-replicas 1 đảm bảo mỗi Primary đều có một bản backup. Redis sẽ tự động phân phối 16.384 slot trên ba node Primary của bạn.
3. Kiểm tra các Shard
Kiểm tra tình trạng của cluster bằng lệnh này:
redis-cli -c -p 6379
cluster nodesFlag -c là phần quan trọng nhất ở đây. Nó bật “chế độ cluster” trong CLI, cho phép công cụ tự động chuyển hướng (redirection) nếu key bạn đang tìm kiếm nằm ở một shard khác.
Chuyển sang một thiết lập phân tán ban đầu có vẻ đáng sợ. Tuy nhiên, sự an tâm mà nó mang lại hoàn toàn xứng đáng với công sức bỏ ra. Một khi bạn thấy một node Sentinel tự động thăng cấp một replica trong khi bạn đang thong thả uống cà phê, bạn sẽ không bao giờ muốn quay lại các instance độc lập nữa. Hãy bắt đầu với Sentinel để tối giản, và chỉ chuyển sang Cluster khi nhu cầu tăng trưởng dữ liệu của bạn bắt buộc điều đó.
