|
|
在《NoSQL架構實踐》系列的前面兩篇文章中，介紹了《以NoSQL為主》和《以NoSQL為輔》的架構。由于NoSQL數據庫天生具有高性能、易擴展的特點，所以我們常常結合關系數據庫，存儲一些高性能的、海量的數據。從另外一個角度看，根據NoSQL的高性能特點，它同樣適合用于緩存數據。用NoSQL緩存數據可以分為內存模式和磁盤持久化模式。
內存模式
說起內存模式緩存，我們自然就會想起大名鼎鼎的Memcached。在互聯網發展過程中，Memcached曾經解救了數據庫的大部分壓力，做出了巨大的貢獻，直到今天，它依然是緩存服務器的首選。Memcached的常見使用方式類似下面的代碼：
Memcached提供了相當高的讀寫性能，一般情況下，都足夠應付應用的性能要求。但是基于內存的Memcached緩存的總數據大小受限于內存的大小。
當前如日中天、討論得異常火熱的NoSQL數據庫Redis又為我們提供了功能更加強大的內存存儲功能。跟Memcached比，Redis的一個key的可以存儲多種數據結構Strings、Hashes、Lists、Sets、Sorted sets。Redis不但功能強大，而且它的性能完全超越大名鼎鼎的Memcached。Redis支持List、hashes等多種數據結構的功能，提供了更加易于使用的api和操作性能，比如對緩存的list數據的修改。
同樣，其他一些NoSQL數據庫也提供了內存存儲的功能，所以也適合用來做內存緩存。比如Tokyo Tyrant就提供了內存hash數據庫、內存tree數據庫功能，內存tree數據可根據key的順序進行遍歷。你可以通過使用其提供的兼容Memcached協議或自定義的協議來使用。
持久化模式
雖然基于內存的緩存服務器具有高性能，低延遲的特點，但是內存成本高、內存數據易失卻不容忽視。幾十GB內存的服務器，在很多公司看來，還比較奢侈。所以，我們應該根據應用的特點，盡量的提高內存的利用率，降低成本。
大部分互聯網應用的特點都是數據訪問有熱點，也就是說，只有一部分數據是被頻繁訪問的。如果全部都cache到內存中，無疑是對內存的浪費。
這時，我們可以利用NoSQL來做數據的緩存。其實NoSQL數據庫內部也是通過內存緩存來提高性能的，通過一些比較好的算法，把熱點數據進行內存cache，非熱點數據存儲到磁盤以節省內存占用。由于其數據庫結構的簡單，從磁盤獲取一次數 據也比從數據庫一次耗時的查詢劃算很多。用NoSQL數據庫做緩存服務器不但具有不錯的性能。而且還能夠Cache比內存大的數據。
使用NoSQL來做緩存，由于其不受內存大小的限制，我們可以把一些不常訪問、不怎么更新的數據也緩存起來。比如論壇、新聞的老數據、數據列表的靠后的頁面，雖然用戶訪問不多，但是搜索引擎爬蟲會訪問，也可能導致系統負載上升。
如果NoSQL持久化緩存也使用類似基于內存的memcached設置過期時間的方式，那么持久化緩存就失去了意義。所以用NoSQL做緩存的過期策略最好不使用時間過期，而是數據是否被更新過，如果數據沒有更新，那么就永久不過期。下面我們用代碼(php)演示一種實現這種策略的方法：
場景：新聞站點的評論系統。用戶對新聞頁面的url進行評論，然后根據url進行查詢展示。
我把上面代碼演示的緩存使用方式稱為基于版本的緩存。這種方式同樣適用于基于內存的Memcached。它能實現緩存數據的實時性，讓用戶感覺不到延遲。只要用戶一發表評論，該新聞的評論緩存就會失效。用戶很少去評論一些過時的新聞，那么緩存就一直存在于NoSQL中，避免了爬蟲訪問過時新聞的評論數據而沖擊數據庫。
總結
目前國內的新浪微博已經在大量的使用Redis緩存數據，趕集網也在大量的使用Redis。Redis作為一些List，Hashes等數據結構的緩存，非常適合。
把NoSQL當持久化Cache使用的模式，在很多大數據量、有熱點、查詢非熱點數據比較消耗資源的場景下比較有用。
NoSQL架構實踐總結
到這里，關于NoSQL架構實踐的三篇文章就結束了。NoSQL架構并不局限于我介紹的三種模式，他們之間也可以進行組合，應該根據你具體的應用場景靈活使用。不管是什么模式，都是為了解決我們的問題而出現的，所以在系統架構的時候，要問下自己，我為什么要用NoSQL；在對NoSQL架構模式選型的時候，要問下自己，我為什么要這么用NoSQL。
參考鏈接：
- 關于Redis的一些介紹： http://blog.nosqlfan.com/tags/redis
- 分布式緩存還是NoSQL（英文）： http://goo.gl/VLECa
- NoSQL微群： http://q.t.sina.com.cn/127870
- 我的微博： http://t.sina.com.cn/sunli1223
it知識庫：NoSQL架構實踐（三）——以NoSQL為緩存，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
