2016-07-28 134 views
1

我使用django的內置緩存與@cache_page裝飾器。但是,我希望自動刷新緩存,以便刷新不會因用戶的實際頁面請求而觸發,從而導致延遲。自動刷新緩存

想到一個明顯的策略是使用芹菜任務。我有兩個問題請:

  1. 如果芹菜任務方法是可以接受的,我需要什麼代碼a)觸發刷新和b)未知數量的頁面,例如, myapp.com/products/?page=2,myapp.com/products/?page=3(我無法預測頁數)
  2. 有沒有更好的方法?

回答

0

我最終編寫了一個使用requests框架的芹菜任務,每小時刷新緩存 - 它也處理分頁。示例代碼:

@shared_task 
def refresh_caches(): 
    header = {"Content-Type": "application/json; charset=utf-8", 
         "Authorization": settings.USER_TOKEN} 

    next_page_url = settings.API_URL +'/products/' 
    while len(next_page_url) > 0: 
     response = requests.get(next_page_url, headers=header) 
     next_page_url = '' 
     jsonresponse = response.json() 
     if jsonresponse.get('next'): 
      next_page_url = jsonresponse['next'] 
0

我認爲這是一個芹菜任務是一個矯枉過正。有一個定義緩存過期的設置:

CACHE_MIDDLEWARE_SECONDS - 每個頁面應該被緩存的秒數。

參考:Django docs

這已在1.8推出,並影響@cache_page時間。不要將它與用於使用緩存功能的CACHES: TIMEOUT設置混淆,例如cache.set()。更多關於這個here

+0

我明白緩存超時。我想要阻止的是用戶啓動的請求刷新緩存導致延遲 - 我想手動觸發緩存刷新。 – RunLoop

+0

@RunLoop我明白了。我的理解是用戶請求不應該擴展緩存,它將在設置後到期'CACHE_MIDDLEWARE_SECONDS',但我們需要挖掘代碼來確認這一點。這是一個問題,雖然你甚至不需要甚至需要手動過期。 – Wtower