python自帶緩存lru_cache用法及擴(kuò)展的使用
本篇博客將結(jié)合python官方文檔和源碼詳細(xì)講述lru_cache緩存方法是怎么實(shí)現(xiàn), 它與redis緩存的區(qū)別是什么, 在使用時(shí)碰上functiontools.wrap裝飾器時(shí)會(huì)發(fā)生怎樣的變化,以及了解它給我們提供了哪些功能然后在其基礎(chǔ)上實(shí)現(xiàn)我們自制的緩存方法my_cache。
1. lru_cache的使用
1.1 參數(shù)詳解
以下是lru_cache方法的實(shí)現(xiàn),我們看出可供我們傳入的參數(shù)有2個(gè)maxsize和typed,如果不傳則maxsize的默認(rèn)值為128,typed的默認(rèn)值為False。其中maxsize參數(shù)表示是的被裝飾的方法最大可緩存結(jié)果數(shù)量, 如果是默認(rèn)值128則表示被裝飾方法最多可緩存128個(gè)返回結(jié)果,如果maxsize傳入為None則表示可以緩存無(wú)限個(gè)結(jié)果,你可能會(huì)疑惑被裝飾方法的n個(gè)結(jié)果是怎么來(lái)的,打個(gè)比方被裝飾的方法為def add(a, b):當(dāng)函數(shù)被lru_cache裝飾時(shí),我們調(diào)用add(1, 2)和add(3, 4)將會(huì)緩存不同的結(jié)果。如果 typed 設(shè)置為true,不同類型的函數(shù)參數(shù)將被分別緩存。例如, 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
1.2 基本用法
在我們編寫接口時(shí)可能需要緩存一些變動(dòng)不大的數(shù)據(jù)如配置信息,我們可能編寫如下接口:
@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)
我們緩存了從數(shù)據(jù)庫(kù)查詢的用戶信息,下次再調(diào)用這個(gè)接口時(shí)將直接返回用戶信息列表而不需要重新執(zhí)行一遍數(shù)據(jù)庫(kù)查詢邏輯,可以有效較少IO次數(shù),加快接口反應(yīng)速度。
1.3 進(jìn)階用法
還是以上面的例子,如果發(fā)生用戶的刪除或者新增時(shí),我們?cè)僬?qǐng)求用戶接口時(shí)仍然返回的是緩存中的數(shù)據(jù),這樣返回的信息就和我們數(shù)據(jù)庫(kù)中的數(shù)據(jù)就會(huì)存在差異,所以當(dāng)發(fā)生用戶新增或者刪除時(shí),我們需要清除原先的緩存,然后再請(qǐng)求用戶接口時(shí)可以重新加載緩存。
@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 具名元組,包含命中次數(shù) hits,未命中次數(shù) misses ,最大緩存數(shù)量 maxsize 和 當(dāng)前緩存大小 currsize # 如果緩存數(shù)量大于0則清除緩存 if cache_info[3] > 0: get_userinfo_list.cache_clear() return jsonify("新增用戶成功")
在上面這個(gè)用法中我們,如果我們把lru_cache裝飾器和login_require裝飾器調(diào)換位置時(shí),上述的寫法將會(huì)報(bào)錯(cuò),這是因?yàn)閘ogin_require裝飾器中用了functiontools.wrap模塊進(jìn)行裝飾導(dǎo)致的,具原因我們?cè)谙鹿?jié)解釋, 如果想不報(bào)錯(cuò)得修改成如下寫法。
@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 具名元組,包含命中次數(shù) hits,未命中次數(shù) misses ,最大緩存數(shù)量 maxsize 和 當(dāng)前緩存大小 currsize # 如果緩存數(shù)量大于0則清除緩存 if cache_info[3] > 0: get_userinfo_list.__wrapped__.cache_clear() return jsonify("新增用戶成功")
2. functiontools.wrap裝飾器對(duì)lru_cache的影響
在上節(jié)我們看到,因?yàn)锧login_require和@functools.lru_cache()裝飾器的順序不同, 就導(dǎo)致了程序是否報(bào)錯(cuò), 其中主要涉及到兩點(diǎn):
- login_require裝飾器中是否用了@functiontools.wrap()裝飾器
- @login_require和@functools.lru_cache()裝飾器的執(zhí)行順序問題
當(dāng)我們了解完這兩點(diǎn)后就可以理解上述寫法了。
2.1 多個(gè)裝飾器裝飾同一函數(shù)時(shí)的執(zhí)行順序
這里從其他地方盜了一段代碼來(lái)解釋一下,如下:
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)
輸出結(jié)果如下:
'Get in decorator_a'
'Get in decorator_b'
'Get in inner_b'
'Get in inner_a'
'Get in f'
是不是很像django中的中間件的執(zhí)行順序,其實(shí)原理都差不多。
2.2 functiontools.wrap原理
引用其他博主的描述:
Python裝飾器(decorator)在實(shí)現(xiàn)的時(shí)候,被裝飾后的函數(shù)其實(shí)已經(jīng)是另外一個(gè)函數(shù)了(函數(shù)名等函數(shù)屬性會(huì)發(fā)生改變),為了不影響,Python的functools包中提供了一個(gè)叫wraps的decorator來(lái)消除這樣的副作用。寫一個(gè)decorator的時(shí)候,最好在實(shí)現(xiàn)之前加上functools的wrap,它能保留原有函數(shù)的名稱和docstring。
補(bǔ)充:為了訪問原函數(shù)此函數(shù)會(huì)設(shè)置一個(gè)__wrapped__屬性指向原函數(shù), 這樣就可以解釋上面1.3節(jié)中我們的寫法了。
2.3 使用wrap裝飾器前后的變化
未完待續(xù)。。。。。。。。。
3. 自制簡(jiǎn)易的my_cache
3.1 lru_cache提供的功能
lru_cache緩存裝飾器提供的功能有:
- 緩存被裝飾對(duì)象的結(jié)果(基礎(chǔ)功能)
- 獲取緩存信息
- 清除緩存內(nèi)容
- 根據(jù)參數(shù)變化緩存不同的結(jié)果
- LRU算法當(dāng)緩存數(shù)量大于設(shè)置的maxsize時(shí)清除最不常使用的緩存結(jié)果
從列出的功能可知,python自帶的lru_cache緩存方法可以滿足我們?nèi)粘9ぷ髦写蟛糠中枨螅?可是它不包含一個(gè)重要的特性就是,超時(shí)自動(dòng)刪除緩存結(jié)果,所以在我們自制的my_cache中我們將實(shí)現(xiàn)緩存的超時(shí)過(guò)期功能。
3.2 cache的核心部件
在作用域內(nèi)存在一個(gè)相對(duì)全局的字典變量cache={}
在作用域內(nèi)設(shè)置相對(duì)全局的變量包含命中次數(shù) hits,未命中次數(shù) misses ,最大緩存數(shù)量 maxsize和 當(dāng)前緩存大小 currsize
第二點(diǎn)中的緩存信息中增加緩存加入時(shí)間和緩存有效時(shí)間
3.3 my_cache的實(shí)現(xiàn)
待實(shí)現(xiàn)。。。。。。。。。。。。
4. lru_cache緩存和redis緩存的區(qū)別
比較類型 | lru_cache | redis |
---|---|---|
緩存類型 | 緩存在app進(jìn)程內(nèi)存中 | 緩存在redis管理的內(nèi)存中 |
分布式 | 只緩存在單個(gè)app進(jìn)程中 | 可做分布式緩存 |
數(shù)據(jù)類型 | hash 參數(shù)作為key,返回結(jié)果為value | 有5種類型的數(shù)據(jù)結(jié)構(gòu) |
適用場(chǎng)景 | 比較小型的系統(tǒng)、單體應(yīng)用 | 常用的緩存解決方案 |
功能 | 緩存功能但是缺少過(guò)期時(shí)間控制,但是使用上更加便捷 | 具備緩存需要的各種要素 |
5. 總結(jié)
綜上所述,python自帶的緩存功能使用于稍微小型的單體應(yīng)用。優(yōu)點(diǎn)是可以很方便的根據(jù)傳入不同的參數(shù)緩存對(duì)應(yīng)的結(jié)果, 并且可以有效控制緩存的結(jié)果數(shù)量,在超過(guò)設(shè)置數(shù)量時(shí)根據(jù)LRU算法淘汰命中次數(shù)最少的緩存結(jié)果。缺點(diǎn)是沒有辦法對(duì)緩存過(guò)期時(shí)間進(jìn)行設(shè)置。
到此這篇關(guān)于python自帶緩存lru_cache用法及擴(kuò)展的使用的文章就介紹到這了,更多相關(guān)python自帶緩存lru_cache內(nèi)容請(qǐng)搜索本站以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持本站!
版權(quán)聲明:本站文章來(lái)源標(biāo)注為YINGSOO的內(nèi)容版權(quán)均為本站所有,歡迎引用、轉(zhuǎn)載,請(qǐng)保持原文完整并注明來(lái)源及原文鏈接。禁止復(fù)制或仿造本網(wǎng)站,禁止在非www.sddonglingsh.com所屬的服務(wù)器上建立鏡像,否則將依法追究法律責(zé)任。本站部分內(nèi)容來(lái)源于網(wǎng)友推薦、互聯(lián)網(wǎng)收集整理而來(lái),僅供學(xué)習(xí)參考,不代表本站立場(chǎng),如有內(nèi)容涉嫌侵權(quán),請(qǐng)聯(lián)系alex-e#qq.com處理。