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号店做为一家成立时间较短的中小规模电商，业务增加十分迅速。咱们意识到本身的实时计算平台在从此会有更大的压力和考验。在保证现有系统正常运行的同时，咱们也在积极搜集业务部门的各类反馈，基于目前的平台和技术作进一步的调研和二次开发。如何提升系统峰值处理时的性能和可靠性，咱们依然任重而道远。