【正文】 。2)5.隨著數(shù)據(jù)量和并發(fā)量的增加，讀寫分離不能滿足系統(tǒng)并發(fā)性能的要求，需要對數(shù)據(jù)進(jìn)行切分，包括對數(shù)據(jù)進(jìn)行分庫和分表。 伸縮1)但是有些場景中，雖然請求已經(jīng)得到處理，但是因其他原因(比如網(wǎng)絡(luò)不穩(wěn)定)，確認(rèn)消息沒有返回，那么這種情況下需要進(jìn)行請求的重發(fā)，對請求的處理設(shè)計因重發(fā)因素需要考慮冪等性。 讀寫分離讀寫分離是對數(shù)據(jù)庫來講的，隨著系統(tǒng)并發(fā)量的增大，提高數(shù)據(jù)訪問可用性的一個重要手段就是寫數(shù)據(jù)和讀數(shù)據(jù)進(jìn)行分離；當(dāng)然在讀寫分離的同時，需要關(guān)注數(shù)據(jù)的一致性問題；對于一致性的問題，在分布式的系統(tǒng)CAP定量中，更多的關(guān)注于可用性。3.2) 任務(wù)切分、分而治之(MR)在大規(guī)模的數(shù)據(jù)中，數(shù)據(jù)存在一定的局部性的特征，利用局部性的原理將海量數(shù)據(jù)計算的問題分而治之。Bitmap是一種非常簡潔快速的數(shù)據(jù)結(jié)構(gòu)，他能同時使存儲空間和速度最優(yōu)化（而不必空間換時間），適合于海量數(shù)據(jù)的的計算場景。 多級緩存，靜態(tài)化客戶端頁面緩存（ header中包含Expires/Cache of Control，last modified(304，server不返回body，客戶端可以繼續(xù)用cache，減少流量)，ETag）反向代理緩存應(yīng)用端的緩存(memcache)內(nèi)存數(shù)據(jù)庫Buffer、cache機(jī)制（數(shù)據(jù)庫，中間件等）2)設(shè)計理念 索引哈希、B樹、倒排、bitmap哈希索引適合綜合數(shù)組的尋址和鏈表的插入特性，可以實現(xiàn)數(shù)據(jù)的快速存取。2.MR模型是無共享的架構(gòu)，數(shù)據(jù)集分布至各個節(jié)點。 多進(jìn)程、多線程并行執(zhí)行(MPP)并行計算（Parallel Computing）是指同時使用多種計算資源解決計算問題的過程，是提高計算機(jī)系統(tǒng)計算速度和處理能力的一種有效手段。 多維度的可用1)3)4) 拆分拆分包括對業(yè)務(wù)的拆分和對數(shù)據(jù)庫的拆分。這種分庫分表的方式，需要增加對數(shù)據(jù)的路由邏輯支持。 優(yōu)化資源利用1) 原子操作與并發(fā)控制對于共享資源的訪問，為了防止沖突，需要進(jìn)行并發(fā)的控制，同時有些交易需要有事務(wù)性來保證交易的一致性，所以在交易系統(tǒng)的設(shè)計時，需考慮原子操作和并發(fā)控制。針對IO型的，可以采取基于事件驅(qū)動的異步非阻塞的方式，單線程方式可以減少線程的切換引起的開銷，或者在多線程的情況下采取自旋spin的方式，減少對線程的切換(比如oracle latch設(shè)計)；對于計算型的，充分利用多線程進(jìn)行操作。有些請求的失敗可能是偶然的暫時的失敗(比如網(wǎng)絡(luò)不穩(wěn)定)，需要進(jìn)行請求重試的考慮。水平方向包括對整個平臺的配置管理部署和監(jiān)控。CDNCDN系統(tǒng)能夠?qū)崟r地根據(jù)網(wǎng)絡(luò)流量和各節(jié)點的連接、負(fù)載狀況以及到用戶的距離和響應(yīng)時間等綜合信息將用戶的請求重新導(dǎo)向離用戶最近的服務(wù)節(jié)點上。當(dāng)然在選擇CDN廠商時，需要考慮經(jīng)營時間長短，是否有可擴(kuò)充的帶寬資源、靈活的流量和帶寬選擇、穩(wěn)定的節(jié)點、性價比。選擇哪種負(fù)載，需要綜合考慮各種因素（是否滿足高并發(fā)高性能，Session保持如何解決，負(fù)載均衡的算法如何，支持壓縮，緩存的內(nèi)存消耗）；下面基于幾種常用的負(fù)載均衡軟件做個介紹。對網(wǎng)絡(luò)環(huán)境的依賴性比較高。對于session對于圖片，需要有單獨(dú)的域名，獨(dú)立或者分布式的圖片服務(wù)器或者如mogileFS，可以圖片服務(wù)器之上加varnish做圖片緩存。sticky支持不是很好或者對接入的可用性要求比較高(app接入節(jié)點宕機(jī)，session隨之丟失)，這就需要考慮session的集中式存儲，使得App接入層無狀態(tài)化，同時系統(tǒng)用戶變多的時候，就可以通過增加更多的應(yīng)用節(jié)點來達(dá)到水平擴(kuò)展的目的。當(dāng)然可以根據(jù)應(yīng)用規(guī)模的大小，模塊可以部署在一起，對于大規(guī)模的應(yīng)用，一般是獨(dú)立部署的?；A(chǔ)服務(wù)中間件1)對于長連接的維護(hù)過程可以分兩個階段，一個是發(fā)送請求過程，另外一個是接收響應(yīng)過程。失效的連接會從連接池中清除掉。2)router監(jiān)聽zookeeper上/bizs/下節(jié)點狀態(tài)，緩存在線biz在router中。3)在分布式的集群中，可以用zookeeper做分布式的協(xié)調(diào)，實現(xiàn)集群的列表維護(hù)和失效通知，客戶端可以選擇hash算法或者roudrobin實現(xiàn)負(fù)載均衡；對于mastermaster模式、masterslave模式，可以通過zookeeper分布式鎖的機(jī)制來支持。業(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)用的到。kafka采用zookeeper對集群中的broker、consumer進(jìn)行管理，可以注冊topic到zookeeper上；通過zookeeper的協(xié)調(diào)機(jī)制，producer保存對應(yīng)topic的broker信息，可以隨機(jī)或者輪詢發(fā)送到broker上；并且producer可以基于語義指定分片，消息發(fā)送到broker的某分片上。5)cache失效引起的抖動，cache和存儲的一致性。對于一致性要求不高的，可以去設(shè)置緩存失效時間的策略。搜索在電子商務(wù)平臺中搜索是一個非常的重要功能，主要有搜索詞類目導(dǎo)航、自動提示和搜索排序功能。索引的實時性c、對于索引搜索實時性，Solr4的之前解決方案是結(jié)合文件全量索引和內(nèi)存增量索引合并的方式，參見下圖。mit到硬盤存儲上，若發(fā)生意外導(dǎo)致程序非正常結(jié)束，未mit的數(shù)據(jù)會丟失，因此需要定時的進(jìn)行mit操作。日志系統(tǒng)需具備三個基本組件，分別為agent（封裝數(shù)據(jù)源，將數(shù)據(jù)源中的數(shù)據(jù)發(fā)送給collector），collector（接收多個agent的數(shù)據(jù)，并進(jìn)行匯總后導(dǎo)入后端的store中），store（中央存儲系統(tǒng)，應(yīng)該具有可擴(kuò)展性和可靠性，應(yīng)該支持當(dāng)前非常流行的HDFS）。分布式可擴(kuò)展，具有高的擴(kuò)展性，當(dāng)數(shù)據(jù)量增加時，可以通過增加節(jié)點水平擴(kuò)展日志收集系統(tǒng)是可以伸縮的，在系統(tǒng)的各個層次都可伸縮，對數(shù)據(jù)的處理不需要帶狀態(tài)，伸縮性方面也比較容易實現(xiàn)。d、多個Sink可以構(gòu)成一個SinkGroup中激活一個Sink。事務(wù)支持Scribe沒有考慮事務(wù)的支持?？苫謴?fù)性FlumeNG的channel根據(jù)可靠性的要求的不同，可以基于內(nèi)存和文件持久化機(jī)制，基于內(nèi)存的數(shù)據(jù)傳輸?shù)匿N量比較高，但是在節(jié)點宕機(jī)后，數(shù)據(jù)丟失，不可恢復(fù)；而文件持久化宕機(jī)是可以恢復(fù)的。數(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ù)庫等。一個方面是Channel需要給agent確認(rèn)已經(jīng)批量收到數(shù)據(jù)記錄了，發(fā)送LSN號給agent，這樣在agent失效恢復(fù)時，可以從這個LSN點開始tail；當(dāng)然對于允許少量的重復(fù)記錄的問題(發(fā)生在channel給agent確認(rèn)的時，agent宕機(jī)并未受到確認(rèn)消息)，需要在業(yè)務(wù)場景中判斷。需要對源數(shù)據(jù)比如mysql進(jìn)行切分，多線程并發(fā)讀源數(shù)據(jù)，多線程并發(fā)批量寫入分布式數(shù)據(jù)庫比如HBase,利用channel作為讀寫之間的緩沖，實現(xiàn)更好的解耦，channel可以基于文件存儲或者內(nèi)存。數(shù)據(jù)分析從傳統(tǒng)的基于關(guān)系型數(shù)據(jù)庫并行處理集群、用于內(nèi)存計算近實時的，到目前的基于hadoop的海量數(shù)據(jù)的分析，數(shù)據(jù)的分析在大型電子商務(wù)網(wǎng)站中應(yīng)用非常廣泛，包括流量統(tǒng)計、推薦引擎、趨勢分析、用戶行為分析、數(shù)據(jù)挖掘分類器、分布式索引等等。海量數(shù)據(jù)的離線分析目前互聯(lián)網(wǎng)公司大量的使用Hadoop，Hadoop在可伸縮性、健壯性、計算性能和成本上具有無可替代的優(yōu)勢，事實上已成為當(dāng)前互聯(lián)網(wǎng)企業(yè)主流的大數(shù)據(jù)分析平臺Hadoop通過MapReuce的分布式處理框架，用于處理大規(guī)模的數(shù)據(jù)，伸縮性也非常好；但是MapReduce最大的不足是不能滿足實時性的場景，主要用于離線的分析。，一方面原有的MapReduce框架存在JobTracker單點的問題，另外一方面JobTracker在做資源管理的同時又做任務(wù)的調(diào)度工作，隨著數(shù)據(jù)量的增大和Job任務(wù)的增多，明顯存在可擴(kuò)展性、內(nèi)存消耗、線程模型、可靠性和性能上的缺陷瓶頸；電商平臺系統(tǒng)或者應(yīng)用對日常產(chǎn)生的大量日志和異常信息，需要經(jīng)過實時過濾、分析，以判定是否需要預(yù)警；同時需要對系統(tǒng)做自我保護(hù)機(jī)制，比如對模塊做流量的控制，以防止非預(yù)期的對系統(tǒng)壓力過大而引起的系統(tǒng)癱瘓，流量過大時，可以采取拒絕或者引流等機(jī)制；有些業(yè)務(wù)需要進(jìn)行風(fēng)險的控制，比如彩票中有些業(yè)務(wù)需要根據(jù)系統(tǒng)的實時銷售情況進(jìn)行限號與放號。storm等，以storm開源產(chǎn)品使用最為廣泛。高性能、低延遲從數(shù)據(jù)流入計算平臺數(shù)據(jù)，到計算輸出結(jié)果，需要性能高效且低延遲，保證消息得到快速的處理，做到實時計算。容錯性系統(tǒng)可以自動管理節(jié)點的宕機(jī)失效，對應(yīng)用來說，是透明的。Nimbus針對該拓?fù)浣⒈镜氐哪夸浉鶕?jù)topology的配置計算task，分配task，在zookeeper上建立assignments節(jié)點存儲task和supervisor機(jī)器節(jié)點中woker的對應(yīng)關(guān)系。Tuple是流的基本處理單元，也就是一個消息，Tuple在task中流轉(zhuǎn)，Tuple的發(fā)送和接收過程如下：發(fā)送Tuple，Worker提供了一個transfer的功能，用于當(dāng)前task把tuple發(fā)到到其他的task中。，每一個woker綁定一個inboundqueue用于接收message，outbond每個tuple可以emit到directidponent通過以上分析可以看到，Storm在伸縮性、容錯性、高性能方面的從架構(gòu)設(shè)計的角度得以支撐；同時在可靠性方面，Storm的ack組件利用異或xor算法在不失性能的同時，保證每一個消息得到完整處理的同時。實時推送實時推送的應(yīng)用場景非常多，比如系統(tǒng)的監(jiān)控動態(tài)的實時曲線繪制，手機(jī)消息的推送，web實時聊天等。每次服務(wù)端數(shù)據(jù)傳送不會關(guān)閉連接，連接只會在通信出現(xiàn)錯誤時，或是連接重建時關(guān)閉（一些防火墻常被設(shè)置為丟棄過長的連接，Html5API12) 推薦引擎