Posted inDevelopment

Scaling Socket.IO: Giải quyết bài toán đồng bộ Real-time với Redis Adapter

Development tutorial - IT technology blog
Development tutorial - IT technology blog

Cơn ác mộng lúc 2 giờ sáng: Khi hệ thống Real-time bỗng dưng ‘im lặng’

Tiếng chuông báo động vang lên phá tan giấc ngủ. Tin nhắn từ sếp ngắn gọn: “30% người dùng than phiền không nhận được thông báo, check gấp!”. Hệ thống vừa mới được nâng cấp lên 3 instance để chuẩn bị cho đợt flash sale, nhưng có vẻ kiến trúc mới đang gặp vấn đề nghiêm trọng.

Sau khi kiểm tra log, mình phát hiện lỗi kinh điển: Sự cô lập bộ nhớ (Memory Isolation). Trong môi trường một server, mọi thứ chạy rất ổn. Tuy nhiên, khi đưa lên cụm (Cluster) nằm sau Load Balancer, các socket client bị chia cắt hoàn toàn. User A kết nối tới Server 1, trong khi User B lại nằm ở Server 2. Khi Server 1 phát đi một sự kiện (emit), User B sẽ chẳng nhận được gì vì Server 1 không hề biết User B đang tồn tại ở phía bên kia.

Tại sao Socket.IO mặc định không thể scale ngang?

Mặc định, Socket.IO sử dụng Memory Adapter. Nó lưu trữ thông tin về rooms và sids ngay trong RAM của tiến trình Node.js đó.

  • Server 1: Quản lý SocketID_1.
  • Server 2: Quản lý SocketID_2.

Nếu bạn gọi io.emit() trên Server 1, nó chỉ gửi dữ liệu cho những client đang kết nối trực tiếp vào nó. Nó hoàn toàn “mù tịt” về các client ở Server 2. Đây là lý do tại sao hệ thống lúc chạy 1 server thì ngon, nhưng lên 3 server là bắt đầu hên xui. Tỉ lệ nhận được thông báo lúc này giống như chơi xổ số vậy.

Redis Adapter: Giải pháp ‘cứu cánh’ chuẩn công nghiệp

Thực tế có vài cách để xử lý vấn đề này, nhưng không phải cách nào cũng tối ưu:

  1. Sticky Sessions: Cấu hình Load Balancer để một client luôn dính chặt vào một server. Cách này chỉ giải quyết được bước bắt tay (handshake) ban đầu, không giúp các server nói chuyện được với nhau.
  2. Tự viết Pub/Sub: Bạn có thể dùng RabbitMQ hoặc Redis để tự điều phối message. Tuy nhiên, việc này rất tốn thời gian và dễ phát sinh bug tiềm ẩn.
  3. Socket.IO Redis Adapter: Đây là lựa chọn hàng đầu. Nó thay thế bộ nhớ RAM cục bộ bằng cơ chế Redis Pub/Sub. Khi một server emit message, nó đẩy vào Redis. Sau đó, Redis sẽ phát tán (broadcast) tới tất cả server Node.js khác trong hệ thống.

Mình chọn Redis Adapter vì tính ổn định và khả năng triển khai cực nhanh, giúp tiết kiệm hàng giờ debug vô nghĩa.

Triển khai thực tế: Từng bước cấu hình

Hãy chuẩn bị một instance Redis (có thể dùng Docker để tiết kiệm thời gian). Kinh nghiệm từ việc refactor dự án 50.000 dòng code của mình là: luôn test kỹ ở local trước khi đụng vào production.

Bước 1: Cài đặt thư viện

Gõ lệnh sau trong terminal của bạn:

npm install socket.io redis @socket.io/redis-adapter

Bước 2: Cấu hình Server

Dưới đây là đoạn mã mình đã tối ưu lại. Điểm mấu chốt nằm ở hàm createAdapter.

const { Server } = require("socket.io");
const { createClient } = require("redis");
const { createAdapter } = require("@socket.io/redis-adapter");

async function setupWorker() {
    const io = new Server(3000);
    const pubClient = createClient({ url: "redis://localhost:6379" });
    const subClient = pubClient.duplicate();

    // Kết nối song song để tiết kiệm thời gian
    await Promise.all([pubClient.connect(), subClient.connect()]);

    io.adapter(createAdapter(pubClient, subClient));

    io.on("connection", (socket) => {
        console.log(`User ${socket.id} kết nối vào process ${process.pid}`);

        socket.on("send_notification", (data) => {
            // Redis sẽ đảm bảo mọi server đều nhận được message này
            io.emit("receive_notification", data);
        });
    });
}

setupWorker();

Bước 3: Lưu ý về Sticky Sessions trên Nginx

Khi dùng transport là polling, bạn bắt buộc phải bật Sticky Sessions. Nếu thiếu, client sẽ liên tục gặp lỗi 400 do server mới không nhận diện được session cũ.

Cấu hình Nginx tham khảo:

upstream nodes {
    ip_hash; # Ép client ở lại một server cố định
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
}

server {
    listen 80;
    location /socket.io/ {
        proxy_pass http://nodes;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
    }
}

Kiểm chứng kết quả

Để kiểm tra, bạn hãy mở hai terminal và chạy hai instance ở port 3000 và 3001. Khi Client A gửi tin nhắn tới port 3000, Client B ở port 3001 phải nhận được ngay lập tức. Nếu message xuất hiện tức thì, chúc mừng bạn đã scale thành công.

Bài học xương máu từ thực tế

Khi traffic chạm ngưỡng 10.000 messages/giây, đừng dùng chung Redis cho cả Caching và Socket.IO. Redis vốn đơn luồng (single-threaded). Việc broadcast quá tải có thể làm nghẽn các truy vấn cache quan trọng khác.

Bên cạnh đó, đừng quên bắt lỗi event error trên Redis client. Mình từng gặp cảnh server treo cứng chỉ vì Redis die mà code không xử lý ngoại lệ. Luồng xử lý socket bị block hoàn toàn khiến toàn bộ hệ thống tê liệt.

Triển khai Redis Adapter không chỉ là để chạy đa server. Đây là nền tảng quan trọng giúp bạn tự tin xây dựng các kiến trúc Microservices phức tạp. Hãy áp dụng ngay để bảo vệ giấc ngủ của chính mình!

Share:
Tags: