轉載請聲明出處： http://blog.csdn.net/yangbutao/article/details/12242441
一、 設計理念
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 的算法來實現，不支持 session 保持。
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 應用。
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 。 L og 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 版本，可以支持在不同的庫上的並行複製。
3) 分佈式數據庫
對於數據的高併發的訪問，傳統的關係型數據庫提供讀寫分離的方案，但是帶來的確實數據的一致性問題提供的數據切分的方案；對於越來越多的海量數據，傳統的數據庫採用的是分庫分表，實現起來比較複雜，後期要不斷的進行遷移維護；對於高可用和伸縮方面，傳統數據採用的是主備、主從、多主的方案，但是本身擴展性比較差，增加節點和宕機需要進行數據的遷移。對於以上提出的這些問題，分佈式數據庫 HBase 有一套完善的解決方案，適用於高併發海量數據存取的要求。
Ø HBase
基於列式的高效存儲降低 IO
通常的查詢不需要一行的全部字段，大多數只需要幾個字段
對與面向行的存儲系統，每次查詢都會全部數據取出，然後再從中選出需要的字段
面向列的存儲系統可以單獨查詢某一列，從而大大降低 IO
提高壓縮效率
同列數據具有很高的相似性，會增加壓縮效率
Hbase 的很多特性，都是由列存儲決定的
高性能
LSM Tree
適合高速寫的場景
強一致的數據訪問
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 供結果的展現和搜索。
