Series Redis Sentinel & Node.js Thực chiến #1: "Tử huyệt" Single Node và Quyền năng của Kẻ gác đền

1. Nỗi đau mang tên SPOF (Single Point of Failure)

Hãy hình dung một kịch bản: Giờ cao điểm lúc 7h sáng, hàng ngàn người ùa vào ga Metro. Ứng dụng Node.js của bạn đang hoạt động hết công suất, liên tục đọc/ghi session và cache vào một server Redis duy nhất.

Đột nhiên, server chứa con Redis đó bị chết nguồn (hoặc tràn RAM dẫn đến OOM Kill).

• Hậu quả: Ứng dụng Node.js mất kết nối, ném lỗi ECONNREFUSED liên tục.
• Hệ lụy: Logic code sẽ fallback (trượt) thẳng xuống Database chính. Hàng ngàn request ập thẳng vào Database cùng một lúc (hiện tượng Cache Stampede), làm Database quá tải và sập theo. Toàn bộ hệ thống sập toàn tập.

Chạy một con Redis duy nhất chính là tạo ra một SPOF (Điểm chết duy nhất).

2. Bước đệm: Kiến trúc Master - Replica (Master - Slave)

Để dữ liệu không bị mất khi một server chết, giới kỹ sư áp dụng cơ chế sao chép (Replication). Thay vì 1 con, chúng ta chạy 3 con Redis:

• 1 Master: Chuyên nhận lệnh Ghi (Write) từ ứng dụng Node.js.
• 2 Replicas: Liên tục copy dữ liệu từ Master về. Chuyên nhận lệnh Đọc (Read) để giảm tải cho Master.

Vấn đề: Mặc dù dữ liệu đã được sao lưu, nhưng nếu con Master chết, hai con Replicas sẽ "ngơ ngác" đứng nhìn. Chúng không tự động bầu ra một con Master mới. Ứng dụng Node.js của bạn vẫn văng lỗi vì không tìm thấy đường link nào để Ghi dữ liệu vào. Bạn phải thức dậy lúc 2h sáng, chui vào server gõ lệnh đẩy một con Replica lên làm Master, rồi sửa lại file .env của Node.js, sau đó khởi động lại service.

Đó không phải là High Availability (Sẵn sàng cao).

3. Sự xuất hiện của Redis Sentinel (Kẻ gác đền)

Để hệ thống thực sự tự động hóa (Auto-Failover) mà không cần con người can thiệp, Redis cung cấp một công cụ kiến trúc mang tên Sentinel.

Sentinel không lưu trữ dữ liệu (không phải là chỗ để Node.js cache data). Nó là một cụm các tiến trình chạy nền, đóng vai trò như những "Bảo vệ" liên tục đi tuần tra các node Redis (Master và Replicas).

Sentinel có 4 nhiệm vụ tối thượng:

1. Monitoring (Giám sát): Nó liên tục ping kiểm tra xem Master và các Replica có đang sống khỏe không.
2. Notification (Cảnh báo): Nếu một node Redis có vấn đề, Sentinel có thể báo cho các hệ thống giám sát khác biết.
3. Automatic Failover (Tự động chuyển đổi dự phòng): ĐÂY LÀ TÍNH NĂNG ĂN TIỀN NHẤT. Nếu Sentinel phát hiện con Master chết, cụm Sentinel sẽ "họp bàn" (thông qua cơ chế quorum) để thống nhất: "Master chết thật rồi, hãy chọn con Replica 1 lên làm Master mới!". Toàn bộ quá trình thăng cấp diễn ra trong vài giây.
4. Configuration Provider (Cung cấp cấu hình cho Node.js): Thay vì Node.js kết nối thẳng vào địa chỉ IP của Master, Node.js sẽ kết nối vào Sentinel và hỏi: "Anh Sentinel ơi, con Master hiện tại đang nằm ở IP nào?". Sentinel sẽ chỉ điểm. Khi có sự kiện sập và đổi Master mới, Sentinel sẽ lập tức báo địa chỉ IP mới cho Node.js biết để chuyển hướng tự động.

4. Bức tranh tổng thể với Node.js

Nhờ Sentinel, cuộc sống của lập trình viên Backend nhàn đi rất nhiều.

Cụm ứng dụng Node.js xử lý nghiệp vụ lúc này chỉ cần sử dụng thư viện ioredis. Trong code cấu hình kết nối, bạn không khai báo hardcode địa chỉ IP của Redis Master nữa, mà khai báo danh sách địa chỉ của cụm Sentinel kèm theo tên của Master group (ví dụ: mymaster).

Phần còn lại (theo dõi sống chết, cập nhật IP mới khi failover), thư viện ioredis và cụm Sentinel sẽ tự động giao tiếp và lo liệu toàn bộ. Dù một server Redis có cháy ổ cứng lúc nửa đêm, hệ thống AFC vẫn tiếp tục bán vé trơn tru mà không rớt một nhịp nào, và bạn thì vẫn được ngủ ngon.

Chúng ta vừa nắm được lý thuyết cốt lõi về sự nguy hiểm của SPOF và sức mạnh Auto-Failover của kiến trúc Sentinel. Ở Bài 2 của series này, chúng ta sẽ xắn tay áo lên và cấu hình thiết lập một cụm Redis Sentinel thực tế bằng docker-compose, chuẩn bị sẵn sàng một môi trường chịu tải cao thực thụ trước khi ghép nối nó vào source code Node.js.