一..memcache應用場景

1.應用場景一： 緩解數據庫壓力，提高交互速度。它的一個總原則是將經常需要從數據庫讀取的數據緩存在memcached中。這些數據也分為幾類：

(1)、經常被讀取并且實時性要求不強可以等到自動過期的數據。例如網站首頁最新文章列表、某某排行等數據。也就是雖然新數據產生了，但對用戶體驗不會產生任何影響的場景。

這類數據就使用典型的緩存策略，設置一過合理的過期時間，當數據過期以后再從數據庫中讀取。當然你得制定一個緩存清除策略，便于編輯或者其它人員能馬上看到效果。

(2)、經常被讀取并且實時性要求強的數據。比如用戶的好友列表，用戶文章列表，用戶閱讀記錄等。

這類數據首先被載入到memcached中，當發生更改(添加、修改、刪除)時就清除緩存。在緩存的時候，我將查詢的SQL語句md5()得到它的

hash值作為key,結果數組作為值寫入memcached，并且將該SQL涉及的table_name以及hash值配對存入memcached中。

當更改了這個表時，我就將與此表相配對的key的緩存全部刪除。

(3)、統計類緩存，比如文章瀏覽數、網站PV等

此類緩存是將在數據庫的中來累加的數據放在memcached來累加。獲取也通過memcached來獲取。但這樣就產生了一個問題，如果

memcached服務器down 掉的話這些數據就有可能丟失，所以一般使用memcached的永固性存儲，這方面新浪使用memcachedb。

(4)、活躍用戶的基本信息或者某篇熱門文章。

此類數據的一個特點就是數據都是一行，也就是一個一維數組，當數據被update時(比如修改昵稱、文章的評論數)，在更改數據庫數據的同時，使用Memcache::replace替換掉緩存里的數據。這樣就有效了避免了再次查詢數據庫。

(5)、session數據

使用memcached來存儲session的效率是最高的。memcached本身也是非常穩定的，不太用擔心它會突然down掉引起session數據的丟失，即使丟失就重新登錄了，也沒啥。

(6)、冷熱數據交互

在做高訪問量的sns應用，比如貼吧和論壇，由于其數據量大，往往采用了分表分庫的策略，但真正的熱數據僅僅是前兩三頁的100條數據，這時，我們就可以把這100條數據，在寫進數據庫之后，同時作為memcache的緩存熱數據來使用。

通過以上的策略數據庫的壓力將會被大大減輕。檢驗你使用memcached是否得當的方法是查看memcached的命中率。有些策略好的網站的命中率可以到達到90%以上。后續本專題也會討論一下memcache的分布式算法,提高其命中率;

2.應用場景二： 秒殺功能。

其實，本場景嚴格的說應該也屬于場景一，單獨拎出來說是由于其廣泛的應用性。

一個人下單，要牽涉數據庫讀取，寫入訂單，更改庫存，及事務要求， 對于傳統型數據庫來說，壓力是巨大的。

可以利用 memcached 的 incr/decr 功能， 在內存存儲 count 庫存量， 秒殺 1000 臺每人搶單主要在內存操作，速度非常快，搶到 count < =1000 的號人，得一個訂單號，這時再去另一個頁面慢慢支付。

3.應用場景三：中繼 MySQL 主從延遲數據

摘自"http://www.cnblogs.com/nixi8/p/4934009.html"；

二。memcache?存儲原理

i.Memcache采用鍵值對存儲方式。它本質是一個大的 hash表，key的最大長度為255個字符，最長過期時間為30天。

ii. 它的內存模型如下：Memcache預先將可支配的內存空間進行分區(Slab)，每個分區里再分為多個塊(Chunk)最大1M，但同一個分區中塊的大 小是固定的。然后，插入數據時，會根據數據大小尋找最合適的塊，然后插入，當然這樣也就會有部分內存浪費，但可一定程度上減少內存碎片，總體上，利大于 弊。當Memcache的內存滿后，它清除舊數據的原則為：LRU閑置>過期>最少訪問。而且它采用的是惰性刪除，它并沒有提供監控數據過期 的機制，而是惰性的，當查詢到某個key的數據時，如果過期，那么直接拋棄

三.常見BUG及解決辦法

1.緩存雪崩

一般是由于某個節點失效，導致其它節點的緩存命中率下降，緩存中缺失的數據直接去數據庫查詢，短時間內造成數據庫服務器崩潰。

或者是由于緩存周期性失效，比如設置每隔6個小時失效一次，那么每6個小時將會有一個請求峰值，嚴重的話，也會導致數據庫崩潰。

重啟DB后，短期內又被壓垮，但緩存又會恢復一點，DB反復重啟多次，直至緩存重建完畢，才能恢復穩定。

2.永久數據被踢

(1).數據在內存中失效后，并不會立馬被刪除，只有在下次get時候，系統才會將其刪除。 Memcache可以因此，被一些未被及時刪除的數據占滿空間。加之LRU淘汰機制，永久數據如果很少被訪問的話，在內存空間被占滿的情況下，再有新數據被緩存，則永久數據，就有可能被刪除。

(2).解決方案：

永久數據和非永久數據分開放。

3.Cache失效后的擁堵問題

(1).通常我們會為兩種數據做Cache，一種是熱數據，也就是說短時間內有很多人訪問的數據；另一種是高成本的數據，也就說查詢很很耗時的數據。當這些數據過 期的瞬間，如果大量請求同時到達，那么它們會一起請求后端重建Cache，造成擁堵問題，就好象在北京上班做地鐵似的，英文稱之為：stampeding herd，老外這里的用詞還是很形象的。

(2).一般有如下幾種解決思路可供選擇：

首先，我們可以主動更新Cache。前端程序里不涉及重建Cache的職責，所有相關邏輯都由后端獨立的程序(比如CRON腳本)來完成，但此方法并不適應所有的需求。還有一些特殊情況沒有考慮到：設想一下服務重啟；或者某個Cache里原本沒有的冷數據因為某些情況突然轉換成熱數據；又或者由于LRU機制導致某些鍵被

意外刪除，等等，這些情況都可能會讓上面的方法失效，因為在這些情況里就不存在所謂的舊數據，等待用戶的將是一個空頁面。

好在我們還有Gearman這根救命稻草。當需要更新Cache的時候，我們不再直接查詢數據庫，而是把任務拋給Gearman來處理，當并發量比較大的時候，Gearman內部的優化可以保證相同的請求只查詢一次后端數據庫

4.Multiget的無底洞問題

(1)只 要保證Multiget中的鍵只出現在一臺服務器上即可！比如說用戶名字(user:foo:name)，用戶年齡(user:foo:age)等數據在 散列到多臺服務器上時，不應按照完整的鍵名(user:foo:name和user:foo:age)來散列的，而應按照特殊的鍵(foo)來散列的

5.緩存無底洞

(1).一個較為簡單的解決方案：

NoSQL和傳統的RDBMS，并不是水火不容，兩者在某些設計上，是可以相互參考的。對于memcached,Redis,這種kv存儲，key的設計，可以參考MySQL中表與列的設計。

比如：user表下有age列,name列,身高列，對應的key，可以用user:133:age=23,user:133:name=’lisi’,user:133:height=168;

可以將某一組key，按其共同前綴來分布，比如按照’user-133’來計算，而不是以user-133-age，user-133-name，user-133-height來計算，這樣3個關于個人信息的key，都落在同一個節點，訪問個人主頁時，只需連接一個節點

.

總結

以上是生活随笔為你收集整理的mysql memcached 使用场景_memcache 应用场景的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。