Quản lý hoạt động của bộ nhớ đệm

Dịch vụ Lưu trữ Firebase sử dụng một CDN mạnh mẽ trên toàn cầu để giúp trang web của bạn có tốc độ nhanh nhất có thể.

Mọi nội dung tĩnh được yêu cầu đều được tự động lưu vào bộ nhớ đệm trên CDN. Nếu bạn triển khai lại nội dung trang web của bạn, tính năng Lưu trữ Firebase sẽ tự động xoá tất cả nội dung được lưu vào bộ nhớ đệm trên CDN cho đến lần yêu cầu tiếp theo.

Tuy nhiên, vì các dịch vụ Cloud Functions và Cloud Run tạo ra nội dung động, thì nội dung của một URL nhất định có thể thay đổi tuỳ theo những điều đó làm hoạt động đầu vào của người dùng hoặc danh tính của người dùng. Để tính đến điều này, những yêu cầu do mã phụ trợ xử lý thì không lưu vào bộ nhớ đệm trên CDN theo mặc định.

Tuy nhiên, bạn có thể định cấu hình hành vi lưu vào bộ nhớ đệm cho nội dung động. Để ví dụ: nếu một hàm chỉ tạo nội dung mới định kỳ, bạn có thể tăng tốc ứng dụng của bạn bằng cách lưu nội dung đã tạo vào bộ nhớ đệm trong ít nhất một khoảng thời gian ngắn.

Bạn cũng có thể định cấu hình hành vi lưu vào bộ nhớ đệm theo cách tương tự để có thể giảm hàm chi phí thực thi do nội dung được phân phát từ CDN chứ không phải từ được kích hoạt. Đọc thêm về cách tối ưu hoá việc thực thi hàm và các dịch vụ trong Cloud FunctionsCloud Run .

Trường hợp ngoại lệ là các yêu cầu trả về lỗi 404. CDN sẽ lưu vào bộ nhớ đệm phản hồi 404 của dịch vụ đối với một URL không tồn tại trong 10 phút để cho URL đó được phân phát ngoài CDN. Nếu bạn thay đổi dịch vụ để nội dung hiện đang tồn tại tại URL này, CDN sẽ tiếp tục phân phát bất kỳ nội dung nào được lưu vào bộ nhớ đệm 404 trong 10 phút (tối đa) rồi phân phát nội dung từ URL đó như bình thường.

Nếu phản hồi 404 đã chứa tiêu đề bộ nhớ đệm do Cloud Functions hoặc dịch vụ Cloud Run, chúng sẽ ghi đè là 10 phút và xác định đầy đủ hành vi lưu vào bộ nhớ đệm của CDN.

Tìm hiểu thêm về hoạt động lưu vào bộ nhớ đệm trong tài liệu dành cho nhà phát triển web.

Thiết lập tính năng Kiểm soát bộ nhớ đệm

Công cụ chính mà bạn sử dụng để quản lý bộ nhớ đệm cho nội dung động là Tiêu đề Cache-Control. Bằng cách định cấu hình tiêu đề này, bạn có thể giao tiếp cả hai với trình duyệt và CDN khoảng thời gian nội dung của bạn có thể được lưu vào bộ nhớ đệm. Trong hàm, bạn đã thiết lập Cache-Control như sau:

res.set('Cache-Control', 'public, max-age=300, s-maxage=600');

Trong tiêu đề ví dụ này, các lệnh thực hiện 3 việc:

  • public – Đánh dấu bộ nhớ đệm là public. Điều này có nghĩa là cả trình duyệt các máy chủ trung gian (nghĩa là CDN cho Lưu trữ Firebase) có thể lưu vào bộ nhớ đệm nội dung.

  • max-age – Cho trình duyệt và CDN biết số giây mà chúng có thể lưu vào bộ nhớ đệm nội dung. Khi thời gian đã đặt hết hạn, trình duyệt và CDN phải xác thực lại nội dung bằng máy chủ gốc. Trong tiêu đề ví dụ, chúng ta cho phép trình duyệt và CDN lưu nội dung vào bộ nhớ đệm trong năm phút (xem s-maxage bên dưới để biết các chế độ kiểm soát cụ thể đối với việc lưu vào bộ nhớ đệm của CDN.

  • s-maxage – Chỉ ghi đè lệnh max-age cho việc lưu vào bộ nhớ đệm của CDN; cho biết số giây mà CDN có thể lưu nội dung vào bộ nhớ đệm. Khi thời gian đã đặt hết hạn, thì CDN phải xác thực lại nội dung đó với máy chủ gốc. Trong tiêu đề ví dụ, chúng tôi sẽ ghi đè chế độ cài đặt cho max-age chỉ dành cho CDN và cho phép CDN lưu nội dung vào bộ nhớ đệm trong mười phút.

Đối với max-ages-maxage, hãy đặt giá trị của chúng thành khoảng thời gian dài nhất mà bạn cảm thấy thoải mái khi người dùng nhận được nội dung lỗi thời. Nếu một trang thay đổi mỗi vài giây, hãy sử dụng giá trị thời gian nhỏ. Tuy nhiên, các loại nội dung khác cũng có thể được lưu vào bộ nhớ đệm an toàn trong nhiều giờ, nhiều ngày hoặc thậm chí nhiều tháng.

Bạn có thể tìm hiểu thêm về tiêu đề Cache-Control trên Mạng nhà phát triển Mozilla và trong tài liệu dành cho nhà phát triển web.

Khi nào nội dung được lưu vào bộ nhớ đệm được phân phát?

Trình duyệt và CDN sẽ lưu nội dung của bạn vào bộ nhớ đệm dựa trên:

  • Tên máy chủ
  • Đường dẫn
  • Chuỗi truy vấn
  • Nội dung của các tiêu đề yêu cầu được chỉ định trong tiêu đề Vary

Thay đổi tiêu đề

Chiến lược phát hành đĩa đơn Tiêu đề Vary xác định tiêu đề của yêu cầu nào sẽ được dùng để cung cấp thông tin (nội dung được lưu vào bộ nhớ đệm có hợp lệ hay không đã được xác thực lại với máy chủ gốc).

Dịch vụ Lưu trữ Firebase tự động đặt một tiêu đề Vary thích hợp trên cho các tình huống thường gặp. Bạn không cần phải lo lắng trong mọi trường hợp về tiêu đề Vary. Tuy nhiên, trong một số trường hợp sử dụng nâng cao, bạn có thể phải tiêu đề khác mà bạn cần tác động đến bộ nhớ đệm. Khi trường hợp đó xảy ra, bạn có thể đặt tiêu đề Vary cho câu trả lời. Ví dụ:

res.set('Vary', 'Accept-Encoding, X-My-Custom-Header');

Trong trường hợp này, giá trị của tiêu đề Vary sẽ là:

vary: X-My-Custom-Header, x-fh-requested-host, accept-encoding, cookie, authorization

Với các chế độ cài đặt này, hai yêu cầu giống hệt nhau có X-My-Custom-Header tiêu đề được lưu vào bộ nhớ đệm riêng. Xin lưu ý rằng tính năng Lưu trữ sẽ thêm CookieAuthorization vào tiêu đề Vary theo mặc định khi có yêu cầu dành cho nội dung động. Điều này đảm bảo rằng mọi uỷ quyền phiên hoặc cookie tiêu đề mà bạn sử dụng thuộc khoá bộ nhớ đệm. Khoá này giúp ngăn chặn việc vô tình rò rỉ dữ liệu về nội dung.

Ngoài ra, xin lưu ý:

  • Chỉ có thể lưu vào bộ nhớ đệm các yêu cầu GETHEAD. Các yêu cầu HTTPS sử dụng tuyệt đối không được lưu vào bộ nhớ đệm.

  • Hãy cẩn thận khi thêm chế độ cài đặt vào tiêu đề Vary. Càng nhiều chế độ cài đặt mà bạn thêm, thì càng ít khả năng CDN có thể phân phát nội dung được lưu vào bộ nhớ đệm. Ngoài ra, hãy nhớ rằng Vary dựa trên tiêu đề yêu cầu, chứ không phải phản hồi .

Sử dụng cookie

Khi sử dụng tính năng Lưu trữ Firebase cùng với Cloud Functions hoặc Cloud Run, thường sẽ loại bỏ cookie khỏi các yêu cầu đến. Chiến dịch này là cần thiết để cho phép hoạt động lưu trong bộ nhớ đệm của CDN hiệu quả. Chỉ cookie __session có tên đặc biệt mới được phép truyền đến ứng dụng của bạn.

Cookie __session sẽ tự động trở thành một phần của bộ nhớ đệm (nếu có) nghĩa là hai người dùng có các cookie khác nhau không thể nhận phản hồi được lưu vào bộ nhớ đệm của đối tượng khác. Chỉ sử dụng cookie __session nếu ứng dụng phân phát nội dung khác nhau tuỳ thuộc vào sự cho phép của người dùng.