在高併發請求時，為何我們頻繁提到快取技術？最直接的原因是，目前磁碟io和網路io相對於記憶體io的成百上千倍的效能劣勢。
做個簡單計算，如果我們需要某個資料，該資料從資料庫磁碟讀出來需要0.1s，從交換機傳過來需要0.05s，那麼每個請求完成最少0.15s（當然，事實上磁碟和網路io也沒有這麼慢，這裡只是舉例），該資料庫伺服器每秒只能響應67個請求；而如果該資料存在於本機記憶體裡，讀出來只需要10us，那麼每秒鐘能夠響應100，000個請求。
通過將高頻使用的資料存在離cpu更近的位置，以減少資料傳輸時間，從而提高處理效率，這就是快取的意義。
一切地方。例如：
我們從硬碟讀資料的時候，其實作業系統還額外把附近的資料都讀到了記憶體裡，例如，cpu在從記憶體裡讀資料的時候，也額外讀了許多資料到各級cache裡，各個輸入輸出之間用buffer儲存一批資料統一傳送和接受，而不是乙個byte乙個byte的處理，上面這是系統層面，在軟體系統設計層面，很多地方也用了快取：
資料庫會快取查詢，所以同一條查詢第二次就是要比第一次快
記憶體資料庫（如redis）選擇把大量資料存在記憶體而非硬碟裡，這可以看作是乙個大型快取，只是把整個資料庫快取了起來
應用程式把最近幾次計算的結果放在本地記憶體裡，如果下次到來的請求還是原請求，就跳過計算直接返回結果
一些常見的事故，系統又是怎麼設計的呢？
但是這個系統有兩個問題：
這時候，如果能在業務端做一層本地快取，直接把算好的資料本地存乙份，那麼就會極大減少網路和redis的壓力，不至於當場觸發熔斷了。
快取很有用，但是快取用不好也會埋很多坑：
快取穿透
快取穿透是說收到了乙個請求，但是該請求快取裡沒有，只能去資料庫裡查詢，然後放進快取。這裡面有兩個風險，乙個是同時有好多請求訪問同乙個資料，然後業務系統把這些請求全發到了資料庫；第二個是有人惡意構造乙個邏輯上不存在的資料，然後大量傳送這個請求，這樣每次請求都會被傳送到資料庫，可能導致資料掛掉。
怎麼應對這種情況呢？對於惡意訪問，乙個思路是事先做校驗，對惡意資料直接過濾掉，不要發到資料庫層；第二個思路是快取空結果，就是對查詢不存在的資料仍然記錄一條該資料不存在在快取裡，這樣能有效的減少查詢資料庫的次數。
那麼非惡意訪問呢？這個要結合快取擊穿來講。
快取擊穿
上面提到的某個資料沒有，然後好多請求都被發到資料庫其實可以歸為快取擊穿的範疇：對於熱點資料，當資料失效的一瞬間，所有請求都被下放到資料庫去請求更新快取，資料庫被壓垮。
怎麼防範這種問題呢？乙個思路是全域性鎖，就是所有訪問某個資料的請求都共享乙個鎖，獲得鎖的那個才有資格去訪問資料庫，其他執行緒必須等待。但是現在的業務都是分布式的，本地鎖沒法控制其他伺服器也等待，所以要用到全域性鎖，比如用redis的setnx實現全域性鎖。
另乙個思路是對即將過期的資料主動重新整理，做法可以有很多，比如起乙個執行緒輪詢資料，比如把所有資料劃分為不同的快取區間，定期分區間重新整理資料等等。這第二個思路又和我們接下來要講的快取雪崩有關係。
快取雪崩
快取雪崩是指比如我們給所有的資料設定了同樣的過期時間，然後在某乙個歷史性時刻，整個快取的資料全部過期了，然後瞬間所有的請求都被打到了資料庫，資料庫就崩了。
解決思路要麼是分治，劃分更小的快取區間，按區間過期；要麼是給每個key的過期時間加個隨機值，避免同時過期，達到錯峰重新整理快取的目的。
快取重新整理
說到重新整理快取，其實也有坑的。比如我之前的乙份工作裡，有一次大活動，正是如火如荼的時候，所有的廣告位突然都變空白了。後來追查原因，所有的廣告素材都在快取裡，然後起了個程式，專門負責重新整理快取，每次把當前的素材全量重新整理。
壞就壞在這個全量上。因為大活動的時候流量極大，廣告更新壓力也很大，把負責提供更新素材的程式壓崩了。重新整理快取的程式在請求時，收到了乙個返回結果null。接下來就喜聞樂見了，重新整理程式根據這個null，清空了整個快取，所有廣告素材都失效了。
總之，想要做好高併發系統的快取，就要考慮到各種邊角情況，小心設計，任何細小的疏忽都可能導致系統崩潰。
專案那些事兒 專案哪些事兒？
專案那些事兒 專案哪些事兒？36kr，鳴謝 專案上有很多事兒。說起專案管理，常想到的是那 金三角 時間 範圍 成本 這是平面上看待的專案管理，簡單描述就是 在什麼時間內你要花多少人力來幹出個什麼事兒來。專案上會遇到很多問題，管理問題 技術問題 人員問題等等 其中專案中常遇到的問題，十有 是溝通上的事...
專案啟動那些事兒
專案啟動會議，標誌乙個專案的正式開始。那在這之前，我們通常做哪些準備工作？其實可以用一句話概括 專案經理必須知道專案的關鍵驅動因素是什麼 專案怎樣才算 完成 而且要把這些結論寫到專案章程中，讓專案團隊都能瞭如指掌。明白上面這句話，其實不難。首先，我們來看看什麼是專案。pmbok裡的定義是為創造獨特的...
《IT專案管理那些事兒》 前言
關於本書 1968年為了解決大型軟體專案的軟體危機，北大西洋公約組織 nato 提出了 軟體工程 這一術語，以改進軟體開發設計過程。1969年美國專案管理協會 pmi 組織成立，從1981年起經過30年的努力形成了目前看到的專案管理知識體系 pmbok 即五大過程和九個知識域，通過評估專案管理人員的...