目錄1. lru_cache的使用1.1 參數(shù)詳解1.2 基本用法1.3 進(jìn)階用法2. functiontools.wrap裝飾器對lru_cache的影響2.1 多個裝飾器裝飾同一函數(shù)時的執(zhí)行順序2.2 functiontools.wrap原理2.3 使用wrap裝飾器前后的變化3. 自制簡易的my_cache3.1 lru_cache提供的功能3.2 cache的核心部件3.3 my_cache的實現(xiàn)4. lru_cache緩存和redis緩存的區(qū)別5. 總結(jié)

本篇博客將結(jié)合python官方文檔和源碼詳細(xì)講述lru_cache緩存方法是怎么實現(xiàn)， 它與redis緩存的區(qū)別是什么， 在使用時碰上functiontools.wrap裝飾器時會發(fā)生怎樣的變化，以及了解它給我們提供了哪些功能然后在其基礎(chǔ)上實現(xiàn)我們自制的緩存方法my_cache。

1. lru_cache的使用1.1 參數(shù)詳解

以下是lru_cache方法的實現(xiàn)，我們看出可供我們傳入的參數(shù)有2個maxsize和typed，如果不傳則maxsize的默認(rèn)值為128，typed的默認(rèn)值為False。其中maxsize參數(shù)表示是的被裝飾的方法最大可緩存結(jié)果數(shù)量， 如果是默認(rèn)值128則表示被裝飾方法最多可緩存128個返回結(jié)果，如果maxsize傳入為None則表示可以緩存無限個結(jié)果，你可能會疑惑被裝飾方法的n個結(jié)果是怎么來的，打個比方被裝飾的方法為def add(a, b):當(dāng)函數(shù)被lru_cache裝飾時，我們調(diào)用add(1, 2)和add(3, 4)將會緩存不同的結(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_function1.2 基本用法

在我們編寫接口時可能需要緩存一些變動不大的數(shù)據(jù)如配置信息，我們可能編寫如下接口：

@api.route('/user/info', methods=['GET'])@functools.lru_cache()@login_requiredef get_userinfo_list(): userinfos = UserInfo.query.all() userinfo_list = [user.to_dict() for user in userinfos] return jsonify(userinfo_list)

我們緩存了從數(shù)據(jù)庫查詢的用戶信息，下次再調(diào)用這個接口時將直接返回用戶信息列表而不需要重新執(zhí)行一遍數(shù)據(jù)庫查詢邏輯，可以有效較少IO次數(shù)，加快接口反應(yīng)速度。

1.3 進(jìn)階用法

還是以上面的例子，如果發(fā)生用戶的刪除或者新增時，我們再請求用戶接口時仍然返回的是緩存中的數(shù)據(jù)，這樣返回的信息就和我們數(shù)據(jù)庫中的數(shù)據(jù)就會存在差異，所以當(dāng)發(fā)生用戶新增或者刪除時，我們需要清除原先的緩存，然后再請求用戶接口時可以重新加載緩存。

@api.route('/user/info', methods=['POST'])@functools.lru_cache()@login_requiredef 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('新增用戶成功')

在上面這個用法中我們，如果我們把lru_cache裝飾器和login_require裝飾器調(diào)換位置時，上述的寫法將會報錯，這是因為login_require裝飾器中用了functiontools.wrap模塊進(jìn)行裝飾導(dǎo)致的，具原因我們在下節(jié)解釋， 如果想不報錯得修改成如下寫法。

@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裝飾器對lru_cache的影響

在上節(jié)我們看到，因為@login_require和@functools.lru_cache()裝飾器的順序不同， 就導(dǎo)致了程序是否報錯， 其中主要涉及到兩點：

login_require裝飾器中是否用了@functiontools.wrap()裝飾器 @login_require和@functools.lru_cache()裝飾器的執(zhí)行順序問題

當(dāng)我們了解完這兩點后就可以理解上述寫法了。

2.1 多個裝飾器裝飾同一函數(shù)時的執(zhí)行順序

這里從其他地方盜了一段代碼來解釋一下，如下：

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_adef 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_adef f(x): print(’Get in f’) return x * 2f(1)

輸出結(jié)果如下：

’Get in decorator_a’’Get in decorator_b’’Get in inner_b’’Get in inner_a’’Get in f’

是不是很像django中的中間件的執(zhí)行順序，其實原理都差不多。

2.2 functiontools.wrap原理

引用其他博主的描述：

Python裝飾器（decorator）在實現(xiàn)的時候，被裝飾后的函數(shù)其實已經(jīng)是另外一個函數(shù)了（函數(shù)名等函數(shù)屬性會發(fā)生改變），為了不影響，Python的functools包中提供了一個叫wraps的decorator來消除這樣的副作用。寫一個decorator的時候，最好在實現(xiàn)之前加上functools的wrap，它能保留原有函數(shù)的名稱和docstring。

補(bǔ)充：為了訪問原函數(shù)此函數(shù)會設(shè)置一個__wrapped__屬性指向原函數(shù)， 這樣就可以解釋上面1.3節(jié)中我們的寫法了。

2.3 使用wrap裝飾器前后的變化

未完待續(xù)。。。。。。。。。

3. 自制簡易的my_cache3.1 lru_cache提供的功能

lru_cache緩存裝飾器提供的功能有：

緩存被裝飾對象的結(jié)果（基礎(chǔ)功能） 獲取緩存信息 清除緩存內(nèi)容 根據(jù)參數(shù)變化緩存不同的結(jié)果 LRU算法當(dāng)緩存數(shù)量大于設(shè)置的maxsize時清除最不常使用的緩存結(jié)果

​ 從列出的功能可知，python自帶的lru_cache緩存方法可以滿足我們?nèi)粘９ぷ髦写蟛糠中枨螅?可是它不包含一個重要的特性就是，超時自動刪除緩存結(jié)果，所以在我們自制的my_cache中我們將實現(xiàn)緩存的超時過期功能。

3.2 cache的核心部件

在作用域內(nèi)存在一個相對全局的字典變量cache={}

在作用域內(nèi)設(shè)置相對全局的變量包含命中次數(shù) hits，未命中次數(shù) misses ，最大緩存數(shù)量 maxsize和 當(dāng)前緩存大小 currsize

第二點中的緩存信息中增加緩存加入時間和緩存有效時間

3.3 my_cache的實現(xiàn)

待實現(xiàn)。。。。。。。。。。。。

4. lru_cache緩存和redis緩存的區(qū)別比較類型 lru_cache redis 緩存類型 緩存在app進(jìn)程內(nèi)存中 緩存在redis管理的內(nèi)存中 分布式 只緩存在單個app進(jìn)程中 可做分布式緩存 數(shù)據(jù)類型 hash 參數(shù)作為key，返回結(jié)果為value 有5種類型的數(shù)據(jù)結(jié)構(gòu) 適用場景 比較小型的系統(tǒng)、單體應(yīng)用 常用的緩存解決方案 功能 緩存功能但是缺少過期時間控制，但是使用上更加便捷 具備緩存需要的各種要素 5. 總結(jié)

綜上所述，python自帶的緩存功能使用于稍微小型的單體應(yīng)用。優(yōu)點是可以很方便的根據(jù)傳入不同的參數(shù)緩存對應(yīng)的結(jié)果， 并且可以有效控制緩存的結(jié)果數(shù)量，在超過設(shè)置數(shù)量時根據(jù)LRU算法淘汰命中次數(shù)最少的緩存結(jié)果。缺點是沒有辦法對緩存過期時間進(jìn)行設(shè)置。

到此這篇關(guān)于python自帶緩存lru_cache用法及擴(kuò)展的使用的文章就介紹到這了,更多相關(guān)python自帶緩存lru_cache內(nèi)容請搜索好吧啦網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持好吧啦網(wǎng)！