python自帶緩存lru_cache用法及擴展(詳細)

​ 本篇博客將結合python官方文檔和源碼詳細講述lru_cache緩存方法是怎麼實現， 它與redis緩存的區別是什麼， 在使用時碰上functiontools.wrap裝飾器時會發生怎樣的變化，以及瞭解它給咱們提供了哪些功能而後在其基礎上實現咱們自制的緩存方法my_cache。

---

目錄

• 1. lru_cache的使用
  • 1.1 參數詳解
  • 1.2 基本用法
  • 1.3 進階用法
• 2. functiontools.wrap裝飾器對lru_cache的影響
  • 2.1 多個裝飾器裝飾同一函數時的執行順序
  • 2.2 functiontools.wrap原理
  • 2.3 使用wrap裝飾器先後的變化
• 3. 自制簡易的my_cache
  • 3.1 lru_cache提供的功能
  • 3.2 cache的核心部件
  • 3.3 my_cache的實現
• 4. lru_cache緩存和redis緩存的區別
• 5. 總結

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算法淘汰命中次數最少的緩存結果。缺點是沒有辦法對緩存過時時間進行設置。