Caching cho MCP Server: Những gì tôi học được sau 87 lần sập hệ thống
Tôi từng nghĩ MCP server của mình không cần caching.
Cơ sở tri thức của tôi chỉ có vài nghìn mục. Các truy vấn diễn ra nhanh chóng. Tôi đã lầm.
Sau 87 lần sập hệ thống trên môi trường production và ba ngày trời debug lỗi timeout, tôi đã rút ra một bài học xương máu. Mọi MCP server đều cần caching. Kể cả những server nhỏ nhất.
Đây là những gì đã xảy ra.
Server sử dụng tìm kiếm ngữ nghĩa (semantic search) để tìm ghi chú. Hầu hết thời gian, nó vẫn hoạt động tốt. Nhưng rồi, mọi thứ bắt đầu hỏng hóc.
- Kết nối bị ngắt giữa chừng khi đang gửi request.
- Claude Desktop bị timeout sau 60 giây.
- Nginx trả về lỗi 504 Gateway Timeout.
Điều tồi tệ nhất? Nó chỉ xảy ra với các truy vấn lặp lại.
Khi người dùng hỏi cùng một câu hỏi hai lần, kết nối có thể ở trạng thái chờ (idle) trong khi AI đang suy nghĩ. Sau đó, một proxy sẽ ngắt kết nối. Claude tự động thử lại (retry) request đó. Giờ đây, bạn có hai lượt tìm kiếm giống hệt nhau đang chạy cùng một lúc.
Khi có nhiều lượt retry xảy ra, pool kết nối cơ sở dữ liệu của bạn sẽ bị cạn kiệt. Mọi thứ sụp đổ.
Tôi nhận ra mình không nên cache phản hồi cuối cùng của AI. Việc đó quá phức tạp đối với MCP. Thay vào đó, tôi cần cache phần nặng nhất: tìm kiếm ngữ nghĩa và lấy nội dung (content fetching).
Tôi đã chuyển sang chiến lược caching hai cấp độ:
• Cấp độ 1: In-memory cache cho các truy vấn thường xuyên. Cách này cực kỳ nhanh. • Cấp độ 2: Redis cache để chia sẻ dữ liệu giữa các lần khởi động lại.
Tôi cũng tuân thủ các quy tắc sau để nó hoạt động hiệu quả:
- Chuẩn hóa truy vấn: Tôi chuyển các truy vấn thành chữ thường và loại bỏ các khoảng trắng thừa. Điều này giúp tăng tỷ lệ cache hit.
- Cache kết quả, không phải stream: Tôi chỉ cache kết quả tìm kiếm. Việc tìm kiếm chiếm tới 95% thời gian.
- Giảm thiểu lỗi một cách êm đẹp (Graceful degradation): Nếu Redis gặp sự cố, server vẫn hoạt động. Nó chỉ đơn giản là truy cập trực tiếp vào cơ sở dữ liệu. Caching là một sự tối ưu hóa, không phải là điều kiện bắt buộc để request thành công.
Kết quả thu được thật sự khổng lồ.
Thời gian tìm kiếm trung bình của tôi giảm từ 320ms xuống còn 12ms. Tức là nhanh hơn 27 lần. Tỷ lệ cache hit tổng thể của tôi là 73%. Hầu hết các truy vấn thậm chí không cần chạm tới cơ sở dữ liệu của tôi.
Nếu bạn xây dựng một MCP server, hãy làm như sau:
- Cho mục đích cá nhân: Sử dụng in-memory cache. Nó giúp ngăn chặn các lỗi timeout ngẫu nhiên.
- Cho các dịch vụ công cộng: Sử dụng phương pháp hai cấp độ với Redis. Nó giúp ngăn chặn sập hệ thống và cải thiện tốc độ.
Caching là về độ tin cậy. Nó ngăn chặn vòng lặp của các lượt retry và lỗi kết nối.
Cộng đồng học tập tùy chọn: https://t.me/GyaanSetuAi