比較常用的快取策略，同樣這也是facebook的快取策略：
1. 讀：應用程式從cache中取資料，取到後返回。
2. 讀：應用程式先從cache取資料，沒有得到，則從資料庫中取資料，成功後，放到快取中。
3. 增刪改：先把資料存到資料庫中，成功後，再讓快取失效。
這裡針對第3點，會有一些其他的用法，乍一看都是很正常的，但後來細細一想其實都是有問題的。
比如（1）「先更新redis，然後更新db」
（2）「先更新db，然後更新快取」
（3）「先刪除快取，然後再更新資料庫」
讓我們來看一看這三個都有什麼問題，先假設更新db和更新redis都是在同乙個事務中，其中乙個失敗了就都不操作，或者假設這兩個動作都不會失敗。
先看第（1）個和第（2）個，quora上的這個問答已經說明了原因：
為了更生動形象說明問題，我畫了張圖來證明它的不可行性：
從圖中可以看出，兩個併發寫操作，由於某些原因（io阻塞，cpu時間片分配，協程排程，網路原因等等），導致goroutine2的更新db晚於goroutine1的更新db，但是redis中此時的資料goroutine1的，而db中的資料時goroutine2的，這就出現了不一致的問題，db中是髒資料。
第（2）個是同樣的道理，見下圖：
Hibernate的檢索策略小結
hibernate的檢索策略包括類級別檢索策略和關聯級別檢索策略。類級別檢索策略有立即檢索和延遲檢索，預設的檢索策略是立即檢索。在hibernate對映檔案中，通過在上配置lazy屬性來確定檢索策略。對於session的檢索方式，類級別檢索策略僅適用於load方法 也就說，對於get qurey檢索...
Hibernate的檢索策略小結
hibernate的檢索策略包括類級別檢索策略和關聯級別檢索策略。類級別檢索策略有立即檢索和延遲檢索，預設的檢索策略是立即檢索。在hibernate對映檔案中，通過在上配置lazy屬性來確定檢索策略。對於session的檢索方式，類級別檢索策略僅適用於load方法 也就說，對於get qurey檢索...
hibernate 的主鍵生成策略小結
hibernate主鍵生成策略 1，increment 以遞增的方式生成oid，每次增加一 hibernate在執行插入語句之前會執行一次查詢，查詢的結果為這個表中的id的最大值，然後加1處理在繫結到這個insert語句中 2，identity 由底層資料庫生成oid，條件是資料庫支援自動增加的字段...