Caching (bản sao tạm)

Caching là gì?

Cache là một bản sao tạm được giữ ở chỗ gần người dùng hơn, để lần sau lấy cho nhanh thay vì đi hỏi lại tận nguồn. Logo của trang không đổi mỗi ngày, nên trình duyệt tải một lần rồi giữ lại vài ngày. Danh sách sản phẩm bán chạy không đổi từng giây, nên máy chủ tính một lần rồi dùng lại trong vài phút.

Điều BA hay bỏ sót: cache không nằm ở một chỗ. Một trang đi qua nhiều tầng, và mỗi tầng có thể giữ bản sao riêng với hạn dùng riêng — trình duyệt của người dùng, CDN đặt gần họ theo vùng, cache của ứng dụng, rồi mới tới database.

Hệ quả quan trọng nhất với BA/PO: "tôi sửa rồi mà vẫn thấy cái cũ" thường không phải bug — là một bản sao ở đâu đó chưa hết hạn. Nhưng cũng chính vì vậy, "đổi giá" không bao giờ đơn giản như nó nghe: sửa ở nguồn mới chỉ là bước đầu.

Baseline — bạn hiểu

• Hệ thống phục vụ bản sao đã lưu để chạy nhanh — "tôi sửa rồi mà vẫn thấy cái cũ" thường là bản sao chưa hết hạn, không phải bug.
• Cache có nhiều tầng, mỗi tầng có hạn dùng riêng và không tầng nào tự biết bạn vừa sửa dữ liệu.
• Vì vậy hai người ở hai nơi có thể thấy hai phiên bản của cùng một trang trong cùng một phút.

Working — bạn làm được

• Loại trừ cache trước khi báo lỗi: hard refresh, cửa sổ ẩn danh, thiết bị khác.
• Phân loại độ tươi trong spec: cái gì được phép cũ vài phút, cái gì phải chính xác từng giây.
• Viết ra sự kiện nào bắt buộc phải xoá cache ngay, và ở những tầng nào.

Cơ chế hoạt động

Ví dụ theo cấp độ

Cơ bản — Sửa tiêu đề rồi mà vẫn thấy tiêu đề cũ

Tình huống: bạn vừa đổi tiêu đề banner trang chủ từ "Sale tháng 7" thành "Sale tháng 8" trong trang quản trị, bấm lưu, mở lại trang chủ — vẫn thấy "Sale tháng 7". Phản xạ đầu tiên của nhiều người là tạo ticket "banner không lưu được".

Ba bước kiểm tra, mất khoảng hai phút, làm trước khi tạo ticket:

1. Hard refresh. Ctrl + F5 trên Windows, hoặc Cmd + Shift + R trên Mac. Thao tác này bảo trình duyệt bỏ qua bản sao đang giữ trên máy bạn và tải lại từ đầu. Vẫn thấy cũ thì đi tiếp.
2. Mở cửa sổ ẩn danh và vào lại trang. Cửa sổ ẩn danh không mang theo bản sao cũ, cũng không mang theo phiên đăng nhập cũ. Nếu ở đây thấy tiêu đề mới thì vấn đề chỉ nằm trên máy bạn, không phải sự cố chung. Vẫn cũ thì đi tiếp.
3. Nhờ một người khác, ở mạng khác — 4G của điện thoại, hoặc đồng nghiệp ở tỉnh khác càng tốt. Họ thấy mới còn bạn thấy cũ: vấn đề nằm trên đường đi tới máy bạn. Cả hai đều thấy cũ: giờ mới thật sự đáng nghi.

Ticket viết ra sau ba bước đó: "Đã hard refresh, đã thử cửa sổ ẩn danh, đã nhờ một máy khác ở mạng 4G — cả ba đều vẫn hiện tiêu đề cũ, lúc 10:35 ngày 12/08. Trang quản trị đã lưu thành công (có bản ghi lịch sử sửa lúc 10:31)."

Học được: ba bước này chính là ba câu dev sẽ hỏi bạn đầu tiên. Làm trước khi hỏi thì hoặc bạn tự giải quyết được trong hai phút, hoặc ticket của bạn bắt đầu từ một chỗ xa hơn hẳn.

Trung bình — Phân loại độ tươi cho từng khối dữ liệu

Tình huống: bạn spec màn hình chi tiết sản phẩm. Trên đó có nhiều con số, và phản xạ tự nhiên là muốn tất cả đều mới nhất. Nhưng mỗi con số có một cái giá khác nhau nếu nó cũ — và đó mới là thứ quyết định.

Các dòng viết vào spec:

• "Giá và trạng thái còn hàng: không phục vụ từ cache quá 30 giây. Khi giá đổi trong trang quản trị, cache của sản phẩm đó bị xoá ngay, không chờ hết hạn."
• "Tại bước xác nhận đặt hàng, giá và tồn kho được đọc lại từ nguồn. Nếu lệch với màn hình trước đó thì hiện thông báo và bắt khách xác nhận lại — không âm thầm đổi số tiền."
• "Số lượt xem và số đã bán: được phép cũ tới 10 phút."
• "Người vừa gửi bình luận thấy bình luận của chính mình ngay, kể cả khi người khác phải chờ tới 5 phút."

Học được: câu hỏi đúng không phải "cache hay không cache", mà "khối dữ liệu này được phép cũ bao lâu, và nếu cũ thì ai chịu thiệt". Trả lời cho từng khối một, bạn vừa có màn hình nhanh vừa không có khiếu nại về giá.

Nâng cao — Đổi giá khuyến mãi mà một số người vẫn thấy giá cũ 10 phút

Tình huống: flash sale bắt đầu lúc 20:00. Đúng 20:00, đội vận hành đổi giá trong trang quản trị. 20:03, marketing báo: một số khách thấy giá sale, một số vẫn thấy giá gốc, và có người thấy giá sale ở trang danh sách nhưng giá gốc khi bấm vào chi tiết.

Vì sao lại là "một số": cùng một trang đi qua nhiều tầng, mỗi tầng có hạn dùng riêng và không tầng nào biết bạn vừa đổi giá.

• Trang danh sách sản phẩm được cache ở CDN theo từng vùng, hạn dùng 10 phút. Vùng nào vừa hết hạn thì thấy giá mới; vùng nào còn 8 phút nữa mới hết hạn thì vẫn phục vụ giá cũ.
• Kết quả tính giá được cache ở tầng ứng dụng, hạn dùng 5 phút, tính riêng cho từng sản phẩm.
• Khách đang mở sẵn trang từ 19:50 thì trình duyệt của họ giữ nguyên dữ liệu đó cho tới khi họ tải lại.

Cộng lại: cùng một thời điểm, khác người, khác tầng hết hạn, nên khác giá. Không ai làm sai cả — nhưng khách hàng không quan tâm điều đó.

Cái bẫy, gọi tên thẳng: spec chỉ viết "đổi giá trong trang quản trị thì giá mới có hiệu lực ngay". Câu đó đúng ở database và sai ở mọi tầng phía trước. Nó tạo ra rủi ro thật: khách thấy 199.000đ và bị tính 249.000đ, đó là chuyện của niềm tin và của bộ phận pháp chế, không chỉ là một ticket kỹ thuật.

Phải viết vào spec:

• "Khi giá một sản phẩm đổi: hệ thống chủ động xoá cache của sản phẩm đó ở tầng ứng dụng và ở CDN ngay lúc lưu, không chờ hết hạn. Danh sách trang bị ảnh hưởng: trang chi tiết, trang danh sách của mọi danh mục chứa sản phẩm, trang kết quả tìm kiếm."
• "Giá cuối cùng luôn được tính lại ở bước xác nhận đơn, không lấy từ màn hình trước."
• "Nếu giá ở bước xác nhận khác giá khách vừa thấy: hiện rõ cả hai con số. Giá mới thấp hơn thì áp giá thấp hơn. Giá mới cao hơn thì không được tự động áp, phải có thao tác xác nhận của khách."
• "Với chiến dịch có giờ bắt đầu định trước: đổi giá và xoá cache theo lịch, chạy trước 20:00 vài phút, thay vì để một người bấm tay đúng 20:00."
• "Trong khung giờ khuyến mãi, hạ hạn dùng cache của trang danh sách xuống 60 giây."

Học được: cache không phải một thứ, nó là nhiều tầng chồng lên nhau, và "sửa ở nguồn" chỉ là bước đầu tiên. Với bất kỳ thay đổi dữ liệu nào mà người dùng phải thấy đúng thời điểm, spec của bạn phải trả lời thêm một câu ngoài "sửa ở đâu": bản sao cũ đang nằm ở những đâu, và ai xoá chúng.

Áp dụng khi viết spec

Với mỗi khối dữ liệu hiển thị cho người dùng, ticket của bạn phải trả lời được bốn câu:

1. Khối này được phép cũ tối đa bao lâu? Nếu cũ thì ai chịu thiệt?
2. Sự kiện nào bắt buộc phải xoá cache ngay, và xoá ở những tầng nào?
3. Trước khi ghi nhận một hành động (đặt hàng, thanh toán), số liệu quyết định có được đọc lại từ nguồn không?
4. Nếu số ở màn hình và số ở bước cuối lệch nhau thì người dùng thấy gì?

Câu hỏi nên hỏi dev

• "Màn hình này có đang được cache không? Ở tầng nào — trình duyệt, CDN hay tầng ứng dụng?"
• "Hạn dùng là bao nhiêu, tức người dùng có thể thấy dữ liệu cũ tối đa bao lâu?"
• "Khi dữ liệu nguồn đổi, cache có được xoá chủ động không hay chờ hết hạn?"
• "Xoá cache cho một sản phẩm thì những trang nào được cập nhật theo?"
• "Ở bước xác nhận đơn, giá và tồn kho có được đọc lại từ nguồn không?"

Sai lầm thường gặp

• Tạo ticket bug ngay khi thấy dữ liệu cũ, chưa làm ba bước loại trừ.
• Viết "có hiệu lực ngay" mà không nói tầng nào phải xoá cache.
• Đòi mọi số trên màn hình đều phải mới nhất — màn hình chậm đi mà không ai được lợi.
• Quên rằng người vừa tạo nội dung phải thấy nội dung của chính mình ngay lập tức.
• Không đọc lại giá ở bước cuối, để chênh lệch rơi thẳng vào hoá đơn của khách.
• Bắt đầu khuyến mãi đúng giờ chẵn bằng thao tác tay, trong khi cache cần vài phút để lan hết.

Definition of done — dấu hiệu bạn đã đạt

• Trước khi báo lỗi dữ liệu, bạn luôn đã làm ba bước loại trừ và ghi kết quả vào ticket.
• Mỗi khối dữ liệu trong spec của bạn có một mức "được phép cũ tối đa" rõ ràng.
• Mọi thay đổi ảnh hưởng tới tiền đều có dòng về xoá cache và dòng về đọc lại ở bước cuối.

Đi sâu hơn

• API (request/response) — đọc tài liệu API và hiểu dữ liệu tới màn hình bằng đường nào.