對於優化**速度，快取有：cdn，js及靜態資源檔案快取。資料庫快取，資料對映層快取(mybatis)，以及業務層快取。
快取能提高訪問速度，但也會造成**邏輯複雜度的增加。通常快取對於非實時性的可以選擇失效時間，對於實時性要求較高的則最好採用事件式更新。
使用快取時，一致性很重要，這樣就涉及到不能用類似ehcache這種本地分布式快取，例：商品服務有兩台機子，對資料a都做了快取，那麼當資料a更新時，如何更新商品服務的兩台機子中的快取
對於cdn的快取，是讓使用者就近訪問乙個快取cache伺服器，通常是用於靜態類資源，如，靜態網頁等。
資料庫快取是資料庫自身的快取，如對於一些查詢熱點，資料庫會將這些結果放入快取中。
資料對映層快取mybatis，有一級快取和二級快取。
其中一級快取是local本地快取，在應用開啟乙個sqlsession時，對於重複的查詢會快取，但個人覺得大多業務不會在乙個事務中重複查詢某個資料。反而如果這個資料由另外乙個事務修改並提交，這時當前事務還是看不到已提交的更新。建議關閉一級快取
mybatis二級快取是應用級別的，基本上是儲存在應用伺服器上。每次查詢時會先查詢二級快取，沒有再查一級快取，還是沒有最終查詢資料庫。從一級快取或資料庫查詢到資料後會將結果集放入二級快取。由於二級快取mybaits預設實現是儲存在相應服務機子上，會存在快取不一致問題。
相對於mybatis快取（一，二級快取），個人更頃向於在業務層構建快取，採用集中式快取。
業務層構建快取關鍵在於易用性，效能，一致性。
對於我們這邊的業務，我們總結出服務提供方cache的規範，目標在於能夠保證效能的情況下，一定程度保證一致性：
1.服務提供者cache約定
分為：基礎塊，普通查詢塊及其它塊
基礎塊：
根據id查詢的cache塊
cache塊名稱：search+服務業務實體名稱+byid，例對於商品poproduct服務，則cache塊名稱為:searchpoproductbyid
普通查詢塊:
普通查詢塊，根據查詢so進行查詢
cache塊名稱：search+服務業務實體名稱+byso，例對於商品poproduct服務，則cache塊名稱為:searchpoproductbyso
根據po進行查詢的塊(特例):
根據poid進行查詢
cache塊名稱：search+服務業務實體名稱+bypoid，例對於商品poproduct服務，則cache塊名稱為:searchpoproductbypoid
其它塊對於基礎塊需要做到事件式更新，在建立業務實體時加入快取，更新業務實體時更新對應實體快取，刪除時刪除對應快取中業務實體。
普通查詢塊及根據po進行查詢的塊，在它們下面的商品發生變動時（含新增，更新，刪除）需要清除
業務邏輯層快取應該設計
在業務制定的時候很少會切入快取設計這一環節,畢竟在指標不明確的情況這屬於一種過渡設計.畢竟快取切入有很多手段,在很多時候直接在web進行乙個頁面快取就有著非常高收益的效果.快取是一種橫向的資料處理應用,一般在設計中引入aop,ico的應用元件都可以在後期切入新增.但aop,ico在沒有比較豐富的經驗...
業務層設計
專案架構設計，主要考慮的就是後期維護和可擴充套件性 目前主流的設計 連線資料庫 通過乙個類對映表 通過dao，對對映類操作實現表的增刪改查，通過業務層，對多個dao操作，實現業務 業務層 現實中，乙個業務肯定會使用多個表的，所以在dao層設計就不合適，比如 的乙個訂單，不 僅僅訂單變化了就行，還要使...
快取設計 快取誤用
服務1和服務2約定好key和value，通過快取傳遞資料 服務1將資料寫入快取，服務2從快取讀取資料，達到兩個服務通訊的目的。存在問題 資料管道，資料通知場景，mq更加合適 思想是讓專業的軟體幹專業的事情，nginx做反向 db做固話，cache做快取，mq做通道 多個服務關聯同乙個快取例項，會導致...