為什麼使用Redis

標籤：

原文地址：http://igoder.iteye.com/blog/1969848

 

先解釋一下軟體編程中常見的一些概念： 
抽象先於具象。這個抽象並非虛無的抽象，而是指事物尚未分化為具象之前的那個前體存在。當那個前體存在分化成具象存在之後，前體存在就退化為背景，成為一種抽象。 
結構是關聯與互動的複合體。 
介面是結構的耦合點。 
架構是從無結構到有結構的過程。 
重構是從舊結構到新結構的過程。 
也就是說，結構是架構的結果，架構是結構化的過程。 
常聽人說語言是工具，這是錯誤的。語言不是工具，但它和工具都是大腦的延伸。語言是介於智力與工具之間的銜接物。 
就好比，人類語言是人與人之間的溝通媒介，是人與工具之間的銜接物，而程式設計語言，不過是將人類語言換成了另外一種符號系統，故程式設計語言可以看成是人腦與電腦的溝通媒介。 

世界萬物，皆有層次性。 
最開始只有程式員。架構師、專案經理、產品經理都是從程式員逐步分化出來的，架構師是項目最頂層的那個人，必須熟悉各個層次的需求，而不再僅僅是程式層面的。而凡高層次存在者，皆以對結構的調控與整合為其核心能力。這裡的結構調整，涉及各個層次，比如人員結構，成本結構，技術結構，語言結構等等。即是說，複雜的工程項目架構不僅僅只是程式的架構，還會涉及人員、流程、管理等各層次的架構。 

cap理論指的是三個層面事物的性質，三個層面指資料、系統、網路，簡述如下： 
一致性：指資料的一致性。 
可用性：指系統的可用性。 
容錯性：指網路的容錯性。 
此三層層層嵌套包含，環環相扣，穩定性依次降低，而靈活性與複雜性依次上揚，因此出錯率也依次提升。越底層的越簡單，也越重要，越具有決定性。網路和系統錯了，還可以修補，而資料要是錯了，就沒法挽回了。這其實和資料庫的發展史也是一致和同步的。所以分布式的系統，允許偶爾存在網路問題，但需要保證可用性。集中式系統，允許偶爾存在可用性問題，但需要保證一致性。 

話說天下大勢，合久必分分久必合。 
而這世間的事物，也是以一種分化與構合的方式逐步交替演化而來。 

nosql的出現，源於資料存放區空間與資料訪問時間的矛盾。 
傳統資料庫的儲存與訪問是集中在一起的。 
即是說，資料存在什麼地方，就去什麼地方訪問。 
集線模式的優點是資料穩定，生命週期長，可靠，強關係，缺點是空間擴充性有限。 
集線模式的代表是關聯式資料庫。 

社會的進一步分化，使得IT系統也開始分化。 
資料庫也逐漸從關聯式資料庫向不同領域不同層次分化。 
網民的行為從最開始的唯讀模式，逐漸分化為讀多寫少的模式。 
隨著訪問量提升，出現了IO密集型訪問(此時主要是讀取密集型)，從而導致讀取時間變慢。 
為提升效能，發展了資料庫緩衝技術，主要是對資料庫的讀取操作進行分離。 

而隨著web2.0的進一步發展，網民的生產力進一步提升，儲存總量開始增加。 
此時雖然仍然是讀多寫少的模式，但寫入量已經大大提升。 
原有的緩衝技術不能緩解寫入壓力，而且原有的空間也受硬碟限制，因此開始出現分庫分表，實現讀寫分離。 

集線模式的資料庫就這樣開始逐漸分化：由一個集中的、穩定的、強關係的結構，朝一個分化的、容錯的、弱關係的結構發展。 
資料的儲存空間與資料訪問時間也進一步分離。 
即原來是資料存在什麼地方，就去什麼地方訪問。現在是資料還是存在老地方(硬碟)，但是訪問卻在另一個地方(比如記憶體，或另一個伺服器)。其目的，就在於縮短IO路徑或分離IO，實現高效訪問。 

儲存空間的分化，導致寫入的分化，實現空間換時間的效果。這種擴充分為兩種模式： 
如果橫向分離(同一層次，空間分離)，則可實現諸如主從複製、分庫分表等效果，使得讀寫分離，IO提升。 
如果縱向分離(不同層次，過程分離)，則可實現資料庫緩衝、分布式緩衝等效果，也能讀寫分離，IO提升。 

redis首先是一個整體，其次是縱向分離的產物(由硬碟分離成硬碟+記憶體)，然後才是橫向分離(分布式)。 
它從內部是一分為二，將儲存空間分為兩塊，將預存程序分為兩步。 
而memcached+mysql是兩個東西，從外部將兩者合二為一。因此在契合度上，redis必然更有優勢。 
由於空間分離，資料也開始分離。冷資料下沉，熱資料上浮，而為了保持資料的一致和同步，必須保證在分離的同時，使得兩者保持聯絡，以便於即時更新資料。 
從整體上來說，redis是一個整體，其整體效果和連貫性要大於M+M的組合效果。redis的資料同步在內部完成，是直接同步處理；而M+M必須藉助中介軟體完成，是間接同步。 
從結構上來說，redis的磁碟儲存資料要比mysql簡單，而記憶體結構卻比memcached多樣和靈活。 
從擴充性來說，由於redis的底盤簡單而穩定，使其有著良好的擴充性，而上層的複雜性使redis可以適應於更多複雜的業務情境。 

原來業內認為M+M的問題是： 
1，擴充時維護麻煩； 
2，存在資料不一致現象； 
3，大容量資料下命中率下降。 

而redis基本沒有上述問題，因此，redis有逐漸取代memcached的趨勢。 

mysql後來推出了一個memcached外掛程式，對外提供與memcached協議相容的介面，使得兩者終於結為一個統一的整體了。 
可以把memcached外掛程式看成是mysql的一部分，因此我們從nosql的角度來看，mysql也可以視為是nosql的一種。 
由於memcached外掛程式朝mysql靠攏，使得memcached外掛程式同時還得受制於mysql，即：memcached外掛程式和mysql更緊密更統一的同時，其生命週期和生存空間受到mysql的制約，一榮俱榮一損俱損，一旦mysql掛了它也得掛。因此memcached外掛程式的推出，使得memcached呈現一種收縮的態勢，擴充性受到mysql的限制。 
從整體上來說，memcached外掛程式的整體性和連貫性使得redis的優勢已經被削弱。 
從結構上來說，memcached外掛程式可以天然的利用mysql自身的儲存和複製，因此儲存方面要強於redis，而上層的記憶體結構和操作方式等依然弱於redis。 
從擴充性來說，memcached外掛程式和mysql結合緊密，由於底盤mysql本身的厚重性，擴充性受限制，使得memcached外掛程式的分布式能力弱化了一些。 

綜上： 
越集中的系統，架構越保守越封閉，穩定性越高，聯絡越緊密，伸縮性和擴充性必然受到制約。 
越開放的系統，架構越分化越創新，穩定性越低，聯絡越鬆散，伸縮性和擴充性必然逐步擴大。 
系統在開放和分離的同時，為了保證子系統內部的統一和連貫，必然要求子系統內部之間保持聯絡。 
這使得現代系統和架構朝分布式和網路化的方向發展，以一種整體的多系統的連續的方式朝外擴散，一如宇宙的膨脹一般。 
從邏輯結構上(而非誕生先後)來說，這種擴充趨勢可以簡單樣本如下： 

mysql --> mysql+handlersocket外掛程式 --> mysql+memcached外掛程式 --> mysql+memcachedb --> mysql+memcached 

由上可見，系統儲存架構從一個強聯絡的整體，朝一個弱聯絡的個體分化開去，記憶體應用一步一步朝獨立的方向發展，逐步擺脫mysql的制約，嚮往極端的自由和靈活，直到memcached完全和mysql隔離，時間和空間不再受mysql限制，必須靠第三方工具進行間接聯絡，使得擴充性達到極致。 
由於系統分化使系統之間的聯絡進一步弱化，勢必要求系統之間採用更加複雜的連絡方式。 
分化的越厲害，中間節點越多，連絡方式就越加複雜，穩定性越低，故障自然越多，維護成本越大。 


而redis則以一種相對簡單和分散的方式，使得這一過程得以繼續延續下去。 
因此為什麼redis能比M+M更好用，原因是：一是結構簡單，二是硬碟與記憶體合為一體。 
由於結構簡單，所以方便擴充；又由於硬碟與記憶體合為一體，所以使資料也能同步擴充，維護更簡單。 


... 

以後會不定時更新該文章，陸續把這個分化過程編的邏輯完整和連貫一些。

為什麼使用Redis