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