Lưu vào bộ nhớ đệm trong thời gian chạy tức là thêm dần phản hồi vào bộ nhớ đệm "khi bạn di chuyển". Mặc dù việc lưu vào bộ nhớ đệm trong thời gian chạy không giúp tăng độ tin cậy của yêu cầu hiện tại, nhưng có thể giúp các yêu cầu trong tương lai cho cùng một URL trở nên đáng tin cậy hơn.
Bộ nhớ đệm HTTP của trình duyệt là một ví dụ về bộ nhớ đệm trong thời gian chạy; bộ nhớ đệm này chỉ được điền sẵn sau khi có yêu cầu cho một URL nhất định. Tuy nhiên, trình chạy dịch vụ cho phép bạn triển khai chức năng lưu vào bộ nhớ đệm trong thời gian chạy vượt ngoài khả năng của bộ nhớ đệm HTTP.
Trở thành chiến lược
Khác với việc lưu trước vào bộ nhớ đệm (luôn cố phân phát một tập hợp các tệp được xác định trước từ bộ nhớ đệm), tính năng lưu vào bộ nhớ đệm trong thời gian chạy có thể kết hợp quyền truy cập vào mạng và bộ nhớ đệm theo nhiều cách. Mỗi kết hợp thường được gọi là một chiến lược lưu vào bộ nhớ đệm. Các chiến lược lưu chính vào bộ nhớ đệm bao gồm:
- Ưu tiên mạng
- Ưu tiên lưu vào bộ nhớ đệm
- Phiên bản cũ trong khi xác thực lại
Ưu tiên mạng
Trong phương pháp này, trước tiên, trình chạy dịch vụ sẽ cố gắng truy xuất một phản hồi từ mạng. Nếu yêu cầu mạng thành công thì thật tuyệt! Phản hồi được trả về ứng dụng web của bạn và bản sao của phản hồi được lưu trữ bằng API Bộ nhớ đệm – tạo một mục mới hoặc cập nhật mục nhập trước đó cho cùng một URL.
Nếu yêu cầu mạng không thành công hoàn toàn hoặc mất quá nhiều thời gian để trả về một phản hồi, thì phản hồi gần đây nhất từ bộ nhớ đệm sẽ được trả về.
Ưu tiên lưu vào bộ nhớ đệm
Chiến lược ưu tiên bộ nhớ đệm có hiệu quả ngược lại với chiến lược ưu tiên mạng. Trong phương pháp này, khi trình chạy dịch vụ chặn một yêu cầu, trước tiên, trình chạy sẽ sử dụng API Bộ nhớ đệm để xem có phản hồi lưu vào bộ nhớ đệm hay không. Nếu có, phản hồi đó sẽ được trả về ứng dụng web.
Tuy nhiên, nếu xảy ra sự cố thiếu bộ nhớ đệm, thì trình chạy dịch vụ sẽ truy cập mạng và cố gắng truy xuất phản hồi ở đó. Giả sử yêu cầu mạng thành công, yêu cầu đó sẽ được trả về ứng dụng web của bạn và một bản sao được lưu trong bộ nhớ đệm. Bản sao đã lưu vào bộ nhớ đệm này sẽ được dùng để bỏ qua mạng vào lần tiếp theo khi bạn thực hiện yêu cầu cho các URL tương tự.
Phiên bản cũ trong khi xác thực lại
Phiên bản cũ trong khi xác thực lại là phương pháp kết hợp. Khi sử dụng phương thức này, trình chạy dịch vụ sẽ ngay lập tức kiểm tra phản hồi đã lưu vào bộ nhớ đệm và nếu tìm thấy phản hồi, hãy truyền phản hồi đó về ứng dụng web của bạn.
Trong thời gian chờ đợi, bất kể có kết quả so khớp bộ nhớ đệm hay không, trình chạy dịch vụ của bạn cũng sẽ kích hoạt một yêu cầu mạng để nhận lại phản hồi "làm mới". Phản hồi này dùng để cập nhật mọi phản hồi đã lưu vào bộ nhớ đệm trước đó. Nếu bỏ lỡ lần kiểm tra bộ nhớ đệm ban đầu, thì một bản sao của phản hồi mạng cũng được chuyển lại ứng dụng web.
Tại sao bạn nên sử dụng Workbox?
Các chiến lược lưu vào bộ nhớ đệm này lên tới các công thức mà bạn thường phải viết lại trong trình chạy dịch vụ của riêng mình nhiều lần. Thay vì dùng lại cách này, Workbox cung cấp các gói này dưới dạng một phần của thư viện chiến lược để bạn có thể sử dụng cho trình chạy dịch vụ của mình.
Workbox cũng hỗ trợ tạo phiên bản, cho phép bạn tự động hết hạn các mục nhập vào bộ nhớ đệm hoặc thông báo cho ứng dụng web khi cập nhật một mục đã lưu vào bộ nhớ đệm trước đó.
Chiến lược nào nên được lưu vào bộ nhớ đệm?
Tính năng lưu vào bộ nhớ đệm trong thời gian chạy có thể được xem là một tính năng bổ sung cho việc lưu trước vào bộ nhớ đệm. Nếu tất cả nội dung của bạn đã được lưu trước vào bộ nhớ đệm, thì bạn đã hoàn tất—bạn không cần lưu vào bộ nhớ đệm trong thời gian chạy. Tuy nhiên, với bất kỳ ứng dụng web tương đối phức tạp nào, có khả năng bạn sẽ không lưu trước mọi thứ trong bộ nhớ đệm.
Tệp nội dung nghe nhìn lớn hơn, tài sản được phân phát từ máy chủ lưu trữ của bên thứ ba như CDN, hoặc phản hồi API, chỉ là một vài ví dụ về các loại tài sản không thể lưu trước vào bộ nhớ đệm trước một cách hiệu quả. Sử dụng Bảng điều khiển mạng trong Công cụ cho nhà phát triển để xác định những yêu cầu thuộc danh mục này và đối với từng yêu cầu, hãy cân nhắc xem nên đánh đổi như thế nào giữa độ mới và độ tin cậy.
Sử dụng tính năng cũ trong khi xác thực lại để ưu tiên độ tin cậy hơn độ mới
Vì chiến lược lỗi thời trong khi xác thực lại sẽ trả về phản hồi đã lưu vào bộ nhớ đệm gần như ngay lập tức (sau khi bộ nhớ đệm được điền thông qua yêu cầu đầu tiên), bạn sẽ thấy hiệu suất nhanh một cách đáng tin cậy khi sử dụng chiến lược này. Điều này đi kèm với việc đánh đổi việc nhận lại dữ liệu phản hồi có thể đã lỗi thời so với dữ liệu được truy xuất từ mạng. Việc sử dụng chiến lược này phù hợp nhất với các thành phần như ảnh hồ sơ người dùng hoặc các phản hồi ban đầu của API dùng để điền sẵn khung hiển thị, khi bạn biết rằng việc hiển thị nội dung nào đó ngay lập tức là chìa khoá, ngay cả khi đó là giá trị cũ hơn.
Sử dụng ưu tiên mạng để ưu tiên độ mới thay vì độ tin cậy
Theo nghĩa nào đó, việc sử dụng chiến lược ưu tiên mạng nghĩa là thừa nhận thất bại trong trận chiến trước mạng. Chiến lược này được ưu tiên, nhưng điều đó cũng đi kèm với sự không chắc chắn về độ tin cậy. Đối với một số loại thành phần, bạn nên xem phản hồi mới thay vì quay lại thông tin lỗi thời. Bạn có thể muốn có độ mới khi đưa ra yêu cầu API cho văn bản của bài viết được cập nhật thường xuyên, chẳng hạn.
Bằng cách sử dụng chiến lược ưu tiên mạng bên trong một trình chạy dịch vụ, thay vì chỉ trực tiếp đối đầu với mạng, bạn sẽ có lợi ích là có thể quay lại một nội dung nào đó, ngay cả khi đó là phản hồi có khả năng đã lỗi thời. Bạn sẽ không nhanh đáng tin cậy, nhưng ít nhất bạn sẽ ổn định khi ngoại tuyến.
Dùng tính năng ưu tiên bộ nhớ đệm cho các URL được tạo phiên bản
Trong chiến lược ưu tiên bộ nhớ đệm, sau khi một mục được lưu vào bộ nhớ đệm thì mục nhập đó sẽ không bao giờ được cập nhật. Vì lý do đó, hãy đảm bảo bạn chỉ sử dụng mã này với các thành phần mà bạn biết là không có khả năng thay đổi. Cụ thể, cách này hiệu quả nhất với các URL chứa thông tin phiên bản – cùng một loại URL nên được phân phát với tiêu đề phản hồi Cache-Control: max-age=31536000.