純緩存操作有必要開啟事務嗎
❶ 往資料庫中插入一條數據 都會建立一次資料庫連接 開啟一個事務嗎
向資料庫中插入一條數據 不一定都會建立一次資料庫連接 開啟一個事務。
資料庫的連接是可以保持的。一旦連接，那麼可以向伺服器進行多次數據傳輸或執行命令。
向資料庫伺服器提交一次數據，會開戶一個隱含的事務。
但是，「資料庫」這個概念在使用時，不僅僅是資料庫伺服器，還包含客戶端，對於客戶端來說，有可能是會緩存一部分數據的。數據的操作可能會向緩存操作，這種情況下不會主動開戶事務。
❷ 如何保證資料庫緩存的最終一致性
對於互聯網業務來說，傳統的直接訪問資料庫方式，主要通過數據分片、一主多從等方式來扛住讀寫流量，但隨著數據量的積累和流量的激增，僅依賴資料庫來承接所有流量，不僅成本高、效率低、而且還伴隨著穩定性降低的風險。
鑒於大部分業務通常是讀多寫少（讀取頻率遠遠高於更新頻率），甚至存在讀操作數量高出寫操作多個數量級的情況。因此， 在架構設計中，常採用增加緩存層來提高系統的響應能力 ，提升數據讀寫性能、減少資料庫訪問壓力，從而提升業務的穩定性和訪問體驗。
根據 CAP 原理，分布式系統在可用性、一致性和分區容錯性上無法兼得，通常由於分區容錯無法避免，所以一致性和可用性難以同時成立。對於緩存系統來說， 如何保證其數據一致性是一個在應用緩存的同時不得不解決的問題 。
需要明確的是，緩存系統的數據一致性通常包括持久化層和緩存層的一致性、以及多級緩存之間的一致性，這里我們僅討論前者。持久化層和緩存層的一致性問題也通常被稱為雙寫一致性問題，「雙寫」意為數據既在資料庫中保存一份，也在緩存中保存一份。
對於一致性來說，包含強一致性和弱一致性 ，強一致性保證寫入後立即可以讀取，弱一致性則不保證立即可以讀取寫入後的值，而是盡可能的保證在經過一定時間後可以讀取到，在弱一致性中應用最為廣泛的模型則是最終一致性模型，即保證在一定時間之後寫入和讀取達到一致的狀態。對於應用緩存的大部分場景來說，追求的則是最終一致性，少部分對數據一致性要求極高的場景則會追求強一致性。
為了達到最終一致性，針對不同的場景，業界逐步形成了下面這幾種應用緩存的策略。
— 1 —
Cache-Aside
Cache-Aside 意為旁路緩存模式，是應用最為廣泛的一種緩存策略。下面的圖示展示了它的讀寫流程，來看看它是如何保證最終一致性的。在讀請求中，首先請求緩存，若緩存命中（cache hit），則直接返回緩存中的數據；若緩存未命中（cache miss），則查詢資料庫並將查詢結果更新至緩存，然後返回查詢出的數據（demand-filled look-aside ）。在寫請求中，先更新資料庫，再刪除緩存（write-invalidate）。
1、為什麼刪除緩存，而不是更新緩存？
在 Cache-Aside 中，對於讀請求的處理比較容易理解，但在寫請求中，可能會有讀者提出疑問，為什麼要刪除緩存，而不是更新緩存？站在符合直覺的角度來看，更新緩存是一個容易被理解的方案，但站在性能和安全的角度，更新緩存則可能會導致一些不好的後果。
首先是性能 ，當該緩存對應的結果需要消耗大量的計算過程才能得到時，比如需要訪問多張資料庫表並聯合計算，那麼在寫操作中更新緩存的動作將會是一筆不小的開銷。同時，當寫操作較多時，可能也會存在剛更新的緩存還沒有被讀取到，又再次被更新的情況（這常被稱為緩存擾動），顯然，這樣的更新是白白消耗機器性能的，會導致緩存利用率不高。
而等到讀請求未命中緩存時再去更新，也符合懶載入的思路，需要時再進行計算。刪除緩存的操作不僅是冪等的，可以在發生異常時重試，而且寫-刪除和讀-更新在語義上更加對稱。
其次是安全 ，在並發場景下，在寫請求中更新緩存可能會引發數據的不一致問題。參考下面的圖示，若存在兩個來自不同線程的寫請求，首先來自線程 1 的寫請求更新了資料庫（step 1），接著來自線程 2 的寫請求再次更新了資料庫（step 3），但由於網路延遲等原因，線程 1 可能會晚於線程 2 更新緩存（step 4 晚於 step 3），那麼這樣便會導致最終寫入資料庫的結果是來自線程 2 的新值，寫入緩存的結果是來自線程 1 的舊值，即緩存落後於資料庫，此時再有讀請求命中緩存（step 5），讀取到的便是舊值。
2、為什麼先更新資料庫，而不是先刪除緩存？
另外，有讀者也會對更新資料庫和刪除緩存的時序產生疑問，那麼為什麼不先刪除緩存，再更新資料庫呢？在單線程下，這種方案看似具有一定合理性，這種合理性體現在刪除緩存成功。
但更新資料庫失敗的場景下，盡管緩存被刪除了，下次讀操作時，仍能將正確的數據寫回緩存，相對於 Cache-Aside 中更新資料庫成功，刪除緩存失敗的場景來說，先刪除緩存的方案似乎更合理一些。那麼，先刪除緩存有什麼問題呢？
問題仍然出現在並發場景下，首先來自線程 1 的寫請求刪除了緩存（step 1），接著來自線程 2 的讀請求由於緩存的刪除導致緩存未命中，根據 Cache-Aside 模式，線程 2 繼而查詢資料庫（step 2），但由於寫請求通常慢於讀請求，線程 1 更新資料庫的操作可能會晚於線程 2 查詢資料庫後更新緩存的操作（step 4 晚於 step 3），那麼這樣便會導致最終寫入緩存的結果是來自線程 2 中查詢到的舊值，而寫入資料庫的結果是來自線程 1 的新值，即緩存落後於資料庫，此時再有讀請求命中緩存（ step 5 ），讀取到的便是舊值。
另外，先刪除緩存，由於緩存中數據缺失，加劇資料庫的請求壓力，可能會增大緩存穿透出現的概率。
3、如果選擇先刪除緩存，再更新資料庫，那如何解決一致性問題呢？
為了避免「先刪除緩存，再更新資料庫」這一方案在讀寫並發時可能帶來的緩存臟數據，業界又提出了延時雙刪的策略，即在更新資料庫之後，延遲一段時間再次刪除緩存，為了保證第二次刪除緩存的時間點在讀請求更新緩存之後，這個延遲時間的經驗值通常應稍大於業務中讀請求的耗時。
延遲的實現可以在代碼中 sleep 或採用延遲隊列。顯而易見的是，無論這個值如何預估，都很難和讀請求的完成時間點准確銜接，這也是延時雙刪被詬病的主要原因。
4、那麼 Cache-Aside 存在數據不一致的可能嗎？
在 Cache-Aside 中，也存在數據不一致的可能性。在下面的讀寫並發場景下，首先來自線程 1 的讀請求在未命中緩存的情況下查詢資料庫（step 1），接著來自線程 2 的寫請求更新資料庫（step 2），但由於一些極端原因，線程 1 中讀請求的更新緩存操作晚於線程 2 中寫請求的刪除緩存的操作（step 4 晚於 step 3），那麼這樣便會導致最終寫入緩存中的是來自線程 1 的舊值，而寫入資料庫中的是來自線程 2 的新值，即緩存落後於資料庫，此時再有讀請求命中緩存（step 5），讀取到的便是舊值。
這種場景的出現，不僅需要緩存失效且讀寫並發執行，而且還需要讀請求查詢資料庫的執行早於寫請求更新資料庫，同時讀請求的執行完成晚於寫請求。足以見得，這種 不一致場景產生的條件非常嚴格，在實際的生產中出現的可能性較小 。
除此之外，在並發環境下，Cache-Aside 中也存在讀請求命中緩存的時間點在寫請求更新資料庫之後，刪除緩存之前，這樣也會導致讀請求查詢到的緩存落後於資料庫的情況。
雖然在下一次讀請求中，緩存會被更新，但如果業務層面對這種情況的容忍度較低，那麼可以採用加鎖在寫請求中保證「更新資料庫&刪除緩存」的串列執行為原子性操作（同理也可對讀請求中緩存的更新加鎖）。 加鎖勢必會導致吞吐量的下降，故採取加鎖的方案應該對性能的損耗有所預期。
— 2 —
補償機制
我們在上面提到了，在 Cache-Aside 中可能存在更新資料庫成功，但刪除緩存失敗的場景，如果發生這種情況，那麼便會導致緩存中的數據落後於資料庫，產生數據的不一致的問題。
其實，不僅 Cache-Aside 存在這樣的問題，在延時雙刪等策略中也存在這樣的問題。針對可能出現的刪除失敗問題，目前業界主要有以下幾種補償機制。
1、刪除重試機制
由於同步重試刪除在性能上會影響吞吐量，所以常通過引入消息隊列，將刪除失敗的緩存對應的 key 放入消息隊列中，在對應的消費者中獲取刪除失敗的 key ，非同步重試刪除。這種方法在實現上相對簡單，但由於刪除失敗後的邏輯需要基於業務代碼的 trigger 來觸發 ，對業務代碼具有一定入侵性。
鑒於上述方案對業務代碼具有一定入侵性，所以需要一種更加優雅的解決方案，讓緩存刪除失敗的補償機制運行在背後，盡量少的耦合於業務代碼。一個簡單的思路是通過後台任務使用更新時間戳或者版本作為對比獲取資料庫的增量數據更新至緩存中，這種方式在小規模數據的場景可以起到一定作用，但其擴展性、穩定性都有所欠缺。
一個相對成熟的方案是基於 Mysql 資料庫增量日誌進行解析和消費，這里較為流行的是阿里巴巴開源的作為 MySQL binlog 增量獲取和解析的組件 canal（類似的開源組件還有 Maxwell、Databus 等）。
canal sever 模擬 MySQL slave 的交互協議，偽裝為 MySQL slave，向 MySQL master 發送 mp 協議，MySQL master 收到 mp 請求，開始推送 binary log 給 slave （即 canal sever ），canal sever 解析 binary log 對象（原始為 byte 流），可由 canal client 拉取進行消費，同時 canal server 也默認支持將變更記錄投遞到 MQ 系統中，主動推送給其他系統進行消費。
在 ack 機制的加持下，不管是推送還是拉取，都可以有效的保證數據按照預期被消費。當前版本的 canal 支持的 MQ 有 Kafka 或者 RocketMQ。另外， canal 依賴 ZooKeeper 作為分布式協調組件來實現 HA ，canal 的 HA 分為兩個部分：
那麼，針對緩存的刪除操作便可以在 canal client 或 consumer 中編寫相關業務代碼來完成。這樣，結合資料庫日誌增量解析消費的方案以及 Cache-Aside 模型，在讀請求中未命中緩存時更新緩存（通常這里會涉及到復雜的業務邏輯），在寫請求更新資料庫後刪除緩存，並基於日誌增量解析來補償資料庫更新時可能的緩存刪除失敗問題，在絕大多數場景下，可以有效的保證緩存的最終一致性。
另外需要注意的是，還應該隔離事務與緩存，確保資料庫入庫後再進行緩存的刪除操作。 比如考慮到資料庫的主從架構，主從同步及讀從寫主的場景下，可能會造成讀取到從庫的舊數據後便更新了緩存，導致緩存落後於資料庫的問題，這就要求對緩存的刪除應該確保在資料庫操作完成之後。所以，基於 binlog 增量日誌進行數據同步的方案，可以通過選擇解析從節點的 binlog，來避免主從同步下刪除緩存過早的問題。
3、數據傳輸服務 DTS
— 3 —
Read-Through
Read-Through 意為讀穿透模式，它的流程和 Cache-Aside 類似，不同點在於 Read-Through 中多了一個訪問控制層，讀請求只和該訪問控制層進行交互，而背後緩存命中與否的邏輯則由訪問控制層與數據源進行交互，業務層的實現會更加簡潔，並且對於緩存層及持久化層交互的封裝程度更高，更易於移植。
— 4 —
Write-Through
Write-Through 意為直寫模式，對於 Write-Through 直寫模式來說，它也增加了訪問控制層來提供更高程度的封裝。不同於 Cache-Aside 的是，Write-Through 直寫模式在寫請求更新資料庫之後，並不會刪除緩存，而是更新緩存。
這種方式的 優勢在於讀請求過程簡單 ，不需要查詢資料庫更新緩存等操作。但其劣勢也非常明顯，除了上面我們提到的更新資料庫再更新緩存的弊端之外，這種方案還會造成更新效率低，並且兩個寫操作任何一次寫失敗都會造成數據不一致。
如果要使用這種方案， 最好可以將這兩個操作作為事務處理，可以同時失敗或者同時成功，支持回滾，並且防止並發環境下的不一致 。另外，為了防止緩存擾動的頻發，也可以給緩存增加 TTL 來緩解。
站在可行性的角度，不管是 Write-Through 模式還是 Cache-Aside 模式，理想狀況下都可以通過分布式事務保證緩存層數據與持久化層數據的一致性，但在實際項目中，大多都對一致性的要求存在一些寬容度，所以在方案上往往有所折衷。
Write-Through 直寫模式適合寫操作較多，並且對一致性要求較高的場景，在應用 Write-Through 模式時，也需要通過一定的補償機制來解決它的問題。首先，在並發環境下，我們前面提到了先更新資料庫，再更新緩存會導致緩存和資料庫的不一致，那麼先更新緩存，再更新資料庫呢？
這樣的操作時序仍然會導致下面這樣線程 1 先更新緩存，最後更新資料庫的情況，即由於線程 1 和 線程 2 的執行不確定性導致資料庫和緩存的不一致。這種由於線程競爭導致的緩存不一致，可以通過分布式鎖解決，保證對緩存和資料庫的操作僅能由同一個線程完成。對於沒有拿到鎖的線程，一是通過鎖的 timeout 時間進行控制，二是將請求暫存在消息隊列中順序消費。
在下面這種並發執行場景下，來自線程 1 的寫請求更新了資料庫，接著來自線程 2 的讀請求命中緩存，接著線程 1 才更新緩存，這樣便會導致線程 2 讀取到的緩存落後於資料庫。同理，先更新緩存後更新資料庫在寫請求和讀請求並發時，也會出現類似的問題。面對這種場景，我們也可以加鎖解決。
另在，在 Write-Through 模式下，不管是先更新緩存還是先更新資料庫，都存在更新緩存或者更新資料庫失敗的情況，上面提到的重試機制和補償機制在這里也是奏效的。
— 5 —
Write-Behind
Write behind 意為非同步回寫模式，它也具有類似 Read-Through/Write-Through 的訪問控制層，不同的是，Write behind 在處理寫請求時，只更新緩存而不更新資料庫，對於資料庫的更新，則是通過批量非同步更新的方式進行的，批量寫入的時間點可以選在資料庫負載較低的時間進行。
在 Write-Behind 模式下，寫請求延遲較低，減輕了資料庫的壓力，具有較好的吞吐性。但資料庫和緩存的一致性較弱，比如當更新的數據還未被寫入資料庫時，直接從資料庫中查詢數據是落後於緩存的。同時，緩存的負載較大，如果緩存宕機會導致數據丟失，所以需要做好緩存的高可用。顯然，Write behind 模式下適合大量寫操作的場景，常用於電商秒殺場景中庫存的扣減。
— 6 —
Write-Around
如果一些非核心業務，對一致性的要求較弱，可以選擇在 cache aside 讀模式下增加一個緩存過期時間，在寫請求中僅僅更新資料庫，不做任何刪除或更新緩存的操作，這樣，緩存僅能通過過期時間失效。這種方案實現簡單，但緩存中的數據和資料庫數據一致性較差，往往會造成用戶的體驗較差，應慎重選擇。
— 7 —
總結
在解決緩存一致性的過程中，有多種途徑可以保證緩存的最終一致性，應該根據場景來設計合適的方案，讀多寫少的場景下，可以選擇採用「Cache-Aside 結合消費資料庫日誌做補償」的方案，寫多的場景下，可以選擇採用「Write-Through 結合分布式鎖」的方案 ，寫多的極端場景下，可以選擇採用「Write-Behind」的方案。
❸ Hibernate緩存何時使用和如何使用
關於hibernate緩存的問題基本的緩存原理
Hibernate緩存分為二級
第一級存放於session中稱為一級緩存 默認帶有且不能卸載
第二級是由sessionFactory控制的進程級緩存 是全局共享的緩存 凡是會調用二級緩存的查詢方法 都會從中受益 只有經正確的配置後二級緩存才會發揮作用 同時在進行條件查詢時必須使用相應的方法才能從緩存中獲取數據 比如erate()方法 load get方法等 必須注意的是session find方法永遠是從資料庫中獲取數據 不會從二級緩存中獲取數據 即便其中有其所需要的數據也是如此
查詢時使用緩存的實現過程為 首先查詢一級緩存中是否具有需要的數據 如果沒有 查詢二級緩存 如果二級緩存中也沒有 此時再執行查詢資料庫的工作 要注意的是 此 種方式的查詢速度是依次降低的
存在的問題
一級緩存的問題以及使用二級緩存的原因
因為Session的生命期往往很短 存在於Session內部的第一級最快緩存的生命期當然也很短 所以第一級緩存的命中率是很低的 其對系統性能的改善也是很有限的 當然 這個Session內部緩存的主要作用是保持Session內部數據狀態同步 並非是hibernate為了大幅提高系統性能所提供的
為了提高使用hibernate的性能 除了常規的一些需要注意的方法比如
使用延遲載入 迫切外連接 查詢過濾等以外 還需要配置hibernate的二級緩存 其對系統整體性能的改善往往具有立竿見影的效果！
（經過自己以前作項目的經驗 一般會有 ~ 倍的性能提高）
N+ 次查詢的問題
什麼時候會遇到 +N的問題？
前提 Hibernate默認表與表的關聯方法是fetch= select 不是fetch= join 這都是為了懶載入而准備的
）一對多(<set><list>) 在 的這方 通過 條sql查找得到了 個對象 由於關聯的存在 那麼又需要將這個對象關聯的集合取出 所以合集數量是n還要發出n條sql 於是本來的 條sql查詢變成了 +n條
）多對一<many to one> 在多的這方 通過 條sql查詢得到了n個對象 由於關聯的存在 也會將這n個對象對應的 方的對象取出 於是本來的 條sql查詢變成了 +n條
）iterator 查詢時 一定先去緩存中找（ 條sql查集合 只查出ID） 在沒命中時 會再按ID到庫中逐一查找 產生 +n條SQL
怎麼解決 +N 問題？
）lazy=true hibernate 開始已經默認是lazy=true了 lazy=true時不會立刻查詢關聯對象 只有當需要關聯對象（訪問其屬性 非id欄位）時才會發生查詢動作
）使用二級緩存 二級緩存的應用將不怕 +N 問題 因為即使第一次查詢很慢（未命中） 以後查詢直接緩存命中也是很快的 剛好又利用了 +N
) 當然你也可以設定fetch= join 一次關聯表全查出來 但失去了懶載入的特性
執行條件查詢時 iterate（）方法具有著名的 n+ 次查詢的問題 也就是說在第一次查詢時iterate方法會執行滿足條件的查詢結果數再加一次（n+ ）的查詢 但是此問題只存在於第一次查詢時 在後面執行相同查詢時性能會得到極大的改善 此方法適合於查詢數據量較大的業務數據
但是注意 當數據量特別大時（比如流水線數據等）需要針對此持久化對象配置其具體的緩存策略 比如設置其存在於緩存中的最大記錄數 緩存存在的時間等參數 以避免系統將大量的數據同時裝載入內存中引起內存資源的迅速耗盡 反而降低系統的性能！！！
使用hibernate二級緩存的其他注意事項
關於數據的有效性
另外 hibernate會自行維護二級緩存中的數據 以保證緩存中的數據和資料庫中的真實數據的一致性！無論何時 當你調用save() update()或 saveOrUpdate()方法傳遞一個對象時 或使用load() get() list() iterate() 或scroll()方法獲得一個對象時 該對象都將被加入到Session的內部緩存中 當隨後flush()方法被調用時 對象的狀態會和資料庫取得同步
也就是說刪除 更新 增加數據的時候 同時更新緩存 當然這也包括二級緩存！
只要是調用hibernate API執行資料庫相關的工作 hibernate都會為你自動保證 緩存數據的有效性！！
但是 如果你使用了JDBC繞過hibernate直接執行對資料庫的操作 此時 Hibernate不會/也不可能自行感知到資料庫被進行的變化改動 也就不能再保證緩存中數據的有效性！！
這也是所有的ORM產品共同具有的問題 幸運的是 Hibernate為我們暴露了Cache的清除方法 這給我們提供了一個手動保證數據有效性的機會！！
一級緩存 二級緩存都有相應的清除方法
其中二級緩存提供的清除方法為
按對象class清空緩存
按對象class和對象的主鍵id清空緩存
清空對象的集合中的緩存數據等
適合使用的情況
並非所有的情況都適合於使用二級緩存 需要根據具體情況來決定 同時可以針對某一個持久化對象配置其具體的緩存策略
適合於使用二級緩存的情況
數據不會被第三方修改
一般情況下 會被hibernate以外修改的數據最好不要配置二級緩存 以免引起不一致的數據 但是如果此數據因為性能的原因需要被緩存 同時又有可能被第 方比如SQL修改 也可以為其配置二級緩存 只是此時需要在sql執行修改後手動調用cache的清除方法 以保證數據的一致性
數據大小在可接收范圍之內
如果數據表數據量特別巨大 此時不適合於二級緩存 原因是緩存的數據量過大可能會引起內存資源緊張 反而降低性能 如果數據表數據量特別巨大 但是經常使用的往往只是較新的那部分數據 此時 也可為其配置二級緩存 但是必須單獨配置其持久化類的緩存策略 比如最大緩存數 緩存過期時間等 將這些參數降低至一個合理的范圍（太高會引起內存資源緊張 太低了緩存的意義不大）
數據更新頻率低
對於數據更新頻率過高的數據 頻繁同步緩存中數據的代價可能和 查詢緩存中的數據從中獲得的好處相當 壞處益處相抵消 此時緩存的意義也不大
非關鍵數據（不是財務數據等）
財務數據等是非常重要的數據 絕對不允許出現或使用無效的數據 所以此時為了安全起見最好不要使用二級緩存
因為此時 正確性 的重要性遠遠大於 高性能 的重要性
目前系統中使用hibernate緩存的建議
目前情況
一般系統中有三種情況會繞開hibernate執行資料庫操作
多個應用系統同時訪問一個資料庫
此種情況使用hibernate二級緩存會不可避免的造成數據不一致的問題 此時要進行詳細的設計 比如在設計上避免對同一數據表的同時的寫入操作 使用資料庫各種級別的鎖定機制等
動態表相關
所謂 動態表 是指在系統運行時根據用戶的操作系統自動建立的數據表
比如 自定義表單 等屬於用戶自定義擴展開發性質的功能模塊 因為此時數據表是運行時建立的 所以不能進行hibernate的映射 因此對它的操作只能是繞開hibernate的直接資料庫JDBC操作
如果此時動態表中的數據沒有設計緩存 就不存在數據不一致的問題
如果此時自行設計了緩存機制 則調用自己的緩存同步方法即可
使用sql對hibernate持久化對象表進行批量刪除時
此時執行批量刪除後 緩存中會存在已被刪除的數據
分析
當執行了第 條（sql批量刪除）後 後續的查詢只可能是以下三種方式
a session find（）方法
根據前面的總結 find方法不會查詢二級緩存的數據 而是直接查詢資料庫
所以不存在數據有效性的問題
b 調用iterate方法執行條件查詢時
根據iterate查詢方法的執行方式 其每次都會到資料庫中查詢滿足條件的id值 然後再根據此id 到緩存中獲取數據 當緩存中沒有此id的數據才會執行資料庫查詢
如果此記錄已被sql直接刪除 則iterate在執行id查詢時不會將此id查詢出來 所以 即便緩存中有此條記錄也不會被客戶獲得 也就不存在不一致的情況 （此情況經過測試驗證）
c 用get或load方法按id執行查詢
客觀上此時會查詢得到已過期的數據 但是又因為系統中執行sql批量刪除一般是針對中間關聯數據表 對於中間關聯表的查詢一般都是採用條件查詢 按id來查詢某一條關聯關系的幾率很低 所以此問題也不存在!
如果某個值對象確實需要按id查詢一條關聯關系 同時又因為數據量大使用 了sql執行批量刪除 當滿足此兩個條件時 為了保證按id 的查詢得到正確的結果 可以使用手動清楚二級緩存中此對象的數據的方法!!(此種情況出現的可能性較小)
建 議
建議不要使用sql直接執行數據持久化對象的數據的更新 但是可以執行 批量刪除 （系統中需要批量更新的地方也較少）
如果必須使用sql執行數據的更新 必須清空此對象的緩存數據 調用
SessionFactory evict(class)
SessionFactory evict(class id)等方法
在批量刪除數據量不大的時候可以直接採用hibernate的批量刪除 這樣就不存在繞開hibernate執行sql產生的緩存數據一致性的問題
不推薦採用hibernate的批量刪除方法來刪除大批量的記錄數據
原因是hibernate的批量刪除會執行 條查詢語句外加 滿足條件的n條刪除語句 而不是一次執行一條條件刪除語句！！當待刪除的數據很多時會有很大的性能瓶頸！！！如果批量刪除數據量較大 比如超過 條 可以採用JDBC直接刪除 這樣作的好處是只執行一條sql刪除語句 性能會有很大的改善 同時 緩存數據同步的問題 可以採用 hibernate清除二級緩存中的相關數據的方法
調 用
SessionFactory evict(class) ;
SessionFactory evict(class id)等方法
所以說 對於一般的應用系統開發而言（不涉及到集群 分布式數據同步問題等） 因為只在中間關聯表執行批量刪除時調用了sql執行 同時中間關聯表一般是執行條件查詢不太可能執行按id查詢 所以 此時可以直接執行sql刪除 甚至不需要調用緩存的清除方法 這樣做不會導致以後配置了二級緩存引起數據有效性的問題
退一步說 即使以後真的調用了按id查詢中間表對象的方法 也可以通過調用清除緩存的方法來解決
具體的配置方法
根據我了解的很多hibernate的使用者在調用其相應方法時都迷信的相信 hibernate會自行為我們處理性能的問題 或者 hibernate 會自動為我們的所有操作調用緩存 實際的情況是hibernate雖然為我們提供了很好的緩存機制和擴展緩存框架的支持 但是必須經過正確的調用其才有可能發揮作用！！所以造成很多使用hibernate的系統的性能問題 實際上並不是hibernate不行或者不好 而是因為使用者沒有正確的了解其使用方法造成的 相反 如果配置得當hibernate的性能表現會讓你有相當 驚喜的 發現 下面我講解具體的配置方法
ibernate提供了二級緩存的介面
net sf hibernate cache Provider
同時提供了一個默認的 實現net sf hibernate cache HashtableCacheProvider
也可以配置 其他的實現 比如ehcache jbosscache等
具體的配置位置位於hibernate cfg xml文件中
- <propertyname= hibernate cache use_query_cache >true</property><propertyname= hibernate cache provider_class >net sf hibernate cache HashtableCacheProvider</property>
很多的hibernate使用者在 配置到 這一步 就以為 完事了
注意 其實光這樣配 根本就沒有使用hibernate的二級緩存 同時因為他們在使用hibernate時大多時候是馬上關閉session 所以 一級緩存也沒有起到任何作用 結果就是沒有使用任何緩存 所有的hibernate操作都是直接操作的資料庫！！性能可以想見
正確的辦法是除了以上的配置外還應該配置每一個vo對象的具體緩存策略 在影射文件中配置 例如
- <hibernate mapping><classname= sobey *** m model entitySystem vo DataTypeVO table= dcm_datatype ><cacheusage= read write /><idname= id column= TYPEID type= java lang Long ><generatorclass= sequence /></id><propertyname= name column= NAME type= java lang String /><propertyname= dbType column= DBTYPE type= java lang String /></class></hibernate mapping>
關鍵就是這個<cache usage= read write /> 其有幾個選擇read only read write transactional 等
然後在執行查詢時 注意了 如果是條件查詢 或者返回所有結果的查詢 此時session find()方法 不會獲取緩存中的數據 只有調用erate()方法時才會調緩存的數據
同時 get 和 load方法 是都會查詢緩存中的數據
對於不同的緩存框架具體的配置方法會有不同 但是大體是以上的配置（另外 對於支持事務型 以及支持集群的環境的配置我會爭取在後續的文章中中 發表出來）