一、簡介：
在過去的幾年中，NoSQL數據庫一度成為高並發、海量數據存儲解決方案的代名詞，與之相應的產品也呈現出雨後春筍般的生機。然而在眾多產品中能夠脫穎而出的卻屈指可數，如Redis、MongoDB、BerkeleyDB和CouchDB等。由於每種產品所擁有的特征不同，因此它們的應用場景也存在著一定的差異，下面僅給出簡單的說明：
1). BerkeleyDB是一種極為流行的開源嵌入式數據庫，在更多情況下可用於存儲引擎，比如BerkeleyDB在被Oracle收購之前曾作為MySQL的存儲引擎，由此可以預見，該產品擁有極好的並發伸縮性，支持事務及嵌套事務，海量數據存儲等重要特征，在用於存儲實時數據方面具有極高的可用價值。然而需要指出的是，該產品的Licence為GPL，這就意味著它並不是在所有情況下都是免費使用的。
2). 對MongoDB的定義為Oriented-Document數據庫服務器，和BerkeleyDB不同的是該數據庫可以像其他關系型數據庫服務器那樣獨立的運行並提供相關的數據服務。從該產品的官方文檔中我們可以獲悉，MongoDB主要適用於高並發的論壇或博客網站，這些網站具有的主要特征是並發訪問量高、多讀少寫、數據量大、邏輯關系簡單，以及文檔數據作為主要數據源等。和BerkeleyDB一樣，該產品的License同為GPL。
3). Redis，典型的NoSQL數據庫服務器，和BerkeleyDB相比，它可以作為服務程序獨立運行於自己的服務器主機。在很多時候，人們只是將Redis視為Key/Value數據庫服務器，然而事實並非如此，在目前的版本中，Redis除了Key/Value之外還支持List、Hash、Set和Ordered Set等數據結構，因此它的用途也更為寬泛。對於此種誤解，Redis官網也進行了相應的澄清。和以上兩種產品不同的是，Redis的License是Apache License，就目前而言，它是完全免費。
4). memcached，數據緩存服務器。為什麼在這裡要給出該產品的解釋呢？很簡單，因為筆者認為它在使用方式上和Redis最為相似。畢竟這是一篇關於Redis的技術系列博客，有鑒於此，我們將簡要的對比一下這兩個產品。首先說一下它們之間的最大區別，memcached只是提供了數據緩存服務，一旦服務器宕機，之前在內存中緩存的數據也將全部消失，因此可以看出memcached沒有提供任何形式的數據持久化功能，而Redis則提供了這樣的功能。再有就是Redis提供了更為豐富的數據存儲結構，如Hash和Set。至於它們的相同點，主要有兩個，一是完全免費，再有就是它們的提供的命令形式極為接近。
二、Redis的優勢：
1). 和其他NoSQL產品相比，Redis的易用性極高，因此對於那些有類似產品使用經驗的開發者來說，一兩天，甚至是幾個小時之後就可以利用Redis來搭建自己的平台了。
2). 在解決了很多通用性問題的同時，也為一些個性化問題提供了相關的解決方案，如索引引擎、統計排名、消息隊列服務等。
三、目前版本中Redis存在的主要問題：
1). 在官方版本中沒有提供Windows平台的支持，已發布的正式版本中只是支持類Unix和MacOSX平台。
2). 沒有提供集群的支持，然而據官網所述，預計在2.6版本中會加入該特征。
3). Publication/Subscription功能中，如果master宕機，slave無法自動提升為master。
四、和關系型數據庫的比較：
在目前版本(2.4.7)的Redis中，提供了對五種不同數據類型的支持，其中只有一種類型，既string類型可以被視為Key-Value結構，而其他的數據類型均有適用於各自特征的應用場景，至於具體細節我們將會在該系列後面的博客中予以說明。
相比於關系型數據庫，由於其存儲結構相對簡單，因此Redis並不能對復雜的邏輯關系提供很好的支持，然而在適用於Redis的場景中，我們卻可以由此而獲得效率上的顯著提升。即便如此，Redis還是為我們提供了一些數據庫應該具有的基礎概念，如：在同一連接中可以選擇打開不同的數據庫，然而不同的是，Redis中的數據庫是通過數字來進行命名的，缺省情況下打開的數據庫為0。如果程序在運行過程中打算切換數據庫，可以使用Redis的select命令來打開其他數據庫，如select 1，如果此後還想再切換回缺省數據庫，只需執行select 0即可。
在數據存儲方面，Redis遵循了現有NoSQL數據庫的主流思想，即Key作為數據檢索的唯一標識，我們可以將其簡單的理解為關系型數據庫中索引的鍵，而Value則作為數據存儲的主要對象，其中每一個Value都有一個Key與之關聯，這就好比索引中物理數據在數據表中存儲的位置。在Redis中，Value將被視為二進制字節流用於存儲任何格式的數據，如Json、XML和序列化對象的字節流等，因此我們也可以將其想象為RDB中的BLOB類型字段。由此可見，在進行數據查詢時，我們只能基於Key作為我們查詢的條件，當然我們也可以應用Redis中提供的一些技巧將Value作為其他數據的Key，這些知識我們都會在後面的博客中予以介紹。
五、如何持久化內存數據：
缺省情況下，Redis會參照當前數據庫中數據被修改的數量，在達到一定的阈值後會將數據庫的快照存儲到磁盤上，這一點我們可以通過配置文件來設定該阈值。通常情況下，我們也可以將Redis設定為定時保存。如當有1000個以上的鍵數據被修改時，Redis將每隔60秒進行一次數據持久化操作。缺省設置為，如果有9個或9個以下數據修改是，Redis將每15分鐘持久化一次。
從上面提到的方案中可以看出，如果采用該方式，Redis的運行時效率將會是非常高效的，既每當有新的數據修改發生時，僅僅是內存中的緩存數據發生改變，而這樣的改變並不會被立即持久化到磁盤上，從而在絕大多數的修改操作中避免了磁盤IO的發生。然而事情往往是存在其兩面性的，在該方法中我們確實得到了效率上的提升，但是卻失去了數據可靠性。如果在內存快照被持久化到磁盤之前，Redis所在的服務器出現宕機，那麼這些未寫入到磁盤的已修改數據都將丟失。為了保證數據的高可靠性，Redis還提供了另外一種數據持久化機制--Append模式。如果Redis服務器被配置為該方式，那麼每當有數據修改發生時，都會被立即持久化到磁盤。
