一、簡介：

在過去的幾年中，NoSQL數(shù)據(jù)庫一度成為高并發(fā)、海量數(shù)據(jù)存儲解決方案的代名詞，與之相應(yīng)的產(chǎn)品也呈現(xiàn)出雨后春筍般的生機(jī)。然而在眾多產(chǎn)品中能夠脫穎而出的卻屈指可數(shù)，如Redis、MongoDB、BerkeleyDB和CouchDB等。由于每種產(chǎn)品所擁有的特征不同，因此它們的應(yīng)用場景也存在著一定的差異，下面僅給出簡單的說明：

1). BerkeleyDB是一種極為流行的開源嵌入式數(shù)據(jù)庫，在更多情況下可用于存儲引擎，比如BerkeleyDB在被Oracle收購之前曾作為MySQL的存儲引擎，由此可以預(yù)見，該產(chǎn)品擁有極好的并發(fā)伸縮性，支持事務(wù)及嵌套事務(wù)，海量數(shù)據(jù)存儲等重要特征，在用于存儲實(shí)時數(shù)據(jù)方面具有極高的可用價值。然而需要指出的是，該產(chǎn)品的Licence為GPL，這就意味著它并不是在所有情況下都是免費(fèi)使用的。

2). 對MongoDB的定義為Oriented-Document數(shù)據(jù)庫服務(wù)器，和BerkeleyDB不同的是該數(shù)據(jù)庫可以像其他關(guān)系型數(shù)據(jù)庫服務(wù)器那樣獨(dú)立的運(yùn)行并提供相關(guān)的數(shù)據(jù)服務(wù)。從該產(chǎn)品的官方文檔中我們可以獲悉，MongoDB主要適用于高并發(fā)的論壇或博客網(wǎng)站，這些網(wǎng)站具有的主要特征是并發(fā)訪問量高、多讀少寫、數(shù)據(jù)量大、邏輯關(guān)系簡單，以及文檔數(shù)據(jù)作為主要數(shù)據(jù)源等。和BerkeleyDB一樣，該產(chǎn)品的License同為GPL。

3). Redis，典型的NoSQL數(shù)據(jù)庫服務(wù)器，和BerkeleyDB相比，它可以作為服務(wù)程序獨(dú)立運(yùn)行于自己的服務(wù)器主機(jī)。在很多時候，人們只是將Redis視為Key/Value數(shù)據(jù)庫服務(wù)器，然而事實(shí)并非如此，在目前的版本中，Redis除了Key/Value之外還支持List、Hash、Set和Ordered Set等數(shù)據(jù)結(jié)構(gòu)，因此它的用途也更為寬泛。對于此種誤解，Redis官網(wǎng)也進(jìn)行了相應(yīng)的澄清。和以上兩種產(chǎn)品不同的是，Redis的License是Apache License，就目前而言，它是完全免費(fèi)。

4). memcached，數(shù)據(jù)緩存服務(wù)器。為什么在這里要給出該產(chǎn)品的解釋呢？很簡單，因?yàn)楣P者認(rèn)為它在使用方式上和Redis最為相似。畢竟這是一篇關(guān)于Redis的技術(shù)系列博客，有鑒于此，我們將簡要的對比一下這兩個產(chǎn)品。首先說一下它們之間的最大區(qū)別，memcached只是提供了數(shù)據(jù)緩存服務(wù)，一旦服務(wù)器宕機(jī)，之前在內(nèi)存中緩存的數(shù)據(jù)也將全部消失，因此可以看出memcached沒有提供任何形式的數(shù)據(jù)持久化功能，而Redis則提供了這樣的功能。再有就是Redis提供了更為豐富的數(shù)據(jù)存儲結(jié)構(gòu)，如Hash和Set。至于它們的相同點(diǎn)，主要有兩個，一是完全免費(fèi)，再有就是它們的提供的命令形式極為接近。
   
二、Redis的優(yōu)勢：

      1). 和其他NoSQL產(chǎn)品相比，Redis的易用性極高，因此對于那些有類似產(chǎn)品使用經(jīng)驗(yàn)的開發(fā)者來說，一兩天，甚至是幾個小時之后就可以利用Redis來搭建自己的平臺了。
      2). 在解決了很多通用性問題的同時，也為一些個性化問題提供了相關(guān)的解決方案，如索引引擎、統(tǒng)計排名、消息隊(duì)列服務(wù)等。

三、目前版本中Redis存在的主要問題：

      1). 在官方版本中沒有提供Windows平臺的支持，已發(fā)布的正式版本中只是支持類Unix和MacOSX平臺。
      2). 沒有提供集群的支持，然而據(jù)官網(wǎng)所述，預(yù)計在2.6版本中會加入該特征。
      3). Publication/Subscription功能中，如果master宕機(jī)，slave無法自動提升為master。
   
四、和關(guān)系型數(shù)據(jù)庫的比較：

      在目前版本(2.4.7)的Redis中，提供了對五種不同數(shù)據(jù)類型的支持，其中只有一種類型，既string類型可以被視為Key-Value結(jié)構(gòu)，而其他的數(shù)據(jù)類型均有適用于各自特征的應(yīng)用場景，至于具體細(xì)節(jié)我們將會在該系列后面的博客中予以說明。
      相比于關(guān)系型數(shù)據(jù)庫，由于其存儲結(jié)構(gòu)相對簡單，因此Redis并不能對復(fù)雜的邏輯關(guān)系提供很好的支持，然而在適用于Redis的場景中，我們卻可以由此而獲得效率上的顯著提升。即便如此，Redis還是為我們提供了一些數(shù)據(jù)庫應(yīng)該具有的基礎(chǔ)概念，如：在同一連接中可以選擇打開不同的數(shù)據(jù)庫，然而不同的是，Redis中的數(shù)據(jù)庫是通過數(shù)字來進(jìn)行命名的，缺省情況下打開的數(shù)據(jù)庫為0。如果程序在運(yùn)行過程中打算切換數(shù)據(jù)庫，可以使用Redis的select命令來打開其他數(shù)據(jù)庫，如select 1，如果此后還想再切換回缺省數(shù)據(jù)庫，只需執(zhí)行select 0即可。
      在數(shù)據(jù)存儲方面，Redis遵循了現(xiàn)有NoSQL數(shù)據(jù)庫的主流思想，即Key作為數(shù)據(jù)檢索的唯一標(biāo)識，我們可以將其簡單的理解為關(guān)系型數(shù)據(jù)庫中索引的鍵，而Value則作為數(shù)據(jù)存儲的主要對象，其中每一個Value都有一個Key與之關(guān)聯(lián)，這就好比索引中物理數(shù)據(jù)在數(shù)據(jù)表中存儲的位置。在Redis中，Value將被視為二進(jìn)制字節(jié)流用于存儲任何格式的數(shù)據(jù)，如Json、XML和序列化對象的字節(jié)流等，因此我們也可以將其想象為RDB中的BLOB類型字段。由此可見，在進(jìn)行數(shù)據(jù)查詢時，我們只能基于Key作為我們查詢的條件，當(dāng)然我們也可以應(yīng)用Redis中提供的一些技巧將Value作為其他數(shù)據(jù)的Key，這些知識我們都會在后面的博客中予以介紹。
   
五、如何持久化內(nèi)存數(shù)據(jù)：

      缺省情況下，Redis會參照當(dāng)前數(shù)據(jù)庫中數(shù)據(jù)被修改的數(shù)量，在達(dá)到一定的閾值后會將數(shù)據(jù)庫的快照存儲到磁盤上，這一點(diǎn)我們可以通過配置文件來設(shè)定該閾值。通常情況下，我們也可以將Redis設(shè)定為定時保存。如當(dāng)有1000個以上的鍵數(shù)據(jù)被修改時，Redis將每隔60秒進(jìn)行一次數(shù)據(jù)持久化操作。缺省設(shè)置為，如果有9個或9個以下數(shù)據(jù)修改是，Redis將每15分鐘持久化一次。
      從上面提到的方案中可以看出，如果采用該方式，Redis的運(yùn)行時效率將會是非常高效的，既每當(dāng)有新的數(shù)據(jù)修改發(fā)生時，僅僅是內(nèi)存中的緩存數(shù)據(jù)發(fā)生改變，而這樣的改變并不會被立即持久化到磁盤上，從而在絕大多數(shù)的修改操作中避免了磁盤IO的發(fā)生。然而事情往往是存在其兩面性的，在該方法中我們確實(shí)得到了效率上的提升，但是卻失去了數(shù)據(jù)可靠性。如果在內(nèi)存快照被持久化到磁盤之前，Redis所在的服務(wù)器出現(xiàn)宕機(jī)，那么這些未寫入到磁盤的已修改數(shù)據(jù)都將丟失。為了保證數(shù)據(jù)的高可靠性，Redis還提供了另外一種數(shù)據(jù)持久化機(jī)制--Append模式。如果Redis服務(wù)器被配置為該方式，那么每當(dāng)有數(shù)據(jù)修改發(fā)生時，都會被立即持久化到磁盤。