【CC++服務(wù)器開發(fā)】中間件的含義及常用中間件介紹

CC++服務(wù)器開發(fā)】中間件的含義及常?中間件介紹?、中間件的定義中間件這個術(shù)語第?次出現(xiàn)是1968年在德國加爾?施帕滕基興舉辦的NATO軟件?程?會結(jié)束后發(fā)表的?份報告中。這屆?會正式確定了軟件?程(SoftwareEngineering)的概念，同時還探討了軟件設(shè)計、?產(chǎn)和分發(fā)等主題。中間件（英語：Middleware），?譯中間件、中介層，是?類提供系統(tǒng)軟件和應?軟件之間連接、便于軟件各部件之間的溝通的軟件，應?軟件可以借助中間件在不同的技術(shù)架構(gòu)之間共享信息與資源。中間件位于客戶機服務(wù)器的操作系統(tǒng)之上，管理著計算資源和?絡(luò)通信。–維基百科我們按照類別來看?些經(jīng)常會遇到的?些不是中間件的概念-業(yè)務(wù)平臺不是中間件，業(yè)務(wù)平臺是從服務(wù)的視?抽象的能同時?撐多個業(yè)務(wù)，業(yè)務(wù)之間的信息能形成交互和增強的平臺。-營銷?具不是中間件，營銷?具是直接作?于最終消費者?戶的軟件或者插件服務(wù)。-??/三??具包不是中間件，??/三??具包是在各種場景的程序開發(fā)過程中沉淀的?些常??具類(功能)的集合，包含于軟件代碼本?。-SaaS不是中間件，SaaS(SoftwareasaService)更多的是?種軟件交付模式，?需?戶安裝，通過?絡(luò)在線訪問的?種服務(wù)模式。-PaaS不是中間件，PaaS(PlatformasaService)將軟件研發(fā)的平臺做為?種服務(wù)，提供軟件部署平臺(強調(diào)的是屏蔽系統(tǒng)和軟件細節(jié)的runtime平臺)。從定義可以總結(jié)出評判的?個地?1.性質(zhì)：中間件是軟件。2.作?層級：系統(tǒng)軟件和應?軟件之間、軟件各部件之間；管理客戶機與系統(tǒng)軟件之間的計算資源和?絡(luò)通信。3.服務(wù)對象：中間件為應?軟件服務(wù)，應?軟件為最終?戶服務(wù)，最終?戶并不直接使?中間件。中間件能給客戶帶來什么？為上層應?軟件的開發(fā)提供便捷的、開箱即?的服務(wù)交互和計算的能?，縮短開發(fā)周期；屏蔽底層runtime的差異；節(jié)省應?本?的系統(tǒng)資源，減少運?成本。什么時候使?中間件基于中間件的定義我們知道中間件是連接軟件與系統(tǒng)之間的服務(wù)，那么我們什么時候使?了中間件，在哪些地??到了中間件了。我們不妨假設(shè)?個http請求過程來窺視?番。當你在瀏覽器中輸??個?址時，它會通過DNS解析到?標服務(wù)注冊的公?IP地址請求到達?標服務(wù)的web反向代理服務(wù)器Tengine之后，經(jīng)過?定的過濾轉(zhuǎn)發(fā)到?標服務(wù)A上服務(wù)A通過RPC框架Dubbo請求服務(wù)B的結(jié)果做中間計算，并且從Tair緩存中讀取計算因?，計算結(jié)果服務(wù)A接著使?Druid通過TDDL寫?計算結(jié)果到MySQLMaster節(jié)點然后返回結(jié)果異步過程中Canal通過模擬Binlog主從復制的原理，迅速將這條Binlog消費并下發(fā)到消息隊列RocketMQ服務(wù)C通過RocketMQ消費到事件之后，通過配置中?ConfigServer拉取到的策略進?對應策略的事件處理。這個過程中我們使?了?系列的中間件來協(xié)同各個微服務(wù)完成整個流程，如web反向代理服務(wù)器Tengine、RPC框架Dubbo、緩存Tair、連接池Driud、數(shù)據(jù)庫代理層TDDL、Binlog同步?具Canal、消息隊列RocketMQ、配置中?ConfigServer。-路由與web服務(wù)器：處理和轉(zhuǎn)發(fā)其他服務(wù)器通信數(shù)據(jù)的服務(wù)器。如被業(yè)界?泛使?的阿?基于Nginx研發(fā)的Tengine、阿?內(nèi)部的集中式路由服務(wù)VipServer-RPC框架：微服務(wù)時代的遠程服務(wù)調(diào)?框架。如grpc,Thrift,阿?的HSF,Dubbo,SOFA-RPC-消息中間件：?持在分布式系統(tǒng)之間發(fā)送和接收消息的軟件。如Apachekafka,ApacheRabbitMQ,NSQ,阿?孵化開源的ApacheRocketMQ-緩存服務(wù):分布式的?速數(shù)據(jù)存儲層，?般是內(nèi)存存儲。如阿?Tair，業(yè)界的Redis,Memcached,Ehcache-配置中?：?來統(tǒng)?管理各個項?中所有配置的系統(tǒng)。如阿?Nacos、攜程Apollo、百度Disconf-分布式事務(wù)：事務(wù)的參與者、?持事務(wù)的服務(wù)器、資源服務(wù)器以及事務(wù)管理器分別位于不同的分布式系統(tǒng)的不同節(jié)點之上。如阿?seata、騰訊DTF-任務(wù)調(diào)度：分布式環(huán)境下提供定時、任務(wù)編排、分布式跑批等功能的系統(tǒng)。如阿?SchedulerX、業(yè)界xxl-job、當當elastic-job、有贊TSP-數(shù)據(jù)庫層?于?持彈性擴容和分庫分表的TDDL，數(shù)據(jù)庫連接池Driud,Binlog同步的Canal等。隨著云時代的到來，?量公司的業(yè)務(wù)向云上遷移；為了云上客戶能夠便捷的使?穩(wěn)定?效的中間件能?，云?商開始將??沉淀的基礎(chǔ)中間件能?云化，?于?撐各個云上客戶和??業(yè)務(wù)的快速?長。?、中間件的開發(fā)隨著國內(nèi)軟件?業(yè)的發(fā)展，國內(nèi)互聯(lián)?公司規(guī)模越來越?，業(yè)務(wù)越來越復雜，隨之使??量的中間件來提?后臺服務(wù)性能。由此產(chǎn)?了中間件開發(fā)和維護?員。誠然，在?公司，中間件，例如緩存，MQ，RPC等服務(wù)，極?可能是由業(yè)務(wù)開發(fā)?員??維護，或者委托第三?云平臺運維（?付?些費?）。但，如果后臺開發(fā)超過200?，基本就會組建??的中間件或者基礎(chǔ)架構(gòu)團隊，?于維護后臺服務(wù)器基礎(chǔ)架構(gòu)和中間件。更?規(guī)模的公司，則由于各種各樣的原因（性能，KPI），會??開發(fā)中間件，簡稱?研。這要求中間件團隊需要更多的?員。既然需要中間件開發(fā)?員，那么中間件開發(fā)?員?般從哪?招聘呢？招聘的要求是什么？通常，?個公司在剛開始組建中間件團隊的時候，都會從公司內(nèi)部挑選精英?才，或者挑選對中間件感興趣的?才。這時候，可能你沒有相關(guān)經(jīng)驗，但你仍然有機會參與到中間件開發(fā)中。反之，如果你沒有中間件開發(fā)經(jīng)驗，想通過招聘的?式進?中間件?業(yè)，那么相對??，會有些曲折。那么，假設(shè)，你想從事中間件開發(fā)，但，你沒有中間件開發(fā)經(jīng)驗，且，你的公司也沒有組建中間件團隊的打算。該怎么突破？答：跳槽。跳槽到別的公司的中間件團隊。這?就涉及到了?個中間件團隊需要哪些技能。因為跳槽肯定就要?試，如果你?試的是中間件崗位，那么?然，就需要準備中間件的相關(guān)知識。另外，還有?點，在這個分?明確的時代，即使是中間件，也有很多種類，我這?稍微分?下，可能不是很準確。1.服務(wù)治理中間件，例如RPC相關(guān)中間件，限流熔斷，鏈路追蹤，分布式配置中?等等。你可以從SpringCloud?找到相關(guān)的產(chǎn)品。當然國內(nèi)也有很多優(yōu)秀的產(chǎn)品。2.存儲中間件，例如緩存，MQ等等，如果存儲涉及到分布式（通常都會涉及），那么要求相對較?。3.各種Proxy，不論是數(shù)據(jù)庫，還是Cache，還是各種存儲，通常單機?法承載海量數(shù)據(jù)，?較簡單的辦法就是使?Proxy進?代理，讓應?透明的使?集群。出于性能考慮，這?通常會使?性能較?的產(chǎn)品，例如goLang，C++等。Java的長處——開發(fā)效率，在這個地?權(quán)重不?。4.各種分布式中間件，例如ZK這種，這個我個?認為難度是較?的。分布式向來是軟件開發(fā)中?較困難的?個點。特別是涉及到存儲和?致性。5.回到之前的話題:?個中間件開發(fā)者需要哪些素質(zhì)？1.語?基礎(chǔ)。從Java程序員的?度，基礎(chǔ)通常就是：集合，并發(fā)，JVM，Netty，IO、NIO（mmap，sendfile）2.計算機基礎(chǔ)，由于中間件開發(fā)?員經(jīng)常和OS打交道，所以計算機基礎(chǔ)也必不可少，例如?件系統(tǒng)（IO/磁盤），進程線程，內(nèi)存管理。3.?絡(luò)基礎(chǔ)，搞后臺的?員，肯定要對?絡(luò)熟悉了，熟悉在Linux下排查?絡(luò)問題，熟悉Epoll原理等。4.分布式相關(guān)知識，互聯(lián)?海量數(shù)據(jù)背景下，分布式知識必不可少，CAP，Paxos，Raft，zab，2pc，3pc，base等等。最好能根據(jù)這些理論寫出實現(xiàn)代碼。5.熟悉開源實現(xiàn)，即使你是業(yè)務(wù)開發(fā)?員，你也100%會接觸開源項?，例如Spring，那么，通常你需要對這種常?的開源代碼有深刻的理解，不僅知曉其原理，也領(lǐng)會其設(shè)計。從?的?度看，你得看清整個框架的背景，設(shè)計和取舍，從?的?度看，你得看清框架的內(nèi)部實現(xiàn)細節(jié)，有哪些有趣的地?（通常這種框架都會進?性能優(yōu)化）。6.了解?業(yè)風向標，中間件?業(yè)和業(yè)務(wù)開發(fā)稍有不同，每個中間件的版本升級都會讓該領(lǐng)域的開發(fā)者們側(cè)?（類似iPhone發(fā)布會），了解其特性，進?了解?業(yè)趨勢，最后成為?業(yè)引領(lǐng)。好，說完了中間件開發(fā)?員需要哪些素質(zhì)，?然，如何成為中間件開發(fā)?員，就不??明了。說?了，以上6個點，都是硬?頭。對于已經(jīng)開始?作的?來說，需要平時深刻的積累，說的難聽?點，如果你的業(yè)務(wù)開發(fā)任務(wù)很重，你很難搞定上門的這些內(nèi)容。對于還在上學的同學來說，很爽，你可以?學校（不僅僅指?學，據(jù)我所知的?神，通常是初中/?學就開始編程，但這不是必須的）??把的時間來學習，?個個的搞定這些知識點，和社招不同，如果你的知識達到上?的?平，那么SPoffer應該是隨便拿了：）我這?重點和那些平時開發(fā)任務(wù)不重，想搞中間件的同學聊聊。我假設(shè)你是?個?作3年以內(nèi)的Java開發(fā)?員，且你可能是培訓?，半路出家，科班?，?專?，初中?，且你不在??，通常在?個后臺開發(fā)不超過200?的創(chuàng)業(yè)公司，title是“Java開發(fā)?程師”，并且有?個程序員的夢想，不想get、set，不想crud，不想html填空，不想和產(chǎn)品同學討論，也不想和測試同學點點點…(感覺這?會得罪?=_=||)你可能想跳槽。那么你?概需要做以下準備：1.鞏固Java基礎(chǔ)，集合源碼，并發(fā)源碼，JVM原理，Netty原理源碼，IO相關(guān)（涉及到零拷貝?件存儲），這些都是Java基礎(chǔ)，通常是必須的。2.分布式原理，最起碼知曉理論知識，最好能寫?個，哪怕參照開源的也?。3.源碼，SpringMybatisTomcat等等，這些代碼通常是你最先接觸的，不妨從這?開始。RPC中間件相關(guān)的，Dubbo，Motan，SOFA，挑?個吧，推薦SOFA。4.再熟悉熟悉（熟悉指源碼和設(shè)計）分布式的相關(guān)產(chǎn)品，假設(shè)你是Java開發(fā)，推薦RocketMQ，Apollo配置中?等等中間件，其實都可以，MQ相對復雜。5.操作系統(tǒng)，通常，你在研究上?的內(nèi)容時，會遇到操作系統(tǒng)的疑問，遇到不要繞過，盡量弄明?。6.??的產(chǎn)品，有就最好了，例如公眾號，博客，教學視頻，GitHub項?等等，總之，是拿得出?的東西。7.加??好友，了解?業(yè)風向標。也許你是?個矜持的?，但從事了這個?業(yè)，你有必要和?業(yè)?優(yōu)秀的?學習(看看朋友圈就好)。三、和NoSQL之前寫了?篇關(guān)于數(shù)據(jù)庫的基礎(chǔ)博客：下?來看看NoSQL的含義。關(guān)系型數(shù)據(jù)庫建?在關(guān)系型數(shù)據(jù)模型的基礎(chǔ)上，是借助于集合代數(shù)等數(shù)學概念和?法來處理數(shù)據(jù)的數(shù)據(jù)庫?，F(xiàn)實世界中的各種實體以及實體之間的各種聯(lián)系均可?關(guān)系模型來表?，市場上占很?份額的Oracle、、DB2等都是?向關(guān)系模型的DBMS。在關(guān)系型數(shù)據(jù)庫中，實體以及實體間的聯(lián)系均由單?的結(jié)構(gòu)類型來表?，這種邏輯結(jié)構(gòu)是?張?維表。圖1所?的學?選課系統(tǒng)中，實體和實體間聯(lián)系在數(shù)據(jù)庫中的邏輯結(jié)構(gòu)可通過圖2所?。圖1：關(guān)系型數(shù)據(jù)庫圖2：學?選課系統(tǒng)數(shù)據(jù)庫邏輯結(jié)構(gòu)關(guān)系型數(shù)據(jù)庫以?和列的形式存儲數(shù)據(jù)，這?系列的?和列被稱為表，?組表組成了數(shù)據(jù)庫。圖3所?的員?信息表就是關(guān)系型數(shù)據(jù)庫。圖3：員?信息表屬性說明：?維表：也稱為關(guān)系，它是?系列?維數(shù)組的集合，?來代表與存儲數(shù)據(jù)對象之間的關(guān)系。它由縱向的列和橫向的?組成。?：也叫元組或記錄，在表中是?條橫向的數(shù)據(jù)集合，代表?個實體。列：也叫字段或?qū)傩?，在表中?條縱?的數(shù)據(jù)集合。列也定義了表中的。主屬性：關(guān)系中的某?屬性組，若它們的值唯?地標識?個記錄，則稱該屬性組為主屬性或主鍵。主屬性可以是?個屬性，也可以由多個屬性共同組成。在圖1-5中，學號是學?信息表的主屬性，但是課程信息表中，學號和課程號共同唯?地標識了?條記錄，所以學號和課程號?起組成了課程信息表的主屬性。結(jié)構(gòu)化查詢語?關(guān)系型數(shù)據(jù)庫的核?是其結(jié)構(gòu)化的查詢語?（StructuredQueryLanguage,SQL），SQL涵蓋了數(shù)據(jù)的查詢、操縱、定義和控制，是?個綜合的、通?的且簡單易懂的數(shù)據(jù)庫管理語?。同時SQL?是?種?度?過程化的語?，數(shù)據(jù)庫管理者只需要指出做什么，?不需要指出該怎么做即可完成對數(shù)據(jù)庫的管理。SQL可以實現(xiàn)數(shù)據(jù)庫全?命周期的所有操作，所以SQL?產(chǎn)?之?起就成了檢驗關(guān)系型數(shù)據(jù)庫管理能?的“試??”，SQL標準的每?次變更和完善都引導著關(guān)系型數(shù)據(jù)庫產(chǎn)品的發(fā)展?向。SQL包含以下四個部分。）DDL包括CREATE、DROP、ALTER等動作。在數(shù)據(jù)庫中使?CREATE來創(chuàng)建新表，DROP來刪除表，ALTER負責數(shù)據(jù)庫對象的修改。例如，創(chuàng)建學?信息表使?以下命令：CREATETABLEStuInfo(idint(10)NOTNULL,PRIMARYKEY(id),namevarchar(20),femalebool,classvarchar(20));）DQL負責進?數(shù)據(jù)查詢，但是不會對數(shù)據(jù)本?進?修改。DQL的語法結(jié)構(gòu)如下：SELECTFROM表名1,表2where查詢條件#可以組合and、or、not、=、between、and、in、like等；groupby分組字段having(分組后的過濾條件)orderby排序字段和規(guī)則;）DML負責對數(shù)據(jù)庫對象運?數(shù)據(jù)訪問?作的指令集，以INSERT、UPDATE、DELETE三種指令為核?，分別代表插?、更新與刪除。向表中插?數(shù)據(jù)命令如下：INSERT表名(字段1,字段2,…，字段n,)VALUES(字段1值，字段2值，…，字段n值)where查詢條件；）DCL是?種可對數(shù)據(jù)訪問權(quán)進?控制的指令。它可以控制特定?戶賬戶對查看表、預存程序、?戶?定義函數(shù)等數(shù)據(jù)庫操作的權(quán)限，由GRANT和REVOKE兩個指令組成。DCL以控制?戶的訪問權(quán)限為主，GRANT為授權(quán)語句，對應的REVOKE是撤銷授權(quán)語句。關(guān)系型數(shù)據(jù)庫已經(jīng)發(fā)展了數(shù)?年，其理論知識、相關(guān)技術(shù)和產(chǎn)品都趨于完善，是?前世界上應?最?泛的數(shù)據(jù)庫系統(tǒng)。容易理解：?維表結(jié)構(gòu)?常貼近邏輯世界的概念，關(guān)系型數(shù)據(jù)模型相對層次型數(shù)據(jù)模型和?狀型數(shù)據(jù)模型等其他模型來說更容易理解。使??便：通?的SQL使?戶操作關(guān)系型數(shù)據(jù)庫?常?便。易于維護：豐富的完整性??減少了數(shù)據(jù)冗余和數(shù)據(jù)不?致的問題。關(guān)系型數(shù)據(jù)庫提供對事務(wù)的?持，能保證系統(tǒng)中事務(wù)的正確執(zhí)?，同時提供事務(wù)的恢復、回滾、并發(fā)控制和死鎖問題的解決。隨著各類互聯(lián)?業(yè)務(wù)的發(fā)展，關(guān)系型數(shù)據(jù)庫難以滿?對海量數(shù)據(jù)的處理需求，存在以下不?。?并發(fā)讀寫能?差：?站類?戶的并發(fā)性訪問?常?，??臺數(shù)據(jù)庫的最?連接數(shù)有限，且硬盤I/O有限，不能滿?很多?同時連接。對海量數(shù)據(jù)的讀寫效率低：若表中數(shù)據(jù)量太?，則每次的讀寫速率都將?常緩慢。擴展性差：在?般的關(guān)系型數(shù)據(jù)庫系統(tǒng)中，通過升級數(shù)據(jù)庫服務(wù)器的硬件配置可提?數(shù)據(jù)處理的能?，即縱向擴展。但縱向擴展終會達到硬件性能的瓶頸，?法應對互聯(lián)?數(shù)據(jù)爆炸式增長的需求。還有?種擴展?式是橫向擴展，即采?多臺計算機組成集群，共同完成對數(shù)據(jù)的存儲、管理和處理。這種橫向擴展的集群對數(shù)據(jù)進?分散存儲和統(tǒng)?管理，可滿?對海量數(shù)據(jù)的存儲和處理的需求。但是由于關(guān)系型數(shù)據(jù)庫具有數(shù)據(jù)模型、完整性約束和事務(wù)的強?致性等特點，導致其難以實現(xiàn)?效率的、易橫向擴展的分布式架構(gòu)。數(shù)據(jù)是當今世界最有價值的資產(chǎn)之?。在時代，?們?產(chǎn)、收集數(shù)據(jù)的能???提升，但是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫在可擴展性、數(shù)據(jù)模型和可?性??已遠遠不能滿?當前的數(shù)據(jù)處理需求，因此，各種數(shù)據(jù)庫系統(tǒng)應運??。NoSQL數(shù)據(jù)庫不像關(guān)系型數(shù)據(jù)庫那樣都有相同的特點，遵循相同的標準。NoSQL數(shù)據(jù)庫類型多樣，可滿?不同場景的應?需求，因此取得了巨?的成功。NoSQL數(shù)據(jù)庫基本理念是以犧牲事務(wù)機制和強?致性機制，來獲取更好的分布式部署能?和橫向擴展能?，創(chuàng)造出新的數(shù)據(jù)模型，使其在不同的應?場景下，對特定業(yè)務(wù)數(shù)據(jù)具有更強的處理性能。NoSQL數(shù)據(jù)庫最初是為了滿?互聯(lián)?的業(yè)務(wù)需求?誕?的，互聯(lián)?數(shù)據(jù)具有?量化、多樣化、快速化等特點。在信息化時代背景下，互聯(lián)?數(shù)據(jù)增長迅猛，數(shù)據(jù)集合規(guī)模已實現(xiàn)從GB、PB到ZB的飛躍。數(shù)據(jù)不僅僅是傳統(tǒng)的結(jié)構(gòu)化數(shù)據(jù)，還包含了?量的?結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)，關(guān)系型數(shù)據(jù)庫?法存儲此類數(shù)據(jù)。因此，很多互聯(lián)?公司著?研發(fā)新型的、?關(guān)系型的數(shù)據(jù)庫，這類?關(guān)系型數(shù)據(jù)庫統(tǒng)稱為NoSQL數(shù)據(jù)庫，其主要優(yōu)勢如下?；ヂ?lián)?數(shù)據(jù)如?站?戶信息、地理位置數(shù)據(jù)、社交圖譜、?戶產(chǎn)?的內(nèi)容、機器?志數(shù)據(jù)以及傳感器數(shù)據(jù)等，正在快速改變著?們的通信、購物、?告、娛樂等?常?活，沒有使?這些數(shù)據(jù)的應?很快就會被?戶所遺忘。開發(fā)者希望使??常靈活的數(shù)據(jù)庫，容納新的數(shù)據(jù)類型，并且不會被第三?數(shù)據(jù)提供商的變化所影響。關(guān)系型數(shù)據(jù)庫的數(shù)據(jù)模型定義嚴格，?法快速容納新的數(shù)據(jù)類型。例如，若要存儲客戶的電話號碼、姓名、地址、城市等信息，則SQL數(shù)據(jù)庫需要提前知曉要存儲的是什么。這對于敏捷開發(fā)模式來說?分不?便，因為每次完成新特性時，通常都需要改變數(shù)據(jù)庫的模式。NoSQL數(shù)據(jù)庫提供的數(shù)據(jù)模型則能很好地滿?這種需求，各種應?可以通過這種靈活的數(shù)據(jù)模型存儲數(shù)據(jù)??須修改表；或者只需增加更多的列，?須進?數(shù)據(jù)的遷移。對企業(yè)來說，關(guān)系型數(shù)據(jù)庫?開始是普遍的選擇。然?，在使?關(guān)系型數(shù)據(jù)庫的過程中卻遇到了越來越多的問題，原因在于它們是中?化的，是縱向擴展?不是橫向擴展的。這使得它們不適合那些需要簡單且動態(tài)可伸縮性的應?。NoSQL數(shù)據(jù)庫從?開始就是分布式、橫向擴展的，因此?常適合互聯(lián)?應?分布式的特性。在互聯(lián)?應?中，當數(shù)據(jù)庫服務(wù)器?法滿?數(shù)據(jù)存儲和數(shù)據(jù)訪問的需求時，只需要增加多臺服務(wù)器，將?戶請求分散到多臺服務(wù)器上，即可減少單臺服務(wù)器的性能瓶頸出現(xiàn)的可能性。由于關(guān)系型數(shù)據(jù)庫存儲的是結(jié)構(gòu)化的數(shù)據(jù)，所以通常采?縱向擴展，即單臺服務(wù)器要持有整個數(shù)據(jù)庫來確?？煽啃耘c數(shù)據(jù)的持續(xù)可?性。這樣做的代價是?常昂貴的，?且擴展也會受到限制。針對這種問題的解決?案就是橫向擴展，即添加服務(wù)器?不是擴展單臺服務(wù)器的處理能?。NoSQL數(shù)據(jù)庫通常都?持?動分?，這意味著它們會?動地在多臺服務(wù)器上分發(fā)數(shù)據(jù)，?不需要應?程序增加額外的操作。NoSQL數(shù)據(jù)庫?持?動復制。在NoSQL數(shù)據(jù)庫分布式集群中，服務(wù)器會?動對數(shù)據(jù)進?備份，即將?份數(shù)據(jù)復制存儲在多臺服務(wù)器上。因此，當多個?戶訪問同?數(shù)據(jù)時，可以將?戶請求分散到多臺服務(wù)器中。同時，當某臺服務(wù)器岀現(xiàn)故障時，其他服務(wù)器的數(shù)據(jù)可以提供備份，即NoSQL數(shù)據(jù)庫的分布式集群具有?可?性與災備恢復的能?。需要通過分布式的集群?式來解決存儲和訪問的問題。分布式系統(tǒng)的核?理念是讓多臺服務(wù)器協(xié)同?作，完成單臺服務(wù)器?法處理的任務(wù)，尤其是?并發(fā)或者?數(shù)據(jù)量的任務(wù)。分布式數(shù)據(jù)庫是數(shù)據(jù)庫技術(shù)與?絡(luò)技術(shù)相結(jié)合的產(chǎn)物，它通過?絡(luò)技術(shù)將物理上分開的數(shù)據(jù)庫連接在?起，進?邏輯層?上的集中管理。在分布式數(shù)據(jù)庫系統(tǒng)中，?個應?程序可以對數(shù)據(jù)庫進?透明操作，數(shù)據(jù)庫中的數(shù)據(jù)分別存儲在不同的局部數(shù)據(jù)庫中，由不同機器上不同的DBMS進?管理，其的體系結(jié)構(gòu)如下圖所?。分布式數(shù)據(jù)處理使?分?治之的辦法來解決?規(guī)模數(shù)據(jù)管理問題，它處理數(shù)據(jù)的基本特點如下。在分布式系統(tǒng)中，數(shù)據(jù)不是存儲在?個場地上，?是存儲在計算機?絡(luò)的多個場地上。但邏輯上是?個整體，它們被所有?戶共享，并由?個DBMS統(tǒng)?管理。?戶訪問數(shù)據(jù)時?須指出數(shù)據(jù)存放在哪?，也不需要知道由分布式系統(tǒng)中的哪臺服務(wù)器來完成。分布式數(shù)據(jù)的復制有助于提?性能，更易于協(xié)調(diào)不同??沖突的?戶需求。同時，當某臺服務(wù)器出現(xiàn)故障時，此服務(wù)器上的數(shù)據(jù)在其他服務(wù)器上還有備份，提?了系統(tǒng)的可?性。這種多副本的?式對?戶來說是透明的，即?戶不需要知道副本的存在，由系統(tǒng)統(tǒng)?管理、協(xié)調(diào)副本的調(diào)?。分布式數(shù)據(jù)處理具有重復的構(gòu)成，因此消除了單點故障的問題，即系統(tǒng)中?個或多個服務(wù)器發(fā)送故障不會使整個系統(tǒng)癱瘓，從?提?了系統(tǒng)的可靠性。但是在分布式系統(tǒng)中，事務(wù)是并發(fā)的，即不同?戶可能在同?時間對同?數(shù)據(jù)源進?訪問，這就要求系統(tǒng)?持分布式的并發(fā)控制，保證系統(tǒng)中數(shù)據(jù)的?致。分布式系統(tǒng)可以解決海量數(shù)據(jù)的存儲和訪問，但是在分布式環(huán)境下，數(shù)據(jù)庫會遇到更為復雜的問題，舉例如下。數(shù)據(jù)在分布式環(huán)境下以多副本?式進?存儲，那么，在為?戶提供數(shù)據(jù)訪問時如何選擇?個副本，或者?戶修改了某?副本的數(shù)據(jù)，如何讓系統(tǒng)中每個副本都得到更新。如果正在更新系統(tǒng)所有副本信息時，某個服務(wù)器由于?絡(luò)或硬、軟件功能出現(xiàn)問題導致其發(fā)?故障。在這種情況下，如何確保故障恢復時，此服務(wù)器上的副本與其他副本?致。這些問題給分布式數(shù)據(jù)庫管理系統(tǒng)帶來了挑戰(zhàn)，它們是分布式系統(tǒng)固有的復雜性，但更重要的是對分布數(shù)據(jù)的管理，控制數(shù)據(jù)之間的?致性以及數(shù)據(jù)訪問的安全性。CAP理論是針對分布式數(shù)據(jù)庫??的，它是指在?個分布式系統(tǒng)中，?致性（Consistency,C）、可?性（Availability,A）、分區(qū)容錯性（PartitionTolerance,P）三者不可兼得。）?致性是指“allnodesseethesamedataatthesametime”，即更新操作成功后，所有節(jié)點在同?時間的數(shù)據(jù)完全?致。?致性可以分為客戶端和服務(wù)端兩個不同的視?：從客戶端?度來看，?致性主要指多個?戶并發(fā)訪問時更新的數(shù)據(jù)如何被其他?戶獲取的問題；從服務(wù)端來看，?致性則是?戶進?數(shù)據(jù)更新時如何將數(shù)據(jù)復制到整個系統(tǒng)，以保證數(shù)據(jù)的?致。?致性是在并發(fā)讀寫時才會出現(xiàn)的問題，因此在理解?致性的問題時，?定要注意結(jié)合考慮并發(fā)讀寫的場景。）可?性是指“readsandwritesalwayssucceed”，即?戶訪問數(shù)據(jù)時，系統(tǒng)是否能在正常響應時間返回結(jié)果。好的可?性主要是指系統(tǒng)能夠很好地為?戶服務(wù)，不出現(xiàn)?戶操作失敗或者訪問超時等?戶體驗不好的情況。在通常情況下，可?性與分布式數(shù)據(jù)冗余、負載均衡等有著很?的關(guān)聯(lián)。）分區(qū)容錯性是指“thesystemcontinuestooperatedespitearbitrarymessagelossorfailureofpartofthesystem”，即分布式系統(tǒng)在遇到某節(jié)點或?絡(luò)分區(qū)故障的時候，仍然能夠?qū)ν馓峁M??致性和可?性的服務(wù)。分區(qū)容錯性和擴展性緊密相關(guān)。在分布式應?中，可能因為?些分布式的原因?qū)е孪到y(tǒng)?法正常運轉(zhuǎn)。分區(qū)容錯性?指在部分節(jié)點故障或出現(xiàn)丟包的情況下，集群系統(tǒng)仍然能提供服務(wù)，完成數(shù)據(jù)的訪問。分區(qū)容錯可視為在系統(tǒng)中采?多副本策略。CAP理論認為分布式系統(tǒng)只能兼顧其中的兩個特性，即出現(xiàn)CA、CP、AP三種情況，如圖所?。P如果不要求PartitionTolerance，即不允許分區(qū)，則強?致性和可?性是可以保證的。其實分區(qū)是始終存在的問題，因此CA的分布式系統(tǒng)更多的是允許分區(qū)后各?系統(tǒng)依然保持CA。A如果不要求可?性，相當于每個請求都需要在各服務(wù)器之間強?致，?分區(qū)容錯性會導致同步時間?限延長，如此CP也是可以保證的。很多傳統(tǒng)的數(shù)據(jù)庫分布式事務(wù)都屬于這種模式。C如果要可?性?并允許分區(qū)，則需放棄?致性。?旦分區(qū)發(fā)?，節(jié)點之間可能會失去聯(lián)系，為了實現(xiàn)?可?，每個節(jié)點只能?本地數(shù)據(jù)提供服務(wù)，?這樣會導致全局數(shù)據(jù)的不?致性。在實踐中，可根據(jù)實際情況進?權(quán)衡，或者在軟件層?提供配置?式，由?戶決定如何選擇CAP策略。CAP理論可?在不同的層?，可以根據(jù)CAP原理定制局部的設(shè)計策略，例如，在分布式系統(tǒng)中，每個節(jié)點??的數(shù)據(jù)是能保證CA的，但在整體上?要兼顧AP或CP。ACID是關(guān)系型數(shù)據(jù)庫的事務(wù)機制需要遵守的原則。事務(wù)是?個?致和可靠計算的基本單元，由作為原?單元執(zhí)?的?系列數(shù)據(jù)庫操作組成。數(shù)據(jù)庫庫?般在啟動時會提供事務(wù)機制，包括事務(wù)啟動、停?、取消或回滾等。關(guān)系型數(shù)據(jù)庫?持事務(wù)的ACID原則，即原?性（Atomicity）、?致性（Consistency）、隔離性（Isolation）、持久性（Durability），這四種原則保證在事務(wù)過程當中數(shù)據(jù)的正確性，具體描述如下。）?個事務(wù)的所有系列操作步驟被看成?個動作，所有的步驟要么全部完成，要么?個也不會完成。如果在事務(wù)過程中發(fā)?錯誤，則會回滾到事務(wù)開始前的狀態(tài)，將要被改變的數(shù)據(jù)庫記錄不會被改變。）?致性是指在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫的完整性約束沒有被破壞，即數(shù)據(jù)庫事務(wù)不能破壞關(guān)系數(shù)據(jù)的完整性及業(yè)務(wù)邏輯上的?致性。）主要?于實現(xiàn)并發(fā)控制，隔離能夠確保并發(fā)執(zhí)?的事務(wù)按順序?個接?個地執(zhí)?。通過隔離，?個未完成事務(wù)不會影響另外?個未完成事務(wù)。）?旦?個事務(wù)被提交，它應該持久保存，不會因為與其他操作沖突?取消這個事務(wù)。從事務(wù)的四個特性可以看到關(guān)系型數(shù)據(jù)庫是要求強?致性的，但是這?點在數(shù)據(jù)庫中是重點弱化的機制。原因是當數(shù)據(jù)庫保存強?致性時，很難保證系統(tǒng)具有橫向擴展和可?性的優(yōu)勢，因此針對分布式數(shù)據(jù)存儲管理只提供了弱?致性的保障，即。BASE理論是針對數(shù)據(jù)庫??的，它是對理論中?致性（C）和可?性（A）進?權(quán)衡的結(jié)果，源于提出者??在?規(guī)模分布式系統(tǒng)上實踐的總結(jié)。其核?思想是?法做到強?致性，但每個應?都可以根據(jù)??的特點，采?適當?式達到最終?致性。）基本可?指分布式系統(tǒng)在出現(xiàn)故障時，系統(tǒng)允許損失部分可?性，即保證核?功能或者當前最重要功能可?。對于?戶來說，他們當前最關(guān)注的功能或者最常?的功能的可?性將會獲得保證，但是其他功能會被削弱。）軟狀態(tài)允許系統(tǒng)數(shù)據(jù)存在中間狀態(tài)，但不會影響系統(tǒng)的整體可?性，即允許不同節(jié)點的副本之間存在暫時的不?致情況。最終?致性（EventuallyConsistent）最終?致性要求系統(tǒng)中數(shù)據(jù)副本最終能夠?致，?不需要實時保證數(shù)據(jù)副本?致。例如，銀?系統(tǒng)中的?實時轉(zhuǎn)賬操作，允許24?時內(nèi)?戶賬戶的狀態(tài)在轉(zhuǎn)賬前后是不?致的，但24?時后賬戶數(shù)據(jù)必須正確。最終?致性是BASE原理的核?，也是NoSQL數(shù)據(jù)庫的主要特點，通過弱化?致性，提?系統(tǒng)的可伸縮性、可靠性和可?性。?且對于?多數(shù)Web應?，其實并不需要強?致性，因此犧牲?致性?換取?可?性，是多數(shù)分布式數(shù)據(jù)庫產(chǎn)品的?向。最終?致性可以分為客戶端和服務(wù)端兩個不同的視?。從客戶端來看，?致性主要指的是多并發(fā)訪問時更新過的數(shù)據(jù)如何獲取的問題，最終?致性有以下5個變種。說明如果進程A通知進程B它已更新了?個數(shù)據(jù)項，那么，進程B的后續(xù)訪問將返回更新后的值，且?次寫?將保證取代前?次寫?。與進程A?因果關(guān)系的進程C的訪問遵守?般的最終?致性規(guī)則。讀?之所寫（Read-當進程A??更新?個數(shù)據(jù)項之后，它總是訪問到更新過的值，且不會看到舊值。這是因果?致性模型的?個特例。這是上?個模型的實?版本，它把訪問存儲系統(tǒng)的進程放到會話的上下?中。只要會話還存在，系統(tǒng)就保證“讀?之所寫”?致性。如果由于某些失敗情形令會話終?，就要建?新的會話，?且系統(tǒng)保證不會延續(xù)到新的會話。如果進程已經(jīng)看到過數(shù)據(jù)對象的某個值，那么任何后續(xù)訪問都不會返回在那個值之前的值。系統(tǒng)保證來?同?個進程的寫操作順序執(zhí)?。單調(diào)寫?致性上述最終?致性的不同?式可以進?組合，例如，單調(diào)讀?致性和“讀?之所寫”?致性就可以組合實現(xiàn)。從實踐的?度來看，這兩者的組合讀取??更新的數(shù)據(jù)，?旦讀取到最新的版本，就不會再讀取舊版本，對基于此架構(gòu)上的程序開發(fā)來說，會減少很多額外的煩惱。從服務(wù)端來看，如何盡快地將更新后的數(shù)據(jù)分布到整個系統(tǒng)，降低達到最終?致性的時間窗?，是提?系統(tǒng)的可?度和?戶體驗度?常重要的??。分布式數(shù)據(jù)系統(tǒng)有以下特性：N為數(shù)據(jù)復制的份數(shù)。W為更新數(shù)據(jù)時需要進?寫操作的節(jié)點數(shù)。R為讀取數(shù)據(jù)的時候需要讀取的節(jié)點數(shù)。如果W+R>N，寫的節(jié)點和讀的節(jié)點重疊，則是強?致性。例如，對于典型的?主?備同步復制的關(guān)系型數(shù)據(jù)庫（N=2,W=2,R=1），則不管讀的是主庫還是備庫的數(shù)據(jù)，都是?致的。如果W+R≤N，則是弱?致性。例如，對于?主?備異步復制的關(guān)系型數(shù)據(jù)庫（N=2,W=1,R=1），如果讀的是備庫，則可能?法讀取主庫已經(jīng)更新過的數(shù)據(jù)，所以是弱?致性。對于分布式系統(tǒng)，為了保證?可?性，?般設(shè)置N≥3。設(shè)置不同的N、W、R組合，是在可?性和?致性之間取?個平衡，以適應不同的應?場景。如果N=W且R=1，則任何?個寫節(jié)點失效，都會導致寫失敗，因此可?性會降低。但是由于數(shù)據(jù)分布的N個節(jié)點是同步寫?的，因此可以保證強?致性。如果N=R且W=1，則只需要?個節(jié)點寫?成功即可，寫性能和可?性都?較?。但是讀取其他節(jié)點的進程可能不能獲取更新后的數(shù)據(jù)，因此是弱?致性。在這種情況下，如果W＜(N+1)/2，并且寫?的節(jié)點不重疊，則會存在寫沖突。NoSQL關(guān)系型數(shù)據(jù)庫產(chǎn)品很多，如、Oracle、MicrosoftSQLSever等，但它們的基本模型都是關(guān)系型數(shù)據(jù)模型。并沒有統(tǒng)?的模型，?且是?關(guān)系型的。常見的NoSQL數(shù)據(jù)庫包括鍵值數(shù)據(jù)庫、列族數(shù)據(jù)庫、?檔數(shù)據(jù)庫和圖形數(shù)據(jù)庫，其具體分類和特點如表所?。應?場景數(shù)據(jù)模型優(yōu)點缺點鍵值數(shù)據(jù)庫<key,value>鍵值對，通過散列表來實現(xiàn)擴展性好，靈活性好，?量操作時性能?內(nèi)容緩存，如會話、配置?件、參數(shù)等；頻繁讀寫、擁有簡單數(shù)據(jù)模型的應?數(shù)據(jù)?結(jié)構(gòu)化，通常只被當做字符串或者?進制數(shù)據(jù)，只能通過鍵來查詢值列族以列族式存儲，將同數(shù)據(jù)模型可擴展性強，查找速優(yōu)點、分布式數(shù)據(jù)存儲與管理應?場景功能局限，不?持事務(wù)的強?致性缺點相關(guān)產(chǎn)品?列數(shù)據(jù)存在?起度快，復雜性低Cassandra?檔數(shù)據(jù)庫、<key,value>value靈活，可以根據(jù)value構(gòu)建索引缺乏統(tǒng)?查詢語法圖形數(shù)據(jù)庫社交?絡(luò)、推薦系統(tǒng)，專注構(gòu)建關(guān)系圖譜圖結(jié)構(gòu)?持復雜的圖形算法復雜性?，只能?持?定的數(shù)據(jù)規(guī)模NoSQL數(shù)據(jù)庫并沒有?個統(tǒng)?的架構(gòu)，兩種不同的NoSQL數(shù)據(jù)庫之間的差異程度，遠遠超過兩種關(guān)系型數(shù)據(jù)庫之間的不同?？梢哉f，NoSQL數(shù)據(jù)庫各有所長，?個優(yōu)秀的NoSQL數(shù)據(jù)庫必然特別適?于某些場合或者某些應?，在這些場合中會遠遠勝過關(guān)系型數(shù)據(jù)庫和其他的NoSQL數(shù)據(jù)庫。常見的NoSQL數(shù)據(jù)庫分為以下?種。這?類數(shù)據(jù)庫主要會使?到?個散列表，這個表中有?個特定的鍵和?個指針指向特定的數(shù)據(jù)。鍵值模型對于IT系統(tǒng)來說，其優(yōu)勢在于簡單、易部署。鍵值數(shù)據(jù)庫可以按照鍵對數(shù)據(jù)進?定位，還可以通過對鍵進?排序和分區(qū)，以實現(xiàn)更快速的數(shù)據(jù)定位。列族數(shù)據(jù)庫通常?來應對分布式存儲的海量數(shù)據(jù)。鍵仍然存在，但是它們的特點是指向了多個列，如圖所?。此列族數(shù)據(jù)庫表中由兩?組成，每??都有關(guān)鍵字RowKey，每??由多個列族組成，即Column-Family-1和Column-Family-2，?每個列族由多個列組成。?檔數(shù)據(jù)庫的靈感來?LotusNotes辦公軟件，它與鍵值數(shù)據(jù)庫類似。該類型的數(shù)據(jù)模型是版本化的?檔，?檔以特定的格式存儲，如JSON。?檔數(shù)據(jù)庫可以看作鍵值數(shù)據(jù)庫的升級版，允許之間嵌套鍵值，如圖所?。?檔數(shù)據(jù)庫?鍵值數(shù)據(jù)庫的查詢效率更?，因為?檔數(shù)據(jù)庫不僅可以根據(jù)鍵創(chuàng)建索引，同時還可以根據(jù)?檔內(nèi)容創(chuàng)建索引。圖形數(shù)據(jù)庫來源于圖論中的拓撲學，以節(jié)點、邊及節(jié)點之間的關(guān)系來存儲復雜?絡(luò)中的數(shù)據(jù)，如圖所?。這種拓撲結(jié)構(gòu)類似E-R圖，但在圖形模式中，關(guān)系和節(jié)點本?就是數(shù)據(jù)，?在E-R圖中，關(guān)系描述的是?種結(jié)構(gòu)。內(nèi)存數(shù)據(jù)庫主要是把磁盤的數(shù)據(jù)加載到內(nèi)存中進?相應操作。與直接讀取磁盤數(shù)據(jù)相?，內(nèi)存的數(shù)據(jù)讀取速度要?出?個數(shù)量級，因此，將數(shù)據(jù)保存在內(nèi)存中能夠極?地提?應?的性能。內(nèi)存數(shù)據(jù)庫改變了磁盤數(shù)據(jù)管理的傳統(tǒng)?式，基于全部數(shù)據(jù)都在內(nèi)存中的特點重新設(shè)計了體系結(jié)構(gòu)，并且在數(shù)據(jù)緩存、快速算法、并?操作??也進?了相應的升級，因此，其數(shù)據(jù)處理速度?般?傳統(tǒng)數(shù)據(jù)庫的數(shù)據(jù)處理速度快??倍。內(nèi)存數(shù)據(jù)庫的最?特點是其應?數(shù)據(jù)常駐內(nèi)存中，即活動事務(wù)只與實時內(nèi)存數(shù)據(jù)庫的內(nèi)存進?數(shù)據(jù)交流。常見的內(nèi)存數(shù)據(jù)庫有Memcached、、SQLite、MicrosoftSQLServerCompact等。Memcached是LiveJournal旗下DangaInteractive公司的布拉德·菲茨帕特?克（BradFitzpatric）開發(fā)的?款，現(xiàn)在已被應?于Facebook、LiveJournal等公司?于提?Web服務(wù)質(zhì)量。?前這款軟件流?于全球各地，經(jīng)常被?來建?緩存項?，并以此分擔來?傳統(tǒng)數(shù)據(jù)庫的并發(fā)負載壓?。Memcached可以輕松應對?量同時出現(xiàn)的數(shù)據(jù)請求，?且它擁有獨特的?絡(luò)結(jié)構(gòu)，在?作機制??，它還可以在內(nèi)存中單獨開辟新的空間，建?HashTable，并對HashTable進?有效的管理。我們有時會見到Memcache和Memcached兩種不同的說法，為什么會有兩種名稱？其實Memcache是這個項?的名稱，?Memcached是它服務(wù)器端的主程序?件名。?個是項?名稱，另?個是主程序?件名。為什么要使?Memcached由于?站的?并發(fā)讀寫和對海量數(shù)據(jù)的處理需求，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫開始出現(xiàn)瓶頸。關(guān)系型數(shù)據(jù)庫本?就是個龐然?物，處理過程?常耗時（如解析SQL語句、事務(wù)處理等）。如果對關(guān)系型數(shù)據(jù)庫進??并發(fā)讀寫（每秒上萬次的訪問），數(shù)據(jù)庫系統(tǒng)是?法承受的。對于?型的SNS?站（如Twitter、新浪微博），每天有上千萬條的數(shù)據(jù)產(chǎn)?。對關(guān)系型數(shù)據(jù)庫??，如果在?個有上億條數(shù)據(jù)的數(shù)據(jù)表中查找某條記錄，效率將?常低。使?Memcached就能很好地解決以上問題。多數(shù)Web應?都將數(shù)據(jù)保存到關(guān)系型數(shù)據(jù)庫中（如），Web服務(wù)器從中讀取數(shù)據(jù)并在瀏覽器中顯?。但隨著數(shù)據(jù)量的增?，訪問的集中，關(guān)系型數(shù)據(jù)庫的負擔就會加重，岀現(xiàn)響應緩慢、?站打開延遲時間長等問題。因此，使?Memcached的主要?的是通過??內(nèi)存中緩存關(guān)系型數(shù)據(jù)庫的查詢結(jié)果，減少數(shù)據(jù)庫??被訪問的次數(shù)，以提?動態(tài)Web應?的速度，增強?站架構(gòu)的并發(fā)能?和可擴展性。通過在事先規(guī)劃好的系統(tǒng)內(nèi)存空間中臨時緩存數(shù)據(jù)庫中的各類數(shù)據(jù)，以達到減少前端業(yè)務(wù)服務(wù)對關(guān)系型數(shù)據(jù)庫的直接?并發(fā)訪問，從?達到提升?規(guī)模?站集群中動態(tài)服務(wù)的并發(fā)訪問能?。Web服務(wù)器讀取數(shù)據(jù)時先讀Memcached服務(wù)器，若Memcached沒有所需的數(shù)據(jù)，則向數(shù)據(jù)庫請求數(shù)據(jù)，然后Web再把請求到的數(shù)據(jù)發(fā)送到Memcached，如下圖所?。是?個開源的、?性能的、鍵值對。它通過提供多種鍵值數(shù)據(jù)類型來滿?不同場景下的存儲需求，并借助許多?層級的接?使其可以勝任如緩存、隊列系統(tǒng)等不同的??。本?節(jié)將介紹Redis的歷史和特性，以使讀者能夠快速地對Redis有?個全?的了解。2008年，意?利的?家創(chuàng)業(yè)公司Merzia推出了?款基于的?站實時統(tǒng)計系統(tǒng)——LLOOGG，然?沒過多久，該公司的創(chuàng)始?薩爾?托·桑菲利普（SalvatoreSanfilippo）便對這個系統(tǒng)的性能感到失望，于是他決定親?為LLOOGG量?定做?個數(shù)據(jù)庫，并于2009年開發(fā)完成，這個數(shù)據(jù)庫就是Redis。不過薩爾?托并不滿?只將Redis?于LLOOGG這?款產(chǎn)品，?是希望讓更多的?使?它，于是薩爾?托將Redis開源發(fā)布，并開始和Redis的另?名主要的代碼貢獻者?特·諾德胡斯（PieterNoordhuis）?起繼續(xù)著Redis的開發(fā)，直到今天。薩爾?托??也沒有想到，在短短的?年時間內(nèi)，Redis就擁有了龐?的?戶群體。HackedNews在2012年發(fā)布了?份數(shù)據(jù)庫的使?情況調(diào)查，結(jié)果顯?有近12%的公司在使?Redis。國內(nèi)如新浪微博和知乎，國外如GitHub、StackOverflow、Flickr、暴雪和Instagram，都是Redis的?戶。現(xiàn)在使?Redis的?戶越來越多，?多數(shù)的互聯(lián)?公司都使?Redis作為公共緩存。VMware公司從2010年開始贊助Redis的開發(fā)，薩爾?托和?特也分別于同年的3?和5?加?VMware，全職開發(fā)Redis。有過腳本語?編程經(jīng)驗的讀者對字典（或稱映射、關(guān)聯(lián)數(shù)組）?定很熟悉，如在代碼dict[“key”]=“value”中，“diet”是?個字典結(jié)構(gòu)變量，字符串“key”是鍵名，?“value”是鍵值，在字典中可以獲取或設(shè)置鍵名對應的鍵值，也可以刪除?個鍵。Redis是RemoteDictionaryServer（遠程字典服務(wù)器）的縮寫，它以字典結(jié)構(gòu)存儲數(shù)據(jù)，并允許其他應?通過TCP讀寫字典中的內(nèi)容。同?多數(shù)腳本語?中的字典?樣，Redis字典中的鍵值除了可以是字符串，還可以是其他數(shù)據(jù)類型。到?前為?，Redis?持的鍵值數(shù)據(jù)類型有：字符串類型、散列類型、列表類型、集合類型和有序集合類型。這種字典形式的存儲結(jié)構(gòu)與常見的MySQL等關(guān)系數(shù)據(jù)庫的?維表形式的存儲結(jié)構(gòu)有很?的差異。舉個例?，在程序中使?post變量存儲了?篇?章的數(shù)據(jù)（包括標題、正?、閱讀量和標簽），如下所?：post["tags"]=["PHP","Ruby","Node.js"]現(xiàn)在希望將這篇?章的數(shù)據(jù)存儲在數(shù)據(jù)庫中，并且要求可以通過標簽檢索岀?章。如果使?關(guān)系數(shù)據(jù)庫存儲，?般會將其中的標題、正?和閱讀量存儲在?個表中，?將標簽存儲在另?個表中，然后使?第三個表連接?章和標簽表。需要查詢時還需要連接三個表，不是很直觀。?Redis字典結(jié)構(gòu)的存儲?式和對多種鍵值數(shù)據(jù)類型的?持使得開發(fā)者可以將程序中的數(shù)據(jù)直接映射到Redis中，數(shù)據(jù)在Redis中的存儲形式和其在程序中的存儲?式?常相似。使?Redis的另?個優(yōu)勢是其對不同的數(shù)據(jù)類型提供了?常?便的操作?式，如使?集合類型存儲?章標簽，Redis可以對標簽進?如交集、并集等集合運算操作。Redis數(shù)據(jù)庫中的所有數(shù)據(jù)都存儲在內(nèi)存中。由于內(nèi)存的讀寫速度遠?于硬盤，因此Redis在性能上與其他基于硬盤存儲的數(shù)據(jù)庫相?有?常明顯的優(yōu)勢。在?臺普通的筆記本電腦上，Redis可以在?秒內(nèi)讀寫超過10萬個鍵值。將數(shù)據(jù)存儲在內(nèi)存中也有問題，例如，程序退出后內(nèi)存中的數(shù)據(jù)會丟失。不過Redis提供了對持久化的?持，即可以將內(nèi)存中的數(shù)據(jù)異步寫?硬盤中，同時不影響其繼續(xù)提供服務(wù)。Redis雖然是作為數(shù)據(jù)庫開發(fā)的，但由于其提供了豐富的功能，越來越多的?將其?作緩存、隊列系統(tǒng)等。Redis可謂是名副其實的多??。Redis可以為每個鍵設(shè)置?存時間（TimeToLive,TTL），?存時間到期后鍵會?動被刪除。這?功能配合出?的性能讓Redis可以作為緩存系統(tǒng)來使?，?且由于Redis?持持久化和豐富的數(shù)據(jù)類型，使其成為另?個?常流?的緩存系統(tǒng)Memcached的有?競爭者。討論Redis和Memcached的優(yōu)劣?直是?個熱門的話題。由于Redis是單線程模型，?Memcached?持多線程，所以在多核服務(wù)器上后者的性能更??些。然?，前?已經(jīng)介紹過，Redis的性能已經(jīng)?夠優(yōu)異，在絕?部分場合下其性能都不會成為瓶頸。所以在使?時更應該關(guān)?的是?者在功能上的區(qū)別，如果需要?到?級的數(shù)據(jù)類型或持久化等功能，Redis將會是Memcached很好的替代品。作為緩存系統(tǒng)，Redis還可以限定數(shù)據(jù)占?的最?內(nèi)存空間，在數(shù)據(jù)達到空間限制后可以按照?定的規(guī)則?動淘汰不需要的鍵。除此之外，Redis的列表類型鍵可以?來實現(xiàn)隊列，?持阻塞式讀取，并且可以很容易地實現(xiàn)?個?性能的優(yōu)先級隊列。同時，在更?層?上，Redis還?持“發(fā)布/訂閱”的消息模式，?戶可以基于此構(gòu)建聊天室等系統(tǒng)。如果?個?具使?起來太復雜，即使它的功能再豐富也很難吸引?。Redis直觀的存儲結(jié)構(gòu)使其通過程序與Redis交互?分簡單。在Redis中使?命令來讀寫數(shù)據(jù)，命令語句之于Redis就相當于SQL之于關(guān)系數(shù)據(jù)庫。例如，在關(guān)系數(shù)據(jù)庫中要獲取posts表內(nèi)id為1的記錄的title字段的值，可以使?如下SQL語句實現(xiàn)：SELECTtitleFROMpostsWHEREid=1LIMIT1相對應的，在Redis中要讀取鍵名為post:1的散列類型鍵的title字段的值，可以使?如下命令語句實現(xiàn)：HGETpost:1title其中，HGET就是?個命令。Redis提供了100多個命令，但是常?的只有??個，并且每個命令都很容易記住。Redis提供了??種不同編程語?的客戶端庫，這些庫都封裝了Redis的命令，這樣在程序中與Redis進?交互變得很容易。有些庫還提供了可以將編程語?中的數(shù)據(jù)類型直接以相應的形式存儲到Redis中（如將數(shù)組直接以列表類型存?Redis）的簡單?法，使?起來?常?便。Redis使?C語?開發(fā)，代碼量只有3萬多?。這降低了?戶通過修改Redis源代碼來使之更適合??項?需要的門檻。對于希望“榨?”數(shù)據(jù)庫性能的開發(fā)者??，這?疑具有很?的吸引?。Redis是開源的，有將近100名開發(fā)者為Redis貢獻了代碼。良好的開發(fā)氛圍和嚴謹?shù)陌姹景l(fā)布機制使得Redis的穩(wěn)定版本的性能?常可靠，如此多的公司選擇使?Redis也可以印證這?點。與Memcached與Redis的?較見下表。數(shù)據(jù)庫MemcachedRedisCPU?持多核單核內(nèi)存利?率持久性數(shù)據(jù)結(jié)構(gòu)簡單?作環(huán)境Linux/WindowsLinux??低（壓縮?Memcached?）有（硬盤存儲，主從同步）復雜四、分布式系統(tǒng)分布式系統(tǒng)是由?組通過?絡(luò)進?通信、為了完成共同的任務(wù)?協(xié)調(diào)?作的計算機節(jié)點組成的系統(tǒng)。分布式系統(tǒng)的出現(xiàn)是為了?廉價的、普通的機器完成單個計算機?法完成的計算、存儲任務(wù)。其?的是利?更多的機器，處理更多的數(shù)據(jù)。?先需要明確的是，只有當單個節(jié)點的處理能??法滿??益增長的計算、存儲任務(wù)的時候，且硬件的提升（加內(nèi)存、加磁盤、使?更好的CPU）?昂到得不償失的時候，應?程序也不能進?步優(yōu)化的時候，我們才需要考慮分布式系統(tǒng)。因為，分布式系統(tǒng)要解決的問題本?就是和單機系統(tǒng)?樣的，?由于分布式系統(tǒng)多節(jié)點、通過?絡(luò)通信的拓撲結(jié)構(gòu)，會引?很多單機系統(tǒng)沒有的問題，為了解決這些問題?會引?更多的機制、協(xié)議，帶來更多的問題。。。在很多?章中，主要講分布式系統(tǒng)分為分布式計算（computation）與分布式存儲（storage）。計算與存儲是相輔相成的，計算需要數(shù)據(jù)，要么來?實時數(shù)據(jù)（流數(shù)據(jù)），要么來?存儲的數(shù)據(jù)；?計算的結(jié)果也是需要存儲的。在操作系統(tǒng)中，對計算與存儲有?常詳盡的討論，分布式系統(tǒng)只不過將這些理論推?到多個節(jié)點罷了。那么分布式系統(tǒng)怎么將任務(wù)分發(fā)到這些計算機節(jié)點呢，很簡單的思想，分?治之，即分?（partition）。對于計算，那么就是對計算任務(wù)進?切換，每個節(jié)點算?些，最終匯總就?了，這就是MapReduce的思想；對于存儲，更好理解?下，每個節(jié)點存?部分數(shù)據(jù)就?了。當數(shù)據(jù)規(guī)模變?的時候，Partition是唯?的選擇，同時也會帶來?些好處：（1）提升性能和并發(fā)，操作被分發(fā)到不同的分?，相互獨?（2）提升系統(tǒng)的可?性，即使部分分?不能?，其他分?不會受到影響理想的情況下，有分?就?了，但事實的情況卻不?理想。原因在于，分布式系統(tǒng)中有?量的節(jié)點，且通過?絡(luò)通信。單個節(jié)點的故障（進程crash、斷電、磁盤損壞）是個?概率事件，但整個系統(tǒng)的故障率會隨節(jié)點的增加?指數(shù)級增加，?絡(luò)通信也可能出現(xiàn)斷?、?延遲的情況。在這種?定會出現(xiàn)的“異?！鼻闆r下，分布式系統(tǒng)還是需要繼續(xù)穩(wěn)定的對外提供服務(wù)，即需要較強的容錯性。最簡單的辦法，就是冗余或者復制集（Replication），即多個節(jié)點負責同?個任務(wù)，最為常見的就是分布式存儲中，多個節(jié)點復雜存儲同?份數(shù)據(jù)，以此增強可?性與可靠性。同時，Replication也會帶來性能的提升，?如數(shù)據(jù)的locality可以減少?戶的等待時間。下?這種來?的圖形象?動說明了Partition與Replication是如何協(xié)作的。Partition和Replication是解決分布式系統(tǒng)問題的?記組合拳，很多具體的問題都可以?這個思路去解決。但這并不是銀彈，往往是為了解決?個問題，會引?更多的問題，?如為了可?性與可靠性保證，引?了冗余（復制集）。有了冗余，各個副本間的?致性問題就變得很頭疼，?致性在系統(tǒng)的?度和?戶的?度?有不同的等級劃分。如果要保證強?致性，那么會影響可?性與性能，在?些應?（?如電商、搜索）是難以接受的。如果是最終?致性，那么就需要處理數(shù)據(jù)沖突的情況。CAP、FLP這些理論告訴我們，在分布式系統(tǒng)中，沒有最佳的選擇，都是需要權(quán)衡，做出最合適的選擇。分布式系統(tǒng)挑戰(zhàn)分布式系統(tǒng)需要?量機器協(xié)作，?臨諸多的挑戰(zhàn)：第?，異構(gòu)的機器與?絡(luò)：分布式系統(tǒng)中的機器，配置不?樣，其上運?的服務(wù)也可能由不同的語?、架構(gòu)實現(xiàn)，因此處理能?也不?樣；節(jié)點間通過?絡(luò)連接，?不同?絡(luò)運營商提供的?絡(luò)的帶寬、延時、丟包率?不?樣。怎么保證?家齊頭并進，共同完成?標，這四個不?的挑戰(zhàn)。第?，普遍的節(jié)點故障：雖然單個節(jié)點的故障概率較低，但節(jié)點數(shù)?達到?定規(guī)模，出故障的概率就變?了。分布式系統(tǒng)需要保證故障發(fā)?的時候，系統(tǒng)仍然是可?的，這就需要監(jiān)控節(jié)點的狀態(tài)，在節(jié)點故障的情況下將該節(jié)點負責的計算、存儲任務(wù)轉(zhuǎn)移到其他節(jié)點第三，不可靠的?絡(luò)：節(jié)點間通過?絡(luò)通信，??絡(luò)是不可靠的?？赡艿?絡(luò)問題包括：?絡(luò)分割、延時、丟包、亂序。相?單機過程調(diào)?，?絡(luò)通信最讓?頭疼的是超時：節(jié)點A向節(jié)點B發(fā)出請求，在約定的時間內(nèi)沒有收到節(jié)點B的響應，那么B是否處理了請求，這個是不確定的，這個不確定會帶來諸多問題，最簡單的，是否要重試請求，節(jié)點B會不會多次處理同?個請求?？??之，分布式的挑戰(zhàn)來?不確定性，不確定計算機什么時候crash、斷電，不確定磁盤什么時候損壞，不確定每次?絡(luò)通信要延遲多久，也不確定通信對端是否處理了發(fā)送的消息。?分布式的規(guī)模放?了這個不確定性，不確定性是令?討厭的，所以有諸多的分布式理論、協(xié)議來保證在這種不確定性的情況下，系統(tǒng)還能繼續(xù)正常?作。?且，很多在實際系統(tǒng)中出現(xiàn)的問題，來源于設(shè)計時的盲?樂觀，覺得這個、那個應該不會出問題。很有意思，介紹了分布式系統(tǒng)新?可能的錯誤的假設(shè)：Thenetworkissecure.Topologydoesn’tchange.Thereisoneadministrator.Transportcostiszero.Thenetworkishomogeneous.劉杰在《分布式系統(tǒng)原理介紹》中指出，處理這些異常的最佳原則是：在設(shè)計、推導、驗證分布式系統(tǒng)的協(xié)議、流程時,最重要的?作之?就是思考在執(zhí)?流程的每個步驟時?旦發(fā)?各種異常的情況下系統(tǒng)的處理?式及造成的影響。Adistributedsystemisacollectionofindependentcomputersthatappearstoitsusersasasinglecoherentsystem.可擴展性：分布式系統(tǒng)的根本?標就是為了處理單個計算機?法處理的任務(wù)，當任務(wù)增加的時候，分布式系統(tǒng)的處理能?需要隨之增加。簡單來說，要?較?便的通過增加機器來應對數(shù)據(jù)量的增長，同時，當任務(wù)規(guī)?？s減的時候，可以撤掉?些多余的機器，達到動態(tài)伸縮的效果可?性與可靠性：?般來說，分布式系統(tǒng)是需要長時間甚?7*24?時提供服務(wù)的。可?性是指系統(tǒng)在各種情況對外提供服務(wù)的能?，簡單來說，可以通過不可?時間與正常服務(wù)時間的必知來衡量；?可靠性?是指計算結(jié)果正確、存儲的數(shù)據(jù)不丟失。?性能：不管是單機還是分布式系統(tǒng)，?家都?常關(guān)注性能。不同的系統(tǒng)對性能的衡量指標是不同的，最常見的：?并發(fā)，單位時間內(nèi)處理的任務(wù)越多越好；低延遲：每個任務(wù)的平均時間越少越好。這個其實跟操作系統(tǒng)CPU的調(diào)度策略很像?致性：分布式系統(tǒng)為了提?可?性可靠性，?般會引?冗余（復制集）。那么如何保證這些節(jié)點上的狀態(tài)?致，這就是分布式系統(tǒng)不得不?對的?致性問題。?致性有很多等級，?致性越強，對?戶越友好，但會制約系統(tǒng)的可?性；?致性等級越低，?戶就需要兼容數(shù)據(jù)不?致的情況，但系統(tǒng)的可?性、并發(fā)性很?很多。假設(shè)這是?個對外提供服務(wù)的?型分布式系統(tǒng)，?戶連接到系統(tǒng)，做?些操作，產(chǎn)??些需要存儲的數(shù)據(jù)，那么在這個過程中，會遇到哪些組件、理論與協(xié)議呢?戶使?Web、APP、SDK，通過HTTP、TCP連接到系統(tǒng)。在分布式系統(tǒng)中，為了?并發(fā)、?可?，?般都是多個節(jié)點提供相同的服務(wù)。那么，第?個問題就是具體選擇哪個節(jié)點來提供服務(wù)，這個就是負載均衡（loadbalance）。負載均衡的思想很簡單，但使??常?泛，在分布式系統(tǒng)、?型?站的????都有使?，或者說，只要涉及到多個節(jié)點提供同質(zhì)的服務(wù)，就需要負載均衡。通過負載均衡找到?個節(jié)點，接下來就是真正處理?戶的請求，請求有可能簡單，也有可能很復雜。簡單的請求，?如讀取數(shù)據(jù)，那么很可能是有緩存的，即分布式緩存，如果緩存沒有命中，那么需要去數(shù)據(jù)庫拉取數(shù)據(jù)。對于復雜的請求，可能會調(diào)?到系統(tǒng)中其他的服務(wù)。承上，假設(shè)服務(wù)A需要調(diào)?服務(wù)B的服務(wù)，?先兩個節(jié)點需要通信，?絡(luò)通信都是建?在TCP/IP協(xié)議的基礎(chǔ)上，但是，每個應?都?寫socket是?件冗雜、低效的事情，因此需要應?層的封裝，因此有了HTTP、FTP等各種應?層協(xié)議。當系統(tǒng)愈加復雜，提供?量的http接?也是?件困難的事情。因此，有了更進?步的抽象，那就是RPC（