溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容主要講解“go-zero如何自動管理緩存”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“go-zero如何自動管理緩存”吧!
go-zero 雖然是20年8月7號才開源，但是已經經過線上大規模檢驗了，也是我近20年工程經驗的積累，開源后得到社區的積極反饋，在5個多月的時間里，獲得了6k stars。多次登頂github Go語言日榜、周榜、月榜榜首，并獲得了gitee最有價值項目（GVP），開源中國年度最佳人氣項目。同時微信社區極為活躍，3000+人的社區群，go-zero愛好者們一起交流go-zero使用心得和討論使用過程中的問題。
我們對緩存是只刪除，不做更新，一旦DB里數據出現修改，我們就會直接刪除對應的緩存，而不是去更新。
我們看看刪除緩存的順序怎樣才是正確的。
先刪除緩存，再更新DB
我們看兩個并發請求的情況，A請求需要更新數據，先刪除了緩存，然后B請求來讀取數據，此時緩存沒有數據，就會從DB加載數據并寫回緩存，然后A更新了DB，那么此時緩存內的數據就會一直是臟數據，直到緩存過期或者有新的更新數據的請求。如圖
先更新DB，再刪除緩存
A請求先更新DB，然后B請求來讀取數據，此時返回的是老數據，此時可以認為是A請求還沒更新完，最終一致性，可以接受，然后A刪除了緩存，后續請求都會拿到最新數據，如圖
讓我們再來看一下正常的請求流程：
第一個請求更新DB，并刪除了緩存
第二個請求讀取緩存，沒有數據，就從DB讀取數據，并回寫到緩存里
后續讀請求都可以直接從緩存讀取
我們再看一下DB查詢有哪些情況，假設行記錄里有ABCDEFG七列數據：
只查詢部分列數據的請求，比如請求其中的ABC，CDE或者EFG等，如圖
查詢單條完整行記錄，如圖
查詢多條行記錄的部分或全部列，如圖
對于上面三種情況，首先，我們不用部分查詢，因為部分查詢沒法緩存，一旦緩存了，數據有更新，沒法定位到有哪些數據需要刪除；其次，對于多行的查詢，根據實際場景和需要，我們會在業務層建立對應的從查詢條件到主鍵的映射；而對于單行完整記錄的查詢，go-zero 內置了完整的緩存管理方式。所以核心原則是：go-zero 緩存的一定是完整的行記錄。
下面我們來詳細介紹 go-zero 內置的三種場景的緩存處理方式：
基于主鍵的緩存
PRIMARY KEY (`id`)
這種相對來講是最容易處理的緩存，只需要在 redis 里用 primary key 作為 key 來緩存行記錄即可。
基于唯一索引的緩存
在做基于索引的緩存設計的時候我借鑒了 database 索引的設計方法，在 database 設計里，如果通過索引去查數據時，引擎會先在 索引->主鍵 的 tree 里面查找到主鍵，然后再通過主鍵去查詢行記錄，就是引入了一個間接層去解決索引到行記錄的對應問題。在 go-zero 的緩存設計里也是同樣的原理。
基于索引的緩存又分為單列唯一索引和多列唯一索引：
但是對于 go-zero 來說，單列和多列只是生成緩存 key 的方式不同而已，背后的控制邏輯是一樣的。然后 go-zero 內置的緩存管理就比較好的控制了數據一致性問題，同時也內置防止了緩存的擊穿、穿透、雪崩問題（這些在 gopherchina 大會上分享的時候仔細講過，見后續 gopherchina 分享視頻）。
另外，go-zero 內置了緩存訪問量、訪問命中率統計，如下所示：
dbcache(sqlc) - qpm: 5057, hit_ratio: 99.7%, hit: 5044, miss: 13, db_fails: 0
可以看到比較詳細的統計信息，便于我們來分析緩存的使用情況，對于緩存命中率極低或者請求量極小的情況，我們就可以去掉緩存了，這樣也可以降低成本。
單列唯一索引如下：
UNIQUE KEY `product_idx` (`product`)
多列唯一索引如下：
UNIQUE KEY `vendor_product_idx` (`vendor`, `product`)
具體實現代碼如下：
func (cc CachedConn) QueryRow(v interface{}, key string, query QueryFn) error {
return cc.cache.Take(v, key, func(v interface{}) error {
return query(cc.db, v)
})
}這里的 Take 方法是先從緩存里去通過 key 拿數據，如果拿到就直接返回，如果拿不到，那么就通過 query 方法去 DB 讀取完整行記錄并寫回緩存，然后再返回數據。整個邏輯還是比較簡單易懂的。
我們詳細看看 Take 的實現：
func (c cacheNode) Take(v interface{}, key string, query func(v interface{}) error) error {
return c.doTake(v, key, query, func(v interface{}) error {
return c.SetCache(key, v)
})
}Take 的邏輯如下：
用 key 從緩存里查找數據
如果找到，則返回數據
如果找不到，用 query 方法去讀取數據
讀到后調用 c.SetCache(key, v) 設置緩存
其中的 doTake 代碼和解釋如下：
// v - 需要讀取的數據對象
// key - 緩存key
// query - 用來從DB讀取完整數據的方法
// cacheVal - 用來寫緩存的方法
func (c cacheNode) doTake(v interface{}, key string, query func(v interface{}) error,
cacheVal func(v interface{}) error) error {
// 用barrier來防止緩存擊穿，確保一個進程內只有一個請求去加載key對應的數據
val, fresh, err := c.barrier.DoEx(key, func() (interface{}, error) {
// 從cache里讀取數據
if err := c.doGetCache(key, v); err != nil {
// 如果是預先放進來的placeholder（用來防止緩存穿透）的，那么就返回預設的errNotFound
// 如果是未知錯誤，那么就直接返回，因為我們不能放棄緩存出錯而直接把所有請求去請求DB，
// 這樣在高并發的場景下會把DB打掛掉的
if err == errPlaceholder {
return nil, c.errNotFound
} else if err != c.errNotFound {
// why we just return the error instead of query from db,
// because we don't allow the disaster pass to the DBs.
// fail fast, in case we bring down the dbs.
return nil, err
}
// 請求DB
// 如果返回的error是errNotFound，那么我們就需要在緩存里設置placeholder，防止緩存穿透
if err = query(v); err == c.errNotFound {
if err = c.setCacheWithNotFound(key); err != nil {
logx.Error(err)
}
return nil, c.errNotFound
} else if err != nil {
// 統計DB失敗
c.stat.IncrementDbFails()
return nil, err
}
// 把數據寫入緩存
if err = cacheVal(v); err != nil {
logx.Error(err)
}
}
// 返回json序列化的數據
return jsonx.Marshal(v)
})
if err != nil {
return err
}
if fresh {
return nil
}
// got the result from previous ongoing query
c.stat.IncrementTotal()
c.stat.IncrementHit()
// 把數據寫入到傳入的v對象里
return jsonx.Unmarshal(val.([]byte), v)
}因為這塊比較復雜，所以我用不同顏色標識出來了響應的代碼塊和邏輯，block 2 其實跟基于主鍵的緩存是一樣的，這里主要講 block 1 的邏輯。
代碼塊的 block 1 部分分為兩種情況：
通過索引能夠從緩存里找到主鍵
此時就直接用主鍵走 block 2 的邏輯了，后續同上面基于主鍵的緩存邏輯
通過索引無法從緩存里找到主鍵
通過索引從DB里查詢完整行記錄，如有 error，返回
查到完整行記錄后，會把主鍵到完整行記錄的緩存和索引到主鍵的緩存同時寫到 redis 里
返回所需的行記錄數據
// v - 需要讀取的數據對象
// key - 通過索引生成的緩存key
// keyer - 用主鍵生成基于主鍵緩存的key的方法
// indexQuery - 用索引從DB讀取完整數據的方法，需要返回主鍵
// primaryQuery - 用主鍵從DB獲取完整數據的方法
func (cc CachedConn) QueryRowIndex(v interface{}, key string, keyer func(primary interface{}) string,
indexQuery IndexQueryFn, primaryQuery PrimaryQueryFn) error {
var primaryKey interface{}
var found bool
// 先通過索引查詢緩存，看是否有索引到主鍵的緩存
if err := cc.cache.TakeWithExpire(&primaryKey, key, func(val interface{}, expire time.Duration) (err error) {
// 如果沒有索引到主鍵的緩存，那么就通過索引查詢完整數據
primaryKey, err = indexQuery(cc.db, v)
if err != nil {
return
}
// 通過索引查詢到了完整數據，設置found，后面直接使用，不需要再從緩存讀取數據了
found = true
// 將主鍵到完整數據的映射保存到緩存里，TakeWithExpire方法已經將索引到主鍵的映射保存到緩存了
return cc.cache.SetCacheWithExpire(keyer(primaryKey), v, expire+cacheSafeGapBetweenIndexAndPrimary)
}); err != nil {
return err
}
// 已經通過索引找到了數據，直接返回即可
if found {
return nil
}
// 通過主鍵從緩存讀取數據，如果緩存沒有，通過primaryQuery方法從DB讀取并回寫緩存再返回數據
return cc.cache.Take(v, keyer(primaryKey), func(v interface{}) error {
return primaryQuery(cc.db, v, primaryKey)
})
}我們來看一個實際的例子
func (m *defaultUserModel) FindOneByUser(user string) (*User, error) {
var resp User
// 生成基于索引的key
indexKey := fmt.Sprintf("%s%v", cacheUserPrefix, user)
err := m.QueryRowIndex(&resp, indexKey,
// 基于主鍵生成完整數據緩存的key
func(primary interface{}) string {
return fmt.Sprintf("user#%v", primary)
},
// 基于索引的DB查詢方法
func(conn sqlx.SqlConn, v interface{}) (i interface{}, e error) {
query := fmt.Sprintf("select %s from %s where user = ? limit 1", userRows, m.table)
if err := conn.QueryRow(&resp, query, user); err != nil {
return nil, err
}
return resp.Id, nil
},
// 基于主鍵的DB查詢方法
func(conn sqlx.SqlConn, v, primary interface{}) error {
query := fmt.Sprintf("select %s from %s where id = ?", userRows, m.table)
return conn.QueryRow(&resp, query, primary)
})
// 錯誤處理，需要判斷是否返回的是sqlc.ErrNotFound，如果是，我們用本package定義的ErrNotFound返回
// 避免使用者感知到有沒有使用緩存，同時也是對底層依賴的隔離
switch err {
case nil:
return &resp, nil
case sqlc.ErrNotFound:
return nil, ErrNotFound
default:
return nil, err
}
}到此，相信大家對“go-zero如何自動管理緩存”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
