業務實現中的本地快取 GO

實際業務實現中常常會使用到本地快取，用以減少對實際儲存的訪問，我們會針對不同的使用場景設計不同的快取模式，但是基本的實現方式都是乙個巨大的map/table(不同語言)。下面用go來說，總體的實現都是通過乙個，根據不同的需求，lfu，lru再設計map裡面具體的entry的struct，儲存需要的計數用來做淘汰，下面從不同使用角度來說明一下

實際使用中，某些中臺服務/服務發現需要拉取比較多的etcd配置(也有可能在其他儲存)，但是整體上還是有限的。此時不需要考慮key的淘汰，存在本地不會占用過多記憶體。目標是反而是為了避免對etcd或儲存的長期訪問以及保證配置有乙個實時更新的機制。

有兩種方法

讀取完了以後快取下來並設定乙個過期時間

相對來說第二種方法比較好，這種實現比較簡單

import (
"sync"
"time"
)var localcache *cache = &cache{}
type cache struct 
type entry struct 
}func (c *cache) set(key string, value inte***ce{}, expiration time.duration) 
c.m.store(key, entry)
}func (c *cache) get(key string) (value inte***ce{}, expired bool) 
return e.value, e.expire.before(time.now())
}

底層核心服務主要是一些crud操作，會有對某些資源的集中式訪問，比如某些核心的ugc內容和使用者，比如微博/twitter大v(其實資訊流本身是推拉結合的，這裡說的是在使用者點開詳情的時候)，他們的資訊如果都直接打在redis/mc上，將會是乙個hot_key，導致儲存不健康。此時就要根據使用場景選擇lfu/lru。

如果是頭部使用者資訊，實時性不是那麼高，而是在乎訪問頻率的，比如明星的個人頁訪問次數在大部分時間是均勻較高的(上熱搜不算也能cover，反正頻率也高)，那對頻率更為敏感，此時就會使用lfu

lru 使用和star比較多的是groupcache

也有人基於此實現了快速使用版golang-lru

使用比較多的lfu演算法比較少 lfu-go算是比較常用的

不過這些cache都比較定製化，實際環境中我們可能需要魔改一下，甚至結合lfu和lru來使用。主要需要改的引數應該至少包含maxlength和expired time(有些業務資料實時性比較高，單純靠remove可能永遠不會remove)。

後面發現其實也有相對定製化的cache實現了，bigcache

分shard的理念極大程度的加大了bigmap的支撐，原理和效能分析可以看下作者的文件

readme中的注釋已經比較清晰了，可以參考下

config := bigcache.config

如果服務純粹是一些io操作，如讀寫資料庫，那cache的值完全可以設大一些，這樣可以減少網路io，加快呼叫速度，減少對儲存的壓力

業務實現中的本地快取 GO

儲存過程中的事務實現轉貼

實現業務系統中的使用者許可權管理

業務中簡單定時任務的實現

業務實現中的本地快取 GO

儲存過程中的事務實現 轉貼

實現業務系統中的使用者許可權管理

業務中簡單定時任務的實現

相關推薦

儲存過程中的事務實現轉貼