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

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