她剪了短髮快取的收益和成本好像溫柔了許多
好像過的很好
好像也沒那麼好
其實我也不知道
我已經很久沒有見過她了。
快取可能會出現的問題
無論是大廠小廠，在專案開發過程中，快取肯定是離不開的，重要性也毋庸置疑。作為高頻面試題，無論是為了應付面試，還是為了學到東西，都必須要認真對待。
完全基於記憶體，絕大部分請求是純粹的記憶體操作，非常快速。資料存在記憶體中，類似於hashmap，hashmap的優勢就是查詢和操作的時間複雜度都是o(1)。
資料結構簡單，對資料操作也簡單，redis中的資料結構是專門進行設計的。
採用單執行緒，避免了不必要的上下文切換和競爭條件，也不存在多程序或者多執行緒導致的切換而消耗 cpu，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導致的效能消耗。
使用多路i/o復用模型（多個網路連線復用乙個執行緒，可以讓單個執行緒高效的處理多個連線請求），非阻塞io。
使用底層模型不同，它們之間底層實現方式以及與客戶端之間通訊的應用協議不一樣，redis直接自己構建了vm 機制 ，因為一般的系統呼叫系統函式的話，會浪費一定的時間去移動和請求。
org.springframework.boot<
/groupid>
spring-boot-starter-cache<
/artifactid>
<
/dependency>
//配置類新增註解
@enablecaching
//一般作用在查方法上
//在執行方法前先檢視快取中是否有資料，如果有資料，則直接返回快取資料；若沒有資料，執行該方法並將方法返回值放進快取。
//引數： value快取名、 key快取鍵值、 condition滿足快取條件、unless否決快取條件
@cacheable
//一般作用於增加修改方法
//和 @cacheable 類似，但會把方法的返回值放入快取中
@cacheput
//一般作用於刪除方法上
//方法執行成功後會從快取中移除相應資料。
//value快取名、 key快取鍵值、 condition滿足快取條件、 unless否決快取條件、 allentries是否移除所有資料（設定為true時會移除所有快取）
@cacheevict
無法設定過期時間，預設過期時間為永久不過期------自定義cachemanager，設定快取過期時間
配置序列化方式，預設的是序列化jdkserialazable------配置類自定義序列化方式
在搭建完集群環境後，不得不考慮的乙個問題就是使用者訪問產生的session如何處理。如果不做任何處理的話，使用者將出現頻繁登入的現象，比如集群中存在a、b兩台伺服器，使用者在第一次訪問**時，nginx通過其負載均衡機制將使用者請求**到a伺服器，這時a伺服器就會給使用者建立乙個session。當使用者第二次傳送請求時，nginx將其負載均衡到b伺服器，而這時候b伺服器並不存在session，所以就會將使用者踢到登入頁面。這將大大降低使用者體驗度，導致使用者的流失，這種情況是專案絕不應該出現的。
我們應當對產生的session進行處理，通過粘性session，session複製或session共享等方式保證使用者的體驗度。
使用redis共享session
org.springframework.session<
/groupid>
spring-session-data-redis<
/artifactid>
<
/dependency>
//引數設定快取時間
50)
spring:session:sessions:expires:
+『sessionid』
降低後端負載------降低關係型資料庫負載壓力
資料不一致------更新策略有問題將導致快取資料和資料庫資料不一致問題
**維護成本------不僅要維護資料庫，還要維護快取
堆內快取記憶體溢位------一般快取方式分為堆內快取和遠端伺服器快取（redis），堆內快取效能更高，不需要進行網路傳輸，遠端快取需要套接字傳輸。使用者級別快取建議遠端快取，大資料量建議遠端快取，服務節點化原則。
如果快取集中在一段時間內失效，發生大量的快取穿透，所有的查詢都落在資料庫上，造成了快取雪崩。
由於原有快取失效，新快取未到期間所有原本應該訪問快取的請求都去查詢資料庫了，而對資料庫cpu 和記憶體造成巨大壓力，嚴重的會造成資料庫宕機。
◆解決
加鎖排隊------排斥鎖
資料預熱------可以通過快取reload機制，預先去更新快取，再即將發生大併發訪問前手動觸發載入快取不同的key。
雙層快取策略------c1為原始快取，c2為拷貝快取，c1失效時，可以訪問c2，c1快取失效時間設定為短期，c2設定為長期。
定時更新快取策略------ 失效性要求不高的快取，容器啟動初始化載入，採用定時任務更新或移除快取。
設定不同的過期時間------讓快取失效的時間點盡量均勻
詳細說一下加鎖排隊
即第乙個執行緒過來讀取cache，發現沒有，就去訪問db。後續執行緒再過來就需要等待第乙個執行緒讀取db成功，cache裡的value變得可用，後續執行緒返回新的value。
用到了加鎖排隊，吞吐率是不高的。僅適用於併發量不大的場景。
偽**
public object getcachevalue
(string key,
int expiredtime)
else
else}}
finally
return cachevalue;
}}
這裡需要注意和快取擊穿的區別，快取擊穿，是指乙個key非常熱點，在不停的扛著大併發，大併發集中對這乙個點進行訪問，當這個key在失效的瞬間，持續的大併發就穿破快取，直接請求資料庫，就像在乙個屏障上鑿開了乙個洞。
◆解決
快取空物件------如果乙個查詢返回的資料為空，我們仍然把這個空結果進行快取，但它的過期時間會很短，最長不超過五分鐘。 通過這個直接設定的預設值存放到快取，這樣第二次到緩衝中獲取就有值了，而不會繼續訪問資料庫。
布隆過濾器------將所有可能存在的資料雜湊到乙個足夠大的 bitmap 中，乙個一定不存在的資料會被這個bitmap 攔截掉，從而避免了對底層儲存系統的查詢壓力（類似set），為什麼不用set?因為布隆過濾器占用記憶體空間很小，bit儲存。效能特別高。
你還不了解的OKRs E是什麼？
2020年，okr目標管理法成為80 企業都開始關注的企業管理方法。一方面因為環境原因，跨地域辦公這種工作模式開始被考慮如何更好的去執行，另一方面okr本身能夠從員工的層面來改變整個企業，因為企業的根本還是大部分普通員工。okr是目標與關鍵成果，這是很多人都已經知道的部分，但能讓okr具體到實際執行...
Redis高階不得不了解的記憶體優化細節
宣告 本文內容來自 redis開發與運維 一書第八章。redis所有的資料都在記憶體中，而記憶體又是非常寶貴的資源。對於如何優化記憶體使用一直是redis使用者非常關注的問題。本文讓我們深入到redis細節中，學習記憶體優化的技巧。分為如下幾個部分 一.redisobject物件 二.縮減鍵值物件 ...
Redis高階不得不了解的記憶體優化細節
宣告 本文內容來自 redis開發與運維 一書第八章。redis所有的資料都在記憶體中，而記憶體又是非常寶貴的資源。對於如何優化記憶體使用一直是redis使用者非常關注的問題。本文讓我們深入到redis細節中，學習記憶體優化的技巧。分為如下幾個部分 一.redisobject物件 二.縮減鍵值物件 ...