最近做乙個比較大的電子商務專案，預計每天訂單量將在５萬多單，客服人員需要頻繁的下單、查詢訂單、操作訂單，客人預訂完訂單後，會立即進入處理流程，為了提高服務質量，要求流水化作業，平均要在４０分鐘－８０分鐘內處理完訂單，對於疑難訂單要到第二天，才能處理完。所以訂單在建立後，會在短時間內，被頻繁的修改和檢視。
由於在專案中orm層主要是基於hibernate框架，所以在調優時，很自然的就想到開啟hibernate的二級快取，以次來減小由於load 訂單大物件時n+1次查詢給資料造成的壓力，自己做的測試效果也非常好，也順利通過壓力測試。
但在上線時，效能卻並不佳，經過分析業務的操作特點，查詢原因有以下幾占：，
1.但由於中臺每天在工作當中，頻繁的批量分配工單，
因為要批量將訂單分配給某乙個工作人員處理，在**當中執行了乙個bulkupdate的操作：
template.bulkupdate("update order set owner = ? where id in (?, ?,?)");
這時hibernate會直接將order物件的二級快取清楚掉。
由於二級快取，總是被刷掉，再查詢時，需要重新從資料庫load，所以二級快取變相直接起的作用很少。
2.由於工作人員在處理訂單時，每一次檢視之後，都有更新操作，在更新之後，訂單被清除快取，下一組人在處理訂單時，又得重新load，所以效果並不好。
3.無論是白盒測試，還是壓力測試時，所基於的案例太過於簡單，沒有更深入的模仿業務操作，對於壓力測試的指令碼，也很難精確的模擬出真實的流程化的業務操作過程。
開始想到，直接獲得session，直接使用jdbc來編寫更新**，並在更新後，使用sessionfactory.evict(order.class, id);來有目標的逐個清除特定的物件，以避免全部清楚快取。
但樣做，會對dao層，修改過大。
由於整個模組最核心的商業物件就是訂單，最後決定在service層對訂單開小灶，對訂單快取的單獨的定製處理。
我覺得應用快取存在以下優點：
１。速度要快於orm快取，
２。對於快取的控制權更大，可以直接控制快取工具的api進行操作，可以避免一些盲目清除的操作。
３。更靈活的控制快取中物件的失效，如根據事件來清除快取，如訂單的處理流程結束時，將該訂單從快取中清除掉，
４。在更新資料庫時，不是直接清除快取，而是更新快取（儘管這有風險），當業務層丟擲異常時，才去清空快取，避免由於頻繁更新，而清空快取。
缺點：１。訂單的更新操作，必須是單點的，只能通過iorderservice提供的介面，進行更新操作，否則資料不一致的風險較大。
２。想要透明化，需要有一定的**工作量,不容易達到orm快取最強大的那種透明化和靈活可配置，你可以使用ehcache, 也可以選jboss，有錢的話，可以用tangosol。
３。如果不對第三方快取包，進行一定的封裝的話，會直接耦合於第三方的快取包，不能像hibernate那樣，靈活選擇和配置快取工具。
４。對業務層**有一定的侵入
目前的方案是採用應用層的現代化，同時使用如proxy模式來提供透明化的設計，
iorderservice －》 orderservice －》 cacheableorderservice
通過spring的bean配置，一樣可以實現透明化的操作。
結論：１。快取的清空與更新，要盡量精確的去操作受到更新影響的物件，而不是全部搞掉。
在hibernate當中，也提供了sessionfactory.evict(class, id)這樣細粒度的清空快取物件的方法。
sessionfactory.evice(class)的操作，要看這樣的操作是否頻繁，如果頻繁，對於快取的作用就會大大的折扣。
２。如果快取物件過多，對於失效的演算法與處理，要與業務物件的特性緊密的聯合起來，通過事件來驅動物件的失效。
３。對於商業物件的快取，必須要深刻分析物件的生命週期，業務特性。
４。對於資料不一致的風險，要有足夠的認識與預防手段。
５。合理的估計訂單物件的大小，分配足夠的記憶體
６。如果只使用中心快取，只能減小資料庫的壓力，對於網路頻寬的壓力，還是有的，速度上也遠遠遜於本地快取的效果，所以要結合本地快取＋中心快取的策略方案，即提高速度，避免群集複製時的瓶頸。
表示層 應用層
表示層 功能 為異種機通訊提供一種公共語言，以便能進行互操作。這種型別的服務之所以需要，是因為不同的計算機體系結構使用的資料表示法不同。例如，ibm主機使用ebcdic編碼，而大部分pc機使用的是ascii碼。在這種情況下，便需要表示層來完成這種轉換。應用層 包含了通常要使用的協議 http協議 超...
應用層協議
應用層協議定義了執行在不同端系統上的應用程式程序如何相互傳遞訊息。特別是定義了 交換的訊息型別，如請求訊息和響應訊息。各種訊息型別的語法，如訊息中的各個字段及其詳細描述。欄位的語義，即包含在字段中的資訊的含義。程序何時 如何傳送訊息及對訊息進行響應的規則。有些應用層協議是由rfc文件定義的，因此它們...
應用層協議
dns 網域名稱解析協議 http 超文字傳輸協議 ftp 文字傳輸協議 tlent internet遠端登入服務的標準協議 smtp 簡單郵件傳輸協議 snmp 簡單網路管理協議 ssh 協議 加密的安全的連線 ftp 給予tcp文字傳輸的協議 tftp 基於udp，簡單檔案傳輸協議 1.網域名稱...