您好,登錄后才能下訂單哦!
這篇文章給大家分享的是有關python中自帶緩存lru_cache怎么用的內容。小編覺得挺實用的,因此分享給大家做個參考,一起跟隨小編過來看看吧。
以下是lru_cache方法的實現,我們看出可供我們傳入的參數有2個maxsize和typed,如果不傳則maxsize的默認值為128,typed的默認值為False。其中maxsize參數表示是的被裝飾的方法最大可緩存結果數量, 如果是默認值128則表示被裝飾方法最多可緩存128個返回結果,如果maxsize傳入為None則表示可以緩存無限個結果,你可能會疑惑被裝飾方法的n個結果是怎么來的,打個比方被裝飾的方法為def add(a, b):當函數被lru_cache裝飾時,我們調用add(1, 2)和add(3, 4)將會緩存不同的結果。如果 typed 設置為true,不同類型的函數參數將被分別緩存。例如, f(3) 和 f(3.0) 將被視為不同而分別緩存。
def lru_cache(maxsize=128, typed=False): if isinstance(maxsize, int): if maxsize < 0: maxsize = 0 elif maxsize is not None: raise TypeError('Expected maxsize to be an integer or None') def decorating_function(user_function): wrapper = _lru_cache_wrapper(user_function, maxsize, typed, _CacheInfo) return update_wrapper(wrapper, user_function) return decorating_function
在我們編寫接口時可能需要緩存一些變動不大的數據如配置信息,我們可能編寫如下接口:
@api.route("/user/info", methods=["GET"]) @functools.lru_cache() @login_require def get_userinfo_list(): userinfos = UserInfo.query.all() userinfo_list = [user.to_dict() for user in userinfos] return jsonify(userinfo_list)
我們緩存了從數據庫查詢的用戶信息,下次再調用這個接口時將直接返回用戶信息列表而不需要重新執行一遍數據庫查詢邏輯,可以有效較少IO次數,加快接口反應速度。
還是以上面的例子,如果發生用戶的刪除或者新增時,我們再請求用戶接口時仍然返回的是緩存中的數據,這樣返回的信息就和我們數據庫中的數據就會存在差異,所以當發生用戶新增或者刪除時,我們需要清除原先的緩存,然后再請求用戶接口時可以重新加載緩存。
@api.route("/user/info", methods=["POST"]) @functools.lru_cache() @login_require def add_user(): user = UserInfo(name="李四") db.session.add(user) db.session.commit() # 清除get_userinfo_list中的緩存 get_userinfo_list = current_app.view_functions["api.get_machine_list"] cache_info = get_userinfo_list.cache_info() # cache_info 具名元組,包含命中次數 hits,未命中次數 misses ,最大緩存數量 maxsize 和 當前緩存大小 currsize # 如果緩存數量大于0則清除緩存 if cache_info[3] > 0: get_userinfo_list.cache_clear() return jsonify("新增用戶成功")
在上面這個用法中我們,如果我們把lru_cache裝飾器和login_require裝飾器調換位置時,上述的寫法將會報錯,這是因為login_require裝飾器中用了functiontools.wrap模塊進行裝飾導致的,具原因我們在下節解釋, 如果想不報錯得修改成如下寫法。
@api.route("/user/info", methods=["POST"]) @login_require @functools.lru_cache() def add_user(): user = UserInfo(name="李四") db.session.add(user) db.session.commit() # 清除get_userinfo_list中的緩存 get_userinfo_list = current_app.view_functions["api.get_machine_list"] cache_info = get_userinfo_list.__wrapped__.cache_info() # cache_info 具名元組,包含命中次數 hits,未命中次數 misses ,最大緩存數量 maxsize 和 當前緩存大小 currsize # 如果緩存數量大于0則清除緩存 if cache_info[3] > 0: get_userinfo_list.__wrapped__.cache_clear() return jsonify("新增用戶成功")
在上節我們看到,因為@login_require和@functools.lru_cache()裝飾器的順序不同, 就導致了程序是否報錯, 其中主要涉及到兩點:
login_require裝飾器中是否用了@functiontools.wrap()裝飾器
@login_require和@functools.lru_cache()裝飾器的執行順序問題
當我們了解完這兩點后就可以理解上述寫法了。
這里從其他地方盜了一段代碼來解釋一下,如下:
def decorator_a(func): print('Get in decorator_a') def inner_a(*args,**kwargs): print('Get in inner_a') res = func(*args,**kwargs) return res return inner_a def decorator_b(func): print('Get in decorator_b') def inner_b(*args,**kwargs): print('Get in inner_b') res = func(*args,**kwargs) return res return inner_b @decorator_b @decorator_a def f(x): print('Get in f') return x * 2 f(1)
輸出結果如下:
'Get in decorator_a'
'Get in decorator_b'
'Get in inner_b'
'Get in inner_a'
'Get in f'
是不是很像django中的中間件的執行順序,其實原理都差不多。
引用其他博主的描述:
Python裝飾器(decorator)在實現的時候,被裝飾后的函數其實已經是另外一個函數了(函數名等函數屬性會發生改變),為了不影響,Python的functools包中提供了一個叫wraps的decorator來消除這樣的副作用。寫一個decorator的時候,最好在實現之前加上functools的wrap,它能保留原有函數的名稱和docstring。
補充:為了訪問原函數此函數會設置一個__wrapped__屬性指向原函數, 這樣就可以解釋上面1.3節中我們的寫法了。
未完待續。。。。。。。。。
lru_cache緩存裝飾器提供的功能有:
緩存被裝飾對象的結果(基礎功能)
獲取緩存信息
清除緩存內容
根據參數變化緩存不同的結果
LRU算法當緩存數量大于設置的maxsize時清除最不常使用的緩存結果
從列出的功能可知,python自帶的lru_cache緩存方法可以滿足我們日常工作中大部分需求, 可是它不包含一個重要的特性就是,超時自動刪除緩存結果,所以在我們自制的my_cache中我們將實現緩存的超時過期功能。
在作用域內存在一個相對全局的字典變量cache={}
在作用域內設置相對全局的變量包含命中次數 hits,未命中次數 misses ,最大緩存數量 maxsize和 當前緩存大小 currsize
第二點中的緩存信息中增加緩存加入時間和緩存有效時間
待實現。。。。。。。。。。。。
比較類型 | lru_cache | redis |
---|---|---|
緩存類型 | 緩存在app進程內存中 | 緩存在redis管理的內存中 |
分布式 | 只緩存在單個app進程中 | 可做分布式緩存 |
數據類型 | hash 參數作為key,返回結果為value | 有5種類型的數據結構 |
適用場景 | 比較小型的系統、單體應用 | 常用的緩存解決方案 |
功能 | 緩存功能但是缺少過期時間控制,但是使用上更加便捷 | 具備緩存需要的各種要素 |
感謝各位的閱讀!關于“python中自帶緩存lru_cache怎么用”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。