Chào bạn, một câu hỏi cực kỳ tư duy và sắc bén Cách bạn nói trong System Design gọi là kỹ thuật Sliding Expiration (Gia hạn trượt) cứ có request chạm vào là cộng thêm giờ sống cho Key.
Đúng là nếu làm thế, Key sẽ "bất tử" miễn là còn traffic, giải quyết được chuyện sập DB. NHƯNG, trong môi trường Enterprise, người ta hiếm khi dùng cách này cho Data Content (bài viết, sản phẩm) vì 2 tử huyệt sau:
Thảm họa 'Dữ liệu ôi thiu' (Stale Data & Inconsistency)
Bản chất của TTL sinh ra là để ép hệ thống thỉnh thoảng phải 'chết' đi, xuống DB lấy dữ liệu mới nhất lên.
Hãy tưởng tượng Admin vừa vào MySQL sửa giá cái iPhone từ 30 triệu xuống 25 triệu (Flash Sale). Nếu bạn dùng Sliding Expiration, và user cứ liên tục F5 (như trong vụ Hot Key), cái Key đó sẽ được cộng thêm giờ sống liên tục. Kết quả? Dữ liệu cũ (30 triệu) kẹt trên Redis mãi mãi, không bao giờ được cập nhật thành 25 triệu. Khách hàng chửi, công ty mất tiền!
Chi phí Hiệu năng (Write Amplification)
Khi có 100.000 người vào đọc bài cùng 1 giây. Nếu bình thường, Redis chỉ chạy lệnh GET (Chỉ Đọc - cực kỳ nhẹ).
Nếu bạn dùng cách cộng TTL, mỗi lần user đọc, bạn phải chạy thêm lệnh EXPIRE (Thao tác Ghi - cập nhật metadata vào RAM). Tự nhiên bạn ép Redis phải gánh 100.000 lệnh Ghi vô nghĩa mỗi giây, làm giảm hiệu suất tổng thể của Cluster.
Vậy cách của bạn khi nào thì được xài?
Tuyệt chiêu Sliding Expiration của bạn là 'Tiêu chuẩn vàng' để làm User Session (Phiên đăng nhập).
Ví dụ: User đăng nhập cấp token sống 30 phút. Cứ user còn click lướt web (còn thở), thì gia hạn token thêm 30 phút. User treo máy đi ngủ -> tự động văng. Ở case này, dữ liệu Session không sợ bị 'ôi thiu' như bài viết, nên cách của bạn là cực kỳ hoàn hảo!
Caching luôn là sự đánh đổi (Trade-off) giữa "Độ trễ (Latency)" và "Độ chính xác (Consistency)". Cảm ơn bạn vì một góc nhìn rất chất lượng nhé!
Ủa sao cá TH2 mỗi lần gọi trúng Key thì không tự động gia hạn EXPIRE thêm TTL lên nhỉ. Đỡ bị hết hạn. Cứ Client còn gọi thì key còn thở.
Nếu fix được TH2 thì trường hợp 3 cũng hiếm xảy ra.
Xem thêm các câu chuyện chia sẻ, suy nghĩ của mình về chặng đường sống, làm việc ở nước ngoài tại blog cá nhân của mình 🙃 🙃 🙃: https://quangchientran.substack.com/
THẢO LUẬN
Chào bạn, một câu hỏi cực kỳ tư duy và sắc bén Cách bạn nói trong System Design gọi là kỹ thuật Sliding Expiration (Gia hạn trượt) cứ có request chạm vào là cộng thêm giờ sống cho Key. Đúng là nếu làm thế, Key sẽ "bất tử" miễn là còn traffic, giải quyết được chuyện sập DB. NHƯNG, trong môi trường Enterprise, người ta hiếm khi dùng cách này cho Data Content (bài viết, sản phẩm) vì 2 tử huyệt sau: Thảm họa 'Dữ liệu ôi thiu' (Stale Data & Inconsistency) Bản chất của TTL sinh ra là để ép hệ thống thỉnh thoảng phải 'chết' đi, xuống DB lấy dữ liệu mới nhất lên. Hãy tưởng tượng Admin vừa vào MySQL sửa giá cái iPhone từ 30 triệu xuống 25 triệu (Flash Sale). Nếu bạn dùng Sliding Expiration, và user cứ liên tục F5 (như trong vụ Hot Key), cái Key đó sẽ được cộng thêm giờ sống liên tục. Kết quả? Dữ liệu cũ (30 triệu) kẹt trên Redis mãi mãi, không bao giờ được cập nhật thành 25 triệu. Khách hàng chửi, công ty mất tiền! Chi phí Hiệu năng (Write Amplification) Khi có 100.000 người vào đọc bài cùng 1 giây. Nếu bình thường, Redis chỉ chạy lệnh GET (Chỉ Đọc - cực kỳ nhẹ). Nếu bạn dùng cách cộng TTL, mỗi lần user đọc, bạn phải chạy thêm lệnh EXPIRE (Thao tác Ghi - cập nhật metadata vào RAM). Tự nhiên bạn ép Redis phải gánh 100.000 lệnh Ghi vô nghĩa mỗi giây, làm giảm hiệu suất tổng thể của Cluster. Vậy cách của bạn khi nào thì được xài? Tuyệt chiêu Sliding Expiration của bạn là 'Tiêu chuẩn vàng' để làm User Session (Phiên đăng nhập). Ví dụ: User đăng nhập cấp token sống 30 phút. Cứ user còn click lướt web (còn thở), thì gia hạn token thêm 30 phút. User treo máy đi ngủ -> tự động văng. Ở case này, dữ liệu Session không sợ bị 'ôi thiu' như bài viết, nên cách của bạn là cực kỳ hoàn hảo! Caching luôn là sự đánh đổi (Trade-off) giữa "Độ trễ (Latency)" và "Độ chính xác (Consistency)". Cảm ơn bạn vì một góc nhìn rất chất lượng nhé!
Ủa sao cá TH2 mỗi lần gọi trúng Key thì không tự động gia hạn EXPIRE thêm TTL lên nhỉ. Đỡ bị hết hạn. Cứ Client còn gọi thì key còn thở. Nếu fix được TH2 thì trường hợp 3 cũng hiếm xảy ra.
👨💻 Nguyễn Huy Hoàng | Software Engineer
📧 Email: hhoang02052004@gmail.com
📞 Số điện thoại: 0941 280 073
GitHub: github.com/HuyHoangCoder
👨💻 Nguyễn Huy Hoàng | Software Engineer
📧 Email: hhoang02052004@gmail.com
📞 Số điện thoại: 0941 280 073
GitHub: github.com/HuyHoangCoder
👨💻 Nguyễn Huy Hoàng | Software Engineer
📧 Email: hhoang02052004@gmail.com
📞 Số điện thoại: 0941 280 073
GitHub: github.com/HuyHoangCoder
👨💻 Nguyễn Huy Hoàng | Software Engineer
📧 Email: hhoang02052004@gmail.com
📞 Số điện thoại: 0941 280 073
GitHub: github.com/HuyHoangCoder
👨💻 Nguyễn Huy Hoàng | Software Engineer
📧 Email: hhoang02052004@gmail.com
📞 Số điện thoại: 0941 280 073
GitHub: github.com/HuyHoangCoder
rất vui khi giúp được bạn
cảm ơn bạn
đúng chủ đề em cần cảm ơn tác giả
bài viết hay, like cho admin
👨💻 Nguyễn Huy Hoàng | Software Engineer
📧 Email: hhoang02052004@gmail.com
📞 Số điện thoại: 0941 280 073
GitHub: github.com/HuyHoangCoder
Trân trọng, Nguyễn Huy Hoàng
👨💻 Nguyễn Huy Hoàng | Software Engineer 📧 Email: hhoang02052004@gmail.com
📞 Số điện thoại: 0941 280 073
GitHub: github.com/HuyHoangCoder
Trân trọng, Nguyễn Huy Hoàng
👨💻 Nguyễn Huy Hoàng | Software Engineer 📧 Email: hhoang02052004@gmail.com
📞 Số điện thoại: 0941 280 073
GitHub: github.com/HuyHoangCoder
Trân trọng, Nguyễn Huy Hoàng
👨💻 Nguyễn Huy Hoàng | Software Engineer 📧 Email: hhoang02052004@gmail.com
📞 Số điện thoại: 0941 280 073
GitHub: github.com/HuyHoangCoder
Trân trọng, Nguyễn Huy Hoàng
Xem thêm các câu chuyện chia sẻ, suy nghĩ của mình về chặng đường sống, làm việc ở nước ngoài tại blog cá nhân của mình 🙃 🙃 🙃: https://quangchientran.substack.com/
👨💻 Nguyễn Huy Hoàng | Software Engineer 📧 Email: hhoang02052004@gmail.com
📞 Số điện thoại: 0941 280 073
GitHub: github.com/HuyHoangCoder
Trân trọng, Nguyễn Huy Hoàng
👨💻 Nguyễn Huy Hoàng | Software Engineer 📧 Email: hhoang02052004@gmail.com
📞 Số điện thoại: 0941 280 073
GitHub: github.com/HuyHoangCoder
Trân trọng, Nguyễn Huy Hoàng
👨💻 Nguyễn Huy Hoàng | Software Engineer 📧 Email: hhoang02052004@gmail.com
📞 Số điện thoại: 0941 280 073
GitHub: github.com/HuyHoangCoder
Trân trọng, Nguyễn Huy Hoàng
👨💻 Nguyễn Huy Hoàng | Software Engineer 📧 Email: hhoang02052004@gmail.com
📞 Số điện thoại: 0941 280 073
GitHub: github.com/HuyHoangCoder
Trân trọng, Nguyễn Huy Hoàng