概述
為了提升介面的響應速度，通常會使用中央快取，比如增加一個memcache叢集，用於儲存熱點資料。
假設資料表是類似下面這樣的：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
table a{ long id String name ......... ......... } table b{ long id long a_id String name ......... ........ } table c { long id long a_id String content //大欄位 ........ ........ } table d{ long id long a_id String content//大欄位 ........ ....... } |
表b、c、d都通過一個a_id去引用a表的記錄。假設這四張表的資料需要儲存到memcache上，那麼memcache 快取維度該怎麼設計呢？是使用一個key，然後把所有記錄儲存起來呢？還是使用多個key呢？
其實都可以，根據業務場景和具體資料來決定。
使用多個key
假設你的服務介面大部分情況下只需要輸出a表和b表中的資料，那就可以使用多個key。比如說，介面需要輸出id=7對應的業務資料，那麼key這樣設計：
|
1 2 3 |
business_7 c_7 d_7 |
business_7這個key用於儲存介面最經常輸出的業務資料，也就是a表和b表的資料，c_7用於輸出c表的資料，d_7用於輸出d表的資料。這樣設計基於以下幾點:
1、c表和d表都有大欄位,而且內容也無需經常輸出，如果每次呼叫介面，不管對方要不要，都要從memcache中獲取。大家應該知道，當資料體積比較大的時候，走網路從memcache中獲取的時候，是比較慢的，會降低介面響應速度的。
2、介面呼叫方，最經常要使用的資料，是a表和b表中的資料。
備註：
不建議針對每張表，都去設計一個key，這樣做雖然粒度比較細。但是每次介面輸出資料時，都得跟memcache做很多次互動。根據我們自己的效能壓測結果，只要跟memcache互動的次數多了，介面效能立馬就下去了。
使用一個key
如果大部分外部系統都需要使用到表a、b、c、d的資料，那麼就使用一個key即可。減少跟memcache互動的次數。
打賞支援我寫出更多好文章，謝謝！
打賞作者
打賞支援我寫出更多好文章，謝謝！
