In-memory caching – Liệu bạn có nên lựa chọn nó và cách sử dụng nó như thế nào

1 Like

Hi @Ntech_Developers

Cảm ơn cậu về bài viết nhé! Đây là một topic rất thú vị, và thực ra là tương đối advance.
Tớ có mấy góp ý dưới đây cho câu về bài viết này nha :smile:

  • Tớ có đọc bài viết của cậu, và nghĩ cậu đang mô tả về local in-memory cache.
    Đó là 1 topology (hay cache architect pattern) hay gặp nhất trong các ứng dụng. Sở dĩ, nên gọi nó là local in-memory cache vì:
    • Đó là tên gọi của pattern này, chỉ cache nằm trong ứng dụng, và chia sẻ tài nguyên với ứng dụng (CPU, heap memory, etc).
    • Thực ra, hầu hết các cache đều là in-memory :smile:
  • Tớ không nghĩ local in-memory cache sử dụng bộ nhớ đệm đâu :smile:
    Trong TH của C#, tớ nghĩ dữ liệu trong local in-memory cache nằm trên heap memory (correct tớ nếu tớ sai nhé! :smile: )
  • Local in-memory cache thực ra có thể được sử dụng trong micro service, khi cậu có thể:
    • Lưu trữ một dữ liệu rất ít khi thay đổi, như configuration, etc.
    • Sử dụng để suport far cache (như redis). Cậu có thể dùng local in-memory cache để cache lại dữ liệu với expiry time rất nhỏ (1 hoặc vài giây).
      Nó sẽ giúp cậu giảm được chút load tới far cache, đặc biệt khi có 1 entry đặc biệt nào đó được request tới rất nhiều (lúc này, redis thường sẽ bị quá tải ở 1 server nhất định chứa entry đó).
  • Local in-memory cache có một hạn chế nữa, đó là việc nó share tài nguyên với ứng dụng, dẫn tới việc nếu cache càng nhiều dữ liệu => resource dành cho application càng ít.
    Trong TH của C#, heap là tài nguyên đó. Ngoài ra, cậu cũng đôi khi sẽ gặp GC overhead khi ứng dụng của cậu có nhiều traffic bởi các operation trên cache (như tính expire time, cache eviction, etc)

Đó là một số góp ý của tớ về bài viết này. Rất hi vọng nó có ích, và chúng ta có thể thảo luận sâu thêm về chủ đề này :smile:

3 Likes
83% thành viên diễn đàn không hỏi bài tập, còn bạn thì sao?