一、 設計理念
1. 空間換時間
1) 多級快取，靜態化
客戶端頁面快取（http header中包含Expires/Cache of Control，last modified(304，server不返回body，客戶端可以繼續用cache，減少流量)，ETag）
反向代理快取
應用端的快取(memcache)
記憶體資料庫
Buffer、cache機制（資料庫，中介軟體等）
2) 索引
雜湊、B樹、倒排、bitmap
雜湊索引適合綜合陣列的定址和連結串列的插入特性，可以實現資料的快速存取。
B樹索引適合於查詢為主導的場景，避免多次的IO，提高查詢的效率。
倒排索引實現單詞到文件對映關係的最佳實現方式和最有效的索引結構，廣泛用在搜尋領域。
Bitmap是一種非常簡潔快速的資料結構，他能同時使儲存空間和速度最優化（而不必空間換時間），適合於海量資料的的計算場景。
2. 並行與分散式計算
1) 任務切分、分而治之(MR)
在大規模的資料中，資料存在一定的區域性性的特徵，利用區域性性的原理將海量資料計算的問題分而治之。
MR模型是無共享的架構，資料集分佈至各個節點。處理時，每個節點就近讀取本地儲存的資料處理(map)，將處理後的資料進行合併(combine)、排序(shuffle and sort)後再分發(至reduce節點)，避免了大量資料的傳輸，提高了處理效率。
2) 多程式、多執行緒並行執行(MPP)
平行計算（Parallel Computing）是指同時使用多種計算資源解決計算問題的過程，是提高計算機系統計算速度和處理能力的一種有效手段。它的基本思想是用多個處理器/程式/執行緒來協同求解同一問題，即將被求解的問題分解成若干個部分，各部分均由一個獨立的處理機來平行計算。
和MR的區別在於，它是基於問題分解的，而不是基於資料分解。
3. 多維度的可用
1) 負載均衡、容災、備份
隨著平臺併發量的增大，需要擴容節點進行叢集，利用負載均衡裝置進行請求的分發；負載均衡裝置通常在提供負載均衡的同時，也提供失效檢測功能；同時為了提高可用性，需要有容災備份，以防止節點當機失效帶來的不可用問題；備份有線上的和離線備份，可以根據失效性要求的不同，進行選擇不同的備份策略。
2) 讀寫分離
讀寫分離是對資料庫來講的，隨著系統併發量的增大，提高資料訪問可用性的一個重要手段就是寫資料和讀資料進行分離；當然在讀寫分離的同時，需要關注資料的一致性問題；對於一致性的問題，在分散式的系統CAP定量中，更多的關注於可用性。
3) 依賴關係
平臺中各個模組之間的關係儘量是低耦合的，可以通過相關的訊息元件進行互動，能非同步則非同步，分清楚資料流轉的主流程和副流程，主副是非同步的，比如記錄日誌可以是非同步操作的，增加整個系統的可用性。
當然在非同步處理中，為了確保資料得到接收或者處理，往往需要確認機制(confirm、ack)。
但是有些場景中，雖然請求已經得到處理，但是因其他原因(比如網路不穩定)，確認訊息沒有返回，那麼這種情況下需要進行請求的重發，對請求的處理設計因重發因素需要考慮冪等性。
4) 監控
監控也是提高整個平臺可用性的一個重要手段，多平臺進行多個維度的監控；模組在執行時候是透明的，以達到執行期白盒化。
4. 伸縮
1) 拆分
拆分包括對業務的拆分和對資料庫的拆分。
系統的資源總是有限的，一段比較長的業務執行如果是一竿子執行的方式，在大量併發的操作下，這種阻塞的方式，無法有效的及時釋放資源給其他程式執行，這樣系統的吞吐量不高。
需要把業務進行邏輯的分段，採用非同步非阻塞的方式，提高系統的吞吐量。
隨著資料量和併發量的增加，讀寫分離不能滿足系統併發效能的要求，需要對資料進行切分，包括對資料進行分庫和分表。這種分庫分表的方式，需要增加對資料的路由邏輯支援。
2) 無狀態
對於系統的伸縮性而言，模組最好是無狀態的，通過增加節點就可以提高整個的吞吐量。
5. 優化資源利用
1) 系統容量有限
系統的容量是有限的，承受的併發量也是有限的，在架構設計時，一定需要考慮流量的控制，防止因意外攻擊或者瞬時併發量的衝擊導致系統崩潰。在設計時增加流控的措施，可考慮對請求進行排隊，超出預期的範圍，可以進行告警或者丟棄。
2) 原子操作與併發控制
對於共享資源的訪問，為了防止衝突，需要進行併發的控制，同時有些交易需要有事務性來保證交易的一致性，所以在交易系統的設計時，需考慮原子操作和併發控制。
保證併發控制一些常用高效能手段有，樂觀鎖、Latch、mutex、寫時複製、CAS等；多版本的併發控制MVCC通常是保證一致性的重要手段，這個在資料庫的設計中經常會用到。
3) 基於邏輯的不同，採取不一樣的策略
平臺中業務邏輯存在不同的型別，有計算複雜型的，有消耗IO型的，同時就同一種型別而言，不同的業務邏輯消耗的資源數量也是不一樣的，這就需要針對不同的邏輯採取不同的策略。
針對IO型的，可以採取基於事件驅動的非同步非阻塞的方式，單執行緒方式可以減少執行緒的切換引起的開銷，或者在多執行緒的情況下采取自旋spin的方式，減少對執行緒的切換(比如oracle latch設計)；對於計算型的，充分利用多執行緒進行操作。
同一型別的呼叫方式，不同的業務進行合適的資源分配，設定不同的計算節點數量或者執行緒數量，對業務進行分流，優先執行優先順序別高的業務。
4) 容錯隔離
系統的有些業務模組在出現錯誤時，為了減少併發下對正常請求的處理的影響，有時候需要考慮對這些異常狀態的請求進行單獨渠道的處理，甚至暫時自動禁止這些異常的業務模組。
有些請求的失敗可能是偶然的暫時的失敗(比如網路不穩定)，需要進行請求重試的考慮。
5) 資源釋放
系統的資源是有限的，在使用資源時，一定要在最後釋放資源，無論是請求走的是正常路徑還是異常的路徑，以便於資源的及時回收，供其他請求使用。
在設計通訊的架構時，往往需要考慮超時的控制。
二、 靜態架構藍圖
整個架構是分層的分散式的架構，縱向包括CDN，負載均衡/反向代理，web應用，業務層，基礎服務層，資料儲存層。水平方向包括對整個平臺的配置管理部署和監控。
三、 剖析架構
1. CDN
CDN系統能夠實時地根據網路流量和各節點的連線、負載狀況以及到使用者的距離和響應時間等綜合資訊將使用者的請求重新導向離使用者最近的服務節點上。其目的是使使用者可就近取得所需內容，解決 Internet網路擁擠的狀況，提高使用者訪問網站的響應速度。
對於大規模電子商務平臺一般需要建CDN做網路加速，大型平臺如淘寶、京東都採用自建CDN，中小型的企業可以採用第三方CDN廠商合作，如藍汛、網宿、快網等。
當然在選擇CDN廠商時，需要考慮經營時間長短，是否有可擴充的頻寬資源、靈活的流量和頻寬選擇、穩定的節點、價效比。
2. 負載均衡、反向代理
一個大型的平臺包括很多個業務域，不同的業務域有不同的叢集，可以用DNS做域名解析的分發或輪詢，DNS方式實現簡單，但是因存在cache而缺乏靈活性；一般基於商用的硬體F5、NetScaler或者開源的軟負載lvs在4層做分發，當然會採用做冗餘(比如lvs+keepalived)的考慮，採取主備方式。
4層分發到業務叢集上後，會經過web伺服器如nginx或者HAProxy在7層做負載均衡或者反向代理分發到叢集中的應用節點。
選擇哪種負載，需要綜合考慮各種因素（是否滿足高併發高效能，Session保持如何解決，負載均衡的演算法如何，支援壓縮，快取的記憶體消耗）；下面基於幾種常用的負載均衡軟體做個介紹。
LVS，工作在4層，Linux實現的高效能高併發、可伸縮性、可靠的的負載均衡器，支援多種轉發方式(NAT、DR、IP Tunneling)，其中DR模式支援通過廣域網進行負載均衡。支援雙機熱備(Keepalived或者Heartbeat)。對網路環境的依賴性比較高。
Nginx工作在7層，事件驅動的、非同步非阻塞的架構、支援多程式的高併發的負載均衡器/反向代理軟體。可以針對域名、目錄結構、正則規則針對http做一些分流。通過埠檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另一個節點，不過其中缺點就是不支援url來檢測。對於session sticky，可以基於ip hash的演算法來實現，通過基於cookie的擴充套件nginx-sticky-module支援session sticky。
HAProxy支援4層和7層做負載均衡，支援session的會話保持，cookie的引導；支援後端url方式的檢測；負載均衡的演算法比較豐富，有RR、權重等。
對於圖片，需要有單獨的域名，獨立或者分散式的圖片伺服器或者如mogileFS，可以圖片伺服器之上加varnish做圖片快取。
3. App接入
應用層執行在jboss或者tomcat容器中，代表獨立的系統，比如前端購物、使用者自主服務、後端系統等
協議介面，HTTP、JSON
可以採用servlet3.0,非同步化servlet,提高整個系統的吞吐量
http請求經過Nginx，通過負載均衡演算法分到到App的某一節點，這一層層擴容起來比較簡單。
除了利用cookie儲存少量使用者部分資訊外(cookie一般不能超過4K的大小)，對於App接入層，儲存有使用者相關的session資料，但是有些反向代理或者負載均衡不支援對session sticky支援不是很好或者對接入的可用性要求比較高(app接入節點當機，session隨之丟失)，這就需要考慮session的集中式儲存，使得App接入層無狀態化，同時系統使用者變多的時候，就可以通過增加更多的應用節點來達到水平擴充套件的目的。
Session的集中式儲存，需要滿足以下幾點要求：
a、高效的通訊協議
b、session的分散式快取，支援節點的伸縮，資料的冗餘備份以及資料的遷移
c、session過期的管理
4. 業務服務
代表某一領域的業務提供的服務，對於電商而言，領域有使用者、商品、訂單、紅包、支付業務等等，不同的領域提供不同的服務，
這些不同的領域構成一個個模組，良好的模組劃分和介面設計非常重要，一般是參考高內聚、介面收斂的原則，
這樣可以提高整個系統的可用性。當然可以根據應用規模的大小，模組可以部署在一起，對於大規模的應用，一般是獨立部署的。
高併發：
業務層對外協議以NIO的RPC方式暴露，可以採用比較成熟的NIO通訊框架，如netty、mina
可用性：
為了提高模組服務的可用性，一個模組部署在多個節點做冗餘，並自動進行負載轉發和失效轉移;
最初可以利用VIP+heartbeat方式，目前系統有一個單獨的元件HA,利用zookeeper實現(比原來方案的優點)
一致性、事務：
對於分散式系統的一致性，儘量滿足可用性，一致性可以通過校對來達到最終一致的狀態。
5. 基礎服務中介軟體
1) 通訊元件
通訊元件用於業務系統內部服務之間的呼叫，在大併發的電商平臺中，需要滿足高併發高吞吐量的要求。
整個通訊元件包括客戶端和服務端兩部分。
客戶端和伺服器端維護的是長連線，可以減少每次請求建立連線的開銷，在客戶端對於每個伺服器定義一個連線池，初始化連線後，可以併發連線服務端進行rpc操作，連線池中的長連線需要心跳維護，設定請求超時時間。
對於長連線的維護過程可以分兩個階段，一個是傳送請求過程，另外一個是接收響應過程。在傳送請求過程中，若發生IOException，則把該連線標記失效。接收響應時，服務端返回SocketTimeoutException，如果設定了超時時間，那麼就直接返回異常，清除當前連線中那些超時的請求。否則繼續傳送心跳包(因為可能是丟包，超過pingInterval間隔時間就傳送ping操作)，若ping不通(傳送IOException)，則說明當前連線是有問題的，那麼就把當前連線標記成已經失效；若ping通，則說明當前連線是可靠的，繼續進行讀操作。失效的連線會從連線池中清除掉。
每個連線對於接收響應來說都以單獨的執行緒執行，客戶端可以通過同步(wait,notify)方式或者非同步進行rpc呼叫，
序列化採用更高效的hession序列化方式。
服務端採用事件驅動的NIO的MINA框架，支撐高併發高吞吐量的請求。
2) 路由Router
在大多數的資料庫切分解決方案中，為了提高資料庫的吞吐量，首先是對不同的表進行垂直切分到不同的資料庫中，
然後當資料庫中一個表超過一定大小時，需要對該表進行水平切分，這裡也是一樣，這裡以使用者表為例；
對於訪問資料庫客戶端來講，需要根據使用者的ID，定位到需要訪問的資料；
資料切分演算法，
根據使用者的ID做hash操作，一致性Hash，這種方式存在失效資料的遷移問題，遷移時間內服務不可用
維護路由表，路由表中儲存使用者和sharding的對映關係,sharding分為leader和replica，分別負責寫和讀
這樣每個biz客戶端都需要保持所有sharding的連線池，這樣有個缺點是會產生全連線的問題；
一種解決方法是sharding的切分提到業務服務層進行，每個業務節點只維護一個shard的連線即可。
見圖（router）
路由元件的實現是這樣的（可用性、高效能、高併發）
基於效能方面的考慮，採用mongodb中維護使用者id和shard的關係，為了保證可用性，搭建replicatset叢集。
biz的sharding和資料庫的sharding是一一對應的，只訪問一個資料庫sharding.
biz業務註冊節點到zookeeper上/bizs/shard/下。
router監聽zookeeper上/bizs/下節點狀態，快取線上biz在router中。
client請求router獲取biz時，router首先從mongodb中獲取使用者對應的shard,router根據快取的內容通過RR演算法獲取biz節點。
為了解決router的可用性和併發吞吐量問題，對router進行冗餘，同時client監聽zookeeper的/routers節點並快取線上router節點列表。
3) HA
傳統實現HA的做法一般是採用虛擬IP漂移，結合Heartbeat、keepalived等實現HA，
Keepalived使用vrrp方式進行資料包的轉發，提供4層的負載均衡，通過檢測vrrp資料包來切換，做冗餘熱備更加適合與LVS搭配。Linux Heartbeat是基於網路或者主機的服務的高可用，HAProxy或者Nginx可以基於7層進行資料包的轉發，因此Heatbeat更加適合做HAProxy、Nginx，包括業務的高可用。
在分散式的叢集中，可以用zookeeper做分散式的協調，實現叢集的列表維護和失效通知，客戶端可以選擇hash演算法或者roudrobin實現負載均衡；對於master-master模式、master-slave模式，可以通過zookeeper分散式鎖的機制來支援。
4) 訊息Message
對於平臺各個系統之間的非同步互動，是通過MQ元件進行的。
在設計訊息服務元件時，需要考慮訊息一致性、持久化、可用性、以及完善的監控體系。
業界開源的訊息中介軟體主要RabbitMQ、kafka有兩種，
RabbitMQ,遵循AMQP協議，由內在高併發的erlanng語言開發；kafka是Linkedin於2010年12月份開源的訊息釋出訂閱系統,它主要用於處理活躍的流式資料,大資料量的資料處理上。
對訊息一致性要求比較高的場合需要有應答確認機制，包括生產訊息和消費訊息的過程；不過因網路等原理導致的應答缺失，可能會導致訊息的重複，這個可以在業務層次根據冪等性進行判斷過濾；RabbitMQ採用的是這種方式。還有一種機制是消費端從broker拉取訊息時帶上LSN號，從broker中某個LSN點批量拉取訊息，這樣無須應答機制，kafka分散式訊息中介軟體就是這種方式。
訊息的在broker中的儲存，根據訊息的可靠性的要求以及效能方面的綜合衡量，可以在記憶體中，可以持久化到儲存上。
對於可用性和高吞吐量的要求，叢集和主備模式都可以在實際的場景應用的到。RabbitMQ解決方案中有普通的叢集和可用性更高的mirror queue方式。 kafka採用zookeeper對叢集中的broker、consumer進行管理，可以註冊topic到zookeeper上；通過zookeeper的協調機制，producer儲存對應topic的broker資訊，可以隨機或者輪詢傳送到broker上；並且producer可以基於語義指定分片，訊息傳送到broker的某分片上。
總體來講，RabbitMQ用在實時的對可靠性要求比較高的訊息傳遞上。kafka主要用於處理活躍的流式資料,大資料量的資料處理上。
5) Cache&Buffer
Cache系統
在一些高併發高效能的場景中，使用cache可以減少對後端系統的負載，承擔可大部分讀的壓力，可以大大提高系統的吞吐量，比如通常在資料庫儲存之前增加cache快取。
但是引入cache架構不可避免的帶來一些問題，cache命中率的問題, cache失效引起的抖動，cache和儲存的一致性。
Cache中的資料相對於儲存來講，畢竟是有限的，比較理想的情況是儲存系統的熱點資料，這裡可以用一些常見的演算法LRU等等淘汰老的資料；隨著系統規模的增加，單個節點cache不能滿足要求，就需要搭建分散式Cache；為了解決單個節點失效引起的抖動 ，分散式cache一般採用一致性hash的解決方案，大大減少因單個節點失效引起的抖動範圍；而對於可用性要求比較高的場景，每個節點都是需要有備份的。資料在cache和儲存上都存有同一份備份，必然有一致性的問題，一致性比較強的，在更新資料庫的同時，更新資料庫cache。對於一致性要求不高的，可以去設定快取失效時間的策略。
Memcached作為高速的分散式快取伺服器，協議比較簡單，基於libevent的事件處理機制。
Cache系統在平臺中用在router系統的客戶端中，熱點的資料會快取在客戶端，當資料訪問失效時，才去訪問router系統。
當然目前更多的利用記憶體型的資料庫做cache，比如redis、mongodb；redis比memcache有豐富的資料操作的API；redis和mongodb都對資料進行了持久化，而memcache沒有這個功能，因此memcache更加適合在關係型資料庫之上的資料的快取。
Buffer系統
用在高速的寫操作的場景中，平臺中有些資料需要寫入資料庫，並且資料是分庫分表的，但對資料的可靠性不是那麼高，為了減少對資料庫的寫壓力，可以採取批量寫操作的方式。
開闢一個記憶體區域，當資料到達區域的一定閥值時如80%時，在記憶體中做分庫梳理工作(記憶體速度還是比較快的)，後分庫批量flush。
6) 搜尋
在電子商務平臺中搜尋是一個非常的重要功能，主要有搜尋詞類目導航、自動提示和搜尋排序功能。
開源的企業級搜尋引擎主要有lucene, sphinx，這裡不去論述哪種搜尋引擎更好一些，不過選擇搜尋引擎除了基本的功能需要支援外，非功能方面需要考慮以下兩點：
a、 搜尋引擎是否支援分散式的索引和搜尋，來應對海量的資料，支援讀寫分離，提高可用性
b、 索引的實時性
c、 效能
Solr是基於lucene的高效能的全文搜尋伺服器，提供了比lucene更為豐富的查詢語言，可配置可擴充套件，對外提供基於http協議的XML/JSON格式的介面。
從Solr4版本開始提供了SolrCloud方式來支援分散式的索引，自動進行sharding資料切分；通過每個sharding的master-slave(leader、replica)模式提高搜尋的效能；利用zookeeper對叢集進行管理，包括leader選舉等等，保障叢集的可用性。
Lucene索引的Reader是基於索引的snapshot的，所以必須在索引commit的後，重新開啟一個新的snapshot，才能搜尋到新新增的內容；而索引的commit是非常耗效能的，這樣達到實時索引搜尋效率就比較低下。
對於索引搜尋實時性，Solr4的之前解決方案是結合檔案全量索引和記憶體增量索引合併的方式，參見下圖。
Solr4提供了NRT softcommit的解決方案，softcommit無需進行提交索引操作，就可以搜素到最新對索引的變更，不過對索引的變更並沒有sync commit到硬碟儲存上，若發生意外導致程式非正常結束，未commit的資料會丟失，因此需要定時的進行commit操作。
平臺中對資料的索引和儲存操作是非同步的，可以大大提高可用性和吞吐量；只對某些屬性欄位做索引操作，儲存資料的標識key，減少索引的大小；資料是儲存在分散式儲存HBase 中的，HBase對二級索引搜尋支援的不好，然而可以結合Solr搜尋功能進行多維度的檢索統計。
索引資料和HBase資料儲存的一致性，也就是如何保障HBase儲存的資料都被索引過，可以採用confirm確認機制，通過在索引前建立待索引資料佇列，在資料儲存並索引完成後，從待索引資料佇列中刪除資料。
7) 日誌收集
在整個交易過程中，會產生大量的日誌，這些日誌需要收集到分散式儲存系統中儲存起來，以便於集中式的查詢和分析處理。
日誌系統需具備三個基本元件，分別為agent（封裝資料來源，將資料來源中的資料傳送給collector），collector（接收多個agent的資料，並進行彙總後匯入後端的store中），store（中央儲存系統，應該具有可擴充套件性和可靠性，應該支援當前非常流行的HDFS）。
開源的日誌收集系統業界使用的比較多的是cloudera的Flume和facebook的Scribe，其中Flume目前的版本FlumeNG對Flume從架構上做了較大的改動。
在設計或者對日誌收集系統做技術選型時，通常需要具有以下特徵：
a、 應用系統和分析系統之間的橋樑，將他們之間的關係解耦
b、 分散式可擴充套件，具有高的擴充套件性，當資料量增加時，可以通過增加節點水平擴充套件
日誌收集系統是可以伸縮的，在系統的各個層次都可伸縮，對資料的處理不需要帶狀態，伸縮性方面也比較容易實現。
c、 近實時性
在一些時效性要求比較高的場景中，需要可以及時的收集日誌，進行資料分析；
一般的日誌檔案都會定時或者定量的進行rolling，所以實時檢測日誌檔案的生成，及時對日誌檔案進行類似的tail操作，並支援批量傳送提高傳輸效率；批量傳送的時機需要滿足訊息數量和時間間隔的要求。
d、 容錯性
Scribe在容錯方面的考慮是，當後端的儲存系統crash時，scribe會將資料寫到本地磁碟上，當儲存系統恢復正常後，scribe將日誌重新載入到儲存系統中。
FlumeNG通過Sink Processor實現負載均衡和故障轉移。多個Sink可以構成一個Sink Group。一個Sink Processor負責從一個指定的Sink Group中啟用一個Sink。Sink Processor可以通過組中所有Sink實現負載均衡；也可以在一個Sink失敗時轉移到另一個。
e、 事務支援
Scribe沒有考慮事務的支援。
Flume通過應答確認機制實現事務的支援，參見下圖，
通常提取傳送訊息都是批量操作的，訊息的確認是對一批資料的確認，這樣可以大大提高資料傳送的效率。
f、 可恢復性
FlumeNG的channel根據可靠性的要求的不同，可以基於記憶體和檔案持久化機制，基於記憶體的資料傳輸的銷量比較高，但是在節點當機後，資料丟失，不可恢復；而檔案持久化當機是可以恢復的。
g、 資料的定時定量歸檔
資料經過日誌收集系統歸集後，一般儲存在分散式檔案系統如Hadoop，為了便於對資料進行後續的處理分析，需要定時(TimeTrigger)或者定量(SizeTrigger的rolling分散式系統的檔案。
8) 資料同步
在交易系統中，通常需要進行異構資料來源的同步，通常有資料檔案到關係型資料庫，資料檔案到分散式資料庫，關係型資料庫到分散式資料庫等。資料在異構源之間的同步一般是基於效能和業務的需求，資料儲存在本地檔案中一般是基於效能的考慮，檔案是順序儲存的，效率還是比較高的；資料同步到關係型資料一般是基於查詢的需求；而分散式資料庫是儲存越來越多的海量資料的，而關係型資料庫無法滿足大資料量的儲存和查詢請求。
在資料同步的設計中需要綜合考慮吞吐量、容錯性、可靠性、一致性的問題
同步有實時增量資料同步和離線全量資料區分，下面從這兩個維度來介紹一下，
實時增量一般是Tail檔案來實時跟蹤檔案變化，批量或者多執行緒往資料庫匯出,這種方式的架構類似於日誌收集框架。這種方式需要有確認機制，包括兩個方面。
一個方面是Channel需要給agent確認已經批量收到資料記錄了，傳送LSN號給agent，這樣在agent失效恢復時，可以從這個LSN點開始tail；當然對於允許少量的重複記錄的問題(發生在channel給agent確認的時，agent當機並未受到確認訊息)，需要在業務場景中判斷。
另外一個方面是sync給channel確認已經批量完成寫入到資料庫的操作，這樣channel可以刪除這部分已經confirm的訊息。
基於可靠性的要求，channel可以採用檔案持久化的方式。
參見下圖
離線全量遵循空間間換取時間，分而治之的原則，儘量的縮短資料同步的時間，提高同步的效率。
需要對源資料比如mysql進行切分，多執行緒併發讀源資料，多執行緒併發批量寫入分散式資料庫比如HBase,利用channel作為讀寫之間的緩衝，實現更好的解耦，channel可以基於檔案儲存或者記憶體。參見下圖：
對於源資料的切分，如果是檔案可以根據檔名稱設定塊大小來切分。
對於關係型資料庫，由於一般的需求是隻離線同步一段時間的資料(比如凌晨把當天的訂單資料同步到HBase)，所以需要在資料切分時(按照行數切分)，會多執行緒掃描整個表(及時建索引，也要回表)，對於表中包含大量的資料來講，IO很高，效率非常低；這裡解決的方法是對資料庫按照時間欄位(按照時間同步的)建立分割槽，每次按照分割槽進行匯出。
9) 資料分析
從傳統的基於關係型資料庫並行處理叢集、用於記憶體計算近實時的，到目前的基於hadoop的海量資料的分析，資料的分析在大型電子商務網站中應用非常廣泛，包括流量統計、推薦引擎、趨勢分析、使用者行為分析、資料探勘分類器、分散式索引等等。
並行處理叢集有商業的EMC Greenplum，Greenplum的架構採用了MPP(大規模並行處理)，基於postgresql的大資料量儲存的分散式資料庫。
記憶體計算方面有SAP的HANA，開源的nosql記憶體型的資料庫mongodb也支援mapreduce進行資料的分析。
海量資料的離線分析目前網際網路公司大量的使用Hadoop，Hadoop在可伸縮性、健壯性、計算效能和成本上具有無可替代的優勢，事實上已成為當前網際網路企業主流的大資料分析平臺
Hadoop通過MapReuce的分散式處理框架，用於處理大規模的資料，伸縮性也非常好；但是MapReduce最大的不足是不能滿足實時性的場景，主要用於離線的分析。
基於MapRduce模型程式設計做資料的分析，開發上效率不高，位於hadoop之上Hive的出現使得資料的分析可以類似編寫sql的方式進行，sql經過語法分析、生成執行計劃後最終生成MapReduce任務進行執行，這樣大大提高了開發的效率，做到以ad-hoc(計算在query發生時)方式進行的分析。
基於MapReduce模型的分散式資料的分析都是離線的分析，執行上都是暴力掃描，無法利用類似索引的機制；開源的Cloudera Impala是基於MPP的並行程式設計模型的，底層是Hadoop儲存的高效能的實時分析平臺，可以大大降低資料分析的延遲。
目前Hadoop使用的版本是Hadoop1.0，一方面原有的MapReduce框架存在JobTracker單點的問題，另外一方面JobTracker在做資源管理的同時又做任務的排程工作，隨著資料量的增大和Job任務的增多，明視訊記憶體在可擴充套件性、記憶體消耗、執行緒模型、可靠性和效能上的缺陷瓶頸；Hadoop2.0 yarn對整個框架進行了重構，分離了資源管理和任務排程，從架構設計上解決了這個問題。
參考Yarn的架構
10) 實時計算
在網際網路領域，實時計算被廣泛實時監控分析、流控、風險控制等領域。電商平臺系統或者應用對日常產生的大量日誌和異常資訊，需要經過實時過濾、分析，以判定是否需要預警；
同時需要對系統做自我保護機制，比如對模組做流量的控制，以防止非預期的對系統壓力過大而引起的系統癱瘓，流量過大時，可以採取拒絕或者引流等機制；有些業務需要進行風險的控制，比如彩票中有些業務需要根據系統的實時銷售情況進行限號與放號。
原始基於單節點的計算，隨著系統資訊量爆炸式產生以及計算的複雜度的增加，單個節點的計算已不能滿足實時計算的要求，需要進行多節點的分散式的計算，分散式實時計算平臺就出現了。
這裡所說的實時計算，其實是流式計算，概念前身其實是CEP複雜事件處理，相關的開源產品如Esper，業界分散式的流計算產品Yahoo S4,Twitter storm等，以storm開源產品使用最為廣泛。
對於實時計算平臺，從架構設計上需要考慮以下幾個因素：
1、 伸縮性
隨著業務量的增加，計算量的增加，通過增加節點處理，就可以處理。
2、 高效能、低延遲
從資料流入計算平臺資料，到計算輸出結果，需要效能高效且低延遲，保證訊息得到快速的處理，做到實時計算。
3、 可靠性
保證每個資料訊息得到一次完整處理。
4、 容錯性
系統可以自動管理節點的當機失效，對應用來說，是透明的。
Twitter的Storm在以上這幾個方面做的比較好，下面簡介一下Storm的架構。
整個叢集的管理是通過zookeeper來進行的。
客戶端提交拓撲到nimbus。
Nimbus針對該拓撲建立本地的目錄根據topology的配置計算task，分配task，在zookeeper上建立assignments節點儲存task和supervisor機器節點中woker的對應關係。
在zookeeper上建立taskbeats節點來監控task的心跳；啟動topology。
Supervisor去zookeeper上獲取分配的tasks，啟動多個woker進行，每個woker生成task，一個task一個執行緒；根據topology資訊初始化建立task之間的連線;Task和Task之間是通過zeroMQ管理的；之後整個拓撲執行起來。
Tuple是流的基本處理單元，也就是一個訊息，Tuple在task中流轉，Tuple的傳送和接收過程如下：
傳送Tuple，Worker提供了一個transfer的功能，用於當前task把tuple發到到其他的task中。以目的taskid和tuple引數，序列化tuple資料並放到transfer queue中。
在0.8版本之前，這個queue是LinkedBlockingQueue，0.8之後是DisruptorQueue。
在0.8版本之後，每一個woker繫結一個inbound transfer queue和outbond queue，inbound queue用於接收message，outbond queue用於傳送訊息。
傳送訊息時，由單個執行緒從transferqueue中拉取資料，把這個tuple通過zeroMQ傳送到其他的woker中。
接收Tuple，每個woker都會監聽zeroMQ的tcp埠來接收訊息，訊息放到DisruptorQueue中後，後從queue中獲取message(taskid,tuple)，根據目的taskid,tuple的值路由到task中執行。每個tuple可以emit到direct steam中，也可以傳送到regular stream中，在Reglular方式下，由Stream Group（stream id–>component id –>outbond tasks）功能完成當前tuple將要傳送的Tuple的目的地。
通過以上分析可以看到，Storm在伸縮性、容錯性、高效能方面的從架構設計的角度得以支撐；同時在可靠性方面，Storm的ack元件利用異或xor演算法在不失效能的同時，保證每一個訊息得到完整處理的同時。
11) 實時推送
實時推送的應用場景非常多，比如系統的監控動態的實時曲線繪製，手機訊息的推送，web實時聊天等。
實時推送有很多技術可以實現，有Comet方式，有websocket方式等。
Comet基於伺服器長連線的“伺服器推”技術，包含兩種：
Long Polling：伺服器端在接到請求後掛起，有更新時返回連線即斷掉，然後客戶端再發起新的連線
Stream方式: 每次服務端資料傳送不會關閉連線，連線只會在通訊出現錯誤時，或是連線重建時關閉（一些防火牆常被設定為丟棄過長的連線， 伺服器端可以設定一個超時時間， 超時後通知客戶端重新建立連線，並關閉原來的連線）。
Websocket：長連線，全雙工通訊
是 Html5 的一種新的協議。它實現了瀏覽器與伺服器的雙向通訊。webSocket API 中，瀏覽器和伺服器端只需要通過一個握手的動作，便能形成瀏覽器與客戶端之間的快速雙向通道，使得資料可以快速的雙向傳播。
Socket.io是一個NodeJS websocket庫，包括客戶端的JS和服務端的的nodejs，用於快速構建實時的web應用。
12) 推薦引擎
待補充
6. 資料儲存
資料庫儲存大體分為以下幾類，有關係型（事務型）的資料庫，以oracle、mysql為代表，有keyvalue資料庫，以redis和memcached db為代表，有文件型資料庫如mongodb，有列式分散式資料庫以HBase，cassandra,dynamo為代表，還有其他的圖形資料庫、物件資料 庫、xml資料庫等。每種型別的資料庫應用的業務領域是不一樣的，下面從記憶體型、關係型、分散式三個維度針對相關的產品做效能可用性等方面的考量分析。
1) 記憶體型資料庫
記憶體型的資料庫，以高併發高效能為目標，在事務性方面沒那麼嚴格，以開源nosql資料庫mongodb、redis為例
Ø Mongodb
通訊方式
多執行緒方式，主執行緒監聽新的連線，連線後，啟動新的執行緒做資料的操作（IO切換）。
資料結構
資料庫–>collection–>record
MongoDB在資料儲存上按名稱空間來劃分，一個collection是一個名稱空間，一個索引也是一個名稱空間。
同一個名稱空間的資料被分成很多個Extent，Extent之間使用雙向連結串列連線。
在每一個Extent中，儲存了具體每一行的資料，這些資料也是通過雙向連結連線的。
每一行資料儲存空間不僅包括資料佔用空間，還可能包含一部分附加空間，這使得在資料update變大後可以不移動位置。
索引以BTree結構實現。
如果你開啟了jorunaling日誌，那麼還會有一些檔案儲存著你所有的操作記錄。
持久化儲存
MMap方式把檔案地址對映到記憶體的地址空間，直接操作記憶體地址空間就可以操作檔案，不用再呼叫write,read操作，效能比較高。
mongodb呼叫mmap把磁碟中的資料對映到記憶體中的，所以必須有一個機制時刻的刷資料到硬碟才能保證可靠性，多久刷一次是與syncdelay引數相關的。
journal（進行恢復用）是Mongodb中的redo log，而Oplog則是負責複製的binlog。如果開啟journal，那麼即使斷電也只會丟失100ms的資料，這對大多數應用來說都可以容忍了。從1.9.2+，mongodb都會預設開啟journal功能，以確保資料安全。而且journal的重新整理時間是可以改變的，2-300ms的範圍,使用 –journalCommitInterval 命令。Oplog和資料重新整理到磁碟的時間是60s，對於複製來說，不用等到oplog重新整理磁碟，在記憶體中就可以直接複製到Sencondary節點。
事務支援
Mongodb只支援對單行記錄的原子操作
HA叢集
用的比較多的是Replica Sets，採用選舉演算法，自動進行leader選舉，在保證可用性的同時，可以做到強一致性要求。
當然對於大量的資料，mongodb也提供了資料的切分架構Sharding。
Ø Redis
豐富的資料結構，高速的響應速度，記憶體操作
通訊方式
因都在記憶體操作，所以邏輯的操作非常快，減少了CPU的切換開銷，所以為單執行緒的模式（邏輯處理執行緒和主執行緒是一個）。
reactor模式，實現自己的多路複用NIO機制（epoll，select，kqueue等）
單執行緒處理多工
資料結構
hash+bucket結構，當連結串列的長度過長時，會採取遷移的措施（擴充套件原來兩倍的hash表，把資料遷移過去，expand+rehash）
持久化儲存
a、全量持久化RDB（遍歷redisDB,讀取bucket中的key,value），save命令阻塞主執行緒，bgsave開啟子程式進行snapshot持久化操作，生成rdb檔案。
在shutdown時，會呼叫save操作
資料發生變化，在多少秒內觸發一次bgsave
sync，master接受slave發出來的命令
b、增量持久化（aof類似redolog），先寫到日誌buffer,再flush到日誌檔案中（flush的策略可以配置的，而已單條，也可以批量），只有flush到檔案上的，才真正返回客戶端。
要定時對aof檔案和rdb檔案做合併操作（在快照過程中，變化的資料先寫到aof buf中等子程式完成快照<記憶體snapshot>後，再進行合併aofbuf變化的部分以及全映象資料）。
在高併發訪問模式下，RDB模式使服務的效能指標出現明顯的抖動，aof在效能開銷上比RDB好，但是恢復時重新載入到記憶體的時間和資料量成正比。
叢集HA
通用的解決方案是主從備份切換，採用HA軟體，使得失效的主redis可以快速的切換到從redis上。主從資料的同步採用複製機制，該場景可以做讀寫分離。
目前在複製方面，存在的一個問題是在遇到網路不穩定的情況下，Slave和Master斷開（包括閃斷）會導致Master需要將記憶體中的資料全部重新生成rdb檔案（快照檔案），然後傳輸給Slave。Slave接收完Master傳遞過來的rdb檔案以後會將自身的記憶體清空，把rdb檔案重新載入到記憶體中。這種方式效率比較低下，在後面的未來版本Redis2.8作者已經實現了部分複製的功能。
2) 關係型資料庫
關係型資料庫在滿足併發效能的同時，也需要滿足事務性，以mysql資料庫為例，講述架構設計原理，在效能方面的考慮，以及如何滿足可用性的需求。
Ø mysql的架構原理(innodb)
在架構上，mysql分為server層和儲存引擎層。
Server層的架構對於不同的儲存引擎來講都是一樣的,包括連線/執行緒處理、查詢處理(parser、optimizer)以及其他系統任務。儲存引擎層有很多種，mysql提供了儲存引擎的外掛式結構，支援多種儲存引擎，用的最廣泛的是innodb和myisamin；inodb主要面向OLTP方面的應用，支援事務處理，myisam不支援事務，表鎖，對OLAP操作速度快。
以下主要針對innodb儲存引擎做相關介紹。
線上程處理方面，Mysql是多執行緒的架構，由一個master執行緒，一個鎖監控執行緒，一個錯誤監控執行緒，和多個IO執行緒組成。並且對一個連線會開啟一個執行緒進行服務。io執行緒又分為節省隨機IO的insert buffer，用於事務控制的類似於oracle的redo log，以及多個write，多個read的硬碟和記憶體交換的IO執行緒。
在記憶體分配方面，包括innodb buffer pool ，以及log buffer。其中innodb buffer pool包括insert buffer、datapage、index page、資料字典、自適應hash。Log buffer用於快取事務日誌，提供效能。
在資料結構方面，innodb包括表空間、段、區、頁/塊，行。索引結構是B+tree結構，包括二級索引和主鍵索引，二級索引的葉子節點是主鍵PK，根據主鍵索引的葉子節點指向儲存的資料塊。這種B+樹儲存結構可以更好的滿足隨機查詢操作IO要求，分為資料頁和二級索引頁，修改二級索引頁面涉及到隨機操作，為了提高寫入時的效能，採用insert buffer做順序的寫入，再由後臺執行緒以一定頻率將多個插入合併到二級索引頁面。為了保證資料庫的一致性(記憶體和硬碟資料檔案)，以及縮短例項恢復的時間，關係型資料庫還有一個checkpoint的功能，用於把記憶體buffer中之前的髒頁按照比例(老的LSN)寫入磁碟，這樣redolog檔案的LSN以前的日誌就可以被覆蓋了，進行迴圈使用；在失效恢復時，只需要從日誌中LSN點進行恢復即可。
在事務特性支援上，關係型資料庫需要滿足ACID四個特性，需要根據不同的事務併發和資料可見性要求，定義了不同的事務隔離級別，並且離不開對資源爭用的鎖機制，要避免產生死鎖，mysql在Server層和儲存引擎層做併發控制，主要體現在讀寫鎖，根據鎖粒度不同，有各個級別的鎖(表鎖、行鎖、頁鎖、MVCC)；基於提高併發效能的考慮，使用多版本併發控制MVCC來支援事務的隔離，並基於undo來實現，在做事務回滾時，也會用到undo段。mysql 用redolog來保證資料的寫入的效能和失效恢復，在修改資料時只需要修改記憶體，再把修改行為記錄到事務日誌中(順序IO)，不用每次將資料修改本身持久化到硬碟(隨機IO)，大大提高效能。
在可靠性方面，innodb儲存引擎提供了兩次寫機制double writer用於防止在flush頁面到儲存上出現的錯誤，解決磁碟half-writern的問題。
Ø 對於高併發高效能的mysql來講，可以在多個維度進行效能方面的調優。
a、硬體級別，
日誌和資料的儲存，需要分開，日誌是順序的寫，需要做raid1+0，並且用buffer-IO；資料是離散的讀寫，走direct IO即可，避免走檔案系統cache帶來的開銷。
儲存能力，SAS盤raid操作（raid卡快取，關閉讀cache，關閉磁碟cache，關閉預讀，只用writeback buffer，不過需要考慮充放電的問題），當然如果資料規模不大，資料的儲存可以用高速的裝置，Fusion IO、SSD。
對於資料的寫入，控制髒頁重新整理的頻率，對於資料的讀取，控制cache hit率；因此而估算系統需要的IOPS，評估需要的硬碟數量(fusion io上到IOPS 在10w以上，普通的硬碟150)。
Cpu方面，單例項關閉NUMA，mysql對多核的支援不是太好，可以對多例項進行CPU繫結。
b、作業系統級別，
核心以及socket的優化，網路優化bond、檔案系統、IO排程
innodb主要用在OLTP類應用，一般都是IO密集型的應用，在提高IO能力的基礎上，充分利用cache機制。需要考慮的內容有，
在保證系統可用記憶體的基礎上，儘可能的擴大innodb buffer pool，一般設定為實體記憶體的3/4
檔案系統的使用，只在記錄事務日誌的時候用檔案系統的cache；儘量避免mysql用到swap(可以將vm.swappiness=0，記憶體緊張時，釋放檔案系統cache)
IO排程優化，減少不必要的阻塞，降低隨機IO訪問的延時(CFQ、Deadline、NOOP)
c、server以及儲存引擎級別（連線管理、網路管理、table管理、日誌）
包括cache/buffer、Connection、IO
d、應用級別（比如索引的考慮，schema的優化適當冗餘；優化sql查詢導致的CPU問題和記憶體問題，減少鎖的範圍，減少回表掃描，覆蓋索引）
Ø 在高可用實踐方面，
支援master-master、master-slave模式，master-master模式是一個作為主負責讀寫，另外一個作為standby提供災備，maser-slave是一個作為主提供寫操作，其他幾個節點作為讀操作，支援讀寫分離。
對於節點主備失效檢測和切換，可以採用HA軟體，當然也可以從更細粒度定製的角度，採用zookeeper作為叢集的協調服務。
對於分散式的系統來講，資料庫主備切換的一致性始終是一個問題，可以有以下幾種方式：
a、叢集方式，如oracle的rack，缺點是比較複雜
b、共享SAN儲存方式，相關的資料檔案和日誌檔案都放在共享儲存上，優點是主備切換時資料保持一致，不會丟失，但由於備機有一段時間的拉起，會有短暫的不可用狀態
c、主備進行資料同步的方式，常見的是日誌的同步，可以保障熱備，實時性好，但是切換時，可能有部分資料沒有同步過來，帶來了資料的一致性問題。可以在操作主資料庫的同時，記錄操作日誌，切換到備時，會和操作日誌做個check，補齊未同步過來的資料；
d、還有一種做法是備庫切換到主庫的regolog的儲存上，保證資料不丟失。
資料庫主從複製的效率在mysql上不是太高，主要原因是事務是嚴格保持順序的，索引mysql在複製方面包括日誌IO和relog log兩個過程都是單執行緒的序列操作，在資料複製優化方面，儘量減少IO的影響。不過到了Mysql5.6版本，可以支援在不同的庫上的並行複製。
Ø 基於不同業務要求的存取方式
平臺業務中，不同的業務有不同的存取要求，比如典型的兩大業務使用者和訂單，使用者一般來講總量是可控的，而訂單是不斷地遞增的，對於使用者表首先採取分庫切分，每個sharding做一主多讀，同樣對於訂單因更多需求的是使用者查詢自己的訂單，也需要按照使用者進行切分訂單庫，並且支援一主多讀。
在硬體儲存方面，對於事務日誌因是順序寫，快閃記憶體的優勢比硬碟高不了多少，所以採取電池保護的寫快取的raid卡儲存；對於資料檔案，無論是對使用者或者訂單都會存在大量的隨機讀寫操作，當然加大記憶體是一個方面，另外可以採用高速的IO裝置快閃記憶體，比如PCIe卡 fusion-io。使用快閃記憶體也適合在單執行緒的負載中，比如主從複製，可以對從節點配置fusion-IO卡，降低複製的延遲。
對於訂單業務來講，量是不斷遞增的，PCIe卡儲存容量比較有限，並且訂單業務的熱資料只有最近一段時間的(比如近3個月的)，對此這裡列兩種解決方案，一種是flashcache方式，採用基於快閃記憶體和硬碟儲存的開源混合儲存方式，在快閃記憶體中儲存熱點的資料。另外一種是可以定期把老的資料匯出到分散式資料庫HBase中，使用者在查詢訂單列表是近期的資料從mysql中獲取，老的資料可以從HBase中查詢，當然需要HBase良好的rowkey設計以適應查詢需求。
3) 分散式資料庫
對於資料的高併發的訪問，傳統的關係型資料庫提供讀寫分離的方案，但是帶來的確實資料的一致性問題提供的資料切分的方案；對於越來越多的海量資料，傳統的資料庫採用的是分庫分表，實現起來比較複雜，後期要不斷的進行遷移維護；對於高可用和伸縮方面，傳統資料採用的是主備、主從、多主的方案，但是本身擴充套件性比較差，增加節點和當機需要進行資料的遷移。對於以上提出的這些問題，分散式資料庫HBase有一套完善的解決方案，適用於高併發海量資料存取的要求。
Ø HBase
基於列式的高效儲存降低IO
通常的查詢不需要一行的全部欄位，大多數只需要幾個欄位
對與面向行的儲存系統，每次查詢都會全部資料取出，然後再從中選出需要的欄位
面向列的儲存系統可以單獨查詢某一列，從而大大降低IO
提高壓縮效率
同列資料具有很高的相似性，會增加壓縮效率
Hbase的很多特性，都是由列儲存決定的
強一致的資料訪問
MVCC
HBase的一致性資料訪問是通過MVCC來實現的。
HBase在寫資料的過程中，需要經過好幾個階段，寫HLog，寫memstore，更新MVCC;
只有更新了MVCC，才算真正memstore寫成功，其中事務的隔離需要有mvcc的來控制，比如讀資料不可以獲取別的執行緒還未提交的資料。
高可靠
HBase的資料儲存基於HDFS，提供了冗餘機制。
Region節點的當機，對於記憶體中的資料還未flush到檔案中，提供了可靠的恢復機制。
可伸縮，自動切分，遷移
通過Zookeeper定位目標Region Server，最後定位Region。
Region Server擴容，通過將自身釋出到Master，Master均勻分佈。
可用性
存在單點故障，Region Server當機後，短時間內該server維護的region無法訪問，等待failover生效。
通過Master維護各Region Server健康狀況和Region分佈。
多個Master，Master當機有zookeeper的paxos投票機制選取下一任Master。Master就算全當機，也不影響Region讀寫。Master僅充當一個自動運維角色。
HDFS為分散式儲存引擎，一備三，高可靠，0資料丟失。
HDFS的namenode是一個SPOF。
為避免單個region訪問過於頻繁，單機壓力過大，提供了split機制
HBase的寫入是LSM-TREE的架構方式，隨著資料的append，HFile越來越多，HBase提供了HFile檔案進行compact，對過期資料進行清除，提高查詢的效能。
Schema free
HBase沒有像關係型資料庫那樣的嚴格的schema，可以自由的增加和刪除schema中的欄位。
HBase分散式資料庫，對於二級索引支援的不太好，目前只支援在rowkey上的索引，所以rowkey的設計對於查詢的效能來講非常關鍵。
7. 管理與部署配置
統一的配置庫
部署平臺
8. 監控、統計
大型分散式系統涉及各種裝置，比如網路交換機，普通PC機，各種型號的網路卡，硬碟，記憶體等等，還有應用業務層次的監控，數量非常多的時候，出現錯誤的概率也會變大，並且有些監控的時效性要求比較高，有些達到秒級別；在大量的資料流中需要過濾異常的資料，有時候也對資料會進行上下文相關的複雜計算，進而決定是否需要告警。因此監控平臺的效能、吞吐量、已經可用性就比較重要，需要規劃統一的一體化的監控平臺對系統進行各個層次的監控。
平臺的資料分類
應用業務級別：應用事件、業務日誌、審計日誌、請求日誌、異常、請求業務metrics、效能度量
系統級別：CPU、記憶體、網路、IO
時效性要求
閥值，告警：
實時計算：
近實時分鐘計算
按小時、天的離線分析
實時查詢
架構
節點中Agent代理可以接收日誌、應用的事件以及通過探針的方式採集資料，agent採集資料的一個原則是和業務應用的流程是非同步隔離的，不影響交易流程。
資料統一通過collector叢集進行收集，按照資料的不同型別分發到不同的計算叢集進行處理；有些資料時效性不是那麼高，比如按小時進行統計，放入hadoop叢集；有些資料是請求流轉的跟蹤資料，需要可以查詢的，那麼就可以放入solr叢集進行索引；有些資料需要進行實時計算的進而告警的，需要放到storm叢集中進行處理。
資料經過計算叢集處理後，結果儲存到Mysql或者HBase中。
監控的web應用可以把監控的實時結果推送到瀏覽器中，也可以提供API供結果的展現和搜尋。
