原文出自：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,PC客戶端,或者第三方，則一定要有一條服務匯流排，如淘寶的TOP。這個原來是用Spring MVC直接寫的，後來發現新增功能太麻煩，開發效率太低了，因此我就基於Spring MVC框架的設計思路和TOP的應用模型寫了一個Rop框架，這個已經開源的，參見我這個帖子：

http://www.iteye.com/topic/1121252

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

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

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

10.圖片伺服器獨立，每張圖片只儲存一張物理的，其實不同規格的圖片動態生成並放到記憶體中；

11.專案採用敏捷開發，DDT,Maven等。

一、 設計理念

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可以基於檔案儲存或者記憶體。參見下圖：