06 thg 5, 2025·8 phút
Kho khóa‑giá trị cho bộ nhớ đệm, phiên và tra cứu nhanh
Tìm hiểu cách kho khóa‑giá trị giúp bộ nhớ đệm, lưu phiên và tra cứu tức thì—cùng TTL, cơ chế trục xuất, tùy chọn mở rộng và các đánh đổi thực tiễn cần lưu ý.
Tìm hiểu cách kho khóa‑giá trị giúp bộ nhớ đệm, lưu phiên và tra cứu tức thì—cùng TTL, cơ chế trục xuất, tùy chọn mở rộng và các đánh đổi thực tiễn cần lưu ý.
Mục tiêu chính của kho khóa‑giá trị rất đơn giản: giảm độ trễ cho người dùng cuối và giảm tải cho cơ sở dữ liệu chính. Thay vì chạy cùng một truy vấn tốn kém nhiều lần hoặc tính lại cùng một kết quả, ứng dụng có thể lấy một giá trị đã được tính trước trong một bước đơn, có độ trễ dự đoán.
Kho khóa‑giá trị được tối ưu cho một thao tác: “cho khóa này, trả về giá trị”. Sự tập trung hẹp đó cho phép đường đi quan trọng rất ngắn.
Trong nhiều hệ thống, một lần tra cứu thường được xử lý bằng:
Kết quả là thời gian phản hồi thấp và ổn định—điều bạn cần cho bộ nhớ đệm, lưu trữ phiên, và các tra cứu tốc độ cao khác.
Dù database được tối ưu tốt, nó vẫn phải phân tích truy vấn, lập kế hoạch, đọc chỉ mục và điều phối đồng thời. Nếu hàng nghìn yêu cầu cùng hỏi “top products”, công việc lặp lại đó tích tụ.
Cache key-value chuyển lưu lượng đọc lặp lại ra khỏi database. Database của bạn có thể dành thời gian cho những yêu cầu thực sự cần nó: ghi, join phức tạp, báo cáo và các đọc cần nhất quán.
Tốc độ không miễn phí. Kho khóa‑giá trị thường đánh đổi khả năng truy vấn phong phú (lọc, join) và có thể có đảm bảo khác nhau về độ bền và nhất quán tuỳ cấu hình.
Chúng phù hợp khi bạn có thể gán dữ liệu bằng một khóa rõ ràng (ví dụ user:123, cart:abc) và muốn truy xuất nhanh. Nếu bạn thường xuyên cần “tìm tất cả mục thỏa X”, cơ sở dữ liệu quan hệ hoặc document thường là nơi lưu trữ chính tốt hơn.
Kho khóa‑giá trị là dạng cơ sở dữ liệu đơn giản nhất: bạn lưu một giá trị (dữ liệu) dưới một khóa duy nhất, và sau đó lấy giá trị bằng cách cung cấp khóa.
Hãy nghĩ khóa như một định danh dễ lặp lại chính xác, và giá trị là thứ bạn muốn lấy lại.
Khóa thường là chuỗi ngắn (như user:1234 hoặc session:9f2a...). Giá trị có thể nhỏ (một bộ đếm) hoặc lớn hơn (một JSON blob).
Kho khóa‑giá trị được xây dựng cho truy vấn “đưa tôi giá trị cho khóa này”. Nội bộ, nhiều hệ thống dùng cấu trúc tương tự bảng băm: khóa được biến đổi thành vị trí nơi tìm thấy giá trị nhanh chóng.
Đó là lý do bạn thường nghe tra cứu hằng thời gian (O(1)): hiệu năng phụ thuộc nhiều hơn vào bao nhiêu yêu cầu bạn thực hiện hơn là bao nhiêu bản ghi tồn tại. Không phải là ma thuật—va chạm và giới hạn bộ nhớ vẫn quan trọng—nhưng với mục đích cache/phiên điển hình, nó rất nhanh.
Dữ liệu nóng là phần nhỏ được yêu cầu lặp lại (trang sản phẩm phổ biến, phiên đang hoạt động, bộ đếm giới hạn tần suất). Giữ dữ liệu nóng trong kho key-value—đặc biệt trong bộ nhớ—tránh các truy vấn chậm hơn tới DB và giữ thời gian phản hồi ổn định khi có tải cao.
Caching nghĩa là giữ bản sao của dữ liệu thường dùng ở nơi truy cập nhanh hơn so với nguồn gốc. Kho key-value là nơi phổ biến để làm điều này vì nó có thể trả về giá trị chỉ trong một lần tra cứu theo khóa, thường trong vài ms.
Cache phát huy khi cùng câu hỏi được hỏi nhiều lần: trang phổ biến, tìm kiếm lặp lại, các API thông dụng, hoặc phép tính tốn kém. Nó cũng hữu ích khi nguồn gốc chậm hoặc bị giới hạn tần suất—như database chính dưới tải nặng hoặc API bên ngoài tính phí theo yêu cầu.
Ứng viên tốt là kết quả được đọc nhiều và không cần luôn luôn chính xác tức thì:
Quy tắc đơn giản: cache outputs mà bạn có thể tái tạo nếu cần. Tránh cache dữ liệu thay đổi liên tục hoặc phải nhất quán hoàn toàn trên mọi lần đọc (ví dụ số dư ngân hàng).
Nếu không có cache, mỗi lượt xem trang có thể kích hoạt nhiều truy vấn DB hoặc cuộc gọi API. Với cache, app có thể phục vụ nhiều yêu cầu từ kho key-value và chỉ “ngã về” DB/API khi cache miss. Điều đó giảm khối lượng truy vấn, giảm contention kết nối, và cải thiện độ tin cậy khi có traffic spike.
Caching đánh đổi tính tươi mới lấy tốc độ. Nếu giá trị cache không được cập nhật kịp, người dùng có thể thấy dữ liệu cũ. Trong hệ phân tán, hai yêu cầu có thể tạm thời đọc các phiên bản khác nhau của cùng dữ liệu.
Bạn quản lý rủi ro bằng cách chọn TTL phù hợp, quyết định dữ liệu nào có thể “cũ một chút”, và thiết kế ứng dụng chấp nhận miss hoặc độ trễ làm mới.
“Mẫu” cache là quy trình lặp lại cho cách app đọc/ghi khi có cache. Chọn mẫu phù hợp phụ thuộc vào tần suất thay đổi của dữ liệu nền và mức độ chấp nhận dữ liệu cũ.
Với cache-aside, ứng dụng điều khiển cache rõ ràng:
Phù hợp nhất: dữ liệu đọc nhiều nhưng thay đổi ít. Cũng là lựa chọn mặc định tốt vì hỏng hóc giảm dần: nếu cache rỗng bạn vẫn đọc được từ DB.
Read-through: tầng cache tự lấy từ DB khi miss (app đọc “từ cache” và cache biết cách load). Giảm phức tạp code app nhưng tăng độ phức tạp cho tầng cache (cần tích hợp loader).
Write-through: mọi ghi đi đồng thời đến cache và DB. Đọc nhanh và nhất quán hơn, nhưng ghi chậm hơn do phải hoàn thành hai thao tác.
Phù hợp khi bạn muốn ít miss hơn và đọc nhất quán, và chấp nhận độ trễ ghi cao hơn.
Với write-back, app ghi vào cache trước, và cache đẩy thay đổi ra DB sau (thường theo lô).
Lợi ích: ghi rất nhanh và giảm tải DB.
Rủi ro: nếu node cache chết trước khi flush, bạn có thể mất dữ liệu. Dùng chỉ khi chấp nhận mất mát hoặc có cơ chế bền vững mạnh.
Nếu dữ liệu thay đổi hiếm, cache-aside với TTL hợp lý thường đủ. Nếu thay đổi nhiều và đọc cũ gây hậu quả, cân nhắc write-through (hoặc TTL rất ngắn cộng cơ chế vô hiệu hóa rõ ràng). Nếu lượng ghi lớn và có thể chấp nhận mất mát đôi khi, write-behind có thể phù hợp.
Giữ cache “tươi đủ” chủ yếu là chọn chiến lược hết hạn phù hợp cho từng khóa. Mục tiêu không phải chính xác tuyệt đối—mà là tránh làm người dùng ngạc nhiên bởi dữ liệu cũ trong khi vẫn giữ lợi ích về tốc độ.
TTL (time to live) đặt thời gian tự động cho một khóa để nó biến mất sau khoảng thời gian. TTL ngắn giảm độ cũ nhưng tăng miss; TTL dài cải thiện hit rate nhưng có rủi ro phục vụ giá trị lỗi thời.
Cách chọn TTL thực tế:
TTL là thụ động. Khi bạn biết dữ liệu đã thay đổi, thường tốt hơn là vô hiệu hóa chủ động: xóa khóa cũ hoặc ghi giá trị mới ngay.
Ví dụ: sau khi user cập nhật email, xóa user:123:profile hoặc cập nhật nó trong cache ngay. Vô hiệu hóa chủ động giảm cửa sổ dữ liệu cũ, nhưng yêu cầu app thực hiện cập nhật cache đáng tin cậy.
Thay vì xóa, thêm phiên bản vào tên khóa, ví dụ product:987:v42. Khi product thay đổi, tăng phiên bản và đọc/ghi v43. Phiên bản cũ sẽ hết hạn sau. Cách này tránh race khi một server xóa trong khi server khác đang ghi.
Stampede xảy ra khi một khóa phổ biến hết hạn và nhiều yêu cầu cùng xây dựng lại.
Các biện pháp thường gặp:
Dữ liệu phiên là gói nhỏ thông tin app cần để nhận diện trình duyệt hoặc client quay lại. Tối thiểu là session ID (hoặc token) ánh xạ tới trạng thái trên server. Tuỳ sản phẩm, nó có thể chứa trạng thái user (cờ đăng nhập, vai trò, nonce CSRF), preference tạm thời, và dữ liệu nhạy thời gian như giỏ hàng.
Kho key-value phù hợp vì đọc/ghi phiên đơn giản: tra token, lấy giá trị, cập nhật và đặt thời hạn. TTL giúp phiên không hoạt động tự hết, giữ storage sạch và giảm rủi ro nếu token bị lộ.
Luồng thông thường:
Dùng khóa rõ ràng, có phạm vi và giữ giá trị nhỏ:
sess:\u003ctoken\u003e hoặc sess:v2:\u003ctoken\u003e (versioning giúp thay đổi sau này).user_sess:\u003cuserId\u003e -> \u003ctoken\u003e để cưỡng chế “một phiên hoạt động mỗi user” hoặc thu hồi theo user.Logout nên xóa khóa phiên và các chỉ mục liên quan (như user_sess:\u003cuserId\u003e). Để xoay token (khuyến nghị sau login, thay đổi quyền, hoặc định kỳ), tạo token mới, ghi phiên mới rồi xóa khóa cũ. Cách này thu hẹp thời gian token bị đánh cắp có thể sử dụng.
Caching là trường hợp phổ biến nhất, nhưng kho key-value còn giúp hệ thống nhanh lên theo những cách khác. Nhiều ứng dụng cần tra cứu nhanh cho các mảnh trạng thái nhỏ—những thứ “gần nguồn dữ liệu chính” và phải kiểm tra nhanh trên gần như mọi yêu cầu.
Kiểm tra ủy quyền thường nằm trên đường đi quan trọng: mỗi API call có thể cần trả lời “user này được phép làm việc này không?” Lấy quyền từ DB quan hệ trên mỗi yêu cầu có thể thêm độ trễ và tải.
Kho key-value có thể giữ dữ liệu ủy quyền gọn để tra cứu nhanh, ví dụ:
perm:user:123 → danh sách/sets mã quyềnentitlement:org:45 → các tính năng bậtĐiều này hữu ích khi model quyền đọc nhiều và thay đổi ít. Khi quyền thay đổi (cập nhật vai trò, nâng cấp plan), bạn có thể cập nhật hoặc vô hiệu hóa một tập khóa nhỏ để lần yêu cầu tiếp theo phản ánh quy tắc mới.
Feature flag là giá trị nhỏ, đọc rất thường xuyên và cần có nhanh và đồng nhất qua nhiều service.
Mẫu lưu thường gặp:
flag:new-checkout → true/falseconfig:tax:region:EU → JSON blob hoặc cấu hình theo phiên bảnKho key-value phù hợp vì đọc đơn giản, dự đoán được và rất nhanh. Bạn cũng có thể phiên bản hóa giá trị (ví dụ config:v27:...) để rollout an toàn và rollback nhanh.
Giới hạn tần suất thường chỉ là bộ đếm theo user, API key hoặc IP. Kho key-value thường hỗ trợ phép toán nguyên tử, cho phép tăng bộ đếm an toàn khi nhiều yêu cầu đến cùng lúc.
Bạn có thể theo dõi:
rl:user:123:minute → tăng mỗi yêu cầu, expire sau 60srl:ip:203.0.113.10:second → kiểm soát burst ngắnVới TTL cho mỗi khóa bộ đếm, giới hạn tự đặt lại mà không cần job nền. Đây là nền tảng thực tế để bảo vệ login, endpoints tốn kém, hoặc thực thi hạn mức theo gói.
Thanh toán và các thao tác “chỉ thực hiện một lần” cần bảo vệ khỏi retry dù do timeout, client retry, hay message re-delivery.
Kho key-value có thể ghi khóa idempotency:
idem:pay:order_789:clientKey_abc → kết quả hoặc trạng thái đã lưuỞ lần đầu, bạn xử lý và lưu kết quả với TTL. Lần retry sau trả lại kết quả đã lưu thay vì thực hiện lại. TTL tránh tăng trưởng không giới hạn trong khi che phủ cửa sổ retry thực tế.
Những dùng này không phải “caching” theo nghĩa cổ điển; chúng giữ độ trễ thấp cho các tra cứu tần suất cao và các nguyên thủy điều phối cần tốc độ và tính nguyên tử.
“Kho khóa‑giá trị” không luôn là “chuỗi vào, chuỗi ra”. Nhiều hệ thống cung cấp cấu trúc phong phú hơn để mô hình hoá nhu cầu bên trong store—thường nhanh hơn và ít thành phần hơn so với việc đẩy mọi thứ vào code ứng dụng.
Hash (map) hữu ích khi bạn có một “thứ” với nhiều thuộc tính liên quan. Thay vì tạo nhiều khóa như user:123:name, user:123:plan, user:123:last_seen, bạn có thể lưu chung dưới user:123 với các field.
Điều này giảm số lượng khóa và cho phép fetch hoặc thay đổi chỉ field cần thiết—phù hợp cho profile, feature flag, hoặc cấu hình nhỏ.
Set phù hợp cho câu hỏi “X có thuộc nhóm không?”:
Sorted set thêm thứ tự bằng score, phù hợp bảng xếp hạng, “top N” và sắp xếp theo thời gian hoặc độ phổ biến. Bạn có thể lưu score như số lượt xem hoặc timestamp và đọc top items nhanh chóng.
Vấn đề concurrency thường xuất hiện ở các tính năng nhỏ: bộ đếm, quota, hành động một lần. Nếu hai yêu cầu cùng lúc làm “đọc → cộng 1 → ghi”, bạn có thể mất cập nhật.
Phép toán nguyên tử giải quyết bằng cách thực hiện thay đổi như một bước không chia cắt trong store:
Với tăng nguyên tử, bạn không cần khoá hay phối hợp phức tạp giữa server. Điều đó giảm race condition, đơn giản hoá code và cho hành vi ổn định dưới tải—đặc biệt cho rate limiting và quota nơi “gần đúng” có thể dẫn tới lỗi hiển thị tới khách hàng.
Khi kho key-value chịu tải lớn, “làm cho nó nhanh hơn” thường là “làm cho nó rộng hơn”: phân phối đọc/ghi qua nhiều node trong khi giữ hệ thống dự đoán được khi có lỗi.
Replication giữ nhiều bản sao của cùng một dữ liệu.
Sharding chia keyspace qua các node.
Nhiều triển khai kết hợp cả hai: sharding để tăng throughput, replica cho mỗi shard để tăng sẵn sàng.
“Tính sẵn sàng cao” nghĩa là tầng cache/phiên tiếp tục phục vụ ngay cả khi một node chết.
Với client-side routing, ứng dụng (hoặc thư viện) tính node nào giữ khóa (thường dùng consistent hashing). Rất nhanh, nhưng client phải cập nhật khi topology thay đổi.
Với server-side routing, gửi request tới proxy hoặc endpoint cluster, nó sẽ chuyển tiếp tới node phù hợp. Đơn giản hoá client và rollout nhưng thêm một lần trung gian.
Lập kế hoạch bộ nhớ theo trên xuống:
Kho key-value cho cảm giác “ngay lập tức” vì nó giữ dữ liệu nóng trong bộ nhớ và tối ưu cho đọc/ghi nhanh. Tốc độ này có giá: bạn thường phải chọn giữa hiệu năng, độ bền và nhất quán. Hiểu rõ đánh đổi từ đầu tránh những bất ngờ đau đầu sau này.
Nhiều kho chạy với các chế độ độ bền khác nhau:
Chọn chế độ phù hợp với mục đích dữ liệu: cache chấp nhận mất; lưu phiên cần thận trọng hơn.
Trong thiết lập phân tán, bạn có thể thấy nhất quán cuối cùng—đọc có thể trả về giá trị cũ ngay sau khi ghi, đặc biệt khi failover hoặc lag replicate. Nhất quán mạnh hơn (ví dụ yêu cầu ack từ nhiều node) giảm bất thường nhưng tăng độ trễ và có thể giảm sẵn sàng khi mạng gặp sự cố.
Cache đầy. Chính sách trục xuất quyết định cái bị loại: ít dùng gần đây nhất (LRU), ít dùng thường xuyên (LFU), ngẫu nhiên, hoặc “không trục xuất” (khi đó đầy sẽ gây lỗi ghi). Quyết định xem bạn muốn thiếu mục cache hay lỗi được ghi khi áp lực cao.
Giả sử sự cố xảy ra. Các biện pháp thường thấy:
Thiết kế những hành vi này có chủ đích là thứ khiến hệ thống cảm giác đáng tin cậy với người dùng.
Kho key-value thường nằm trên “đường đi nóng” của app. Điều đó làm cho nó vừa nhạy cảm (có thể chứa token phiên hoặc ID người dùng) vừa đắt (thường tốn nhiều bộ nhớ). Làm đúng từ sớm tránh các sự cố sau này.
Bắt đầu với ranh giới mạng rõ ràng: đặt store trong subnet/VPC riêng tư và chỉ cho phép traffic từ dịch vụ ứng dụng cần thiết.
Dùng xác thực nếu sản phẩm hỗ trợ, và tuân theo nguyên tắc ít đặc quyền: tài khoản riêng cho app, admin, automation; xoay secrets; tránh dùng token “root” chung. Mã hoá truyền tải (TLS) khi có thể—đặc biệt khi traffic qua host hoặc zone. Mã hoá dữ liệu ở rest tuỳ sản phẩm; nếu hỗ trợ, bật cho managed services và kiểm tra mã hoá backup.
Một tập metrics nhỏ cho biết cache có giúp hay gây hại:
Thêm cảnh báo cho thay đổi đột ngột, không chỉ ngưỡng tuyệt đối, và log thao tác khóa cẩn trọng (không log giá trị nhạy cảm).
Những yếu tố chính:
Một đòn bẩy thực tế là giảm kích thước giá trị và đặt TTL thực tế để store chỉ giữ thứ hữu ích đang hoạt động.
Bắt đầu bằng chuẩn hoá quy ước đặt tên khóa để cache và khóa phiên dễ đoán, tìm kiếm và thao tác hàng loạt. Một quy ước như app:env:feature:id (ví dụ shop:prod:cart:USER123) giúp tránh va chạm và gỡ lỗi nhanh.
Định nghĩa chiến lược TTL trước khi ra mắt. Quyết dữ liệu nào an toàn hết hạn nhanh (giây/phút), cần lâu hơn (giờ), và không nên cache. Nếu cache dòng DB, căn TTL với tần suất dữ liệu nền thay đổi.
Ghi ra kế hoạch vô hiệu hóa cho mỗi loại cache:
product:v3:123) khi muốn invalidate toàn bộ đơn giảnChọn vài metrics và theo dõi từ ngày đầu:
Cũng theo dõi eviction và sử dụng bộ nhớ để xác nhận cache đã được kích thước hợp lý.
Giá trị quá lớn làm tăng thời gian mạng và áp lực bộ nhớ—ưu tiên cache các đoạn nhỏ, đã tính trước. Tránh thiếu TTL (dẫn tới dữ liệu lỗi thời và rò bộ nhớ) và tăng trưởng khóa không giới hạn (ví dụ cache mọi query tìm kiếm mãi mãi). Cẩn thận khi cache dữ liệu theo user dưới khóa chia sẻ.
Nếu bạn đang đánh giá lựa chọn, so sánh cache cục bộ trong process với cache phân tán và quyết nơi nào cần nhất tính nhất quán. Để chi tiết triển khai và hướng dẫn vận hành, xem tài liệu nội bộ. Nếu bạn cần ước tính dung lượng hoặc giả định giá, xem phần định giá nội bộ.
Nếu bạn xây dựng sản phẩm mới (hoặc hiện đại hoá), nên coi caching và lưu trữ phiên là mối quan tâm hàng đầu từ đầu. Trên Koder.ai, các đội thường tạo nguyên mẫu end-to-end (React trên web, dịch vụ Go với PostgreSQL, và tuỳ chọn Flutter cho mobile) rồi lặp tối ưu hiệu năng theo các mẫu như cache-aside, TTL và bộ đếm giới hạn tần suất. Các tính năng như chế độ lập kế hoạch, snapshot và rollback giúp thử nghiệm thiết kế khóa cache và chiến lược vô hiệu hóa an toàn, và bạn có thể xuất mã nguồn khi sẵn sàng chạy trong pipeline của riêng mình.
Key-value store tối ưu cho một phép toán: cho một khóa, trả về một giá trị. Sự tập trung hẹp này cho phép những đường dẫn nhanh như chỉ mục trong bộ nhớ và băm, với ít overhead cho việc lập kế hoạch truy vấn so với cơ sở dữ liệu đa năng.
Chúng cũng cải thiện hệ thống gián tiếp bằng cách chuyển bớt các đọc lặp lại (trang phổ biến, các phản hồi API thông dụng) khỏi cơ sở dữ liệu chính, để DB tập trung vào ghi và truy vấn phức tạp.
Khóa là một định danh duy nhất bạn có thể lặp lại chính xác (thường là chuỗi như user:123 hoặc sess:\u003ctoken\u003e). Giá trị là thứ bạn muốn nhận lại—từ một bộ đếm nhỏ đến một JSON blob.
Khóa tốt là ổn định, có phạm vi, và dễ đoán, giúp việc caching, phiên và tra cứu vận hành và gỡ lỗi đơn giản.
Hãy lưu những kết quả được đọc thường xuyên và an toàn để tái tạo nếu mất.
Ví dụ thông dụng:
Tránh cache dữ liệu luôn phải cập nhật tức thì (ví dụ số dư tài khoản) trừ khi bạn có chiến lược vô hiệu hóa mạnh.
Cache-aside (tải lười) thường là mặc định:
key từ cache.Nó xuống cấp một cách mềm mại: nếu cache trống hoặc gặp sự cố, bạn vẫn có thể phục vụ từ database (với các biện pháp bảo vệ phù hợp).
Dùng read-through khi bạn muốn tầng cache tự tải khi miss (code ứng dụng đơn giản hơn, nhưng cần tích hợp loader ở tầng cache).
Dùng write-through khi bạn muốn đọc luôn ấm vì mọi ghi đồng bộ cập nhật cả cache lẫn database—đổi lấy độ trễ ghi cao hơn.
Chọn khi bạn chấp nhận phức tạp vận hành (read-through) hoặc thời gian ghi tăng (write-through).
TTL khiến một khóa tự hết hạn sau khoảng thời gian. TTL ngắn giảm độ cũ nhưng tăng tần suất miss và tải backend; TTL dài cải thiện hit rate nhưng tăng rủi ro trả dữ liệu lỗi thời.
Mẹo thực tế:
Cache stampede xảy ra khi một khóa nóng hết hạn và nhiều yêu cầu đồng thời xây dựng lại nó.
Các cách giảm:
Những cách này giảm đột biến lên database hoặc API bên ngoài.
Phiên rất hợp với key-value vì thao tác đơn giản: đọc/ghi theo token và đặt thời hạn. TTL giúp các phiên không hoạt động tự hết, giữ lưu trữ gọn và giảm rủi ro khi token bị lộ.
Thực hành tốt:
sess:\u003ctoken\u003e (phiên bản hóa như sess:v2:\u003ctoken\u003e giúp di trú).Nhiều kho key-value hỗ trợ tăng nguyên tử, làm cho bộ đếm an toàn khi có đồng thời.
Mẫu thường gặp:
rl:user:123:minute → tăng mỗi yêu cầuNếu bộ đếm vượt ngưỡng, hãy throttle hoặc từ chối yêu cầu. TTL tự động đặt lại giới hạn mà không cần job nền.
Những điểm cần cân nhắc:
Thiết kế cho chế độ suy giảm: sẵn sàng bỏ qua cache, phục vụ dữ liệu hơi cũ khi an toàn, hoặc đóng chặt với các thao tác nhạy cảm.