Tại sao tạm thời bị xóa sớm?

Bạn sẽ nghĩ rằng một bộ tạm thời hết hạn tại một thời điểm nhất định, sẽ tồn tại cho đến thời điểm đó. Thật không may, có vẻ như chúng đang biến mất khỏi cơ sở dữ liệu trước đó, cả về thử nghiệm và sản xuất. Để làm ví dụ đơn giản để xem hành vi này, hãy thử:

<?php
/*
Plugin Name: Test transient
Description: Show transients bug
Version: 0.1
*/

add_action( 'wp_head', 'doAnAlert' );

function doAnAlert()
{
    if( !get_transient( 'my_messageDismiss' ) )
    {
        //Transient nonexistent or expired
        ?><script> alert("This alert should also show again in 24hr"); </script>
        <?php

        set_transient( 'my_messageDismiss', 'dismissed', 86400); //Set for a day
    }

}

Vậy tôi còn thiếu gì về API khách hàng? Cảnh báo cho thấy nhiều giờ sau, không một ngày sau.

TL; DR

• Phần Wordpress của xử lý nhất thời là vững chắc, mọi thứ khá chính xác
• Khách hàng sử dụng bộ đệm đối tượng thay vì lưu trữ dữ liệu để triển khai không mặc định
• Điều đó có nghĩa là một số hệ thống bộ đệm phía sau loại bỏ bộ đệm không được truy cập gần đây
• Điểm mấu chốt: đó không phải là lỗi của WordPress, nó chỉ phụ thuộc vào cách thiết lập bộ đệm ẩn phía sau của bạn

Bạn có thể có được các quá độ chính xác hơn nhưng nó yêu cầu tinh chỉnh bộ đệm phía sau mà tôi không khuyến nghị nếu bạn không biết bạn đang làm gì, quá nhiều bộ đệm có thể có tác dụng ngược lại.

Nhưng ngay cả khi đó, đừng cho rằng nó chính xác 100%.

Từ Codex WordPress :

Mọi người dường như hiểu sai về cách thức hết hạn tạm thời hoạt động, vì vậy thời gian dài và ngắn của nó là: thời gian hết hạn tạm thời là một thời gian tối đa. Không có tuổi tối thiểu. Các khách hàng có thể biến mất một giây sau khi bạn đặt chúng hoặc 24 giờ, nhưng chúng sẽ không bao giờ xuất hiện sau thời gian hết hạn.

Bạn nên luôn luôn có một phương pháp trở lại.

Tại sao nó lại xảy ra?!

WordPress chỉ làm mất hiệu lực quá độ khi cố gắng đọc chúng (điều này dẫn đến các vấn đề về thu gom rác trong quá khứ). Tuy nhiên, điều này không được đảm bảo cho các phụ trợ khác.

Transents sử dụng bộ đệm đối tượng cho các triển khai không mặc định. Phần thực sự quan trọng cần lưu ý ở đây là bộ đệm đối tượng là bộ đệm và hoàn toàn không phải là kho lưu trữ dữ liệu. Điều này có nghĩa là hết hạn là tuổi tối đa, không phải là điểm tối thiểu hoặc điểm đặt.

Một nơi điều này có thể xảy ra dễ dàng là với Memcache được đặt ở chế độ Least Recent used (LRU). Trong chế độ này, Memcache sẽ tự động loại bỏ các mục không được truy cập gần đây khi cần chỗ cho các mục mới. Điều này có nghĩa là dữ liệu ít được truy cập (như dữ liệu được sử dụng bởi dữ liệu cron) có thể bị loại bỏ trước khi hết hạn.

Đọc thêm từ bài viết này , nó được giải thích rất tốt.

Bộ nhớ đệm?

Có rất nhiều hệ thống khác nhau nhưng đây là một ví dụ về cách bộ nhớ cache cơ sở dữ liệu MySQL thường hoạt động. Tôi không chắc nó hữu ích như thế nào để hiểu bộ nhớ đệm tạm thời nhưng tôi đoán nó không thể gây hại.

• Dữ liệu từ mỗi truy vấn khác nhau được lưu trữ
• Mỗi dữ liệu được lưu trữ sẽ nhận được một giá trị ( ==giá trị cao hơn truy vấn phức tạp hơn)
• Các giá trị này được giảm dần (như bộ đếm thời gian đếm ngược nếu bạn muốn)
• Hệ thống bộ đệm kiểm tra các giá trị này trong khoảng thời gian
• Nếu bất kỳ giá trị nào trong số này đạt đến 0, bộ đệm đó sẽ bị hủy
• Nếu cùng một truy vấn được chạy lại, giá trị sẽ trở về giá trị ban đầu

Vì vậy, những gì bạn có thể kết luận từ đó? Không có điểm nào để đặt thoáng qua đó là:

• Quá đơn giản
• Không thường xuyên sử dụng

Bởi vì những thứ này bị phá hủy rất nhanh trong hầu hết các trường hợp. Tôi hy vọng điều này cung cấp cho bạn một hình ảnh rõ ràng hơn về cách thức bộ nhớ đệm thường hoạt động. Nó ưu tiên thường xuyên và phức tạp hơn dữ liệu đơn giản và hiếm khi được sử dụng.

Lưu ý: có rất nhiều khái quát trong giải thích bộ đệm để dễ theo dõi và hiểu.