电商5

VMALL之旅 [分享自博客] [原创] [精华]
孙扬 转载了 吴坤林 的博文 【查看原文】【转载时间：2014-08-13 13:55】

第一次，有甜蜜，有悲伤，有轻松，有烦恼，有得意，有失意，......第一次来到了南山，走在深大校园的路上，吃着南山荔枝感受着逝去的校园时光。第一次来到南山的华为商城，感受着大家忙碌奋斗的身影：加班发版本，加班分析流量数据，开发功能特性，测试功能特性，规划设计商城,......我们即将融入他们，一起来撑起华为商城的明天。随之拉起了前端优化，提高抢购秒杀并发的攻关团队：一位中软规划部的专家，一位来自中研的底层专家，还有2只来自中软平台的小菜鸟。
1 路漫漫其修远兮

来到商城之前，我们更多的是从心声社区上了解的VMALL：呼唤杨工、谩骂、怒其不争的帖子比比皆是。顿觉压力山大，因为我们即将成为“杨工”的一份子。以后帖子的背后就有我们2只菜鸟的身影。

来到商城，我们了解的现状：

每次抢购活动时，保障了抢购流程，主站却不能同时保障，抢购完成后的订单支付也需要2小时才能支付。

2013年12月25号初步用上了Nginx，在抢购高并发的情况下服务器崩溃。之后抢购摒弃Nginx，继续采用Apache+Tomcat模式。
2 流如潮，其势万钧，当节截分流，以卸其势

与VMALL一起制定了“三分安天下”的妙招：
2.1 动静分离，以静制动——关键入口页面静态化，用静态服务导流、限流
2.1.1 合抱之木始于毫末,万丈高楼起于垒土：模型搭建

面对这些问题，首先我们与VMALL一起搭建模拟环境来重现这些问题。下来就是激情的奋斗加班测试日，为了选择一个合适的测试工具，我们先后尝试过Loadrunner，Ab，Jmeter，Xcopy，TcpCopy等压测工具，最终选择轻量型的Ab进行压测。Ab虽提供不了高并发的场景，但是我们选择多台机器一起压测。

磨刀不误砍材工，有了测试工具，接下来就开始构建模型了，参考用户行为,模拟用户用IE、Chrome、FireFox浏览器访问VMALL网站，我们选择了报文请求的长连接作为我们的模型构建。压测出每台虚拟机可达10000 QPS，我们的工作就是把这台虚拟机的最大产能给激发出来。有了结果我们跟VMALL沟通成果后发现，我们构建的场景却偏离了生产环境，VMALL选择的某公有云并不是以长连接转发，而是短连接，这说明我们前面的“喜人”成果是个烟雾弹，这下我们给自己挖了个坑，还很开心的把自己埋进去。

重新搭建真实生产环境的场景，理想是丰满的，现实却是骨感的，经过验证，短连接场景在我们的前次优化下，只能达到“喜人”成果的一半不到。下面就开始找原因解决这个问题了，从系统、软件各个方面去讨论去验证。
2.1.2 冰冻三尺，非一日之寒：底层系统探究

经过一番的模型测试验证，发现并发开始打了6万多报文后却是无法继续打报文了，报文返回的都是超时，猜想是否是防火墙的原因，但关掉后却还是一样。继续排查，我们发现关掉报文跟踪iptAble予以解决。

接着继续压测发现CPU负载不高，但是并发量却无法继续往上打，不管优化句柄还是在虚拟机上的多核收发报文。又陷入瓶颈了，不管我们测试大报文还是小报文，问题依然存在。我们只能继续深挖，测试均衡软中断，分隔硬中断，但是这也无法解决这个问题。不管你信是不信，它还在那里。继续啃吧，启用多核收发报文负载均衡，但是它却不均衡。查Linux官网信息才知道，我们的虚拟平台的系统版本比较低不支持，高级版本才能比较完美的支持。

求助于虚拟平台团队，升级了我们的系统进行测试，但是问题依然还在那里，不增不减。接着挖吧，搭了个物理环境进行比对测试，发现我们的成果在物理机上能够完美的呈现。这回我们猜想应该是虚拟平台的问题，又一次求助于虚拟平台团队，我们发现物理层在往虚拟层报文传输时，就是单核在收发报文。最终在虚拟平台兄弟的帮助下，发现是dom0在收发报文时就是单核的，那怎么优化？单独部署一台升级后的新系统以及升级后的虚拟平台进行验证，成功捍卫“喜人”成果。这里我们非常感谢虚拟平台的那位兄弟：曾在丈母娘家做客的他被我们call回，晚上还来公司帮我们解决验证问题。

最大的“骨头”被啃光之后，下来就啃啃“骨头屑”：系统最大句柄的合理设置，这个大约是1G内存10W句柄数；高并发下要求对接收校验报文参数的优化；内核参数的优化。


2.1.3 滴水石穿，非一日之功：Nginx保活与优化

底层的限制解套之后，我们就可以安心的在业界有着极佳生产环境实践过的高并发的Nginx故障排除和优化。

1 合理的参数配置

若系统是4核的话，那Nginx的进程数配置压迫小于等于4，句柄数配置也要与系统的句柄数匹对。

2 静态压缩

为减少网络带宽，提高吞吐量，需要压缩网页。静态网页可以选择预压缩模式，减少动态压缩造成的CPU负载。

3 转发由短连接优化成长连接

其实还是“联通”好，提高资源利用率，减少建链和拆链的开销。长连接数的设置，需要与后端的服务相一致。

4 黑白名单

为识别出正常的流量请求，我们请来了“黑白双煞”来把守门关：黑名单可以限制恶意的网络攻击，以及黄牛的持续攻击；白名单防止URL Code攻击，以及防止不存在的URL的攻击。“木兰”抢购活动时，就有URL Code攻击绕过了我们的流控系统，我们一上白名单，后端CPU负载立马降下来。

5 缓存

提高请求的反应速度，减轻后端服务的负载，提供高并发大流量的请求。我们忽悠来了“哼哈二将”：采用Redis动态缓存；Varnish作为静态缓存。
2.1.4 道高一尺，魔高一丈：黄牛真的很牛

我们的虚拟机单台的最大能力被我们攻克了，也保证Nginx不会崩溃。青山依旧在，问题依旧没有非常明显的改善，因为后端还是扛不住不断增长的压力。同时分析用户行为得知，很多流量是黄牛造成的，这是个让人又爱又怕的群体，如何预防？解析正常用户的行为，我们上了流控，并返回友好的“花粉太热情”页面。在灰度区间，我们因流控未考虑到公司集体用户而误控，这在第二天的心声上体现了，所以VMALL也是伴着心声的呼唤、谩骂、鼓励一起成长起来的。感谢同学们的不离不弃，一直支持者VMALL。

这个阶段是一个里程碑，解决服务器DOWN机崩溃的问题，也为我们的后续工作提供了强力的保障。也完美的支持了4.8荣耀狂欢节的顺利进行。
2.2 轻重分拆，卫戍京畿——以业务属性分拆前端，保障核心业务

流控有助于减轻的压力，但是用户体验肯定受到影响。很牛的黄牛肯定又想新招来破解了。所以下来的课题是如何提高后端服务器的能力？
2.2.1 溯洄从之,道阻且长：困难重重

在抢购期间，曾因购物车被频繁的添加和删除导致主站不可访问和订单的无法创建。

在抢购期间，曾因收货地址被频繁修改导致主站的不可访问和订单的无法创建。

数据库采用读写分离方案，在现有的生产环境上，一个写库和多个读库。所有Portal的数据都存储在这套数据库集群中，造成这个数据库的很大负载,如评论、评分。

主站、购物车、评论、收货地址、商品详情等都在一个系统里面，不易横向扩展部署，同时又受限于一个主数据库。
2.2.2 溯游从之,宛在水中央：拆分

这回我们又迎来了另一位中软规划部的专家，还有一位WEB前端的大拿，下来就是对这些对主库造成不好影响的子系统进行拆分，这样又走进我们熟悉的流程：熟悉业务、读代码、设计方案、写代码、功能特性测试、性能验证、部署、灰度发布、最终上线。

1 动静分离

网页页面区分静态和动态，静态部分放在前端Nginx上，可以减轻后端的压力，动态部分用Ajax请求，访问后端。

2 读写分离

购物车和评论都采用各自的Redis存储，收货地址采用新的Mysql存储。避免所有的数据都在一个数据库实例上，导致只要其中一个负载不较大，其它全部受影响的问题。

3 去Mysql化

不执行复杂的SQL语句，将这些逻辑移到应用上；SQL语句不参与计算，计算逻辑移到应用上；就是将复杂度比较高的SQL语句进行拆分，变成多条简单的SQL语句，从而提高Mysql的执行效率。

4 缓存

经过上面3步骤后，我们对数据服务器的数据请求就变得比较简单，再分析并拆分数据更新频繁与不频繁的，把数据更新频率不频繁的放在缓存里，这样可以减轻数据库的压力。
2.3 用户分隔，各个击破——以用户维度分库，横向扩展，限制影响
2.3.1 裂土分茅：水平快速扩展

按用户维度进行扩展，有需要新扩展一个服务器时，只要把其中一台的镜像快速部署到新的虚拟平台上。平台部署时，可以区分活跃用户和非活跃用户，对活跃用户做重点保障。
2.3.2 愚公移山：数据迁移

按用户维度进行迁移数据：全量+增量+数据订正+并行运行检查。Redis、Mysql等数据存储服务器要设计方便数据迁移的方案。