redis入門學習手冊分享-Redis-PHP中文網

redis入門學習手冊分享

一、前言

在過去的幾年時間裡，一提到高並發、大量資料儲存解決方案，我們想到的都是NoSQL資料庫，與之相應的產品自然也呈現出勃勃生機。而在眾多產品中脫穎而出的有Redis、MongoDB、BerkeleyDB和CouchDB等。下面來簡單說明一下。

（學習影片分享：redis影片教學）

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伺服器被配置為該方式，那麼每當有資料修改發生時，都會立即被持久化到磁碟。