1號店電商峯值與流式計算

概述：  京東61八、 1號店711，還有全民購物狂歡節雙11，電商促銷的浪潮此起彼伏。然而，在買家和賣家歡呼雀躍的同時，電商平臺正在經歷着很是嚴峻的考驗。面對一天以內猶如洪水般的網購流量，哪怕出現幾分鐘的閃失，均可能形成衆多筆訂單的損失，以及沒法挽回的銷售收入。

電商峯值系統要知足三面的要求：低時延，系統對數據的處理速度要快；高可用性，故障可及時恢復，對業務影響降到最小；易擴展性，可動態添加新的計算節點，不影響在線業務，甚至能夠自動作出優化調整。

從這三個角度出發，Hadoop框架更適合於大數據批量處理。畢竟，它是先存儲再訪問，屬於「一次寫入屢次讀取」的業務類型。然而電商行業的不少業務，強調訪問處理的實時性，包括電商搜索引擎、基於用戶購買行爲的實時商品推薦和針對網站流量的監控及反做弊等功能。這些業務要求處理行爲達到秒級甚至毫秒級的時延，從而促進了以Storm爲表明的流式計算系統的推廣和應用。

流式計算解決方案

1號店結合本身的業務需求，在力求下降成本的前提下，最終採納Storm計算框架來實現本身的分佈式流計算平臺

Tracker是1號店獨自開發的數據記錄方案，它結合Flume構成網站的數據採集模塊，能在保證日誌記錄效率和穩定性的同時，更好地支持橫向擴展，以應對日益龐大的數據量。咱們採用Kafka做爲前端消息數據緩衝，儘量下降數據丟失率，同時可以靈活知足不一樣業務對消息處理並行性和有序性的偏好要求。Storm應用的計算結果，按照各自業務需求選擇持久化存儲或丟棄。

 

爲了更進一步保證流式計算系統的穩定性，光有容錯處理是不夠的，咱們還必須千方百計減小計算平臺被太重負載壓垮的風險。Linux容器技術爲咱們的需求提供了極大便利。它以CGroup內核功能爲基礎，能夠支持對CPU、內存、塊設備讀寫和網絡流量等資源的隔離限制，並且此類限制能夠細化到進程級別（CGroup是以進程組爲基本工做單位的）。經過採用Linux容器技術，能夠避免某些業務進程侵佔過多系統資源，從而致使節點系統響應緩慢甚至徹底癱瘓。

 

很遺憾，Storm自身尚未支持CGroup資源隔離功能。目前的Storm on Yarn仍是個概念性實現，由於YARN對Storm的資源隔離，僅針對整個Storm集羣所佔用的資源，以實現和Hadoop批量計算框架在同一集羣上的共存。而咱們的客觀需求是但願能對Storm平臺上Topology一級進行資源限制，對應到每一個計算節點上，就是一種進程級別的資源隔離需求。最終的解決辦法是，咱們獨立設計本身的CGroup資源管理框架，來實現對Storm Topology的資源隔離限制

更簡單的用戶體驗

1. 用戶不需掌握CGroup的複雜細節（層級、子系統、組概念及相關操做系統和文件系統知識）。

2. 僅需掌握三種操做：

建立/刪除某一類型的CGroup，目前支持cpu、memory和cpuset三種類型；

分配進程到指定的CGroup。

3. 如上操做能夠經過從新設計實現的客戶端指令（ycgClient）完成。

4. 用戶僅需在Storm UI上對Storm Topology指定優先級（該處優先級定義爲進程所在的進程組可獲取資源的大小）。

5. 由守護進程（ycgManager）自動管理各計算節點的進程級優先級

自動化方案下降手動管理成本

Storm Topology的優先級信息存儲在ZooKeeper集羣中。

資源管理框架能夠自適應異構機器結點的動態添加。

便於集羣管理（機器配置信息會自動存儲在ZooKeeper中，包括邏輯CPU個數、內存和交換分區大小）。

總結：

1號店做爲一家成立時間較短的中小規模電商，業務增加十分迅速。咱們意識到本身的實時計算平臺在從此會有更大的壓力和考驗。在保證現有系統正常運行的同時，咱們也在積極蒐集業務部門的各類反饋，基於目前的平臺和技術作進一步的調研和二次開發。如何提升系統峯值處理時的性能和可靠性，咱們依然任重而道遠。