本篇部落格將結合python官方文件和原始碼詳細講述lru_cache快取方法是怎麼實現， 它與redis快取的區別是什麼， 在使用時碰上functiontools.wrap裝飾器時會發生怎樣的變化，以及瞭解它給我們提供了哪些功能然後在其基礎上實現我們自制的快取方法my_cache。
1. lru_cache的使用
1.1 引數詳解
以下是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
1.2 基本用法
在我們編寫介面時可能需要快取一些變動不大的資料如配置資訊，我們可能編寫如下介面：
@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次數，加快介面反應速度。
1.3 進階用法
還是以上面的例子，如果發生使用者的刪除或者新增時，我們再請求使用者介面時仍然返回的是快取中的資料，這樣返回的資訊就和我們資料庫中的資料就會存在差異，所以當發生使用者新增或者刪除時，我們需要清除原先的快取，然後再請求使用者介面時可以重新載入快取。
@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("新增使用者成功")
2. functiontools.wrap裝飾器對lru_cache的影響
在上節我們看到，因為@login_require和@functools.lru_cache()裝飾器的順序不同， 就導致了程式是否報錯， 其中主要涉及到兩點：
- login_require裝飾器中是否用了@functiontools.wrap()裝飾器
- @login_require和@functools.lru_cache()裝飾器的執行順序問題
當我們瞭解完這兩點後就可以理解上述寫法了。
2.1 多個裝飾器裝飾同一函式時的執行順序
這裡從其他地方盜了一段程式碼來解釋一下，如下：
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中的中介軟體的執行順序，其實原理都差不多。
2.2 functiontools.wrap原理
引用其他博主的描述：
Python裝飾器（decorator）在實現的時候，被裝飾後的函式其實已經是另外一個函式了（函式名等函式屬性會發生改變），為了不影響，Python的functools包中提供了一個叫wraps的decorator來消除這樣的副作用。寫一個decorator的時候，最好在實現之前加上functools的wrap，它能保留原有函式的名稱和docstring。
補充：為了訪問原函式此函式會設定一個
__wrapped__屬性指向原函式， 這樣就可以解釋上面1.3節中我們的寫法了。
2.3 使用wrap裝飾器前後的變化
未完待續。。。。。。。。。
3. 自制簡易的my_cache
3.1 lru_cache提供的功能
lru_cache快取裝飾器提供的功能有：
- 快取被裝飾物件的結果（基礎功能）
- 獲取快取資訊
- 清除快取內容
- 根據引數變化快取不同的結果
- LRU演算法當快取數量大於設定的maxsize時清除最不常使用的快取結果
從列出的功能可知，python自帶的lru_cache快取方法可以滿足我們日常工作中大部分需求， 可是它不包含一個重要的特性就是，超時自動刪除快取結果，所以在我們自制的my_cache中我們將實現快取的超時過期功能。
3.2 cache的核心部件
-
在作用域記憶體在一個相對全域性的字典變數cache={}
-
在作用域內設定相對全域性的變數包含命中次數 hits，未命中次數 misses ，最大快取數量 maxsize和 當前快取大小 currsize
-
第二點中的快取資訊中增加快取加入時間和快取有效時間
3.3 my_cache的實現
待實現。。。。。。。。。。。。
4. lru_cache快取和redis快取的區別
| 比較型別 | lru_cache | redis |
|---|---|---|
| 快取型別 | 快取在app程式記憶體中 | 快取在redis管理的記憶體中 |
| 分散式 | 只快取在單個app程式中 | 可做分散式快取 |
| 資料型別 | hash 引數作為key，返回結果為value | 有5種型別的資料結構 |
| 適用場景 | 比較小型的系統、單體應用 | 常用的快取解決方案 |
| 功能 | 快取功能但是缺少過期時間控制，但是使用上更加便捷 | 具備快取需要的各種要素 |
5. 總結
綜上所述，python自帶的快取功能使用於稍微小型的單體應用。優點是可以很方便的根據傳入不同的引數快取對應的結果， 並且可以有效控制快取的結果數量，在超過設定數量時根據LRU演算法淘汰命中次數最少的快取結果。缺點是沒有辦法對快取過期時間進行設定。