[DB] Tiêu chí thiết lập bộ nhớ đệm

Xin chào? Tôi là Jayon.

Hôm nay, tôi muốn giải thích các tiêu chí thiết lập bộ nhớ đệm (cache). Bài đăng này được viết dựa trên kinh nghiệm thực tế cá nhân, vì vậy bạn nên xem nó như một tài liệu tham khảo ㅎㅎ

Cache là gì?

Cache có nghĩa là lưu trữ trước kết quả của các yêu cầu trong tương lai để phục vụ nhanh hơn. Nói cách khác, nó lưu trữ kết quả trước và khi có yêu cầu, thay vì tham chiếu đến cơ sở dữ liệu (DB) hoặc API, nó sẽ truy cập vào cache để xử lý yêu cầu. Nguồn gốc của cache xuất phát từ định luật Pareto.

Định luật Pareto nói rằng 80% kết quả là do 20% nguyên nhân gây ra, bạn có thể tham khảo hình ảnh bên dưới!

Tức là, cache không cần phải lưu trữ tất cả kết quả, mà chỉ cần lưu trữ 20% được sử dụng nhiều nhất khi cung cấp dịch vụ, qua đó có thể cải thiện hiệu quả tổng thể.

Nên lưu trữ dữ liệu nào trong cache?

Theo định luật Pareto, chúng ta không nên lưu trữ bất kỳ dữ liệu nào vào cache mà chỉ nên lưu trữ những dữ liệu thực sự cần thiết. Vậy, nên lưu trữ những dữ liệu nào?

Dữ liệu thường được đọc nhưng hiếm khi được ghi

Về mặt lý thuyết, người ta thường nói rằng “nên lưu trữ dữ liệu thường được đọc nhưng hiếm khi được ghi vào cache”, nhưng tiêu chí “thường được đọc” và “hiếm khi được ghi” khá mơ hồ.

Vì vậy, tôi điều tra dữ liệu cần lưu trữ cache theo các bước sau.

• Kiểm tra 5 truy vấn hàng đầu của RDB thông qua APM như DataDog.
• Trong số đó, tìm kiếm truy vấn truy vấn và xác định bảng nào được truy vấn.
• Kiểm tra xem truy vấn cập nhật của bảng đó được gọi bao nhiêu lần.

Qua quy trình này, chúng ta kiểm tra xem truy vấn truy vấn có nhiều nhưng truy vấn cập nhật ít xảy ra hay không. Bảng mà tôi đã kiểm tra trong thực tế có 1,74 triệu lần truy vấn truy vấn mỗi ngày, nhưng truy vấn cập nhật chỉ khoảng 500 lần. Với điều kiện này, ai cũng có thể thấy rằng nó phù hợp để lưu trữ trong cache ㅎㅎ

Dữ liệu nhạy cảm với cập nhật

Dữ liệu nhạy cảm với cập nhật có nghĩa là sự khác biệt giữa RDB và cache phải ngắn. Ví dụ, thông tin liên quan đến thanh toán rất nhạy cảm với cập nhật, vì vậy ngay cả khi đáp ứng các điều kiện cache ở trên, chúng ta cũng cần phải cân nhắc việc áp dụng nó.

Tôi phải lưu trữ các bảng liên quan đến thanh toán đáp ứng 2 đặc điểm trên trong cache. Vì vậy, tôi không áp dụng cache cho tất cả các logic sử dụng các bảng liên quan đến thanh toán này, mà đã quyết định áp dụng cache một phần cho các logic tương đối an toàn, nơi mà thanh toán không thực sự diễn ra.

Cache cục bộ so với cache toàn cầu

Bây giờ, chúng ta đã xác định được dữ liệu và phạm vi cần lưu trữ trong cache. Tiếp theo, chúng ta phải xem xét “nơi” để lưu trữ dữ liệu cache. Thông thường, chúng ta có thể lưu trữ trong bộ nhớ cục bộ hoặc trên một máy chủ riêng biệt như Redis.

Cache cục bộ

Cache cục bộ là phương pháp lưu trữ dữ liệu cache trong bộ nhớ của máy chủ ứng dụng, và thường sử dụng Guava cache hoặc Caffeine cache.

Ưu điểm

• Vì truy vấn cache trực tiếp từ bộ nhớ trong cùng một máy chủ trong quá trình thực thi logic ứng dụng, nên tốc độ rất nhanh.
• Dễ triển khai.

Nhược điểm

• Nếu có nhiều instance, sẽ phát sinh một số vấn đề.

Cache toàn cầu

Cache toàn cầu là phương pháp sử dụng máy chủ lưu trữ dữ liệu cache riêng biệt như Redis.

Ưu điểm

• Vì chia sẻ cache giữa các instance, nên ngay cả khi cache được sửa đổi trên một instance, tất cả các instance đều có thể nhận được cùng một giá trị cache.
• Ngay cả khi instance mới xuất hiện, nó cũng có thể tham chiếu đến kho lưu trữ cache đã tồn tại, vì vậy không cần phải tải lại cache.

Nhược điểm

• Vì phải thông qua lưu lượng truy cập mạng, nên tốc độ chậm hơn so với cache cục bộ.
• Phải sử dụng máy chủ cache riêng biệt, dẫn đến chi phí quản lý cơ sở hạ tầng.

Tác giả đã chọn cái nào?

Hiện tại, máy chủ ứng dụng của công ty đang chạy nhiều instance, nhưng tôi đã chọn cache cục bộ.

Có 3 lý do chính.

• Dữ liệu cần lưu trữ trong cache được lưu trữ trong RDB có khoảng 40.000 hàng, nếu tải tất cả vào bộ nhớ thì dung lượng dưới 4MB.
• Cần phải cải thiện hiệu năng truy vấn dữ liệu liên quan đến thanh toán.
• Mặc dù Redis đã được sử dụng, nhưng việc lưu trữ cache mới vào Redis sẽ phát sinh chi phí cơ sở hạ tầng.

Làm thế nào để cập nhật cache?

Nếu có nhiều máy chủ ứng dụng và áp dụng cache cục bộ, giá trị cache được lưu trữ trên mỗi máy chủ ứng dụng có thể khác nhau. Ví dụ, dữ liệu cache được lưu trữ trên máy chủ A là “1”, nhưng dữ liệu cache được lưu trữ trên máy chủ B đã được thay đổi thành “2” trên máy chủ B. Trong trường hợp này, nếu người dùng gửi yêu cầu đến bộ cân bằng tải, họ sẽ nhận được các giá trị khác nhau từ máy chủ A và máy chủ B.

Do đó, cần phải cấu hình để tự động xóa cache trên mỗi instance và truy vấn từ RDB, và TTL thường được sử dụng trong trường hợp này.

Nên thiết lập TTL là bao nhiêu?

TTL là viết tắt của Time To Live, là cài đặt xóa cache sau một khoảng thời gian nhất định. Ví dụ, nếu TTL được đặt là 5 giây, dữ liệu cache sẽ tự động bị xóa sau 5 giây. Sau đó, nếu xảy ra lỗi cache, dữ liệu sẽ được truy vấn từ RDB và lưu trữ.

Vậy, nên thiết lập TTL là bao nhiêu?

Đọc/ghi xảy ra trên một máy chủ cache

Nếu đọc/ghi xảy ra trên một máy chủ cache toàn cầu như Redis hoặc trên một máy chủ ứng dụng đã áp dụng cache cục bộ, thì giá trị TTL có thể được đặt cao hơn đơn vị thời gian. Dù sao thì khi ghi, cache cũ sẽ được sửa đổi và máy chủ truy cập dữ liệu từ cache đó luôn nhận được dữ liệu mới nhất.

Trong trường hợp này, TTL có thể không được thiết lập và cache có thể được xóa dần bằng thuật toán LRU khi cache đầy.

Đọc/ghi xảy ra trên nhiều máy chủ cache

Nếu đọc/ghi xảy ra trên nhiều máy chủ cache toàn cầu hoặc trên nhiều máy chủ ứng dụng đã áp dụng cache cục bộ, tốt nhất nên đặt TTL trong khoảng từ vài giây đến vài phút. Bởi vì có thể xảy ra trường hợp đọc dữ liệu cũ từ máy chủ cache chưa phản ánh dữ liệu đã được sửa đổi.

Trong trường hợp này, TTL được xác định dựa trên nhiều ngữ cảnh khác nhau, nếu cập nhật quan trọng và xác suất thay đổi giá trị cao thì TTL nên ngắn, ngược lại, nếu cập nhật không quan trọng và xác suất thay đổi giá trị thấp thì TTL có thể dài hơn một chút.

Tác giả đã thiết lập TTL như thế nào?

Dữ liệu tôi cần lưu trữ trong cache là dữ liệu liên quan đến thanh toán, và ngay cả khi không áp dụng cache cho các logic thanh toán thực tế, thì tính chất thanh toán vẫn đòi hỏi cập nhật. Tuy nhiên, khả năng cập nhật thấp, vì vậy tôi đã đặt TTL là 5 giây để đảm bảo an toàn.

Kết luận

Tóm lại, phương thức cache mà tôi đã chọn như sau.

• Dữ liệu liên quan đến thanh toán
• Truy vấn rất thường xuyên, nhưng cập nhật rất hiếm.
• Chỉ áp dụng cache cho các logic không thực hiện thanh toán nhưng vẫn có truy vấn.
• Áp dụng cache cục bộ và thiết lập TTL là 5 giây.

Công việc tiếp theo là tiến hành kiểm tra hiệu năng cho phương thức cache đã áp dụng. Hiện tại, tôi vẫn đang suy nghĩ về cách thức kiểm tra hiệu năng cụ thể, vì vậy tôi sẽ viết trong các bài đăng tiếp theo!