之前與同事討論接口性能問題時聽他介紹了一種緩存設計思路，覺得不錯，做個記錄供以后參考。

場景

假設有個以下格式的接口：

GET /api?keys={key1,key2,key3,...}&types={1,2,3,...}

其中 keys 是業務主鍵列表，types 是想要取到的信息的類型。

請求該接口需要返回業務主鍵列表對應的業務對象列表，對象里需要包含指定類型的信息。

業務主鍵可能的取值較多，千萬量級，type 取值范圍為 1-10，可以任意組合，每種 type 對應到數據庫是 1-N 張表，示意：

現在設想這個接口遇到了性能瓶頸，打算添加 Redis 緩存來改善響應速度，應該如何設計？

設計思路

方案一：最簡單粗暴的方法是直接使用請求的所有參數作為緩存 key，請求的返回內容為 value。

方案二：如果稍做一下思考，可能就會想到文首我提到的覺得不錯的思路了：

• 使用 業務主鍵:表名 作為緩存 key，表名里對應的該業務主鍵的記錄作為 value；
• 查詢時，先根據查詢參數 keys，以及 types 對應的表，得到所有 key1:tb_1_1、key1:tb_1_2 這樣的組合，使用 Redis 的 mget 命令，批量取到所有緩存中存在的信息，剩下沒有命中的，批量到數據庫里查詢到結果，并放入緩存；
• 在某個表的數據有更新時，只需刷新 涉及業務主鍵:該表名 的緩存，或令其失效即可。

小結

在以上兩種方案之間做評估和選擇，考慮幾個方面：

• 緩存命中率；
• 緩存數量、占用空間大小；
• 刷新緩存是否方便；

稍作思考和計算，就會發現此場景下方案二的優勢。

另外，就是需要根據實際業務場景，如業務對象復雜度、讀寫次數比等，來評估合適的緩存數據的粒度和層次，是對應到某一級組合后的業務對象（緩存值對應存儲 + 部分邏輯），還是最基本的數據庫表/字段（存儲的歸存儲，邏輯的歸邏輯）。