A. redis常見問題
1. 緩存擊穿
緩存擊穿是指一個請求要訪問的數據，緩存中沒有，但資料庫中有的情況。這種情況一般都是緩存過期了。
但是這時由於並發訪問這個緩存的用戶特別多，這是一個熱點 key，這么多用戶的請求同時過來，在緩存裡面沒有取到數據，所以又同時去訪問資料庫取數據，引起資料庫流量激增，壓力瞬間增大，直接崩潰給你看。
所以一個數據有緩存，每次請求都從緩存中快速的返回了數據，但是某個時間點緩存失效了，某個請求在緩存中沒有請求到數據，這時候我們就說這個請求就"擊穿"了緩存。
針對這個場景，對應的解決方案一般來說有三種。
藉助Redis setNX命令設置一個標志位就行。設置成功的放行，設置失敗的就輪詢等待。就是在更新緩存時加把鎖
後台開一個定時任務，專門主動更新過期數據
比如程序中設置 why 這個熱點 key 的時候，同時設置了過期時間為 10 分鍾，那後台程序在第 8 分鍾的時候，會去資料庫查詢數據並重新放到緩存中，同時再次設置緩存為 10 分鍾。
其實上面的後台續命思想的最終體現是也是永不過期。
只是後台續命的思想，會主動更新緩存，適用於緩存會變的場景。會出現緩存不一致的情況，取決於你的業務場景能接受多長時間的緩存不一致。
2. 緩存穿透
緩存穿透是指一個請求要訪問的數據，緩存和資料庫中都沒有，而用戶短時間、高密度的發起這樣的請求，每次都打到資料庫服務上，給資料庫造成了壓力。一般來說這樣的請求屬於惡意請求。
解決方案有兩種：
就是在資料庫即使沒有查詢到數據，我們也把這次請求當做 key 緩存起來，value 可以是 NULL。下次同樣請求就會命中這個 NULL，緩存層就處理了這個請求，不會對資料庫產生壓力。這樣實現起來簡單，開發成本很低。
3. 緩存雪崩
緩存雪崩是指緩存中大多數的數據在同一時間到達過期時間，而查詢數據量巨大，這時候，又是緩存中沒有，資料庫中有的情況了。
防止雪崩的方案簡單來說就是錯峰過期。
在設置 key 過期時間的時候，在加上一個短的隨機過期時間，這樣就能避免大量緩存在同一時間過期，引起的緩存雪崩。
如果發了雪崩，我們可以有服務降級、熔斷、限流手段來拒絕一些請求，保證服務的正常。但是，這些對用戶體驗是有一定影響的。
4. Redis 高可用架構
Redis 高可用架構，大家基本上都能想到主從、哨兵、集群這三種模式。
哨兵模式：
它主要執行三種類型的任務：
哨兵其實也是一個分布式系統，我們可以運行多個哨兵。
然後這些哨兵之間需要相互通氣，交流信息，通過投票來決定是否執行自動故障遷移，以及選擇哪個從伺服器作為新的主伺服器。
哨兵之間採用的協議是 gossip，是一種去中心化的協議，達成的是最終一致性。
選舉規則：
B. 如何保證資料庫緩存的最終一致性
對於互聯網業務來說，傳統的直接訪問資料庫方式，主要通過數據分片、一主多從等方式來扛住讀寫流量，但隨著數據量的積累和流量的激增，僅依賴資料庫來承接所有流量，不僅成本高、效率低、而且還伴隨著穩定性降低的風險。
鑒於大部分業務通常是讀多寫少（讀取頻率遠遠高於更新頻率），甚至存在讀操作數量高出寫操作多個數量級的情況。因此， 在架構設計中，常採用增加緩存層來提高系統的響應能力 ，提升數據讀寫性能、減少資料庫訪問壓力，從而提升業務的穩定性和訪問體驗。
根據 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」的方案。
C. 想了解緩存的概念
緩存
緩存就是指可以進行高速數據交換的存儲器，它先於內存與CPU交換數據，因此速度極快，所以又被稱為高速緩存。與處理器相關的緩存一般分為兩種——L1緩存，也稱內部緩存；和L2緩存，也稱外部緩存。例如Pentium4「Willamette」內核產品採用了423的針腳架構，具備400MHz的前端匯流排，擁有256KB全速二級緩存，8KB一級追蹤緩存，SSE2指令集。
內部緩存(L1 Cache)
也就是我們經常說的一級高速緩存。在CPU裡面內置了高速緩存可以提高CPU的運行效率，內置的L1高速緩存的容量和結構對CPU的性能影響較大，L1緩存越大，CPU工作時與存取速度較慢的L2緩存和內存間交換數據的次數越少，相對電腦的運算速度可以提高。不過高速緩沖存儲器均由靜態RAM組成，結構較復雜，在CPU管芯面積不能太大的情況下，L1級高速緩存的容量不可能做得太大，L1緩存的容量單位一般為KB。
外部緩存(L2 Cache)
CPU外部的高速緩存，外部緩存成本昂貴，所以Pentium 4 Willamette核心為外部緩存256K，但同樣核心的賽揚4代只有128K。
硬碟緩存越高,讀取速度越快
D. ae資料庫和緩存是啥
資料庫文件。ae資料庫會在用戶輸入後自動保存到磁碟中，ae資料庫和緩存的意思就是資料庫的文件，屬於自動備份的內容，用戶可以自行刪除。
E. 緩存是啥意思
緩存指的是將需要頻繁訪問的網路內容存放在離用戶最近、訪問速度更快的系統中，以提高內容訪問速度的一種技術。緩存伺服器就是存放頻繁訪問內容的伺服器。
幀緩沖存儲器(Frame Buffer)：簡稱幀緩存或顯存，它是屏幕所顯示畫面的一個直接映象，又稱為位映射圖(Bit Map)或光柵。幀緩存的每一存儲單元對應屏幕上的一個像素，整個幀緩存對應一幀圖像。
可刻錄CD或DVD驅動器一般具有2MB-4MB以上的大容量緩沖器，用於防止緩存欠載（buffer underrun）錯誤，同時可以使刻錄工作平穩、恆定的寫入。一般來說，驅動器越快，就有更多的緩沖存儲器，以處理更高的傳輸速率。
(5)緩存庫和成本庫擴展閱讀
緩存工作原理
1、讀取順序
CPU要讀取一個數據時，首先從Cache中查找，如果找到就立即讀取並送給CPU處理；如果沒有找到，就用相對慢的速度從內存中讀取並送給CPU處理，同時把這個數據所在的數據塊調入Cache中，可以使得以後對整塊數據的讀取都從Cache中進行，不必再調用內存。
正是這樣的讀取機制使CPU讀取Cache的命中率非常高（大多數CPU可達90%左右），也就是說CPU下一次要讀取的數據90%都在Cache中，只有大約10%需要從內存讀取。
這大大節省了CPU直接讀取內存的時間，也使CPU讀取數據時基本無需等待。總的來說，CPU讀取數據的順序是先Cache後內存。
2、緩存分類
Intel從Pentium開始將Cache分開，通常分為一級高速緩存L1和二級高速緩存L2。在以往的觀念中，L1 Cache是集成在CPU中的，被稱為片內Cache。在L1中還分數據Cache（D-Cache）和指令Cache（I-Cache）。
它們分別用來存放數據和執行這些數據的指令，而且兩個Cache可以同時被CPU訪問，減少了爭用Cache所造成的沖突，提高了處理器效能。
3、讀取命中率
CPU在Cache中找到有用的數據被稱為命中，當Cache中沒有CPU所需的數據時（這時稱為未命中），CPU才訪問內存。從理論上講，在一顆擁有2級Cache的CPU中，讀取L1 Cache的命中率為80%。
也就是說CPU從L1 Cache中找到的有用數據占數據總量的80%，剩下的20%從L2 Cache讀取。由於不能准確預測將要執行的數據，讀取L2的命中率也在80%左右（從L2讀到有用的數據占總數據的16%）。那麼還有的數據就不得不從內存調用，但這已經是一個相當小的比例了。
在一些高端領域的CPU（像Intel的Itanium）中，我們常聽到L3 Cache，它是為讀取L2 Cache後未命中的數據設計的—種Cache，在擁有L3 Cache的CPU中，只有約5%的數據需要從內存中調用，這進一步提高了CPU的效率。
F. 網站里的資料庫緩存是什麼清楚了對網站有什麼影響
比如說這個網站首頁有2張圖片及需要運算的XML或JSON格式的網頁資料庫，每次訪問都要下載10秒鍾，如果你開啟允許緩存，下次進入後，如果網站的數據尚未更新，就能減少等候那10秒鍾。
缺點是它保存在你的緩存區的 cookie 文件會涉及到個人隱私問題。詳細設置在菜單→工具→internet選項→隱私內的規則。所以有些網站強制性（不開啟許可權就不顯示網頁內容給你看）。
G. 緩存什麼意思啊詳細點，謝謝！
緩存是指臨時文件交換區，電腦把最常用的文件從
存儲器
里提出來臨時放在緩存里，就像把工具和材料搬上工作台一樣，這樣會比用時現去倉庫取更方便。因為緩存往往使用的是RAM（斷電即掉的非永久儲存），所以在忙完後還是會把文件送到
硬碟
等
存儲器
里永久存儲。電腦里最大的緩存就是
內存條
了，最快的是CPU上鑲的L1和L2緩存，
顯卡
的顯存是給GPU用的緩存，
硬碟
上也有16M或者32M的緩存。
千萬不能把緩存理解成一個東西，它是一種處理方式的統稱！
H. 談一談NSCache
NSCache介紹
NSCache是蘋果提供的一套緩存機制，與NSMutableDictionary可變字典的用法類似，常見於一些第三方庫，比如AFNetworking，SDWebImage。
使用場景：通常用使用緩存來臨時存儲短時間使用但創建昂貴的對象，優化性能，避免這些對象的多次創建 。
NSCache和NSMutableDictionary的區別
1、NSCache是線程安全的，不需要加線程鎖，而NSMutableDictionary線程不安全，多線程訪問和操作，需要我們自己設置管理。
2、NSCache的內存由系統管理，當內存不足時，NSCache會自動釋放內存。
3、NSCache可以設置緩存對象數量和佔用的內存大小，當緩存超出了設置，會自動釋放內存。
4、NSCache是Key-Value的數據結構，其中key是強引用，不實現NSCoping協議，作為key的對象不會被拷貝。
下面介紹NSCache的屬性、方法、代理
屬性
countLimit: 能夠緩存對象的最大數量，默認值是0，沒有限制（限制是不精/不嚴格的）。 totalCostLimit: 設置緩存佔用的內存大小（限制是不精/不嚴格的）。
: 是否回收廢棄內容，默認YES。
方法
setObject: forKey: 緩存對象。
setObject: forKey: cost: 緩存對象，並指定key值對應的成本，用於計算緩存中所有對象的總成本。
objectForKey: 通過key獲得緩存對象。
removeObjectForKey: 刪除指定對象removeAllObjects: 刪除所有緩存對象
代理（NSCacheDelegate）
willEvictObject: 緩存對象即將被清理時調用，一般開發者用來調試，不能在此方法中修改緩存
以下場景會被調用：
1、 removeObjectForKey
2、緩存對象超過NSCache的countLimit和otalCostLimit屬性設置的限制
3、App進入後台
4、系統發出內存警告
5、cache這個實例的生命周期結束前
NSCache注意點
1、當收到內存警告，而我們又調用removeAllObjects，則無法再繼續往緩存中添加數據。
-(void)didReceiveMemoryWarning{
[super didReceiveMemoryWarning];
// 當收到內存警告，在這里清除緩存
[self.cache removeAllObjects];
// 如果再繼續添加數據的話 會直接被刪除
}
2、不提供緩存總的大小，想知道NSCache佔用的內存大小，只有通過添加緩存的cost自己計算。
3、NSCache自動釋放內存的演算法是不確定的， 有時是按照LRU(最近最久未使用)釋放，有時隨機釋放。
4、NSCache中的數據在APP重啟後會消失，因為NSCache只是將數據保存在內存。
I. 安全庫存和緩存庫存的區別
安全庫存：為了避免物料供應商的原因而導致的延遲短缺等現象而建立的庫存
緩存庫存：為了應對自身原因而導致的需求增加而建立的庫存
特此答復，以正視聽！
J. .Net的Cache和Memcached有什麼優缺點
如果你的伺服器只有一台，且資料庫讀寫壓力不大，就沒必要使用Memcached。HttpRuntime.Cache是本地緩存，Memcached是分布式緩存，兩者的區別在於：
本地緩存
本地緩存可能是大家用的最多的一種緩存方式了，不管是本地內存還是磁碟，其速度快，成本低，在有些場合非常有效。
但是對於web系統的集群負載均衡結構來說，本地緩存使用起來就比較受限制，因為當資料庫數據發生變化時，你沒有一個簡單有效的方法去更新本地緩存；然而，你如果在不同的伺服器之間去同步本地緩存信息，由於緩存的低時效性和高訪問量的影響，其成本和性能恐怕都是難以接受的。
分布式緩存
前面提到過，本地緩存的使用很容易讓你的應用伺服器帶上「狀態」，這種情況下，數據同步的開銷09會比較大；尤其是在集群環境中更是如此！
分布式緩存這種東西存在的目的就是為了提供比RDB更高的TPS和擴展性，同時有幫你承擔了數據同步的痛苦；優秀的分布式緩存系統有大家所熟知的Memcached、Redis（當然也許你把它看成是NoSQL，但是我個人更願意把分布式緩存也看成是NoSQL），還有淘寶自主開發的Tair等。
對比關系型資料庫和緩存存儲，其在讀和寫性能上的差距可謂天壤之別；就拿淘寶的Tair來說，mdb引擎的單機QPS已在10w以上，ldb的也達到了5w~7w，而集群的性能會更高（目前uic所用的Tair集群QPS高達數十萬！）。
所以，在技術和業務都可以接受的情況下，我們可以盡量把讀寫壓力從資料庫轉移到緩存上，以保護看似強大，其實卻很脆弱的關系型資料庫。