高併發電子商務平臺技術架構

原文出自：http://blog.csdn.net/yangbutao/article/details/12242441

http://stamen.iteye.com/blog/1525924

我本身的大型B2B和B2C站點原來也是用Hibernate，但是後來不得不換成mybatis，
第一是用Hibernate 由於它封裝得過高了。很是多東西是隱式進行的。經常引發問題，很是難定位。畢竟凡事有利必有弊；
第二大型站點確定不是一個數據庫。這點Hibernate是很是麻煩的，用Jdbc或Mybatis 可以輕鬆應付之。我本身寫的shard分庫框架眼下就是支持mybatis和Jdbc Template。
    另，認爲割捨不了Hibernate的iteyer,事實上也是建議直接再用Hibernate，待遇到痛苦時。再換，這樣體會會更深些

    個人技術選型和onecan的相似，差異在於：

1.緩存：我採用ehcache+memcached結合的方式，ehcache作JVM本地緩存。memcached作進程外全局緩存，即由本地緩存和全局緩存構成系統的二級緩存；

2.數據庫上。你用單數據庫確定是不行的。

個人平臺是劃分爲100多個庫。早期我採用淘寶的amoeba(陳師儒兄寫的)分庫技術（事實上是一個分庫中間件。經過一臺代理amoeba實現對後端mysql集羣的透明化代理。

後來發現問題多多，還有一個是中間件方案儘管使用簡單。但不夠靈活，不能作多數據庫事務，因此棄之。不得以本身寫了一個基於Java的分庫框架。即Shard。在應用層直接經過Shard操做數據庫集羣；

3.全文索引，咱們採用Solr，只是眼下想把它換成ElasticSearch,因爲Solr的全文索引同步比較慢，延時是一個很是大的問題，ES作得好些。

4.任務調度你這裏沒有講，事實上這塊對於大型站點是很是重要的。我是基於Quautz本身寫了一個全局任務調度框架。至關於任務調度雲的方式。

如天天晚上彙總數據。按期遷移數據等就可以很是好地使用任務調度來完畢。

5.編碼生成：凡是商城或應用系統，確定是要有一個編碼生成的框架，如單據號，商品編號等，要求是全局惟一。規則可本身定義。這個我是基於Spring Expression寫了一個全局的編碼框架。稱爲codeman,後面我也擬把它開源出來；

6.開放平臺：假設你的商城要贊成多終端接入，如iphone,android,PCclient,或者第三方。則必定要有一條服務總線，如淘寶的TOP。這個原來是用Spring MVC直接寫的，後來發現新增功能太麻煩。開發效率過低了。所以我就基於Spring MVC框架的設計思路和TOP的應用模型寫了一個Rop框架。這個已經開源的。參見我這個帖子：http://www.iteye.com/topic/1121252

7.NoSQL和mySQL結合。mySQL畢竟是關係型的，對於高併發的數據。咱們是放到mogonDB中的，這個數據庫的壓力會小很是多。

8.日誌的記錄：大型站點的日誌記錄是很是重要的，是審計，問題定位的根據。原來早期，我直接把日誌記錄到MySQL中，日誌很是大。數據庫壓力大。後來把它直接異步到Elastic Search中，不但可以全文檢索。併發性大時也沒有問題。
此外。對日誌編寫了一些分析引擎，可以從日誌中發現關鍵的問題，即時報警。

9.會話管理的問題：由於應用服務節點很是多，所以棄用Web應用server自己的Session功能，直接本身編寫了一個全局會話管理功能。以實現全局統一的會話管理。

10.圖片server獨立，每張圖片僅僅保存一張物理的，事實上不一樣規格的圖片動態生成並放到內存中；

11.項目採用敏捷開發。DDT,Maven等。

1、 設計理念

 

 

1.      空間換時間

1)      多級緩存，靜態化

client頁面緩存（http header中包括Expires/Cache of Control。last modified(304，server不返回body，client可以繼續用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)      資源釋放

系統的資源是有限的，在使用資源時。必定要在最後釋放資源。無論是請求走的是正常路徑仍是異常的路徑，以便於資源的及時回收，供其它請求使用。

在設計通訊的架構時。每每需要考慮超時的控制。

 

 

 

 

 

2、 靜態架構藍圖

 

整個架構是分層的分佈式的架構。縱向包含CDN，負載均衡/反向代理。web應用，業務層。基礎服務層，數據存儲層。水平方向包含對整個平臺的配置管理部署和監控。

 

3、 剖析架構

1. CDN

CDN系統能夠實時地依據網絡流量和各節點的鏈接、負載情況以及到用戶的距離和響應時間等綜合信息將用戶的請求又一次導向離用戶近期的服務節點上。其目的是使用戶可就近取得所需內容。解決 Internet網絡擁擠的情況。提升用戶訪問站點的響應速度。

對於大規模電子商務平臺通常需要建CDN作網絡加速。大型平臺如淘寶、京東都採用自建CDN，中小型的企業可以採用第三方CDN廠商合做，如藍汛、網宿、快網等。

固然在選擇CDN廠商時，需要考慮經營時間長短，是否有可擴充的帶寬資源、靈活的流量和帶寬選擇、穩定的節點、性價比。

2. 負載均衡、反向代理

一個大型的平臺包含很是多個業務域。不一樣的業務域有不一樣的集羣，可以用DNS作域名解析的分發或輪詢。DNS方式實現簡單，但是因存在cache而缺少靈活性；通常基於商用的硬件F5、NetScaler或者開源的軟負載lvs在4層作分發，固然會採用作冗餘(比方lvs+keepalived)的考慮，採取主備方式。

4層分發到業務集羣上後。會通過webserver如nginx或者HAProxy在7層作負載均衡或者反向代理分發到集羣中的應用節點。

選擇哪一種負載，需要綜合考慮各類因素（是否知足高併發高性能，Session保持怎樣解決，負載均衡的算法怎樣，支持壓縮。緩存的內存消耗）；如下基於幾種常用的負載均衡軟件作個介紹。

LVS。工做在4層，Linux實現的高性能高併發、可伸縮性、可靠的的負載均衡器。支持多種轉發方式(NAT、DR、IP Tunneling)，當中DR模式支持經過廣域網進行負載均衡。

支持雙機熱備(Keepalived或者Heartbeat)。對網絡環境的依賴性比較高。

Nginx工做在7層。事件驅動的、異步非堵塞的架構、支持多進程的高併發的負載均衡器/反向代理軟件。可以針對域名、文件夾結構、正則規則針對http作一些分流。經過port檢測到server內部的故障。比方依據server處理網頁返回的狀態碼、超時等等。並且會把返回錯誤的請求又一次提交到還有一個節點，只是當中缺點就是不支持url來檢測。

對於session sticky。可以基於ip hash的算法來實現，經過基於cookie的擴展nginx-sticky-module支持session sticky。

HAProxy支持4層和7層作負載均衡，支持session的會話保持，cookie的引導；支持後端url方式的檢測。負載均衡的算法比較豐富，有RR、權重等。

對於圖片，需要有單獨的域名。獨立或者分佈式的圖片server或者如mogileFS。可以圖片server之上加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) 通訊組件

通訊組件用於業務系統內部服務之間的調用，在大併發的電商平臺中，需要知足高併發高吞吐量的要求。

整個通訊組件包含client和服務端兩部分。

client和server端維護的是長鏈接，可以下降每次請求創建鏈接的開銷，在client對於每個server定義一個鏈接池，初始化鏈接後。可以併發鏈接服務端進行rpc操做，鏈接池中的長鏈接需要心跳維護，設置請求超時時間。

對於長鏈接的維護過程可以分兩個階段。一個是發送請求過程。另一個是接收響應過程。在發送請求過程當中。若發生IOException，則把該鏈接標記失效。

接收響應時，服務端返回SocketTimeoutException，假設設置了超時時間，那麼就直接返回異常，清除當前鏈接中那些超時的請求。不然繼續發送心跳包(因爲多是丟包，超過pingInterval間隔時間就發送ping操做)，若ping不通(發送IOException)。則說明當前鏈接是有問題的。那麼就把當前鏈接標記成已經失效；若ping通，則說明當前鏈接是可靠的，繼續進行讀操做。

失效的鏈接會從鏈接池中清除掉。

每個鏈接對於接收響應來講都以單獨的線程執行，client可以經過同步(wait,notify)方式或者異步進行rpc調用，

序列化採用更高效的hession序列化方式。

服務端採用事件驅動的NIO的MINA框架，支撐高併發高吞吐量的請求。

 

2) 路由Router

在大多數的數據庫切分解決方式中。爲了提升數據庫的吞吐量，首先是對不一樣的表進行垂直切分到不一樣的數據庫中，

而後當數據庫中一個表超過必定大小時，需要對該表進行水平切分，這裏也是同樣，這裏以用戶表爲例。

對於訪問數據庫client來說，需要依據用戶的ID，定位到需要訪問的數據；

數據切分算法，

依據用戶的ID作hash操做。一致性Hash，這樣的方式存在失效數據的遷移問題。遷移時間內服務不可用

維護路由表，路由表中存儲用戶和sharding的映射關係,sharding分爲leader和replica，分別負責寫和讀

這樣每個bizclient都需要保持所有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作分佈式的協調，實現集羣的列表維護和失效通知，client可以選擇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做爲快速的分佈式緩存server。協議比較簡單。基於libevent的事件處理機制。

Cache系統在平臺中用在router系統的client中，熱點的數據會緩存在client，當數據訪問失效時，纔去訪問router系統。

固然眼下不少其它的利用內存型的數據庫作cache。比方redis、mongodb。redis比memcache有豐富的數據操做的API；redis和mongodb都對數據進行了持久化，而memcache沒有這個功能。所以memcache更加適合在關係型數據庫之上的數據的緩存。

 

Buffer系統

用在快速的寫操做的場景中，平臺中有些數據需要寫入數據庫。並且數據是分庫分表的，但對數據的可靠性不是那麼高，爲了下降對數據庫的寫壓力。可以採取批量寫操做的方式。

開闢一個內存區域，當數據到達區域的必定閥值時如80%時。在內存中作分庫梳理工做(內存速度仍是比較快的)，後分庫批量flush。

6) 搜索

在電子商務平臺中搜索是一個很的重要功能，主要有搜索詞類目導航、本身主動提示和搜索排序功能。

開源的企業級搜索引擎主要有lucene, sphinx，這裏不去論述哪一種搜索引擎更好一些，只是選擇搜索引擎除了主要的功能需要支持外，非功能方面需要考慮下面兩點：

a、 搜索引擎是否支持分佈式的索引和搜索。來應對海量的數據，支持讀寫分離。提升可用性

b、 索引的實時性

c、 性能

Solr是基於lucene的高性能的全文搜索server。提供了比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、 分佈式可擴展。具備高的擴展性。當數據量添加時。可以經過添加節點水平擴展

日誌收集系統是可以伸縮的，在系統的各個層次均可伸縮。對數據的處理不需要帶狀態，伸縮性方面也比較easy實現。

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開源產品使用最爲普遍。

對於實時計算平臺。從架構設計上需要考慮下面幾個因素：

一、 伸縮性

隨着業務量的添加，計算量的添加，經過添加節點處理，就可以處理。

二、 高性能、低延遲

從數據流入計算平臺數據，到計算輸出結果。需要性能高效且低延遲，保證消息獲得高速的處理，作到實時計算。

三、 可靠性

保證每個數據消息獲得一次完整處理。

四、 容錯性

系統可以本身主動管理節點的宕機失效，相應用來講，是透明的。

Twitter的Storm在以上這幾個方面作的比較好，如下簡單介紹一下Storm的架構。

整個集羣的管理是經過zookeeper來進行的。

client提交拓撲到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的tcpport來接收消息，消息放到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基於server長鏈接的「server推」技術，包括兩種：

Long Polling：server端在接到請求後掛起。有更新時返回鏈接即斷掉，而後client再發起新的鏈接

Stream方式: 每次服務端數據傳送不會關閉鏈接，鏈接僅僅會在通訊出現錯誤時，或是鏈接重建時關閉（一些防火牆常被設置爲丟棄過長的鏈接， server端可以設置一個超時時間， 超時後通知client又一次創建鏈接。並關閉原來的鏈接）。

Websocket：長鏈接。全雙工通訊

是 Html5 的一種新的協議。它實現了瀏覽器與server的雙向通信。webSocket API 中。瀏覽器和server端僅僅需要經過一個握手的動做。便能造成瀏覽器與client之間的高速雙向通道，使得數據可以高速的雙向傳播。

Socket.io是一個NodeJS websocket庫，包含client的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到文件上的，才真正返回client。

要定時對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的很是多特性。都是由列存儲決定的

高性能

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供結果的展示和搜索。