概述：??京東618、 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號店作為一家成立時間較短的中小規模電商，業務增長十分迅速。我們意識到自己的實時計算平臺在今后會有更大的壓力和考驗。在保證現有系統正常運行的同時，我們也在積極搜集業務部門的各種反饋，基于目前的平臺和技術做進一步的調研和二次開發。如何提高系統峰值處理時的性能和可靠性，我們依然任重而道遠。

?

轉載于:https://www.cnblogs.com/z12568/p/10932238.html

總結

以上是生活随笔為你收集整理的1号店电商峰值与流式计算的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。