Khi bạn mở X (Twitter) hay Facebook, bảng tin (Timeline) của bạn xuất hiện gần như tức thì với hàng trăm bài viết, hình ảnh, lượt like và comment mới nhất. Có bao giờ bạn tự hỏi: Làm thế nào hệ thống có thể phục vụ hơn 500 triệu người dùng hoạt động mỗi ngày với hàng chục tỷ lượt xem Timeline mà độ trễ chỉ dưới 50 mili-giây?

Nếu mỗi lần người dùng vuốt màn hình, ứng dụng lại chọc xuống SQL Database để SELECT * FROM posts JOIN followers..., cụm Database sẽ sập chỉ trong vài giây.

Hành trình thiết kế hệ thống Caching cho Social Timeline là một bài học kinh điển về xử lý hệ thống phân tán ở quy mô cực hạn.

1. Bài toán "Fan-out" khổng lồ của Social Timeline

Khái niệm cốt lõi đằng sau bảng tin Social Network là Fan-out (Phát tán dữ liệu). Khi người dùng A đăng một bài viết mới, làm sao để bài viết đó xuất hiện trên Timeline của 1.000 người theo dõi A?

Có 2 mô hình cơ bản:

1.1. Fan-out on Read (Mô hình Pull)

Khi bạn mở app, hệ thống sẽ đi tìm danh sách tất cả những người bạn đang theo dõi, sau đó quét Database lấy ra bài viết mới nhất của họ và sắp xếp theo thời gian.

Ưu điểm: Việc đăng bài (Write) rất nhanh. Người đăng chỉ cần nhét 1 dòng vào DB. Nhược điểm: Việc đọc (Read) thảm họa. Nếu bạn theo dõi 1.000 người, hệ thống phải thực hiện câu query vô cùng nặng nề. Khi có 100.000 người cùng mở app, DB sẽ nổ tung.

1.2. Fan-out on Write (Mô hình Push)

Mỗi người dùng có riêng một "Hộp thư" (Inbox/Timeline Cache) lưu trữ danh sách ID bài viết trong Redis. Khi người dùng A đăng bài, một Worker ngầm sẽ lấy danh sách 1.000 người theo dõi A, và đẩy thẳng ID bài viết mới vào Redis List Timeline của từng người đó.

Ưu điểm: Việc đọc (Read) siêu nhanh. Khi bạn mở app, Redis chỉ cần LRANGE timeline:user_id 0 20 mất chưa tới 1ms! Nhược điểm: Thách thức lớn xuất hiện khi gặp các tài khoản "Siêu sao" (Celebrity Problem).

2. Thách thức "Celebrity Problem" & Kiến trúc Caching Hybrid

Hãy hình dung một tài khoản như Elon Musk hay Taylor Swift có hơn 100 triệu người theo dõi.

Nếu áp dụng thuần túy Fan-out on Write, khi Cristiano Ronaldo đăng một bức ảnh, hệ thống Worker phải thực hiện 100 triệu phép ghi (Write) vào 100 triệu danh sách Redis khác nhau. Quá trình này có thể mất tới vài phút, gây tắc nghẽn toàn bộ hàng đợi Message Queue và tốn hàng trăm GB bộ nhớ RAM!

Giải pháp Hybrid của X & Meta: Hệ thống phân loại người dùng thành 2 nhóm:

• Người dùng thông thường (< 10.000 followers): Sử dụng Fan-out on Write (Push). Bài viết được đẩy sẵn vào Redis Timeline của bạn bè.
• Tài khoản Siêu sao (> 10.000 followers): Không đẩy vào Timeline của ai cả. Bài viết của họ được lưu trong một Redis Cache riêng. Khi người dùng mở app, hệ thống sẽ lấy Timeline từ Redis (đã push sẵn) và trộn (Merge) thêm các bài viết mới từ Cache của các Siêu sao mà người đó đang theo dõi.

3. Quái vật Cache Stampede & Bài học trên Production

Dù đã có bộ nhớ đệm Redis, một thảm họa khác vẫn có thể xảy ra: Cache Stampede (Dog-piling Effect).

Hãy hình dung bài viết mới của một Siêu sao được lưu trong Redis Key post:celebrity:999 với thời gian sống TTL = 5 phút. Đúng vào lúc 12:00:00, key này hết hạn (TTL = 0).

Tại đúng mili-giây đó, có 100.000 người dùng cùng kéo màn hình để đọc bài viết này. Tất cả 100.000 request đồng thời nhận về kết quả Cache Miss. Ngay lập tức, 100.000 request cùng lúc "lao thẳng" xuống Database chính để query lại bài viết.

Hậu quả: Connection Pool của DB kiệt sức, CPU nhảy vọt lên 100%, kéo theo toàn bộ ứng dụng bị nghẽn (Cascading Failure).

Cách giải quyết triệt để trên thực tế:

A. Distributed Lock (Mutex Lock)

Khi xảy ra Cache Miss, không cho phép tất cả request cùng chọc xuống DB. Request đầu tiên sẽ lấy một Distributed Lock (bằng Redisson hoặc Redis Lua script) để dành quyền query DB và update lại Cache. Các request đến sau khi thấy Lock bận sẽ tạm thời chờ 50ms rồi đọc lại từ Redis.

public PostData getPostWithLock(String postId) {
    String cacheKey = "post:" + postId;
    String cachedData = redisTemplate.opsForValue().get(cacheKey);
    
    if (cachedData != null) {
        return deserialize(cachedData);
    }
    
    String lockKey = "lock:post:" + postId;
    RLock lock = redissonClient.getLock(lockKey);
    
    try {
        if (lock.tryLock(2, 5, TimeUnit.SECONDS)) {
            try {
                cachedData = redisTemplate.opsForValue().get(cacheKey);
                if (cachedData != null) return deserialize(cachedData);
                
                PostData data = dbRepository.findPostById(postId);
                redisTemplate.opsForValue().set(cacheKey, serialize(data), 3600, TimeUnit.SECONDS);
                return data;
            } finally {
                lock.unlock();
            }
        } else {
            Thread.sleep(50);
            return getPostWithLock(postId);
        }
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        throw new RuntimeException("Lock Error", e);
    }
}

B. Logical Expiration (Làm mới ngầm)

Không bao giờ cài đặt TTL vật lý cho Redis. Thay vào đó, nhét thêm trường timestamp expireAt vào dữ liệu lưu ở Redis. Khi đọc dữ liệu thấy đã hết hạn logic:

Trả ngay lập tức dữ liệu hiện tại (Stale Data) cho Client (Độ trễ = 1ms). Khởi chạy một Async Thread ngầm để query DB và cập nhật dữ liệu mới vào Redis. Client hoàn toàn không bị delay dù chỉ 1ms, còn DB thì không bao giờ bị quá tải đột biến.

C. Thêm Random Jitter chống Tuyết Lở (Cache Avalanche)

Để tránh tình trạng hàng loạt key cùng hết hạn tại một mốc thời gian (ví dụ sau khi chạy Batch Job lúc 00:00), hệ thống luôn cộng thêm một khoảng ngẫu nhiên vào TTL:

int baseTtl = 7200; // 2 giờ
int jitter = new Random().nextInt(300); // Random 0 - 300 giây
redisTemplate.opsForValue().set(key, value, baseTtl + jitter, TimeUnit.SECONDS);

Bài học rút ra

Không có giải pháp hoàn hảo duy nhất: Sự kết hợp Hybrid giữa Push (Fan-out on Write) và Pull (Fan-out on Read) mới là chìa khóa giải bài toán scale cho hàng trăm triệu user. Cache không phải là viên đạn bạc: Đừng bọc Cache một cách ngây thơ. Luôn tính trước các kịch bản key bị hết hạn đồng loạt (Cache Stampede) hoặc truy vấn ID không tồn tại (Cache Penetration). Async & Batching cứu sống hệ thống: Xử lý ngầm dưới background (Logical Expiration) giúp giữ độ trễ ứng dụng ở mức thấp nhất mà không gây áp lực lên Database.

Trạm Code.

Xem thêm các nội dung về IT chất lượng tại tramcode[.]io[.]vn