Redis vs Memcached: Chọn cache phù hợp cho hệ thống

Bạn có biết?

Redis và Memcached đều là cache trong bộ nhớ, đều nổi tiếng, đều "cực nhanh". Vậy tại sao Memcached vẫn còn tồn tại khi Redis ra đời sau và "làm được nhiều hơn"? Vì có những bài toán Memcached làm tốt hơn và đơn giản hơn. Bài này sẽ giúp bạn chọn đúng công cụ — và quan trọng hơn, biết khi nào không cần đổi.

Tổng quan nhanh

Memcached (2003) — cache key-value thuần túy, đơn giản đến mức tối giản: lưu string, hết hạn theo TTL, LRU tự động. Redis (2009) — không chỉ cache mà còn là cấu trúc dữ liệu server: Strings, Lists, Sets, Hashes, Sorted Sets, Streams, Lua Scripts, Pub/Sub, persistence…

Đừng nhìn Redis như "Memcached thay thế" — hãy nhìn như hai công cụ khác hẳn nhau, dù bề ngoài giống nhau.

So sánh chi tiết

Tiêu chí	Redis	Memcached
Data types	String, List, Set, Hash, Sorted Set, Stream, Geo, Bitmap…	Chỉ string (giá trị ≤ 1MB)
Persistence	RDB + AOF (dữ liệu sống sót sau restart)	Không — mất sạch khi restart
Replication / HA	Master-slave, Sentinel, Cluster	Không có sẵn (client tự quản)
Scripting	Lua (atomic operations)	Không
Threading	Đơn luồng (single-thread)	Đa luồng (multi-thread)
Eviction	Nhiều policy: allkeys-lru, volatile-lru, noeviction…	Chỉ LRU
Lệnh mở rộng	INCR, LPUSH, SADD, ZADD, PUBLISH…	INCR/DECR cơ bản, append/prepend
Kích thước key/value	Value lên tới 512MB	Value tối đa 1MB

Hiệu năng: ai nhanh hơn?

Với thao tác GET/SET đơn giản, cả hai đều trả lời trong dưới 1ms — khác biệt không đáng kể với ứng dụng thực tế. Điểm khác thật sự:

• Memcached đa luồng — tận dụng nhiều CPU core, tốt khi bạn cần đẩy throughput tối đa trên máy nhiều core
• Redis single-thread — nhanh nhưng một lệnh nặng (KEYS, SMEMBERS set lớn) có thể chặn toàn bộ
• Redis thông minh hơn — bạn trả về ít dữ liệu hơn nhờ thao tác ngay trên cấu trúc (vd ZRANGE chỉ lấy top 10 thay vì cả list)

Kết luận: với cache thuần túy, Memcached có thể nhanh hơn chút trên máy nhiều core; với mọi thứ khác, Redis thắng tuyệt đối về khả năng.

Khi nào dùng Memcached

• Cache thuần túy — bạn chỉ cần GET/SET theo key, mất dữ liệu khi restart cũng không sao
• Hạ tầng cũ — hệ thống đang chạy Memcached ổn định, không có nhu cầu data types phức tạp
• Đơn giản tối đa — không muốn lo persistence, replication, config phức tạp
• Máy nhiều core, tải cache cực cao — muốn tận dụng đa luồng cho throughput thuần GET/SET

Khi nào dùng Redis (đa số trường hợp)

• Cần data types phong phú — cache object (Hash), hàng đợi (List), tag (Set), leaderboard (Sorted Set)
• Cần dữ liệu bền vững — session, counter, dữ liệu không thể mất (Persistence)
• Cần HA và scale — Sentinel/Cluster, failover tự động
• Cần atomic operations — INCR, Lua Scripts, Distributed Lock (xem bài Distributed Lock)
• Cần nhiều hơn cache — Pub/Sub, Streams, Rate Limiter, Message Queue (xem bài Message Queue)

Chuyển từ Memcached sang Redis có khó không?

Rất dễ nếu bạn chỉ dùng GET/SET: hầu hết client đều có cùng API (get, set, delete). Khác biệt chính:

// Memcached: set(key, value, ttlSeconds)
client.set("user:1001", JSON.stringify(user), 300);

// Redis (ioredis): set(key, value, "EX", ttlSeconds)
await redis.set("user:1001", JSON.stringify(user), "EX", 300);

Lưu ý nhỏ: Memcached chấp nhận value "0" và rỗng, còn một số client Redis trả null khi key không tồn tại — code kiểm tra falsy vẫn hoạt động, nhưng hãy dùng === null để chính xác.

Kết hợp cả hai?

Một số hệ thống lớn dùng cả hai: Memcached cho cache tầng đầu (hot data, throughput cao), Redis cho dữ liệu có cấu trúc và bền vững. Nhưng với 99% ứng dụng — đặc biệt là startup và hệ thống vừa — một mình Redis là đủ. Thêm Memcached vào chỉ để "tối ưu" thường làm tăng độ phức tạp vận hành mà lợi ích không đáng.

Tổng kết

Memcached: nhanh, đơn giản, đa luồng — phù hợp cache thuần túy. Redis: phong phú, bền vững, thông minh — phù hợp hầu hết mọi bài toán từ cache đến hàng đợi, lock, real-time. Nếu bạn đang băn khoăn, câu trả lời mặc định là Redis; chọn Memcached chỉ khi bạn chắc chắn mình chỉ cần GET/SET tốc độ cao.

Bước tiếp theo: đào sâu Cache Strategies với Redis để dùng cache đúng cách — TTL, tránh stampede, giữ đồng bộ dữ liệu.