參考：https://www.cnblogs.com/lifei01/p/14105346.html
1. Iru_cache介紹
1.1 lru_cache提供的功能
lru_cache緩存裝飾器提供的功能有：
- 緩存被裝飾對象的結果（基礎功能）
- 獲取緩存信息
- 清除緩存內容
- 根據參數變化緩存不同的結果
- LRU算法當緩存數量大於設置的maxsize時清除最不常使用的緩存結果
從列出的功能可知，python自帶的lru_cache緩存方法可以滿足我們日常工作中大部分需求， 可是它不包含一個重要的特性就是，超時自動刪除緩存結果，所以在我們自制的my_cache中我們將實現緩存的超時過期功能。
1.2 cache的核心部件
-
在作用域內存在一個相對全局的字典變量cache={}
-
在作用域內設置相對全局的變量包含命中次數 hits，未命中次數 misses ，最大緩存數量 maxsize和 當前緩存大小 currsize
-
第二點中的緩存信息中增加緩存加入時間和緩存有效時間
1.3 應用場景
python自帶的緩存功能使用於稍微小型的單體應用。優點是可以很方便的根據傳入不同的參數緩存對應的結果， 並且可以有效控制緩存的結果數量，在超過設置數量時根據LRU算法淘汰命中次數最少的緩存結果。缺點是沒有辦法對緩存過期時間進行設置。
2. lru_cache的使用
2.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) 將被視為不同而分別緩存。
1 def lru_cache(maxsize=128, typed=False): 2 if isinstance(maxsize, int): 3 if maxsize < 0: 4 maxsize = 0 5 elif maxsize is not None: 6 raise TypeError('Expected maxsize to be an integer or None') 7 8 def decorating_function(user_function): 9 wrapper = _lru_cache_wrapper(user_function, maxsize, typed, _CacheInfo) 10 return update_wrapper(wrapper, user_function) 11 12 return decorating_function
2.2 基本用法
在我們編寫接口時可能需要緩存一些變動不大的數據如配置信息，我們可能編寫如下接口：
1 @api.route("/user/info", methods=["GET"]) 2 @functools.lru_cache() 3 @login_require 4 def get_userinfo_list(): 5 userinfos = UserInfo.query.all() 6 userinfo_list = [user.to_dict() for user in userinfos] 7 return jsonify(userinfo_list)
我們緩存了從數據庫查詢的用戶信息，下次再調用這個接口時將直接返回用戶信息列表而不需要重新執行一遍數據庫查詢邏輯，可以有效較少IO次數，加快接口反應速度。
2.3 進階用法
還是以上面的例子，如果發生用戶的刪除或者新增時，我們再請求用戶接口時仍然返回的是緩存中的數據，這樣返回的信息就和我們數據庫中的數據就會存在差異，所以當發生用戶新增或者刪除時，我們需要清除原先的緩存，然后再請求用戶接口時可以重新加載緩存。
1 @api.route("/user/info", methods=["POST"]) 2 @login_require 3 @functools.lru_cache() 4 def add_user(): 5 user = UserInfo(name="李四") 6 db.session.add(user) 7 db.session.commit() 8 9 # 清除get_userinfo_list中的緩存 10 get_userinfo_list = current_app.view_functions["api.get_machine_list"] 11 cache_info = get_userinfo_list.__wrapped__.cache_info() 12 # cache_info 具名元組，包含命中次數 hits，未命中次數 misses ，最大緩存數量 maxsize 和 當前緩存大小 currsize 13 # 如果緩存數量大於0則清除緩存 14 if cache_info[3] > 0: 15 get_userinfo_list.__wrapped__.cache_clear() 16 return jsonify("新增用戶成功")
3. functiontools.wrap裝飾器對lru_cache的影響
在上節我們看到，因為@login_require和@functools.lru_cache()裝飾器的順序不同， 就導致了程序是否報錯， 其中主要涉及到兩點：
- login_require裝飾器中是否用了@functiontools.wrap()裝飾器
- @login_require和@functools.lru_cache()裝飾器的執行順序問題
當我們了解完這兩點后就可以理解上述寫法了。
3.1 多個裝飾器裝飾同一函數時的執行順序
這里從其他地方盜了一段代碼來解釋一下，如下：
1 def decorator_a(func): 2 print('Get in decorator_a') 3 def inner_a(*args,**kwargs): 4 print('Get in inner_a') 5 res = func(*args,**kwargs) 6 return res 7 return inner_a 8 9 def decorator_b(func): 10 print('Get in decorator_b') 11 def inner_b(*args,**kwargs): 12 print('Get in inner_b') 13 res = func(*args,**kwargs) 14 return res 15 return inner_b 16 17 18 @decorator_b 19 @decorator_a 20 def f(x): 21 print('Get in f') 22 return x * 2 23 24 f(1)
輸出結果如下：
1 'Get in decorator_a' 2 'Get in decorator_b' 3 'Get in inner_b' 4 'Get in inner_a' 5 'Get in f'
3.2 functiontools.wrap原理
引用其他博主的描述：
Python裝飾器（decorator）在實現的時候，被裝飾后的函數其實已經是另外一個函數了（函數名等函數屬性會發生改變），為了不影響，Python的functools包中提供了一個叫wraps的decorator來消除這樣的副作用。寫一個decorator的時候，最好在實現之前加上functools的wrap，它能保留原有函數的名稱和docstring。
補充：為了訪問原函數此函數會設置一個
__wrapped__屬性指向原函數， 這樣就可以解釋上面1.3節中我們的寫法了。
4. 注意事項
被lru_cache()裝飾的函數不能分辨運行時環境的變化而智能對參數進行緩存，就導致下面的函數運行結果的不同：
1 import functools 2 3 class Solution: 4 5 Member = 10 6 7 def add(self, num1, num2): 8 self.Member += 1 9 return num1 + num2 + self.Member 10 11 s = Solution() 12 print(s.add(3, 4)) # result: 18 13 print(s.add(3, 4)) # result: 19
加上裝飾器以后：
1 import functools 2 3 class Solution: 4 5 Member = 10 6 7 @functools.lru_cache() 8 def add(self, num1, num2): 9 self.Member += 1 10 return num1 + num2 + self.Member 11 12 s = Solution() 13 print(s.add(3, 4)) # result: 18 14 print(s.add(3, 4)) # result: 18