Tiếp tục bài trước, bài này tôi sẽ tổng hợp những kiến thức về disbuted cache và cache replacement/invalication

Link bài 1: Caching part 1

Link bài 2: Cahcing part 2

Caching phần 3

  1. cache strategies
    • cache aside
    • read through
    • write around
    • write through
    • write back
    • which strategies do people prefer? Pros and Cons của mỗi loại
  2. cache challenges
    • thundering herd
    • cache penetration
    • cache Avalanche
    • big key
    • hot key
    • data consistency
  3. monitoring and alerts

6. Cache strategies [1]

Cache strategies

Đối với read, tôi thường lựa chọn Read through, xem cache như là interface duy nhất để giao tiếp. Đối với write, nếu sử dụng event-based, thì nên write trực tiếp vào db rồi gửi event xóa cache. Hoặc nếu không dùng event based, cũng ghi trực tiếp vào db và gọi hàm xóa cache. Tôi không ưu tiên việc update data trên cache.

7. Cache challenges

7.1 Thundering herd problem (Cache break down) [2]

Thundering (sấm sét), herd (lượng lớn động vật trong 1 đàn) -> thundering herd mô tả việc server phải xử lý 1 lượng lớn request cùng lúc, lớn hơn mức nó có thể xử lý.

Nhiều request truy cập database tại cùng thời điểm, tìm kiếm cùng key, thundering herd xảy ra. Ví dụ, ta có 1000 request, trong đó 1 request có key là key_A, 999 request có key là key_B. Nếu key_B bị miss cache, lượng lớn request này sẽ gọi database cùng lúc. Điểm cần lưu ý là 999 request của key_B phải được gọi cùng lúc. Do được kiểm tra cache cùng lúc, nên 999 request đều báo cache miss

Mitigate solution:

  • Refresh-ahead strategy: asynchronously refresh hot data, do đó, hot key sẽ không bao giờ bị expired. Giả sử expired time là 60s và refresh factor là 0.5. Nếu data được access ở giây thứ 25, không có chuyện gì xảy ra. Nếu data được access ở giây 45, expired time được reset lại 60s

7.2 Cache penetration [2]

Cache penetration là khi search key không tồn tại trong cache hoặc database. Khi gặp key kiểu này, ta đều gọi cache và database liên tục. Bởi vì database trả về null, ta không cache nó vào cache. Attacker có thể tận dụng điều này, khiến database quá tải bằng việc liên tục gửi key không có trong cache và database.

Giải pháp:

  • Cache empty result trong thời gian ngắn, có thể là 5 phút.
  • Xem xét lại các hàm validation
  • Sử dụng Bloom filtering. Trước khi gọi database, key cần được tìm kiếm trong bloom filter và return ngay lập tức nếu key không tồn tại trong db.

7.3 Cache Avalanche (tuyết lở) [2]

Xảy ra khi lượng lớn request truy cập database 1 cách bất thường.

Thường xảy ra khi:

  • Lượng lớn cache data bị expired cùng thời điểm
  • Cache service bị down, tất cả request phải truy cập db
  • Cache service bị khởi động, không có warm up cache

Mitigation solution

  • Sử dụng refresh-ahead strategy: asynchronously refresh hot data, do đó, hot key sẽ không bao giờ bị expired
  • Sử dụng cahce cluster, tránh single pont of failure

7.4 Hot key problem [3]

Hot key problem xảy ra khi lượng lớn traffic cho 1 key, vượt quá khả năng xử lý của cahce server, dẫn đến giảm performance cho toàn application.

Trong distributed cache, nếu 1 vài hot key tập trung trong 1 server, server này sẽ quá tải, trong khi các server khác không có gì để làm.

Vấn đề này thường xảy ra khi có các chiến dịch quảng cáo, sự kiện phim ảnh, ca nhạc mới nổi, …. Nếu vấn đề thường xảy ra, cần có cơ chế phân tích và định dạng đâu là hot key

Để giảm thiểu, ta có thể

  • Distribute traffic pressure across the entire cache system. Giả sử key1 là hot key. Ta có thể thêm suffix cho nó, như là key1_1, key1_2, key1_3, … key1_n. Cố gắng để key1 được phân phối trên toàn cache cluster. Key có request cho key1, dùng random đẻ chọn suffix.
  • Nếu có 1 lượng đáng kể hot-key, đặc biệt hơn là nó thay đổi theo mùa, thì cần có cơ chế tự động
  • Ta cũng có thể dùng local cache, giảm traffic cho remote cache.

7.5 Large key problem [3]

Khi giá trị cần cache của key lớn, nó có thể dẫn tới timeout –> large key problem

  • Việc thường duyên phải truy suất key lớn, dẫn tới sử dụng nhiều network bandwidth
  • Nếu large key bị invalid, việc reload cũng tốn thời gian.

8. monitoring and alerts

  • Sử dụng cache hit ratio để xem xét hiệu quả của cache
  • Có thể monitor xem cache peak có theo quy luật nào không?

Tôi cũng chưa có nhiều kinh nghiệm cho vụ monitor này. Hy vọng sau này có thể cập nhật thêm.

Referene:

  1. Top caching strategies
  2. 3 Caching Problems Every Developer Should Know
  3. A Crash Course in Caching - Final Part