基於大資料量的快取查詢實現方案
業務、應用系統最常用的就是基於資料的查詢，這不同於巨集觀意義上的系統各個層面優化（應用端、服務端、DB端等等），基於資料的查詢更多時候需要考慮資料的規模、使用者的習慣、資料的變化性等因素，但同時資料查詢的優化也貫穿著系統的各個層面。本文主要針對一個特定領域進行分析，以供各位參考！
基於資料的查詢往往首要考慮的是快取資料，那麼快取的前提：
1、資料不會實時變化
2、每個使用者最大範圍的可以共用資料集合
基於快取的實現方案，通常需要這樣的一個快取框架來完成，OK，接下來首先來應用溫老師的ADMEMS矩陣方法進行結構化的需求分析，來看看我們的關鍵性需求、功能以及約束影響：
|
功能 |
質量 |
約束 |
|
|
業務級需求 |
當前：管理遊戲類複雜產品的資料快取 未來：管理其他類產品的資料快取 |
新產品上線快，釋出頻繁 快取資料的關鍵性 |
支援DB直連和快取切換 與關聯業務系統快取同時生效 支援快取更新、重新整理（5分鐘時效） 支援快取故障恢復 支援其他類產品快取管理 |
|
使用者級需求 |
手機平臺 Web平臺 遊戲平臺 |
高可用 易用性 效能：快取查詢、吞吐 |
分散式的使用要求 不同平臺的差異因素 |
|
開發級需求 |
資料安全機制 可重用、可擴充套件 |
補充說明：
1、可擴充套件性
不同型別資料庫的以外掛方式接入快取體系（Oracle、SQL Server等等）
2、可用性
資料獲取重試機制、快取重新整理重試機制、快取通知重試機制
3、效能
以最小粒度為資料快取更新點
4、故障恢復
分散式伺服器、單臺WEB下線，上線，快取資料重新拉取
廢話不多說，針對以上的需求分析，現對該快取的預設計實現方案陳述如下：
另外，考慮到Cache應用到不同的系統層面，也應一併考慮到如下的優化：
1、應用端
如果是列表類，動態變化的查詢，可採用分頁查詢
另外根據業務需求，可將首頁或查詢命中率較高的頁資料進行快取
同時可配合非同步查詢的方式進行
2、資料庫
查詢優化，針對不同的查詢維度，進行分割槽並建立合適的索引，適當時候考慮資料遷移
另外建立資料同步機制，完成讀寫分離
其他，待補充！
其他參考：