平臺體系構(gòu)架

1、電子商務(wù)平臺構(gòu)架一、設(shè)計(jì)理念空間換時間1）多級緩存，靜態(tài)化客戶端頁面緩存（httpheader中包含Expires/CacheofControl,lastmodified（304,server不返回body，客戶端可以繼續(xù)用cache，減少流量），ETag）反向代理緩存應(yīng)用端的緩存（memcache）內(nèi)存數(shù)據(jù)庫Buffer、cache機(jī)制（數(shù)據(jù)庫，中間件等）2）索引哈希、B樹、倒排、bitmap哈希索引適合綜合數(shù)組的尋址和鏈表的插入特性，可以實(shí)現(xiàn)數(shù)據(jù)的快速存取。B樹索引適合于查詢?yōu)橹鲗?dǎo)的場景，避免多次的10,提髙查詢的效率。倒排索引實(shí)現(xiàn)單詞到文檔映射關(guān)系的最佳實(shí)現(xiàn)方式和最有效的索引結(jié)構(gòu)，廣泛用

2、在搜索領(lǐng)域。Bitmap是一種非常簡潔快速的數(shù)據(jù)結(jié)構(gòu)，他能同時使存儲空間和速度最優(yōu)化（而不必空間換時間），適合于海量數(shù)據(jù)的的計(jì)算場景。并行與分布式計(jì)算1）任務(wù)切分、分而治之（MR）在大規(guī)模的數(shù)據(jù)中，數(shù)據(jù)存在一定的局部性的特征，利用局部性的原理將海量數(shù)據(jù)計(jì)算的問題分而治之。MR模型是無共享的架構(gòu)，數(shù)據(jù)集分布至各個節(jié)點(diǎn)。處理時，每個節(jié)點(diǎn)就近讀取本地存儲的數(shù)據(jù)處理(map)，將處理后的數(shù)據(jù)進(jìn)行合并(combine)、排序(shuffleandsort)后再分發(fā)(至reduce節(jié)點(diǎn))，避免了大量數(shù)據(jù)的傳輸，提高了處理效率。2)多進(jìn)程、多線程并行執(zhí)行(MPP)并行計(jì)算(ParallelComputing

3、)是指同時使用多種計(jì)算資源解決計(jì)算問題的過程，是提高計(jì)算機(jī)系統(tǒng)計(jì)算速度和處理能力的一種有效手段。它的基本思想是用多個處理器/進(jìn)程/線程來協(xié)同求解同一問題，即將被求解的問題分解成若干個部分，各部分均由一個獨(dú)立的處理機(jī)來并行計(jì)算。和MR的區(qū)別在于，它是基于問題分解的，而不是基于數(shù)據(jù)分解。多維度的可用負(fù)載均衡、容災(zāi)、備份隨著平臺并發(fā)量的增大，需要擴(kuò)容節(jié)點(diǎn)進(jìn)行集群，利用負(fù)載均衡設(shè)備進(jìn)行請求的分發(fā)；負(fù)載均衡設(shè)備通常在提供負(fù)載均衡的同時，也提供失效檢測功能；同時為了提高可用性，需要有容災(zāi)備份，以防止節(jié)點(diǎn)宕機(jī)失效帶來的不可用問題；備份有在線的和離線備份，可以根據(jù)失效性要求的不同，進(jìn)行選擇不同的備份策略。讀寫

4、分離讀寫分離是對數(shù)據(jù)庫來講的，隨著系統(tǒng)并發(fā)量的增大，提髙數(shù)據(jù)訪問可用性的一個重要手段就是寫數(shù)據(jù)和讀數(shù)據(jù)進(jìn)行分離；當(dāng)然在讀寫分離的同時，需要關(guān)注數(shù)據(jù)的一致性問題；對于一致性的問題，在分布式的系統(tǒng)CAP定量中，更多的關(guān)注于可用性。依賴關(guān)系平臺中各個模塊之間的關(guān)系盡量是低耦合的，可以通過相關(guān)的消息組件進(jìn)行交互，能異步則異步，分清楚數(shù)據(jù)流轉(zhuǎn)的主流程和副流程，主副是異步的，比如記錄日志可以是異步操作的，增加整個系統(tǒng)的可用性。當(dāng)然在異步處理中，為了確保數(shù)據(jù)得到接收或者處理，往往需要確認(rèn)機(jī)制（confirm、ack）。但是有些場景中，雖然請求已經(jīng)得到處理，但是因其他原因（比如網(wǎng)絡(luò)不穩(wěn)定），確認(rèn)消息沒有返回，

5、那么這種情況下需要進(jìn)行請求的重發(fā)，對請求的處理設(shè)計(jì)因重發(fā)因素需要考慮冪等性。4）監(jiān)控監(jiān)控也是提高整個平臺可用性的一個重要手段，多平臺進(jìn)行多個維度的監(jiān)控；模塊在運(yùn)行時候是透明的，以達(dá)到運(yùn)行期白盒化。伸縮1）拆分拆分包括對業(yè)務(wù)的拆分和對數(shù)據(jù)庫的拆分。系統(tǒng)的資源總是有限的，一段比較長的業(yè)務(wù)執(zhí)行如果是一竿子執(zhí)行的方式，在大量并發(fā)的操作下，這種阻塞的方式，無法有效的及時釋放資源給其他進(jìn)程執(zhí)行，這樣系統(tǒng)的吞吐量不高。需要把業(yè)務(wù)進(jìn)行邏輯的分段，采用異步非阻塞的方式，提高系統(tǒng)的吞吐量。隨著數(shù)據(jù)量和并發(fā)量的增加，讀寫分離不能滿足系統(tǒng)并發(fā)性能的要求，需要對數(shù)據(jù)進(jìn)行切分，包括對數(shù)據(jù)進(jìn)行分庫和分表。這種分庫分表的方式

6、，需要增加對數(shù)據(jù)的路由邏輯支持。2）無狀態(tài)對于系統(tǒng)的伸縮性而言，模塊最好是無狀態(tài)的，通過增加節(jié)點(diǎn)就可以提高整個的吞吐量。優(yōu)化資源利用1）系統(tǒng)容量有限系統(tǒng)的容量是有限的，承受的并發(fā)量也是有限的，在架構(gòu)設(shè)計(jì)時，一定需要考慮流量的控制，防止因意外攻擊或者瞬時并發(fā)量的沖擊導(dǎo)致系統(tǒng)崩潰。在設(shè)計(jì)時增加流控的措施，可考慮對請求進(jìn)行排隊(duì)，超出預(yù)期的范圍，可以進(jìn)行告警或者丟棄。2）原子操作與并發(fā)控制對于共享資源的訪問，為了防止沖突，需要進(jìn)行并發(fā)的控制，同時有些交易需要有事務(wù)性來保證交易的一致性，所以在交易系統(tǒng)的設(shè)計(jì)時，需考慮原子操作和并發(fā)控制。保證并發(fā)控制一些常用高性能手段有，樂觀鎖、Latch、mutex、寫

7、時復(fù)制、CAS等；多版本的并發(fā)控制MVCC通常是保證一致性的重要手段，這個在數(shù)據(jù)庫的設(shè)計(jì)中經(jīng)常會用到。3）基于邏輯的不同，采取不一樣的策略平臺中業(yè)務(wù)邏輯存在不同的類型，有計(jì)算復(fù)雜型的，有消耗IO型的，同時就同一種類型而言，不同的業(yè)務(wù)邏輯消耗的資源數(shù)量也是不一樣的，這就需要針對不同的邏輯采取不同的策略。針對IO型的，可以采取基于事件驅(qū)動的異步非阻塞的方式，單線程方式可以減少線程的切換引起的開銷，或者在多線程的情況下采取自旋spin的方式，減少對線程的切換（比如oraclelatch設(shè)計(jì)）；對于計(jì)算型的，充分利用多線程進(jìn)行操作。同一類型的調(diào)用方式，不同的業(yè)務(wù)進(jìn)行合適的資源分配，設(shè)置不同的計(jì)算節(jié)點(diǎn)數(shù)

8、量或者線程數(shù)量，對業(yè)務(wù)進(jìn)行分流，優(yōu)先執(zhí)行優(yōu)先級別高的業(yè)務(wù)。4）容錯隔離系統(tǒng)的有些業(yè)務(wù)模塊在出現(xiàn)錯誤時，為了減少并發(fā)下對正常請求的處理的影響，有時候需要考慮對這些異常狀態(tài)的請求進(jìn)行單獨(dú)渠道的處理，甚至?xí)簳r自動禁止這些異常的業(yè)務(wù)模塊。有些請求的失敗可能是偶然的暫時的失敗（比如網(wǎng)絡(luò)不穩(wěn)定），需要進(jìn)行請求重試的考慮。5）資源釋放系統(tǒng)的資源是有限的，在使用資源時，一定要在最后釋放資源，無論是請求走的是正常路徑還是異常的路徑，以便于資源的及時回收供其他請求使用。admirL/GonfigrnonitorF5斗囲l-lginxrJSlvarniishCDMLB/Praxy/CachfiApp-tomca七j

9、bc55eprinstrutsSdsploy在設(shè)靜態(tài)架構(gòu)藍(lán)圖需要考慮超時的控制。對整個平三、部署和監(jiān)控。:minaspring.itutis將由1HAzoiDk&gp-rroirterZDDk&epsrh-e-artb-iestFlumeMQCacherabbitMQmemMQhe|Salr/lucen-&IMRTS-tormiTiDgileFsuraczle-ffnysqlhadDophhasemongodbecfim整個架構(gòu)是分層的分布式的架構(gòu)，縱向包括CDN,負(fù)載均衡/反向代理，web應(yīng)用，業(yè)務(wù)層，基礎(chǔ)服務(wù)層，數(shù)據(jù)存儲層。水平方向包括1.CDNCDN系統(tǒng)能夠?qū)崟r地根據(jù)網(wǎng)絡(luò)流量和各節(jié)點(diǎn)的連

10、接、負(fù)載狀況以及到用戶的距離和響應(yīng)時間等綜合信息將用戶的請求重新導(dǎo)向離用戶最近的服務(wù)節(jié)點(diǎn)上。其目的是使用戶可就近取得所需內(nèi)容，解決Internet網(wǎng)絡(luò)擁擠的狀況，提髙用戶訪問網(wǎng)站的響應(yīng)速度。對于大規(guī)模電子商務(wù)平臺一般需要建CDN做網(wǎng)絡(luò)加速，大型平臺如淘寶、京東都采用自建CDN，中小型的企業(yè)可以采用第三方CDN廠商合作，如藍(lán)汛、網(wǎng)宿、快網(wǎng)等。當(dāng)然在選擇CDN廠商時，需要考慮經(jīng)營時間長短，是否有可擴(kuò)充的帶寬資源、靈活的流量和帶寬選擇、穩(wěn)定的節(jié)點(diǎn)、性價比。2.負(fù)載均衡、反向代理一個大型的平臺包括很多個業(yè)務(wù)域，不同的業(yè)務(wù)域有不同的集群,可以用DNS做域名解析的分發(fā)或輪詢，DNS方式實(shí)現(xiàn)簡單，但是因存在

11、cache而缺乏靈活性；一般基于商用的硬件F5、NetScaler或者開源的軟負(fù)載lvs在4層做分發(fā)，當(dāng)然會采用做冗余(比如lvs+keepalived)的考慮，采取主備方式。4層分發(fā)到業(yè)務(wù)集群上后，會經(jīng)過web服務(wù)器如nginx或者HAProxy在7層做負(fù)載均衡或者反向代理分發(fā)到集群中的應(yīng)用節(jié)點(diǎn)。選擇哪種負(fù)載，需要綜合考慮各種因素(是否滿足高并發(fā)高性能，Session保持如何解決，負(fù)載均衡的算法如何，支持壓縮，緩存的內(nèi)存消耗)；下面基于幾種常用的負(fù)載均衡軟件做個介紹。LVS，工作在4層，Linux實(shí)現(xiàn)的髙性能髙并發(fā)、可伸縮性、可靠的的負(fù)載均衡器，支持多種轉(zhuǎn)發(fā)方式(NAT、DR、IPTunne

12、ling)，其中DR模式支持通過廣域網(wǎng)進(jìn)行負(fù)載均衡。支持雙機(jī)熱備(Keepalived或者Heartbeat)。對網(wǎng)絡(luò)環(huán)境的依賴性比較髙。Nginx工作在7層，事件驅(qū)動的、異步非阻塞的架構(gòu)、支持多進(jìn)程的髙并發(fā)的負(fù)載均衡器/反向代理軟件?？梢葬槍τ蛎?、目錄結(jié)構(gòu)、正則規(guī)則針對http做一些分流。通過端口檢測到服務(wù)器內(nèi)部的故障，比如根據(jù)服務(wù)器處理網(wǎng)頁返回的狀態(tài)碼、超時等等，并且會把返回錯誤的請求重新提交到另一個節(jié)點(diǎn)，不過其中缺點(diǎn)就是不支持url來檢測。對于sessionsticky，可以基于iphash的算法來實(shí)現(xiàn)，通過基于cookie的擴(kuò)展nginx-sticky-module支持sessions

13、ticky。HAProxy支持4層和7層做負(fù)載均衡，支持session的會話保持，cookie的引導(dǎo)；支持后端url方式的檢測；負(fù)載均衡的算法比較豐富，有RR、權(quán)重等。對于圖片，需要有單獨(dú)的域名，獨(dú)立或者分布式的圖片服務(wù)器或者如mogileFS，可以圖片服務(wù)器之上加varnish做圖片緩存。App接入應(yīng)用層運(yùn)行在jboss或者tomcat容器中，代表獨(dú)立的系統(tǒng)，比如前端購物、用戶自主服務(wù)、后端系統(tǒng)等協(xié)議接口，HTTP、JS0N可以采用servlet3.0,異步化servlet,提髙整個系統(tǒng)的吞吐量http請求經(jīng)過Nginx，通過負(fù)載均衡算法分到到App的某一節(jié)點(diǎn)，這一層層擴(kuò)容起來比較簡單。除了

14、利用cookie保存少量用戶部分信息外（cookie般不能超過4K的大小），對于App接入層，保存有用戶相關(guān)的session數(shù)據(jù)，但是有些反向代理或者負(fù)載均衡不支持對sessionsticky支持不是很好或者對接入的可用性要求比較髙（app接入節(jié)點(diǎn)宕機(jī)，session隨之丟失），這就需要考慮session的集中式存儲，使得App接入層無狀態(tài)化，同時系統(tǒng)用戶變多的時候，就可以通過增加更多的應(yīng)用節(jié)點(diǎn)來達(dá)到水平擴(kuò)展的目的。Session的集中式存儲，需要滿足以下幾點(diǎn)要求：a、髙效的通訊協(xié)議b、session的分布式緩存，支持節(jié)點(diǎn)的伸縮，數(shù)據(jù)的冗余備份以及數(shù)據(jù)的遷移c、session過期的管理業(yè)務(wù)服務(wù)

15、代表某一領(lǐng)域的業(yè)務(wù)提供的服務(wù)，對于電商而言，領(lǐng)域有用戶、商品、訂單、紅包、支付業(yè)務(wù)等等，不同的領(lǐng)域提供不同的服務(wù)，這些不同的領(lǐng)域構(gòu)成一個個模塊，良好的模塊劃分和接口設(shè)計(jì)非常重要，一般是參考髙內(nèi)聚、接口收斂的原則，這樣可以提髙整個系統(tǒng)的可用性。當(dāng)然可以根據(jù)應(yīng)用規(guī)模的大小模塊可以部署在一起，對于大規(guī)模的應(yīng)用，一般是獨(dú)立部署的。髙并發(fā)：業(yè)務(wù)層對外協(xié)議以NIO的RPC方式暴露，可以采用比較成熟的NIO通訊框架，如netty、mina可用性：為了提高模塊服務(wù)的可用性，一個模塊部署在多個節(jié)點(diǎn)做冗余，并自動進(jìn)行負(fù)載轉(zhuǎn)發(fā)和失效轉(zhuǎn)移;最初可以利用VIP+heartbeat方式，目前系統(tǒng)有一個單獨(dú)的組件HA,利用

16、zookeeper實(shí)現(xiàn)（比原來方案的優(yōu)點(diǎn)）一致性、事務(wù)：對于分布式系統(tǒng)的一致性，盡量滿足可用性，一致性可以通過校對來達(dá)到最終一致的狀態(tài)。5.基礎(chǔ)服務(wù)中間件1）通信組件通信組件用于業(yè)務(wù)系統(tǒng)內(nèi)部服務(wù)之間的調(diào)用，在大并發(fā)的電商平臺中，需要滿足高并發(fā)高吞吐量的要求。整個通信組件包括客戶端和服務(wù)端兩部分。客戶端和服務(wù)器端維護(hù)的是長連接，可以減少每次請求建立連接的開銷，在客戶端對于每個服務(wù)器定義一個連接池，初始化連接后，可以并發(fā)連接服務(wù)端進(jìn)行rpc操作，連接池中的長連接需要心跳維護(hù)，設(shè)置請求超時時間。對于長連接的維護(hù)過程可以分兩個階段，一個是發(fā)送請求過程，另外一個是接收響應(yīng)過程。在發(fā)送請求過程中，若發(fā)生I

17、OException，則把該連接標(biāo)記失效。接收響應(yīng)時，服務(wù)端返回SocketTimeoutException,如果設(shè)置了超時時間，那么就直接返回異常，清除當(dāng)前連接中那些超時的請求。否則繼續(xù)發(fā)送心跳包（因?yàn)榭赡苁莵G包，超過pinginterval間隔時間就發(fā)送ping操作），若ping不通（發(fā)送IOException），則說明當(dāng)前連接是有問題的，那么就把當(dāng)前連接標(biāo)記成已經(jīng)失效；若ping通，則說明當(dāng)前連接是可靠的，繼續(xù)進(jìn)行讀操作。失效的連接會從連接池中清除掉。每個連接對于接收響應(yīng)來說都以單獨(dú)的線程運(yùn)行，客戶端可以通過同步（wait,notify）方式或者異步進(jìn)行rpc調(diào)用，序列化采用更高效的he

18、ssion序列化方式。服務(wù)端采用事件驅(qū)動的NIO的MINA框架，支撐高并發(fā)高吞吐量的請求。在大多數(shù)的數(shù)據(jù)庫切分解決方案中，為了提高數(shù)據(jù)庫的吞吐量，首先是對不同的表進(jìn)行垂直切分到不同的數(shù)據(jù)庫中，然后當(dāng)數(shù)據(jù)庫中一個表超過一定大小時，需要對該表進(jìn)行水平切分，這里也是一樣，這里以用戶表為例；對于訪問數(shù)據(jù)庫客戶端來講，需要根據(jù)用戶的ID,定位到需要訪問的數(shù)據(jù)；數(shù)據(jù)切分算法，根據(jù)用戶的ID做hash操作，一致性Hash，這種方式存在失效數(shù)據(jù)的遷移問題，遷移時間內(nèi)服務(wù)不可用維護(hù)路由表，路由表中存儲用戶和sharding的映射關(guān)系，sharding分為leader和replica，分別負(fù)責(zé)寫和讀這樣每個biz

19、客戶端都需要保持所有sharding的連接池，這樣有個缺點(diǎn)是會產(chǎn)生全連接的問題；一種解決方法是sharding的切分提到業(yè)務(wù)服務(wù)層進(jìn)行，每個業(yè)務(wù)節(jié)點(diǎn)只維護(hù)一個shard的連接即可。見圖（router）db11-bizl1-bizl2hardlgrutpsdbll-dhl2vatch；watch-tentersroutBrlrouter2clientb-irUshardlbi1152Qkespr|lardlrouterrouterdb13db12路由組件的實(shí)現(xiàn)是這樣的（可用性、高性能、高并發(fā)）基于性能方面的考慮，采用mongodb中維護(hù)用戶id和shard的關(guān)系，為了保證可用性，搭建replic

20、atset集群。biz的sharding和數(shù)據(jù)庫的sharding是一一對應(yīng)的，只訪問一個數(shù)據(jù)庫業(yè)務(wù)注冊節(jié)點(diǎn)至Hzookeeper上/bizs/shard/下。router監(jiān)聽zookeeper上/bizs/下節(jié)點(diǎn)狀態(tài)，緩存在線biz在router中。client請求router獲取biz時，router首先從mongodb中獲取用戶對應(yīng)的shard,router根據(jù)緩存的內(nèi)容通過RR算法獲取biz節(jié)點(diǎn)。為了解決router的可用性和并發(fā)吞吐量問題，對router進(jìn)行冗余，同時client監(jiān)聽zookeeper的/routers節(jié)點(diǎn)并緩存在線router節(jié)點(diǎn)列表。HA傳

21、統(tǒng)實(shí)現(xiàn)HA的做法一般是采用虛擬IP漂移，結(jié)合Heartbeat、keepalived等實(shí)現(xiàn)HA，Keepalived使用vrrp方式進(jìn)行數(shù)據(jù)包的轉(zhuǎn)發(fā)，提供4層的負(fù)載均衡，通過檢測vrrp數(shù)據(jù)包來切換，做冗余熱備更加適合與LVS搭配。LinuxHeartbeat是基于網(wǎng)絡(luò)或者主機(jī)的服務(wù)的髙可用，HAProxy或者Nginx可以基于7層進(jìn)行數(shù)據(jù)包的轉(zhuǎn)發(fā)，因此Heatbeat更加適合做HAProxy、Nginx，包括業(yè)務(wù)的髙可用。在分布式的集群中，可以用zookeeper做分布式的協(xié)調(diào)，實(shí)現(xiàn)集群的列表維護(hù)和失效通知，客戶端可以選擇hash算法或者roudrobin實(shí)現(xiàn)負(fù)載均衡；對于master-ma

22、ster模式、master-slave模式，可以通過zookeeper分布式鎖的機(jī)制來支持。消息Message對于平臺各個系統(tǒng)之間的異步交互，是通過MQ組件進(jìn)行的。在設(shè)計(jì)消息服務(wù)組件時，需要考慮消息一致性、持久化、可用性、以及完善的監(jiān)控體系。業(yè)界開源的消息中間件主要RabbitMQ、kafka有兩種，RabbitMQ,遵循AMQP協(xié)議，由內(nèi)在髙并發(fā)的erlanng語言開發(fā);kafka是Linkedin于2010年12月份開源的消息發(fā)布訂閱系統(tǒng)，它主要用于處理活躍的流式數(shù)據(jù),大數(shù)據(jù)量的數(shù)據(jù)處理上。對消息一致性要求比較髙的場合需要有應(yīng)答確認(rèn)機(jī)制，包括生產(chǎn)消息和消費(fèi)消息的過程；不過因網(wǎng)絡(luò)等原理導(dǎo)致的

23、應(yīng)答缺失，可能會導(dǎo)致消息的重復(fù)，這個可以在業(yè)務(wù)層次根據(jù)冪等性進(jìn)行判斷過濾；RabbitMQ采用的是這種方式。還有一種機(jī)制是消費(fèi)端從broker拉取消息時帶上LSN號，從broker中某個LSN點(diǎn)批量拉取消息，這樣無須應(yīng)答機(jī)制，kafka分布式消息中間件就是這種方式。消息的在broker中的存儲，根據(jù)消息的可靠性的要求以及性能方面的綜合衡量，可以在內(nèi)存中，可以持久化到存儲上。對于可用性和髙吞吐量的要求，集群和主備模式都可以在實(shí)際的場景應(yīng)用的到。RabbitMQ解決方案中有普通的集群和可用性更髙的mirrorqueue方式。kafka采用zookeeper對集群中的broker、consumer進(jìn)

24、行管理，可以注冊topic到zookeeper上；通過zookeeper的協(xié)調(diào)機(jī)制，producer保存對應(yīng)topic的broker信息，可以隨機(jī)或者輪詢發(fā)送到broker上；并且producer可以基于語義指定分片，消息發(fā)送到broker的某分片上?？傮w來講，RabbitMQ用在實(shí)時的對可靠性要求比較高的消息傳遞上。afka主要用于處理活躍的流式數(shù)據(jù)，大數(shù)據(jù)量的數(shù)據(jù)處理上。5)Cache&BufferCache系統(tǒng)在一些高并發(fā)高性能的場景中，使用cache可以減少對后端系統(tǒng)的負(fù)載，承擔(dān)可大部分讀的壓力，可以大大提高系統(tǒng)的吞吐量，比如通常在數(shù)據(jù)庫存儲之前增加cache緩存。但是引入cache架

25、構(gòu)不可避免的帶來一些問題，cache命中率的問題，cache失效引起的抖動，cache和存儲的一致性。Cache中的數(shù)據(jù)相對于存儲來講，畢竟是有限的，比較理想的情況是存儲系統(tǒng)的熱點(diǎn)數(shù)據(jù)，這里可以用一些常見的算法LRU等等淘汰老的數(shù)據(jù)；隨著系統(tǒng)規(guī)模的增加，單個節(jié)點(diǎn)cache不能滿足要求，就需要搭建分布式Cache；為了解決單個節(jié)點(diǎn)失效引起的抖動，分布式cache一般采用一致性hash的解決方案，大大減少因單個節(jié)點(diǎn)失效引起的抖動范圍；而對于可用性要求比較高的場景，每個節(jié)點(diǎn)都是需要有備份的。數(shù)據(jù)在cache和存儲上都存有同一份備份，必然有一致性的問題，一致性比較強(qiáng)的,在更新數(shù)據(jù)庫的同時，更新數(shù)據(jù)庫c

26、ache。對于一致性要求不高的，可以去設(shè)置緩存失效時間的策略。Memcached作為髙速的分布式緩存服務(wù)器，協(xié)議比較簡單，基于libevent的事件處理機(jī)制。Cache系統(tǒng)在平臺中用在router系統(tǒng)的客戶端中，熱點(diǎn)的數(shù)據(jù)會緩存在客戶端，當(dāng)數(shù)據(jù)訪問失效時，才去訪問router系統(tǒng)。當(dāng)然目前更多的利用內(nèi)存型的數(shù)據(jù)庫做cache，比如redis、mongodb；redis比memcache有豐富的數(shù)據(jù)操作的API；redis和mongodb都對數(shù)據(jù)進(jìn)行了持久化，而memcache沒有這個功能，因此memcache更加適合在關(guān)系型數(shù)據(jù)庫之上的數(shù)據(jù)的緩存。Buffer系統(tǒng)用在高速的寫操作的場景中，平臺

27、中有些數(shù)據(jù)需要寫入數(shù)據(jù)庫，并且數(shù)據(jù)是分庫分表的，但對數(shù)據(jù)的可靠性不是那么高，為了減少對數(shù)據(jù)庫的寫壓力，可以采取批量寫操作的方式。開辟一個內(nèi)存區(qū)域，當(dāng)數(shù)據(jù)到達(dá)區(qū)域的一定閥值時如80%時，在內(nèi)存中做分庫梳理工作（內(nèi)存速度還是比較快的），后分庫批量flush。6）搜索在電子商務(wù)平臺中搜索是一個非常的重要功能，主要有搜索詞類目導(dǎo)航、自動提示和搜索排序功能。開源的企業(yè)級搜索引擎主要有l(wèi)ucene,sphinx，這里不去論述哪種搜索引擎更好一些，不過選擇搜索引擎除了基本的功能需要支持外非功能方面需要考慮以下兩點(diǎn)：a、搜索引擎是否支持分布式的索引和搜索，來應(yīng)對海量的數(shù)據(jù)，支持讀寫分離，提高可用性b、索引的實(shí)

28、時性c、性能Solr是基于lucene的高性能的全文搜索服務(wù)器，提供了比lucene更為豐富的查詢語言，可配置可擴(kuò)展，對外提供基于http協(xié)議的XML/JSON格式的接口。從Solr4版本開始提供了SolrCloud方式來支持分布式的索引，自動進(jìn)行sharding數(shù)據(jù)切分；通過每個sharding的master-slave（leader、replica）模式提髙搜索的性能；利用zookeeper對集群進(jìn)行管理，包括leader選舉等等，保障集群的可用性。Lucene索引的Reader是基于索引的snapshot的，所以必須在索引commit的后，重新打開一個新的snapshot,才能搜索到新添

29、加的內(nèi)容；而索引的commit是非常耗性能的，這樣達(dá)到實(shí)時索引搜索效率就比較低下。對于索引搜索實(shí)時性，Solr4的之前解決方案是結(jié)合文件全量索引和內(nèi)存增量索引合并的方式，參見下圖。A訂初始狀態(tài)B訂門存索引A離后卅態(tài)合并門存盍引A和硬雖索豆C:磴繪親弓用此內(nèi)存索引臺并結(jié)豆之后狀Solr4提供了NRTsoftcommit的解決方案，softcommit無需進(jìn)行提交索引操作，就可以搜素到最新對索引的變更，不過對索引的變更并沒有synccommit到硬盤存儲上，若發(fā)生意外導(dǎo)致程序非正常結(jié)束，未commit的數(shù)據(jù)會丟失，因此需要定時的進(jìn)行commit操作。平臺中對數(shù)據(jù)的索引和存儲操作是異步的，可以大大提

30、高可用性和吞吐量；只對某些屬性字段做索引操作，存儲數(shù)據(jù)的標(biāo)識key，減少索引的大??；數(shù)據(jù)是存儲在分布式存儲HBase中的，HBase對二級索引搜索支持的不好，然而可以結(jié)合Solr搜索功能進(jìn)行多維度的檢索統(tǒng)計(jì)。索引數(shù)據(jù)和HBase數(shù)據(jù)存儲的一致性，也就是如何保障HBase存儲的數(shù)據(jù)都被索引過，可以采用confirm確認(rèn)機(jī)制，通過在索引前建立待索引數(shù)據(jù)隊(duì)列，在數(shù)據(jù)存儲并索引完成后，從待索引數(shù)據(jù)隊(duì)列中刪除數(shù)據(jù)。7）日志收集在整個交易過程中，會產(chǎn)生大量的日志，這些日志需要收集到分布式存儲系統(tǒng)中存儲起來，以便于集中式的查詢和分析處理。日志系統(tǒng)需具備三個基本組件，分別為agent（封裝數(shù)據(jù)源，將數(shù)據(jù)源中的

31、數(shù)據(jù)發(fā)送給collector）,collector（接收多個agent的數(shù)據(jù)，并進(jìn)行匯總后導(dǎo)入后端的store中），store（中央存儲系統(tǒng),應(yīng)該具有可擴(kuò)展性和可靠性，應(yīng)該支持當(dāng)前非常流行的HDFS）。開源的日志收集系統(tǒng)業(yè)界使用的比較多的是cloudera的Flume和facebook的Scribe，其中Flume目前的版本FlumeNG對Flume從架構(gòu)上做了較大的改動。在設(shè)計(jì)或者對日志收集系統(tǒng)做技術(shù)選型時，通常需要具有以下特征：a、應(yīng)用系統(tǒng)和分析系統(tǒng)之間的橋梁，將他們之間的關(guān)系解耦b、分布式可擴(kuò)展，具有高的擴(kuò)展性，當(dāng)數(shù)據(jù)量增加時，可以通過增加節(jié)點(diǎn)水平擴(kuò)展日志收集系統(tǒng)是可以伸縮的，在系統(tǒng)的各

32、個層次都可伸縮，對數(shù)據(jù)的處理不需要帶狀態(tài)，伸縮性方面也比較容易實(shí)現(xiàn)。c、近實(shí)時性在一些時效性要求比較高的場景中，需要可以及時的收集日志，進(jìn)行數(shù)據(jù)分析；一般的日志文件都會定時或者定量的進(jìn)行rolling，所以實(shí)時檢測日志文件的生成，及時對日志文件進(jìn)行類似的tail操作，并支持批量發(fā)送提高傳輸效率；批量發(fā)送的時機(jī)需要滿足消息數(shù)量和時間間隔的要求。d、容錯性Scribe在容錯方面的考慮是，當(dāng)后端的存儲系統(tǒng)crash時，scribe會將數(shù)據(jù)寫到本地磁盤上，當(dāng)存儲系統(tǒng)恢復(fù)正常后，scribe將日志重新加載到存儲系統(tǒng)中。FlumeNG通過SinkProcessor實(shí)現(xiàn)負(fù)載均衡和故障轉(zhuǎn)移。多個Sink可以構(gòu)

33、成一個SinkGroup。一個SinkProcessor負(fù)責(zé)從一個指定的SinkGroup中激活一個Sink。SinkProcessor可以通過組中所有Sink實(shí)現(xiàn)負(fù)載均衡；也可以在一個Sink失敗時轉(zhuǎn)移到另一個。e、事務(wù)支持Scribe沒有考慮事務(wù)的支持。Flume通過應(yīng)答確認(rèn)機(jī)制實(shí)現(xiàn)事務(wù)的支持，參見下圖，ChannelSinktakacuGnisSourceChannelsbndonetxstartexputgYSflSandtx通常提取發(fā)送消息都是批量操作的，消息的確認(rèn)是對一批數(shù)據(jù)的確認(rèn)，這樣可以大大提髙數(shù)據(jù)發(fā)送的效率。f、可恢復(fù)性FlumeNG的channel根據(jù)可靠性的要求的不同，可

34、以基于內(nèi)存和文件持久化機(jī)制，基于內(nèi)存的數(shù)據(jù)傳輸?shù)匿N量比較髙，但是在節(jié)點(diǎn)宕機(jī)后，數(shù)據(jù)丟失，不可恢復(fù)；而文件持久化宕機(jī)是可以恢復(fù)的。g、數(shù)據(jù)的定時定量歸檔數(shù)據(jù)經(jīng)過日志收集系統(tǒng)歸集后，一般存儲在分布式文件系統(tǒng)如Hadoop，為了便于對數(shù)據(jù)進(jìn)行后續(xù)的處理分析，需要定時(TimeTrigger)或者定量(SizeTrigger的rolling分布式系統(tǒng)的文件。數(shù)據(jù)同步在交易系統(tǒng)中，通常需要進(jìn)行異構(gòu)數(shù)據(jù)源的同步，通常有數(shù)據(jù)文件到關(guān)系型數(shù)據(jù)庫，數(shù)據(jù)文件到分布式數(shù)據(jù)庫，關(guān)系型數(shù)據(jù)庫到分布式數(shù)據(jù)庫等。數(shù)據(jù)在異構(gòu)源之間的同步一般是基于性能和業(yè)務(wù)的需求,數(shù)據(jù)存儲在本地文件中一般是基于性能的考慮，文件是順序存儲的，效

35、率還是比較髙的；數(shù)據(jù)同步到關(guān)系型數(shù)據(jù)一般是基于查詢的需求；而分布式數(shù)據(jù)庫是存儲越來越多的海量數(shù)據(jù)的，而關(guān)系型數(shù)據(jù)庫無法滿足大數(shù)據(jù)量的存儲和查詢請求。在數(shù)據(jù)同步的設(shè)計(jì)中需要綜合考慮吞吐量、容錯性、可靠性、一致性的問題同步有實(shí)時增量數(shù)據(jù)同步和離線全量數(shù)據(jù)區(qū)分，下面從這兩個維度來介紹一下，實(shí)時增量一般是Tail文件來實(shí)時跟蹤文件變化，批量或者多線程往數(shù)據(jù)庫導(dǎo)出，這種方式的架構(gòu)類似于日志收集框架。這種方式需要有確認(rèn)機(jī)制，包括兩個方面。一個方面是Channel需要給agent確認(rèn)已經(jīng)批量收到數(shù)據(jù)記錄了,發(fā)送LSN號給agent,這樣在agent失效恢復(fù)時，可以從這個LSN點(diǎn)開始tail；當(dāng)然對于允許少量

36、的重復(fù)記錄的問題（發(fā)生在channel給agent確認(rèn)的時，agent宕機(jī)并未受到確認(rèn)消息），需要在業(yè)務(wù)場景中判斷。另外一個方面是sync給channel確認(rèn)已經(jīng)批量完成寫入到數(shù)據(jù)庫的操作，這樣channel可以刪除這部分已經(jīng)confirm的消息?；诳煽啃缘囊?，channel可以采用文件持久化的方式。參見下圖離線全量遵循空間間換取時間，分而治之的原則，盡量的縮短數(shù)據(jù)同步的時間，提髙同步的效率。需要對源數(shù)據(jù)比如MySQL進(jìn)行切分，多線程并發(fā)讀源數(shù)據(jù)，多線程并發(fā)批量寫入分布式數(shù)據(jù)庫比如HBase，利用channel作為讀寫之間的緩沖，實(shí)現(xiàn)更好的解耦，channel可以基于文件存儲或者內(nèi)存。參見

37、下圖：對于源數(shù)據(jù)的切分，如果是文件可以根據(jù)文件名稱設(shè)置塊大小來切分。對于關(guān)系型數(shù)據(jù)庫，由于一般的需求是只離線同步一段時間的數(shù)據(jù)（比如凌晨把當(dāng)天的訂單數(shù)據(jù)同步到HBase），所以需要在數(shù)據(jù)切分時（按照行數(shù)切分），會多線程掃描整個表（及時建索引，也要回表），對于表中包含大量的數(shù)據(jù)來講，10很髙，效率非常低；這里解決的方法是對數(shù)據(jù)庫按照時間字段（按照時間同步的）建立分區(qū)，每次按照分區(qū)進(jìn)行導(dǎo)出。9）數(shù)據(jù)分析從傳統(tǒng)的基于關(guān)系型數(shù)據(jù)庫并行處理集群、用于內(nèi)存計(jì)算近實(shí)時的，到目前的基于hadoop的海量數(shù)據(jù)的分析，數(shù)據(jù)的分析在大型電子商務(wù)網(wǎng)站中應(yīng)用非常廣泛，包括流量統(tǒng)計(jì)、推薦引擎、趨勢分析、用戶行為分析、數(shù)據(jù)

38、挖掘分類器、分布式索引等等。并行處理集群有商業(yè)的EMCGreenplum，Greenplum的架構(gòu)采用了MPP（大規(guī)模并行處理），基于postgresql的大數(shù)據(jù)量存儲的分布式數(shù)據(jù)庫。內(nèi)存計(jì)算方面有SAP的HANA，開源的nosql內(nèi)存型的數(shù)據(jù)庫mongodb也支持mapreduce進(jìn)行數(shù)據(jù)的分析。海量數(shù)據(jù)的離線分析目前互聯(lián)網(wǎng)公司大量的使用Hadoop，Hadoop在可伸縮性、健壯性、計(jì)算性能和成本上具有無可替代的優(yōu)勢，事實(shí)上已成為當(dāng)前互聯(lián)網(wǎng)企業(yè)主流的大數(shù)據(jù)分析平臺Hadoop通過MapReuce的分布式處理框架，用于處理大規(guī)模的數(shù)據(jù)，伸縮性也非常好；但是MapReduce最大的不足是不能滿足

39、實(shí)時性的場景，主要用于離線的分析。基于MapRduce模型編程做數(shù)據(jù)的分析，開發(fā)上效率不髙，位于hadoop之上Hive的出現(xiàn)使得數(shù)據(jù)的分析可以類似編寫sql的方式進(jìn)行，sql經(jīng)過語法分析、生成執(zhí)行計(jì)劃后最終生成MapReduce任務(wù)進(jìn)行執(zhí)行，這樣大大提髙了開發(fā)的效率，做到以ad-hoc（計(jì)算在query發(fā)生時）方式進(jìn)行的分析。基于MapReduce模型的分布式數(shù)據(jù)的分析都是離線的分析，執(zhí)行上都是暴力掃描，無法利用類似索引的機(jī)制；開源的ClouderaImpala是基于MPP的并行編程模型的，底層是Hadoop存儲的髙性能的實(shí)時分析平臺，可以大大降低數(shù)據(jù)分析的延遲。目前Hadoop使用的版本是

40、Hadoopl.0,方面原有的MapReduce框架存在JobTracker單點(diǎn)的問題，另外一方面JobTracker在做資源管理的同時又做任務(wù)的調(diào)度工作，隨著數(shù)據(jù)量的增大和Job任務(wù)的增多，明顯存在可擴(kuò)展性、內(nèi)存消耗、線程模型、可靠性和性能上的缺陷瓶頸；Hadoop2.0yarn對整個框架進(jìn)行了重構(gòu)，分離了資源管理和任務(wù)調(diào)度，從架構(gòu)設(shè)計(jì)上解決了這個問題。參考Yarn的架構(gòu)10）實(shí)時計(jì)算在互聯(lián)網(wǎng)領(lǐng)域，實(shí)時計(jì)算被廣泛實(shí)時監(jiān)控分析、流控、風(fēng)險控制等領(lǐng)域。電商平臺系統(tǒng)或者應(yīng)用對日常產(chǎn)生的大量日志和異常信息，需要經(jīng)過實(shí)時過濾、分析，以判定是否需要預(yù)警；同時需要對系統(tǒng)做自我保護(hù)機(jī)制，比如對模塊做流量的控

41、制，以防止非預(yù)期的對系統(tǒng)壓力過大而引起的系統(tǒng)癱瘓，流量過大時，可以采取拒絕或者引流等機(jī)制；有些業(yè)務(wù)需要進(jìn)行風(fēng)險的控制，比如彩票中有些業(yè)務(wù)需要根據(jù)系統(tǒng)的實(shí)時銷售情況進(jìn)行限號與放號。原始基于單節(jié)點(diǎn)的計(jì)算，隨著系統(tǒng)信息量爆炸式產(chǎn)生以及計(jì)算的復(fù)雜度的增加，單個節(jié)點(diǎn)的計(jì)算已不能滿足實(shí)時計(jì)算的要求，需要進(jìn)行多節(jié)點(diǎn)的分布式的計(jì)算，分布式實(shí)時計(jì)算平臺就出現(xiàn)了。這里所說的實(shí)時計(jì)算，其實(shí)是流式計(jì)算，概念前身其實(shí)是CEP復(fù)雜事件處理，相關(guān)的開源產(chǎn)品如Esper，業(yè)界分布式的流計(jì)算產(chǎn)品YahooS4,Twitterstorm等，以storm開源產(chǎn)品使用最為廣泛。對于實(shí)時計(jì)算平臺，從架構(gòu)設(shè)計(jì)上需要考慮以下幾個因素：1、

42、伸縮性隨著業(yè)務(wù)量的增加，計(jì)算量的增加，通過增加節(jié)點(diǎn)處理，就可以處理。2、髙性能、低延遲從數(shù)據(jù)流入計(jì)算平臺數(shù)據(jù)，到計(jì)算輸出結(jié)果，需要性能髙效且低延遲，保證消息得到快速的處理，做到實(shí)時計(jì)算。3、可靠性保證每個數(shù)據(jù)消息得到一次完整處理。4、容錯性建立Topology地目錄提交topology-*NimbusI-/taskbeatsI-Jri-task-id監(jiān)控丁話知卜跳計(jì)算工作星TasksE-/ta&ksI-topoiovidIT琢I。client茯取分噸的佰g飾啟動任務(wù)建立說爛間的連蜜Supervisor分flasks工二zookeeper啟S?Topoipg?Super/isor-/assign

43、ments-tORqjogyjdfnasterf-CrrBSnh（!sttaskrmdE+port（加Re）taskhtart-tiT-tecm-/storms|-tqpoloqid-/supervisors凈supervisor-idI；woker1sccKetTask1Taskfsocketf系統(tǒng)可以自動管理節(jié)點(diǎn)的宕機(jī)失效，對應(yīng)用來說，是透明的。Twitter的Storm在以上這幾個方面做的比較好，下面簡介一下Storm的架構(gòu)。整個集群的管理是通過zookeeper來進(jìn)行的?？蛻舳颂峤煌?fù)涞絥imbus。Nimbus針對該拓?fù)浣⒈镜氐哪夸浉鶕?jù)topology的配置計(jì)算task，分配tas

44、k,在zookeeper上建立assignments節(jié)點(diǎn)存儲task和supervisor機(jī)器節(jié)點(diǎn)中woker的對應(yīng)關(guān)系。在zookeeper上創(chuàng)建taskbeats節(jié)點(diǎn)來監(jiān)控task的心跳；啟動topology。Supervisor去zookeeper上獲取分配的tasks，啟動多個woker進(jìn)行，每個woker生成task，一個task個線程；根據(jù)topology信息初始化建立task之間的連接；Task和Task之間是通過zeroMQ管理的；之后整個拓?fù)溥\(yùn)行起來。Tuple是流的基本處理單元，也就是一個消息，Tuple在task中流轉(zhuǎn)，Tuple的發(fā)送和接收過程如下：發(fā)送Tuple,Wo

45、rker提供了一個transfer的功能，用于當(dāng)前task把tuple發(fā)到到其他的task中。以目的taskid和tuple參數(shù)，序列化tuple數(shù)據(jù)并放到transferqueue中。在0.8版本之前，這個queue是LinkedBlockingQueue，0.8之后是DisruptorQueue。在0.8版本之后，每一個woker綁定一個inboundtransferqueue和outbondqueue，inboundqueue用于接收message，outbondqueue用于發(fā)送消息。發(fā)送消息時，由單個線程從transferqueue中拉取數(shù)據(jù)，把這個tuple通過zeroMQ發(fā)送到其

46、他的woker中。接收Tuple，每個woker都會監(jiān)聽zeroMQ的tcp端口來接收消息，消息放到DisruptorQueue中后，后從queue中獲取message(taskid,tuple)，根據(jù)目的taskid,tuple的值路由到task中執(zhí)行。每個tuple可以emit到directsteam中，也可以發(fā)送到regularstream中，在Reglular方式下，由StreamGrou(pstreamid-componentidoutbondtasks)功能完成當(dāng)前tuple將要發(fā)送的Tuple的目的地。通過以上分析可以看到，Storm在伸縮性、容錯性、髙性能方面的從架構(gòu)設(shè)計(jì)的角度

47、得以支撐；同時在可靠性方面，Storm的ack組件利用異或xor算法在不失性能的同時，保證每一個消息得到完整處理的同時。11）實(shí)時推送實(shí)時推送的應(yīng)用場景非常多，比如系統(tǒng)的監(jiān)控動態(tài)的實(shí)時曲線繪制，手機(jī)消息的推送，web實(shí)時聊天等。實(shí)時推送有很多技術(shù)可以實(shí)現(xiàn)，有Comet方式，有websocket方式等。Comet基于服務(wù)器長連接的“服務(wù)器推”技術(shù)，包含兩種：LongPolling：服務(wù)器端在接到請求后掛起，有更新時返回連接即斷掉，然后客戶端再發(fā)起新的連接Stream方式:每次服務(wù)端數(shù)據(jù)傳送不會關(guān)閉連接，連接只會在通信出現(xiàn)錯誤時，或是連接重建時關(guān)閉（一些防火墻常被設(shè)置為丟棄過長的連接，服務(wù)器端可以

48、設(shè)置一個超時時間，超時后通知客戶端重新建立連接，并關(guān)閉原來的連接）。Websocket：長連接，全雙工通信是Html5的一種新的協(xié)議。它實(shí)現(xiàn)了瀏覽器與服務(wù)器的雙向通訊。webSocketAPI中，瀏覽器和服務(wù)器端只需要通過一個握手的動作，便能形成瀏覽器與客戶端之間的快速雙向通道，使得數(shù)據(jù)可以快速的雙向傳播。Socket.io是一個NodeJSwebsocket庫，包括客戶端的JS和服務(wù)端的的nodejs，用于快速構(gòu)建實(shí)時的web應(yīng)用。數(shù)據(jù)存儲數(shù)據(jù)庫存儲大體分為以下幾類，有關(guān)系型（事務(wù)型）的數(shù)據(jù)庫，以oracle、mysql為代表，有keyvalue數(shù)據(jù)庫，以redis和memcacheddb為

49、代表，有文檔型數(shù)據(jù)庫如mongodb，有列式分布式數(shù)據(jù)庫以HBase，cassandra,dynamo為代表，還有其他的圖形數(shù)據(jù)庫、對象數(shù)據(jù)庫、xml數(shù)據(jù)庫等。每種類型的數(shù)據(jù)庫應(yīng)用的業(yè)務(wù)領(lǐng)域是不一樣的，下面從內(nèi)存型、關(guān)系型、分布式三個維度針對相關(guān)的產(chǎn)品做性能可用性等方面的考量分析。1）內(nèi)存型數(shù)據(jù)庫內(nèi)存型的數(shù)據(jù)庫，以髙并發(fā)髙性能為目標(biāo)，在事務(wù)性方面沒那么嚴(yán)格，以開源nosql數(shù)據(jù)庫mongodb、redis為例通信方式多線程方式，主線程監(jiān)聽新的連接，連接后，啟動新的線程做數(shù)據(jù)的操作（10切換）。數(shù)據(jù)結(jié)構(gòu)ExtentRecordDocReccjrdDocResortDocRetwdCdBction

50、NamespacestructDisklDcaiion(hleNooffsetIndexMarnespaceActualdatJ*paddingPaddingfactoriscolecticmspecific日treeBteelNodeMode數(shù)據(jù)庫-collection-recordMongoDB在數(shù)據(jù)存儲上按命名空間來劃分，一個collection是一個命名空間，一個索引也是一個命名空間。同一個命名空間的數(shù)據(jù)被分成很多個Extent，Extent之間使用雙向鏈表連接。在每一個Extent中，保存了具體每一行的數(shù)據(jù)，這些數(shù)據(jù)也是通過雙向鏈接連接的。每一行數(shù)據(jù)存儲空間不僅包括數(shù)據(jù)占用空間，還可

51、能包含一部分附加空間，這使得在數(shù)據(jù)update變大后可以不移動位置。索引以BTree結(jié)構(gòu)實(shí)現(xiàn)。如果你開啟了jorunaling日志，那么還會有一些文件存儲著你所有的操作記錄。持久化存儲MMap方式把文件地址映射到內(nèi)存的地址空間，直接操作內(nèi)存地址空間就可以操作文件，不用再調(diào)用write,read操作，性能比較高。mongodb調(diào)用mmap把磁盤中的數(shù)據(jù)映射到內(nèi)存中的，所以必須有一個機(jī)制時刻的刷數(shù)據(jù)到硬盤才能保證可靠性，多久刷一次是與syncdelay參數(shù)相關(guān)的。journal（進(jìn)行恢復(fù)用）是Mongodb中的redolog，而Oplog則是負(fù)責(zé)復(fù)制的binlogo如果打開journal,那么即使

52、斷電也只會丟失100ms的數(shù)據(jù)，這對大多數(shù)應(yīng)用來說都可以容忍了。從1.9.2+，mongodb都會默認(rèn)打開journal功能，以確保數(shù)據(jù)安全。而且journal的刷新時間是可以改變的，2-300ms的范圍,使用-journalCommitinterval命令。Oplog和數(shù)據(jù)刷新到磁盤的時間是60s,對于復(fù)制來說，不用等到oplog刷新磁盤，在內(nèi)存中就可以直接復(fù)制到Sencondary節(jié)點(diǎn)。事務(wù)支持Mongodb只支持對單行記錄的原子操作HA集群用的比較多的是ReplicaSets,采用選舉算法，自動進(jìn)行l(wèi)eader選舉，在保證可用性的同時，可以做到強(qiáng)一致性要求。、Querycangotoma

53、steroranyslaveThiscanbesetperqueryheartbeatUpdatealwaysgotomaster.csdn.nf/yflngfcitcUpdatepropagatestosecondaryasyncSecondaryDBSecondaryDBClientLib當(dāng)然對于大量的數(shù)據(jù)，mongodb也提供了數(shù)據(jù)的切分架構(gòu)Sharding。0Redis豐富的數(shù)據(jù)結(jié)構(gòu)，高速的響應(yīng)速度，內(nèi)存操作通信方式因都在內(nèi)存操作，所以邏輯的操作非?？?，減少了CPU的切換開銷，所以為單線程的模式（邏輯處理線程和主線程是一個）。reactor模式，實(shí)現(xiàn)自己的多路復(fù)用N10機(jī)制（epoll

54、，select,kqueue等）單線程處理多任務(wù)數(shù)據(jù)結(jié)構(gòu)hash+bucket結(jié)構(gòu)，當(dāng)鏈表的長度過長時，會采取遷移的措施（擴(kuò)展原來兩倍的hash表，把數(shù)據(jù)遷移過去，expand+rehash）持久化存儲a、全量持久化RDB（遍歷redisDB,讀取bucket中的key,value）,save命令阻塞主線程，bgsave開啟子進(jìn)程進(jìn)行snapshot持久化操作，生成rdb文件。在shutdown時，會調(diào)用save操作數(shù)據(jù)發(fā)生變化，在多少秒內(nèi)觸發(fā)一次bgsavesync，master接受slave發(fā)出來的命令b、增量持久化（aof類似redolog）,先寫到日志buffer,再flush到日志文

55、件中（flush的策略可以配置的，而已單條，也可以批量），只有flush到文件上的，才真正返回客戶端。要定時對aof文件和rdb文件做合并操作（在快照過程中，變化的數(shù)據(jù)先寫到aofbuf中等子進(jìn)程完成快照內(nèi)存snapshot后，再進(jìn)行合并aofbuf變化的部分以及全鏡像數(shù)據(jù)）。在髙并發(fā)訪問模式下，RDB模式使服務(wù)的性能指標(biāo)出現(xiàn)明顯的抖動，aof在性能開銷上比RDB好，但是恢復(fù)時重新加載到內(nèi)存的時間和數(shù)據(jù)量成正比。集群HA通用的解決方案是主從備份切換，采用HA軟件，使得失效的主redis可以快速的切換到從redis上。主從數(shù)據(jù)的同步采用復(fù)制機(jī)制，該場景可以做讀寫分離。目前在復(fù)制方面，存在的一個問

56、題是在遇到網(wǎng)絡(luò)不穩(wěn)定的情況下Slave和Master斷開（包括閃斷）會導(dǎo)致Master需要將內(nèi)存中的數(shù)據(jù)全部重新生成rdb文件（快照文件），然后傳輸給Slave。Slave接收完Master傳遞過來的rdb文件以后會將自身的內(nèi)存清空，把rdb文件重新加載到內(nèi)存中。這種方式效率比較低下，在后面的未來版本Redis2.8作者已經(jīng)實(shí)現(xiàn)了部分復(fù)制的功能。2）關(guān)系型數(shù)據(jù)庫關(guān)系型數(shù)據(jù)庫在滿足并發(fā)性能的同時，也需要滿足事務(wù)性，以mysql數(shù)據(jù)庫為例，講述架構(gòu)設(shè)計(jì)原理，在性能方面的考慮，以及如何滿足可用性的需求。0mysql的架構(gòu)原理（innodb）在架構(gòu)上，mysql分為server層和存儲引擎層。Serv

57、er層的架構(gòu)對于不同的存儲引擎來講都是一樣的，包括連接/線程處理、查詢處理（parser、optimizer）以及其他系統(tǒng)任務(wù)。存儲引擎層有很多種，mysql提供了存儲引擎的插件式結(jié)構(gòu)，支持多種存儲引擎，用的最廣泛的是innodb和myisamin；inodb主要面向OLTP方面的應(yīng)用，支持事務(wù)處理，myisam不支持事務(wù)，表鎖，對0LAP操作速度快。以下主要針對innodb存儲引擎做相關(guān)介紹。在線程處理方面，Mysql是多線程的架構(gòu)，由一個master線程，一個鎖監(jiān)控線程，一個錯誤監(jiān)控線程，和多個10線程組成。并且對一個連接會開啟一個線程進(jìn)行服務(wù)。io線程又分為節(jié)省隨機(jī)IO的insertbu

58、ffer，用于事務(wù)控制的類似于oracle的redolog,以及多個write,多個read的硬盤和內(nèi)存交換的IO線程。在內(nèi)存分配方面，包括innodbbufferpool，以及l(fā)ogbuffer。其中innodbbufferpool包括insertbuffer、datapage、indexpage、數(shù)據(jù)字典、自適應(yīng)hash。Logbuffer用于緩存事務(wù)日志，提供性能。在數(shù)據(jù)結(jié)構(gòu)方面，innodb包括表空間、段、區(qū)、頁/塊，行。索引結(jié)構(gòu)是B+tree結(jié)構(gòu)，包括二級索引和主鍵索引，二級索引的葉子節(jié)點(diǎn)是主鍵PK，根據(jù)主鍵索引的葉子節(jié)點(diǎn)指向存儲的數(shù)據(jù)塊。這種B+樹存儲結(jié)構(gòu)可以更好的滿足隨機(jī)查詢操作

59、IO要求，分為數(shù)據(jù)頁和二級索引頁，修改二級索引頁面涉及到隨機(jī)操作，為了提高寫入時的性能，采用insertbuffer做順序的寫入，再由后臺線程以一定頻率將多個插入合并到二級索引頁面。為了保證數(shù)據(jù)庫的一致性（內(nèi)存和硬盤數(shù)據(jù)文件），以及縮短實(shí)例恢復(fù)的時間，關(guān)系型數(shù)據(jù)庫還有一個checkpoint的功能，用于把內(nèi)存buffer中之前的臟頁按照比例（老的LSN）寫入磁盤，這樣redolog文件的LSN以前的日志就可以被覆蓋了，進(jìn)行循環(huán)使用；在失效恢復(fù)時，只需要從日志中LSN點(diǎn)進(jìn)行恢復(fù)即可。在事務(wù)特性支持上，關(guān)系型數(shù)據(jù)庫需要滿足ACID四個特性，需要根據(jù)不同的事務(wù)并發(fā)和數(shù)據(jù)可見性要求，定義了不同的事務(wù)隔

60、離級別，并且離不開對資源爭用的鎖機(jī)制，要避免產(chǎn)生死鎖，mysql在Server層和存儲引擎層做并發(fā)控制，主要體現(xiàn)在讀寫鎖，根據(jù)鎖粒度不同，有各個級別的鎖（表鎖、行鎖、頁鎖、MVCC）；基于提髙并發(fā)性能的考慮,使用多版本并發(fā)控制MVCC來支持事務(wù)的隔離，并基于undo來實(shí)現(xiàn)，在做事務(wù)回滾時，也會用到undo段。mysql用redolog來保證數(shù)據(jù)的寫入的性能和失效恢復(fù)，在修改數(shù)據(jù)時只需要修改內(nèi)存，再把修改行為記錄到事務(wù)日志中（順序I0），不用每次將數(shù)據(jù)修改本身持久化到硬盤（隨機(jī)10）,大大提髙性能。在可靠性方面，innodb存儲引擎提供了兩次寫機(jī)制doublewriter用于防止在flush頁面