一、簡(jiǎn)介：

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

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

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

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

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

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

三、目前版本中Redis存在的主要問(wèn)題：

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

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

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