天之道，损有余而补不足，是故虚胜实，不足胜有余。——《九阴真经》
第三章、以战养战
该来的，早迟会来！我们不可能永远只胜上半场，如何救活下半场，在有限的时间里实现，是个难题。如不解决，脑袋上就始终有柄达摩克利斯之剑，寝食难安！每周确定的两次活动，必须支撑，各种需求还要实现。除了在战争中成长，在战斗中改进之外，别无选择，我们没有额外机动部队，只能大家拼搏。
十一、小步快跑
从每周一次大型抢购，到每周2~3次大型抢购，最近更是一天4次！我们从春节前开始，就一直以这样的频度支撑荣耀系列的抢购活动。每周2~3个活动版本上线，周期很短，每周能加入的新东西有限，但我们坚决地进行每周改进。大家压力也很大，可以腾挪的空间相当的小，每一次的变动，都很难说充分测试验证，采用的手段是尽可能灰度上线，用现网实际部分用户来进行压力测试验证。象NGX上线，我们就经过多轮，每次活动替换一部分Apache，流量通过路由进行控制，最终完全上线，打造了高性能的WEB服务器（这里要感谢2012的专家组，对NGX进行攻关、调优，涉及到底层优化，最终快速帮助我们实现了高性能WEB服务器）。
在这些过程之中，逐步去掉会话，全程无状态，这样，各系统可完全独立部署，消除可能存在的会聚点，以实现平滑扩容。“无状态”原理简单，但要实现，还是费了一些精力。
下面是我们主要记录的变更，有些零碎，有些也没记录进来。在实际上线运行中，会遇到各种意想不到的情况，有些很快搞明白了，有些拖很久才搞明白，还有一些疑点一直没搞明白。虽然在使用上，用户不一定感知到异常，但实际模型与分析模型总会有偏差，有些偏差很难得到合理解释。比如，我们理论分析应该3秒结束抢购，但实际上会在10秒左右结束，这个偏差后来发现与DNS解析相关，对网络技术很熟的人就可以因此掌握一些技巧，比如先将抢购过程中会涉及的域名都ping一遍，或者自己配置hosts。对公司内网来说，内网DNS面临的突发流量，很容易造成解析延时的。这个，说实话，对我们系统来说，是个天然屏障，可以缓冲一下瞬时压力。关于公司内网的复杂性问题，有空后文再说。至于黄牛软件，会使用到各种技巧，与黄牛斗法的故事我们也会抽空专门在后面去讲。
独立订单中心，是13年中制定的架构优化，原计划13年底上线，受到荣耀活动的强烈冲击，最终拖到3.22日，经过十几个兄弟通宵奋战，终于成功上线。上线之后，极大减轻了前端的压力。而在这期间，并行多个版本开发，需求响应也是压力巨大，新架构的上线，被我们定义为大决战，只能成功，不能失败，经过这一战，后续的分库，子系统拆分工作会更容易。订单中心拆分之后，就立即对订单中心进行了分库改造，到6月份成功上线。这样，整个后端稳固了，前端的压力也减轻了。
十三、灰度升级
互联网业务，很难象电信业务一样，可以在实验室基本完全模拟现网，能真正充份测试完备。互联网业务的网络环境，远比电信业务要复杂，用户侧环境也是各有差异，这也是互联网服务没有哪家能承诺达到电信级SLA。为了应对这种复杂情况，几乎每个互联网服务，都采用了各种手段，在现网进行试验、测试与验证，类似ABTest，灰度升级等。我们也一样，一方面要支撑每周至少两次的抢购活动，另一方面，要每周小改进，去试点上线一些新方案，抢购的现网高并发流量是很难在实验室模拟的。下面是典型的几个灰度升级方案，可供分享。在灰度升级之中，实际隐含着试错的理念，关键是控制错误影响的范围，毕竟新的方案，是有可能出意想不到的错误的。虽然，试错这个提法，是不太符合我司的文化，可能会有较大争议，但现实的问题，有限的时间，有限的资源，要测试近乎无穷的场景，以有涯逐无涯，殆矣。这大概也是很多互联网公司选择灰度的原因之一吧。
在灰度升级方案上，我们主要使用了以下四类：
1、基于地理位置的灰度升级
通过路由选择，分区域将用户访问路由指向不同服务器。鉴于主机房带宽有限，在分散压力的思路下，我们引入了业界云平台服务。引入过程，也是要考虑可靠性与安全性，采用的也是逐步分散压力的作法。刚引入时，对广东等重点区域客户群，继续保留在成熟的现有几个机房中，将其他非重点区域用户，采用公有云平台进行支撑。逐次增加负载到公有云，随着对公有云平台的熟悉以及多次考验，现在大部分的流量会承载到公有云平台，极大缓解了主机房带宽压力。每次活动租用几个小时，其公有云的运营支撑系统，还是挺NB的，几分钟内就可以开通一大批服务器，提供各种API接口，相当值得借鉴学习。
参考组网示意图：
2、基于流量的灰度升级
12.25日的问题，对我们最严重打击，不是问题的本身，而是当时预案的失败，虽然事后分析，是有底层的问题，但我们对NGX仍是心存疑虑，缺乏信心。尽管业界经验，NGX在性能上是远高于Apache的，但我们为保险起见，采用的仍是Apache。在承接了几轮抢购之后，我们还是开始了这个过程。随着2012的专家组外援加入，让我们也对NGX上线有了保障。在实际NGINX上线步骤上，我们是遵从先极小量，逐步放量方式完成，基本上都是2.5%、10%、25%、50%、100%几个档位，有时会根据实际情况减少几个步骤。高性能前端中，新增的流控、缓存特性，也是按照2.5%、25％、100％等逐步灰度，最终完成完整上线。
参考下组网示意图，各集群是逐步完成变化的。
3、基于用户的灰度升级
购物车、评论等子系统的上线，由于改造范围很大，实现按照用户灰度的方式进行逐步上线，从专项组成员、研发、Vmall产品团队、花粉友好用户等逐步放大用户量，实现了版本的灰度上线。
4、基于功能的灰度升级
前面NGX上线，除了按流量灰度之外，也结合了功能的灰度升级。首先用于抢购活动的子系统，在抢购活动充分验证之后，将其引入到主站系统中，首先用于首页，然后再将分类页、详情页等逐步引入。对于缓存特性的上线，也是先从用户不感知的一些功能开始灰度，逐步应用到一些重要的功能中。
另外，OMS（订单管理系统）作为电商的核心模块，几乎所有的子系统都和它产生关联，为了降低新特性上线的风险，新特性上线时，只升级部分OMS服务器，通过网关路由，只路由给依赖这些新特性的业务使用，其他依赖OMS的业务，仍然路由到现有的OMS服务器组中，经过长时间运转稳定后，再升级所有OMS到新版本中，去掉灰度的路由规则。
5、数据库分库灰度升级
对数据库的分库，是一个非常大的动作，除了应用系统本身的变化，管理系统的影响更大，那些大量全表查询、联合查询、排序等操作，都面临重构。几乎所有涉及全表的运维工具，都要重新开发。工作量是非常大的。业软的DDS中间件，发挥了作用，可以减轻我们这方面面临的困难。这里要感谢业软的兄弟团队，为了快速支撑我们的需求，抽调资源快速实现了mysql的支持。
我们最初定的灰度计划（实际过程有些调整）
i. 灰度区试用（可牺牲服务先试用）
ii. 非保障区应用（非核心服务试用）
iii. 保障区应用（截止此时，仍是一个写库，各库数据实际相同）
iv. DDS与自行分库组合应用（正式分库，多写多读）
十四、百炼成钢
在尝试放出主站的过程中，我们遇到过很多问题。一次一次的尝试，最终3.18成功上线！中间经历的过程，可以作为教训分享一下。在不断压缩抢购到订单可见的停顿间隙中，遇到并解决过很多大大小小的问题，几乎每个周二的下半场，都在紧张中度过，都有各种故事，也正是这些问题的解决，提升了我们的经验与战斗力。这里就只列三个典型的问题，对其的解决方法或有参考意义吧。
购物车
某个周二的抢购活动，和预期一样，上半场顺利完成。我们已将主站放出的速度提升到20分钟了，当然对外仍以30分钟宣传，这样可以起到一定的缓冲作用。我们经历了多轮的优化调整，本次打算再压缩下时间，提升到15分钟。
这里需要解释一下，每周二活动开始时间10：08，最高的抢购压力就是10：08分，但同时在线的用户最高峰不是10：08，总有些人忘了登录，总有些人忘了时间来晚了，在活动结束之后的10分钟内，抢不到的用户心有不甘，抢到的用户要等待确认订单，因此，放开主站时，又是一个并发的峰值。晚过20分钟放开，一部分用户就会先撤了，大量未抢到的用户，我们是希望他们先撤走的。从20分钟提升到15分钟，就踩进并发峰里了，虽然不是最高峰，但已进入我们认为的雷区了。
刚一放开，开始还挺顺利，似乎一切正常，正当我们松了口气，突然主库CPU告警！开始影响到用户修改地址！我们的神经又紧绷起来。
追查数据库日志，从大量日志中寻找肇事者，终于发现是购物车造成的！
赶紧屏蔽掉购物车功能，先让用户能完成订单修改、支付！
事后，再仔细分析，遇到了奇葩了！大千世界，无奇不有，这也是B2C业务的特点吧。
购物车本身是个简单功能，用户一般购物车内也不太可能有大量商品，正常使用，性能应该没有问题。可是在这种饥渴营销模式之下，我们遇到了问题。虽然在我们的抢购方式中，不会经历购物车流程，但其他商城上有些抢购是通过购物车来完成的。不幸的是，我们躺枪了。有个神经的用户将在其他商城的经验，拿到VMALL来用了，使用机器进行购物车操作。我们的流程设计，购物车商品是不会占用库存的，加购物车成功，也不表示能下单成功。这伙计不知道是恶意，还是恼羞成怒，加了几十万条购物车记录，然后又删除几十万条购物车记录。我们的购物车与主站没有拆分，用的是同一数据库，一下子，数据库性能就被极大消耗，严重影响其他业务的使用。
为了解决这个问题，我们分了两步。第一步，临时解决方案，将购物车在活动结束，主站开放后的几分钟里屏蔽掉，暂不提供购物车服务，算是回避了这个问题。第二步，通过子系统拆分，将购物车独立出来，并且采用高性能的Redis方案，去掉了DB，算是个较彻底的方案。
这事一出，我们又退回到20分钟的安全区，用户的行为很难预测，几十上百万用户在线，不知道哪些用户就踢中我们主站的软肋了。
评论
在将首页，分类页，详情页静态化之后，也经过验证，我们认为应该没有问题了。
为了小心起见，不敢选择周二，选择的是周四小场，流量相对较低，我们又尝试进入雷区！
上半场顺利结束！下半场，放开主站！又是过了几分钟，主库又告警了！
同样的过程分析，紧急的处理，最终化解。
事后分析，是有两个变化引起的。一个是，在经过多轮的抢购之后，数据库中的记录悄悄在发生着变化，我们没有密切关注到。评论记录猛地增加了几十倍，关键是记录主要都是3C单品的。在详情页，除了评论记录之外，还有根据评论计算分数等信息，虽然详情页已静态化，但这部分是动态请求，需要进行DB查询。在记录基本都是3C单品下，索引基本无效，就是一个全表操作了。另一个，这是活动中间上的一个新特性，用户评论能实时变化。活动结束后，流量又导向了3C详情页，这样几十万人短时间大量访问3C详情页，立即造成DB压力，虽然已做了读写分离，但读库性能还是不够。我们立即将虚拟机读库直接切换为主库上，虽然主库开销立即上升，但还好，勉强能撑住。
问题之后，我们立即申请了物理机来部署读库。然后进行了几个调整，对详情页的动态请求部分，采用非实时模式，采用定时更新为静态化，极大减轻DB请求，进一步，我们将评论也拆分为子系统，换为Redis，彻底避免这样问题的发生。教训啊，在高流量下，全局性体验要大过细节的体验，这种评论，实时性要求并不那么高的。在我们进行细节体验改进时，是需要考虑到全局性影响的。另外，对于短期内极剧增长的数据库表，要给予足够重视。
用户表
不到一个月的时间，用户新增近四千万，这超出了我们的DB能力了，尤其是用户表。这张过大的用户表，在某个周二，终于爆发，让我们非常痛苦，放开主站后，整个主站都很慢，虽然没有卡死，但响应非常慢，拖了较久时间，直到大量用户完成了交易后，才缓解。
按一般的原则，应该分库了，只是这个分库的计划还没开始实施，之前才百万级用户，猛增的用户，让问题提前出现了。怎么办？正好，早期大量预约的是很多机器手段预约的三无帐号，为了打击黄牛，和运营部讨论，新的预约都必须是真实手机号码，提高门槛。在这种情况下，早期的预约帐号，就全部失效。而整个云业务都有共用的基础用户帐号系统UP，只要用户在VMALL没有相应的业务信息，比如下单、评论等，只有基础帐号，就可以直接删除，用户再次登录VMALL时，系统再重新添加。在这种情况之下，我们删除了大量无效帐号，将用户表压缩到千万记录以内。赢得了时间之后，我们就可以逐步去完成分库的工作。
经验的浪费，是最大的浪费。相信公司内部有很多类似的经验，只是在我们没有经历前，未能有效获取相关知识，因此，遇到了很多大大小小的问题。将欲取之，必先予之，希望这个分享能有点用吧。
十五、强力外援
在VMALL最困难的时候，公司内的援手及时伸过来了！在此，对2012，业软，公司IT等众多兄弟单位的帮助，表示感谢！
NGINX是我们12.25的心头之痛，最终经2012专家的攻关，完成了优化，并成功上线。
底层优化的工作，涉及云平台、硬件层参数，这个需要等待企业云系统大版本升级之后才能实施了，那时性能还会提升。
在2012专家们的支撑下，基于策略的流控方案，也成功上线了，这是我们强有力的防线，更是我们的底气。在流量超大下，总可以通过流控手段，将峰值削平。
基于Nginx打造的高性能WEB接入系统，通过缓存、压缩等手段，很大程度上减小了后端系统压力，整体性能性能提升更高。
NoSQL技术在消除DB瓶颈方面发挥了很大作用，我们多个子系统拆分工作，在2012兄弟的协助下，成功实施上线。
看到我们在数据库方面面临的压力，业软兄弟的强力投入，非常快的速度，就从Oracle版本上移植了一个支持MySQL的DDS版本来帮我们抵御压力，DDS在我们分库工作中发挥了很大作用。
几个月来，这么多的专家和我们一起奋战，对我们自身能力的提升，也是大有裨益。如果有兄弟对这些技术有兴趣，可以咨询的哈。给我们的专家作下广告先：）
具体这些技术攻关的工作，希望有空，专家组也能分享一二了，这里就不弄斧了。
第四章 斗法黄牛
十六、道高一尺
“黄牛”，大家在生活中大多遇到过，这两天紧急挂号又用到了，真难以说清是好事还是坏事了。只要有利可图，资源紧张，就会有“黄牛党”存在。在荣耀3C之前，只是听闻小米的黄牛，但没有见识过。在12.31日顺利完成抢购之后，我们开始有意识地去识别黄牛。考虑到12.31的活动版本极为简单，技术控很容易制造工具，以工具代替人来抢，普通客户就永远处于劣势，为避免全部被黄牛抢走，我们需要想些办法。在相当长的一段时间里，我们几乎每次活动，都会变招，设置陷阱，抓获黄牛。每次紧张的活动保障，与黄牛的斗法，算是其中最有乐趣，也最让大家兴奋的事了。下面是我们的历次战绩，这里要请原谅，我们的陷阱技巧就不能说了，说了就不灵了：）
1.8日 捕获64万次黄牛软件恶意抢购；
1.10日 捕获65万次；
1.15日 达到首个顶峰，2000万次； （经跟踪发现主要居然是临时租用企业云的同机房客户通过服务器直接攻击）
1.17日 420万次；
1.23日 3000万次；
……
7.1日 新的顶峰，黄牛机器刷了4.2亿次抢购；对手恶意攻击主站4千万次；
……
以如此大量的机器黄牛，如果不设置陷阱，普通用户基本就颗粒无收了。
前面我们对于机器预约的用户，判断为无效用户，不清楚其目的，等到我们确实抓到黄牛之后，我们系统地分析黄牛，才发现这些帐号的价值！由于3C的热抢，只能是预约用户，结果这些预约帐号就在淘宝上销售了，从1元到10元不等，我们查过，最多的一家卖过2000多号，典型无本万利啊！在我们看来，是完全无意义的“三无帐号”俗称“白号”，无手机绑定，无真实Email，无安全设置，恰恰是黄牛需要的。黄牛会囤积大量这样的三无帐号，有些是黄牛自己机器刷注册的，有些是网上购买的。在抢购活动前，发放给大量赚小钱的用户，如没事干的学生。这些人抢到后，再由黄牛进行回收。规模大的黄牛，基本上都会使用工具，进行批量回收，批量支付。只有三无帐号，才是安全可靠的回收帐号！这就是生意！
为了有效打击黄牛，在运营方案上进行调整，改为每周进行一轮新的预约！为了避免系统中留下大量垃圾帐号，预约必须使用手机，以提高黄牛预约难度！即使这样，那些大的黄牛，手上拥有的手机号码非常之多！并且都有卡机，批量处理短信！早期预约时，黄牛会集中处理，我们通过IP，预约时间集中度，可以识别出机器预约，直接纳入黑名单。黄牛后来就采用完全分散的IP（这个在淘宝上可以很便宜买到大把IP），分时段，小批次预约。真是道高一尺，魔高一丈！
每次活动前，在尽量不降低用户体验的情况下，绞尽脑汁去想陷阱，抓捕黄牛，以保证普通用户可以抢到。但有时，防不甚防，黄牛背后是完善的产业链。看下某黄牛工具截止到四月的版本说明，几乎每一次成功的陷阱，下一轮活动就不可用了，对手反应的速度是相当的快。我们用过5位数加减法，用过图形验证码，用过图形+文字，用过各种智力题，当然还有一些用户感觉不到的陷阱。在有巨大利益空间之下，说百分百防住，这我们目前还保证不了。对抗整个成熟的产业链，不是一件容易的事，只能说尽力去想办法，保护普通用户能抢到。
现在我们在不断积累用户行为，通过行为分析，识别可能的黄牛，对明确的黄牛用户，总是可以拦截的。当然，对于明确的友好用户，比如公司内部用户，是直接进入白名单的。现在，内部用户专用通道中，基本不用去抢了，还是照顾到公司内部需求了。
十七、魔高一丈
看一下我们获取到的某黄牛抢购软件版本变更清单说明，这是4月份拿到的，我们的变化，也都对体现在黄牛软件版本的变更之中。这种职业，在巨大利益驱动之下，反应非常迅速，我们的每次手段，基本只能当次有效。
[V2.3]
1、集成前台+后台到一个版本，使用时请先设置前台抢购数量；
2、修改登录方式为登录完成一个账号后再登录下一个账号，避免同时登录造成卡顿，请保证导入的账号密码都正确，密码错误将无法登录下一个账号；
[V2.2]
1、本次更新推出3个版本：前台版、后台版、前台+后台版；
2、前台版需要手动在网页上输入登录验证码并手动到抢购页面，其余的操作和后台一样；
3、所有版本均继承老版本的提前取计算题验证码，自动回答问题，批量提交功能；
4、前台版可靠性大，但是暂时不能统一问题；
5、请自行选择使用的版本；
6、这里说的前台、后台均指的是抢购时用到的，查单和设置地址都是后台操作；
7、代理IP功能暂时请不要使用；
[V2.1.2]
1、尝试解决出现提示成功但是无订单，请使用通道二登录；
[V2.1.1]
1、华为更改代码，紧急更新；
2、因华为本次抢购有几个不同的页面，故在登录前必须先设置好商品ID；
[V2.1]
1、增加可选抢购商品：畅玩、3C、3X，选择后会自动填写不带套餐的ID，如需套餐，请自行添加ID。
切记：需要抢购什么商品不要选错，套餐ID不要填错，选择抢购3c如果填了畅玩的ID，那么这次抢购就白费了！！！
[V2.0.1]
1、增加设置地址时自动填写邮编；（自动获取当地邮编，无需输入）
2、修复未导入代理IP时误报更换代理IP的BUG；
3、增加右键导入账号，解决部分用户拖动账号文本不能导入的问题；
4、修复部分用户选择登录入口一或者二时，登录报错的BUG；
5、增加点击商品ID列表自动填写功能；
6、说明：如果之前有设置收货地址的账号，使用软件设置地址会保留上一次的默认地址，也就是会看到收货信息里有两个地址，新的默认地址是软件设置的新地址，这个并不影响。
[V2.0]
1、增加一键填写默认地址；
2、增加使用代理IP登录账号；（请导入足够数量的可用代理IP，最大不超过1000个）
3、修改导入账号为直接拖放账号文件到状态显示框；
4、增加右键单独对某账号设置地址或重新登录；
5、增加自定义停止热键，按热键停止所有操作；
[V1.9]
1、增加订单查询显示下单日期；
2、增加停止操作按钮；
3、增加右键单独取验证码功能，输入错误答案可以使用此功能进行修正；
4、上期3C因提交太快，华为官方删除了部分早期订单，以供后面其他人抢购，所以官网在10分左右都还能手动抢到，建议以后抢购时，自动提交提示抢购成功后，过5秒或10秒再次点击开始抢购，重新提交一次；
近期发现有人冒充作者进行行骗，现郑重声明：作者不会主动联系任何人收取钱财，战神已经停止招收代理，谨防上当受骗；
[V1.8.3]
1、修复可能出现部分验证码无限错误的BUG；
[V1.8.2]
1、修复订单查询显示价格错误；
[V1.8.1]
1、增加提前取码，请先打好码，等到抢购开始前10秒点击开始抢购；
2、畅玩版套餐代码：9990,9991，如果需要同时抢购，设置ID：1512|9990|9991
[V1.8]
1、针对华为改代码，增加计算题回答，请详细参考附带的教程；
[V1.7.1]
1、添加荣耀畅玩版ID；
[V1.7]
1、增加自动提交问题中带答案的问题；
[V1.6]
1、修复出部分问题报错；
2、增加自动粘贴答案到答题框，确认无误后点击提交或者回车提交；
[V1.5]
1、增加登录验证码自动打码；
2、增加自动回答抢购验证码常见问题，比如姓什么，笔画数，第几个字是什么；
[V1.4]
1、增加检测是否预约账号；
[V1.3]
1、修复入口4登录错误；
[V1.2]
1、增加登录入口四：电脑版快速通道，无验证码
[V1.1]
1、修复打开软件后回车键失效；
十八、潜伏暗战
与黄牛的战斗，还有潜伏式作战，一些兄弟伪装为黄牛，加入各黄牛群中，收集各种信息，通过这些信息，能较准确地识别出黄牛帐号，黄牛地址，可以更好地防范黄牛。最紧张的一次，是某个周二早上九点多，发现黄牛群中破解了我们的陷阱，可能是周一晚上线上测试时，被黄牛跟踪到的，连夜破解的。我们是紧急变招，在10点前完成上线，避免了全被黄牛抢光的恶性事件发生。当然，对我们也是极为紧张，在最短的时间里变招换版本，压力、风险都是很大的。随后，我们对线上测试进一步保护，减少被跟踪可能。
还有一些兄弟，从群中收集各种工具，进行反编译破解，了解对手招术。上面的版本变更，就来源于黄牛群中的文档。有兴趣的同学，可以在网上搜，黄牛软件还录了教学视频，非常之专业啊！
有些招术看上去土，但非常有效，无法防范，比如录制，完全就是模拟正常用户的抢购行为，可从公有云集群机器发起，威力很大，防不甚防，这也是为什么我们要不断变换验证码。有兴趣的同学，可以在淘宝上搜索“云打码”，可以了解到现在产业链的完善程度了。
高级的黄牛群，对于入群，会有些约束，弄不好就被踢出去了，要装得像，需要实际去动手，简直是现代版“投名状”，有兄弟努力多次，也未抢到小米，只能通过京东抢什么大神之类，混个文凭，进去打听消息。春江水暧鸭先知，手机冷热听黄牛！黄牛是直接面向最终用户，其市场敏感性比我们还强，商品的热度如何，通过黄牛群内的信息，可以有个基本判断。
黄牛群里，也会有欺诈存在，出现过收单不给钱的，这只能吃哑巴亏了，你和群主较劲也没用，这就是个灰色产业，见不得阳光，只能信任群主。
现在，我们有兄弟部队在尝试通过大数据分析来识别普通用户与黄牛，希望工具能早日发挥威力！若有此方面的高手，热烈欢迎！
给大家算个小帐，3C线下最高炒到过1400，价差有600之高，如果一次工具抢到1万台，利润空间600万！一周一次甚至二次抢购，还有其他各厂家类似抢购，最著名的自然是小米。这些黄牛每周会抢购多轮次，一周获利空间就是数千万！如此巨大的利润空间，推动的是整个产业链的发达。有专门开发工具的，有提供云服务的，有收单的，有抢单的，有卖号的，大黄牛甚至搞定区域快递员，约定某种暗号，就表示是他们的单！各种玩法，不亲身经历，以我们习惯的学院派玩法，都不知道别人在玩什么把戏。为了防止在收货地址上被识别，看下黄牛是怎么玩的：
XX小学前行100米左拐30米二楼王XX家。
广东省深圳市龙岗区 坂田街道 五和路四巷2号连扳档口肠粉店
广东坂田街道第三工业区C座麻酱面小吃部
龙岗 坂田小学⑤十栋 光明超市
叙宵魏霸颧疼稽双银大厦2004纯乘雌拖节顽 （要在海量订单中，找这样地址，不易啊）
认僧矾菱巩趋跋双银大厦2004捉徒瘪奉赐怕
吨悟由绩骏护堡双银大厦2004南梁充技敏筏
……
各种防识别手段，层出不穷啊。估计这些都是经历过小米、京东K单的黄牛，总结出了经验，具备很强的防K单手段。
勤奋的黄牛，真没办法，每次换的地址都难以识别。有技术大拿，给我们来个NB方案吧，现在相当一部分需要靠客服MM人眼凭感觉去识别。有些黄牛干脆给个垃圾地址，然后直接电话快递自提。曾有个黄牛不小心搞错了，货发到广州找不到具体地址，顺丰快递员一联系，黄牛直接从深圳开车去广州自提了！黄牛根本不希望商城知道，顺丰不说，我们也不知道。
十九、些许欣慰
下面是某次活动，在黄牛群的中截取的对话，能看到我们的变招产生了效果，就算是被黄牛骂了，也还是小有成就感，兄弟们也能感到些许的欣慰啊：） 为了安全起见，对黄牛帐号隐藏几位。
【大学】路人乙(94xxx0741) 14:46:32
三场我一台都没秒到
【博士】三生三世(976xxx748) 14:46:38
都显示了这样的，就是没有订单
坑
【大学】路人乙(94xxx0741) 14:46:51
客服怎么说
【博士】三生三世(976xxx748) 14:47:05
没问客服
不想问
【大学】路人乙(94xxx0741) 14:47:21
我是没看到这个页面 每次都显示抢购人数过多
唉
3x 感觉不会再爱了
【博士】结账红米(41xxx7381) 14:47:59
机智得华为
【博士】三生三世(976xxx748) 14:48:08
下次抢不用软件了
【博士】三生三世(976xxx748) 14:48:25
貌似我每次买抢购软件都废了
买一次，费一次
【博士】结账红米(41xxx7381) 14:52:04
，，哈哈
多少钱买的
【博士】 گوگو 靓 گوگو(85xxx6163) 14:52:17
你妹啊
【博士】三生三世(976xxx748) 14:52:24
10元买的周卡
由于利益空间的存在，就会有骗子的存在，估计在全球，骗子这个职业是个最古老而顽强的职业了！我们的客服遇到过多次用户上当受骗，过来投诉。有买了别人帐号，下了订单，支付后又被原帐号主人更改了收货人的。有中了钓鱼网站招的。各种情况，不一枚举。
为了减少这种欺骗带来的影响，后来决定用户抢购订单的收货人地址不允许修改，必须提前准备好缺省地址。其实很难有完美的方案，这个在减少欺骗的影响同时，也给普通用户带来不便，比如心声中就有很多人让客服美眉代修改订单收货地址。再后来，我们进一步优化，用户抢购中可以直接填写地址，订单提交前都可以更改，建议大家下单前仔细确认地址，让客服美眉修改，也是运营成本啊。随着系统优化的不断进行，性能的提高，体验方面也有基础去作些优化。
在我们认为通过限制订单不让给地址之后，杜绝了欺诈，可以有效限制黄牛，但实际上对收单黄牛更为安全。只要地址正确，黄牛就敢支付，免去判断帐号是否白号的问题。这样，黄牛不用再提供白号，普通用户愿意，完全可以用自己的帐号去抢，只要抢成功，将帐号、订单发给黄牛，黄牛就可以放心支付。这反而造成黄牛交易更简单。这也使得黄牛帐号变得更为分散，难以识别。
改进无止境，我们永远在路上！如果有兄弟在对付黄牛方面有好的想法，非常欢迎贡献智慧！前两天，JD和我们一起讨论如何防黄牛的问题，大家都很苦恼，按理JD比我们应该更好防一些，其用户相关数据比我们多很多，识别起来要有效多了。
对了，最近小米也学习我们，玩起了智力题：
这样类似的智力题库，每次若能有几千乃至上万道以上，对黄牛工具来说，杀伤力还是很大的，题目太少，只能防住一小会，大华为这多员工，在此征集一下这类智力题，要求很简单，是个人都能答，是个机器都不能答，也不能穷举：）也许到这儿，有人能理解，我们曾经搞5位数加减法吧，位数少了，机器可以硬穷举的。用过几次之后，也放弃了，对手很强大！因为数字太容易识别了，即使我们混入汉字，也易于识别，就那几个特定模式，识别率很容易提上去的。再加上云打码服务，数字题目基本就没用了。
验证码最神奇的故事，是我们遇到个千年老妖啊。该用户投诉说我们的智力题是骗人的，他答对了，我们判断错了，导致他没有抢到，要求赔偿精神损失。我们客服MM怎么沟通，都不行，最后我们说给他下个单，让他自己支付，这都不行，非要免费送他手机，如果不送，就去工商局告，说我们这是属于欺骗，要罚十倍。最后我们就只能让其去告了，罚十倍没事，罚千倍呗，反正他一分钱没花，一万倍也还是个0。类似的故事非常之多，运营部的兄弟姐妹，有机会也分享一下乐子吧。
第三章、以战养战
该来的，早迟会来！我们不可能永远只胜上半场，如何救活下半场，在有限的时间里实现，是个难题。如不解决，脑袋上就始终有柄达摩克利斯之剑，寝食难安！每周确定的两次活动，必须支撑，各种需求还要实现。除了在战争中成长，在战斗中改进之外，别无选择，我们没有额外机动部队，只能大家拼搏。
十一、小步快跑
从每周一次大型抢购，到每周2~3次大型抢购，最近更是一天4次！我们从春节前开始，就一直以这样的频度支撑荣耀系列的抢购活动。每周2~3个活动版本上线，周期很短，每周能加入的新东西有限，但我们坚决地进行每周改进。大家压力也很大，可以腾挪的空间相当的小，每一次的变动，都很难说充分测试验证，采用的手段是尽可能灰度上线，用现网实际部分用户来进行压力测试验证。象NGX上线，我们就经过多轮，每次活动替换一部分Apache，流量通过路由进行控制，最终完全上线，打造了高性能的WEB服务器（这里要感谢2012的专家组，对NGX进行攻关、调优，涉及到底层优化，最终快速帮助我们实现了高性能WEB服务器）。
在这些过程之中，逐步去掉会话，全程无状态，这样，各系统可完全独立部署，消除可能存在的会聚点，以实现平滑扩容。“无状态”原理简单，但要实现，还是费了一些精力。
下面是我们主要记录的变更，有些零碎，有些也没记录进来。在实际上线运行中，会遇到各种意想不到的情况，有些很快搞明白了，有些拖很久才搞明白，还有一些疑点一直没搞明白。虽然在使用上，用户不一定感知到异常，但实际模型与分析模型总会有偏差，有些偏差很难得到合理解释。比如，我们理论分析应该3秒结束抢购，但实际上会在10秒左右结束，这个偏差后来发现与DNS解析相关，对网络技术很熟的人就可以因此掌握一些技巧，比如先将抢购过程中会涉及的域名都ping一遍，或者自己配置hosts。对公司内网来说，内网DNS面临的突发流量，很容易造成解析延时的。这个，说实话，对我们系统来说，是个天然屏障，可以缓冲一下瞬时压力。关于公司内网的复杂性问题，有空后文再说。至于黄牛软件，会使用到各种技巧，与黄牛斗法的故事我们也会抽空专门在后面去讲。
独立订单中心，是13年中制定的架构优化，原计划13年底上线，受到荣耀活动的强烈冲击，最终拖到3.22日，经过十几个兄弟通宵奋战，终于成功上线。上线之后，极大减轻了前端的压力。而在这期间，并行多个版本开发，需求响应也是压力巨大，新架构的上线，被我们定义为大决战，只能成功，不能失败，经过这一战，后续的分库，子系统拆分工作会更容易。订单中心拆分之后，就立即对订单中心进行了分库改造，到6月份成功上线。这样，整个后端稳固了，前端的压力也减轻了。
十三、灰度升级
互联网业务，很难象电信业务一样，可以在实验室基本完全模拟现网，能真正充份测试完备。互联网业务的网络环境，远比电信业务要复杂，用户侧环境也是各有差异，这也是互联网服务没有哪家能承诺达到电信级SLA。为了应对这种复杂情况，几乎每个互联网服务，都采用了各种手段，在现网进行试验、测试与验证，类似ABTest，灰度升级等。我们也一样，一方面要支撑每周至少两次的抢购活动，另一方面，要每周小改进，去试点上线一些新方案，抢购的现网高并发流量是很难在实验室模拟的。下面是典型的几个灰度升级方案，可供分享。在灰度升级之中，实际隐含着试错的理念，关键是控制错误影响的范围，毕竟新的方案，是有可能出意想不到的错误的。虽然，试错这个提法，是不太符合我司的文化，可能会有较大争议，但现实的问题，有限的时间，有限的资源，要测试近乎无穷的场景，以有涯逐无涯，殆矣。这大概也是很多互联网公司选择灰度的原因之一吧。
在灰度升级方案上，我们主要使用了以下四类：
1、基于地理位置的灰度升级
通过路由选择，分区域将用户访问路由指向不同服务器。鉴于主机房带宽有限，在分散压力的思路下，我们引入了业界云平台服务。引入过程，也是要考虑可靠性与安全性，采用的也是逐步分散压力的作法。刚引入时，对广东等重点区域客户群，继续保留在成熟的现有几个机房中，将其他非重点区域用户，采用公有云平台进行支撑。逐次增加负载到公有云，随着对公有云平台的熟悉以及多次考验，现在大部分的流量会承载到公有云平台，极大缓解了主机房带宽压力。每次活动租用几个小时，其公有云的运营支撑系统，还是挺NB的，几分钟内就可以开通一大批服务器，提供各种API接口，相当值得借鉴学习。
参考组网示意图：
2、基于流量的灰度升级
12.25日的问题，对我们最严重打击，不是问题的本身，而是当时预案的失败，虽然事后分析，是有底层的问题，但我们对NGX仍是心存疑虑，缺乏信心。尽管业界经验，NGX在性能上是远高于Apache的，但我们为保险起见，采用的仍是Apache。在承接了几轮抢购之后，我们还是开始了这个过程。随着2012的专家组外援加入，让我们也对NGX上线有了保障。在实际NGINX上线步骤上，我们是遵从先极小量，逐步放量方式完成，基本上都是2.5%、10%、25%、50%、100%几个档位，有时会根据实际情况减少几个步骤。高性能前端中，新增的流控、缓存特性，也是按照2.5%、25％、100％等逐步灰度，最终完成完整上线。
参考下组网示意图，各集群是逐步完成变化的。
3、基于用户的灰度升级
购物车、评论等子系统的上线，由于改造范围很大，实现按照用户灰度的方式进行逐步上线，从专项组成员、研发、Vmall产品团队、花粉友好用户等逐步放大用户量，实现了版本的灰度上线。
4、基于功能的灰度升级
前面NGX上线，除了按流量灰度之外，也结合了功能的灰度升级。首先用于抢购活动的子系统，在抢购活动充分验证之后，将其引入到主站系统中，首先用于首页，然后再将分类页、详情页等逐步引入。对于缓存特性的上线，也是先从用户不感知的一些功能开始灰度，逐步应用到一些重要的功能中。
另外，OMS（订单管理系统）作为电商的核心模块，几乎所有的子系统都和它产生关联，为了降低新特性上线的风险，新特性上线时，只升级部分OMS服务器，通过网关路由，只路由给依赖这些新特性的业务使用，其他依赖OMS的业务，仍然路由到现有的OMS服务器组中，经过长时间运转稳定后，再升级所有OMS到新版本中，去掉灰度的路由规则。
5、数据库分库灰度升级
对数据库的分库，是一个非常大的动作，除了应用系统本身的变化，管理系统的影响更大，那些大量全表查询、联合查询、排序等操作，都面临重构。几乎所有涉及全表的运维工具，都要重新开发。工作量是非常大的。业软的DDS中间件，发挥了作用，可以减轻我们这方面面临的困难。这里要感谢业软的兄弟团队，为了快速支撑我们的需求，抽调资源快速实现了mysql的支持。
我们最初定的灰度计划（实际过程有些调整）
i. 灰度区试用（可牺牲服务先试用）
ii. 非保障区应用（非核心服务试用）
iii. 保障区应用（截止此时，仍是一个写库，各库数据实际相同）
iv. DDS与自行分库组合应用（正式分库，多写多读）
十四、百炼成钢
在尝试放出主站的过程中，我们遇到过很多问题。一次一次的尝试，最终3.18成功上线！中间经历的过程，可以作为教训分享一下。在不断压缩抢购到订单可见的停顿间隙中，遇到并解决过很多大大小小的问题，几乎每个周二的下半场，都在紧张中度过，都有各种故事，也正是这些问题的解决，提升了我们的经验与战斗力。这里就只列三个典型的问题，对其的解决方法或有参考意义吧。
购物车
某个周二的抢购活动，和预期一样，上半场顺利完成。我们已将主站放出的速度提升到20分钟了，当然对外仍以30分钟宣传，这样可以起到一定的缓冲作用。我们经历了多轮的优化调整，本次打算再压缩下时间，提升到15分钟。
这里需要解释一下，每周二活动开始时间10：08，最高的抢购压力就是10：08分，但同时在线的用户最高峰不是10：08，总有些人忘了登录，总有些人忘了时间来晚了，在活动结束之后的10分钟内，抢不到的用户心有不甘，抢到的用户要等待确认订单，因此，放开主站时，又是一个并发的峰值。晚过20分钟放开，一部分用户就会先撤了，大量未抢到的用户，我们是希望他们先撤走的。从20分钟提升到15分钟，就踩进并发峰里了，虽然不是最高峰，但已进入我们认为的雷区了。
刚一放开，开始还挺顺利，似乎一切正常，正当我们松了口气，突然主库CPU告警！开始影响到用户修改地址！我们的神经又紧绷起来。
追查数据库日志，从大量日志中寻找肇事者，终于发现是购物车造成的！
赶紧屏蔽掉购物车功能，先让用户能完成订单修改、支付！
事后，再仔细分析，遇到了奇葩了！大千世界，无奇不有，这也是B2C业务的特点吧。
购物车本身是个简单功能，用户一般购物车内也不太可能有大量商品，正常使用，性能应该没有问题。可是在这种饥渴营销模式之下，我们遇到了问题。虽然在我们的抢购方式中，不会经历购物车流程，但其他商城上有些抢购是通过购物车来完成的。不幸的是，我们躺枪了。有个神经的用户将在其他商城的经验，拿到VMALL来用了，使用机器进行购物车操作。我们的流程设计，购物车商品是不会占用库存的，加购物车成功，也不表示能下单成功。这伙计不知道是恶意，还是恼羞成怒，加了几十万条购物车记录，然后又删除几十万条购物车记录。我们的购物车与主站没有拆分，用的是同一数据库，一下子，数据库性能就被极大消耗，严重影响其他业务的使用。
为了解决这个问题，我们分了两步。第一步，临时解决方案，将购物车在活动结束，主站开放后的几分钟里屏蔽掉，暂不提供购物车服务，算是回避了这个问题。第二步，通过子系统拆分，将购物车独立出来，并且采用高性能的Redis方案，去掉了DB，算是个较彻底的方案。
这事一出，我们又退回到20分钟的安全区，用户的行为很难预测，几十上百万用户在线，不知道哪些用户就踢中我们主站的软肋了。
评论
在将首页，分类页，详情页静态化之后，也经过验证，我们认为应该没有问题了。
为了小心起见，不敢选择周二，选择的是周四小场，流量相对较低，我们又尝试进入雷区！
上半场顺利结束！下半场，放开主站！又是过了几分钟，主库又告警了！
同样的过程分析，紧急的处理，最终化解。
事后分析，是有两个变化引起的。一个是，在经过多轮的抢购之后，数据库中的记录悄悄在发生着变化，我们没有密切关注到。评论记录猛地增加了几十倍，关键是记录主要都是3C单品的。在详情页，除了评论记录之外，还有根据评论计算分数等信息，虽然详情页已静态化，但这部分是动态请求，需要进行DB查询。在记录基本都是3C单品下，索引基本无效，就是一个全表操作了。另一个，这是活动中间上的一个新特性，用户评论能实时变化。活动结束后，流量又导向了3C详情页，这样几十万人短时间大量访问3C详情页，立即造成DB压力，虽然已做了读写分离，但读库性能还是不够。我们立即将虚拟机读库直接切换为主库上，虽然主库开销立即上升，但还好，勉强能撑住。
问题之后，我们立即申请了物理机来部署读库。然后进行了几个调整，对详情页的动态请求部分，采用非实时模式，采用定时更新为静态化，极大减轻DB请求，进一步，我们将评论也拆分为子系统，换为Redis，彻底避免这样问题的发生。教训啊，在高流量下，全局性体验要大过细节的体验，这种评论，实时性要求并不那么高的。在我们进行细节体验改进时，是需要考虑到全局性影响的。另外，对于短期内极剧增长的数据库表，要给予足够重视。
用户表
不到一个月的时间，用户新增近四千万，这超出了我们的DB能力了，尤其是用户表。这张过大的用户表，在某个周二，终于爆发，让我们非常痛苦，放开主站后，整个主站都很慢，虽然没有卡死，但响应非常慢，拖了较久时间，直到大量用户完成了交易后，才缓解。
按一般的原则，应该分库了，只是这个分库的计划还没开始实施，之前才百万级用户，猛增的用户，让问题提前出现了。怎么办？正好，早期大量预约的是很多机器手段预约的三无帐号，为了打击黄牛，和运营部讨论，新的预约都必须是真实手机号码，提高门槛。在这种情况下，早期的预约帐号，就全部失效。而整个云业务都有共用的基础用户帐号系统UP，只要用户在VMALL没有相应的业务信息，比如下单、评论等，只有基础帐号，就可以直接删除，用户再次登录VMALL时，系统再重新添加。在这种情况之下，我们删除了大量无效帐号，将用户表压缩到千万记录以内。赢得了时间之后，我们就可以逐步去完成分库的工作。
经验的浪费，是最大的浪费。相信公司内部有很多类似的经验，只是在我们没有经历前，未能有效获取相关知识，因此，遇到了很多大大小小的问题。将欲取之，必先予之，希望这个分享能有点用吧。
十五、强力外援
在VMALL最困难的时候，公司内的援手及时伸过来了！在此，对2012，业软，公司IT等众多兄弟单位的帮助，表示感谢！
NGINX是我们12.25的心头之痛，最终经2012专家的攻关，完成了优化，并成功上线。
底层优化的工作，涉及云平台、硬件层参数，这个需要等待企业云系统大版本升级之后才能实施了，那时性能还会提升。
在2012专家们的支撑下，基于策略的流控方案，也成功上线了，这是我们强有力的防线，更是我们的底气。在流量超大下，总可以通过流控手段，将峰值削平。
基于Nginx打造的高性能WEB接入系统，通过缓存、压缩等手段，很大程度上减小了后端系统压力，整体性能性能提升更高。
NoSQL技术在消除DB瓶颈方面发挥了很大作用，我们多个子系统拆分工作，在2012兄弟的协助下，成功实施上线。
看到我们在数据库方面面临的压力，业软兄弟的强力投入，非常快的速度，就从Oracle版本上移植了一个支持MySQL的DDS版本来帮我们抵御压力，DDS在我们分库工作中发挥了很大作用。
几个月来，这么多的专家和我们一起奋战，对我们自身能力的提升，也是大有裨益。如果有兄弟对这些技术有兴趣，可以咨询的哈。给我们的专家作下广告先：）
具体这些技术攻关的工作，希望有空，专家组也能分享一二了，这里就不弄斧了。
第四章 斗法黄牛
十六、道高一尺
“黄牛”，大家在生活中大多遇到过，这两天紧急挂号又用到了，真难以说清是好事还是坏事了。只要有利可图，资源紧张，就会有“黄牛党”存在。在荣耀3C之前，只是听闻小米的黄牛，但没有见识过。在12.31日顺利完成抢购之后，我们开始有意识地去识别黄牛。考虑到12.31的活动版本极为简单，技术控很容易制造工具，以工具代替人来抢，普通客户就永远处于劣势，为避免全部被黄牛抢走，我们需要想些办法。在相当长的一段时间里，我们几乎每次活动，都会变招，设置陷阱，抓获黄牛。每次紧张的活动保障，与黄牛的斗法，算是其中最有乐趣，也最让大家兴奋的事了。下面是我们的历次战绩，这里要请原谅，我们的陷阱技巧就不能说了，说了就不灵了：）
1.8日 捕获64万次黄牛软件恶意抢购；
1.10日 捕获65万次；
1.15日 达到首个顶峰，2000万次； （经跟踪发现主要居然是临时租用企业云的同机房客户通过服务器直接攻击）
1.17日 420万次；
1.23日 3000万次；
……
7.1日 新的顶峰，黄牛机器刷了4.2亿次抢购；对手恶意攻击主站4千万次；
……
以如此大量的机器黄牛，如果不设置陷阱，普通用户基本就颗粒无收了。
前面我们对于机器预约的用户，判断为无效用户，不清楚其目的，等到我们确实抓到黄牛之后，我们系统地分析黄牛，才发现这些帐号的价值！由于3C的热抢，只能是预约用户，结果这些预约帐号就在淘宝上销售了，从1元到10元不等，我们查过，最多的一家卖过2000多号，典型无本万利啊！在我们看来，是完全无意义的“三无帐号”俗称“白号”，无手机绑定，无真实Email，无安全设置，恰恰是黄牛需要的。黄牛会囤积大量这样的三无帐号，有些是黄牛自己机器刷注册的，有些是网上购买的。在抢购活动前，发放给大量赚小钱的用户，如没事干的学生。这些人抢到后，再由黄牛进行回收。规模大的黄牛，基本上都会使用工具，进行批量回收，批量支付。只有三无帐号，才是安全可靠的回收帐号！这就是生意！
为了有效打击黄牛，在运营方案上进行调整，改为每周进行一轮新的预约！为了避免系统中留下大量垃圾帐号，预约必须使用手机，以提高黄牛预约难度！即使这样，那些大的黄牛，手上拥有的手机号码非常之多！并且都有卡机，批量处理短信！早期预约时，黄牛会集中处理，我们通过IP，预约时间集中度，可以识别出机器预约，直接纳入黑名单。黄牛后来就采用完全分散的IP（这个在淘宝上可以很便宜买到大把IP），分时段，小批次预约。真是道高一尺，魔高一丈！
每次活动前，在尽量不降低用户体验的情况下，绞尽脑汁去想陷阱，抓捕黄牛，以保证普通用户可以抢到。但有时，防不甚防，黄牛背后是完善的产业链。看下某黄牛工具截止到四月的版本说明，几乎每一次成功的陷阱，下一轮活动就不可用了，对手反应的速度是相当的快。我们用过5位数加减法，用过图形验证码，用过图形+文字，用过各种智力题，当然还有一些用户感觉不到的陷阱。在有巨大利益空间之下，说百分百防住，这我们目前还保证不了。对抗整个成熟的产业链，不是一件容易的事，只能说尽力去想办法，保护普通用户能抢到。
现在我们在不断积累用户行为，通过行为分析，识别可能的黄牛，对明确的黄牛用户，总是可以拦截的。当然，对于明确的友好用户，比如公司内部用户，是直接进入白名单的。现在，内部用户专用通道中，基本不用去抢了，还是照顾到公司内部需求了。
十七、魔高一丈
看一下我们获取到的某黄牛抢购软件版本变更清单说明，这是4月份拿到的，我们的变化，也都对体现在黄牛软件版本的变更之中。这种职业，在巨大利益驱动之下，反应非常迅速，我们的每次手段，基本只能当次有效。
[V2.3]
1、集成前台+后台到一个版本，使用时请先设置前台抢购数量；
2、修改登录方式为登录完成一个账号后再登录下一个账号，避免同时登录造成卡顿，请保证导入的账号密码都正确，密码错误将无法登录下一个账号；
[V2.2]
1、本次更新推出3个版本：前台版、后台版、前台+后台版；
2、前台版需要手动在网页上输入登录验证码并手动到抢购页面，其余的操作和后台一样；
3、所有版本均继承老版本的提前取计算题验证码，自动回答问题，批量提交功能；
4、前台版可靠性大，但是暂时不能统一问题；
5、请自行选择使用的版本；
6、这里说的前台、后台均指的是抢购时用到的，查单和设置地址都是后台操作；
7、代理IP功能暂时请不要使用；
[V2.1.2]
1、尝试解决出现提示成功但是无订单，请使用通道二登录；
[V2.1.1]
1、华为更改代码，紧急更新；
2、因华为本次抢购有几个不同的页面，故在登录前必须先设置好商品ID；
[V2.1]
1、增加可选抢购商品：畅玩、3C、3X，选择后会自动填写不带套餐的ID，如需套餐，请自行添加ID。
切记：需要抢购什么商品不要选错，套餐ID不要填错，选择抢购3c如果填了畅玩的ID，那么这次抢购就白费了！！！
[V2.0.1]
1、增加设置地址时自动填写邮编；（自动获取当地邮编，无需输入）
2、修复未导入代理IP时误报更换代理IP的BUG；
3、增加右键导入账号，解决部分用户拖动账号文本不能导入的问题；
4、修复部分用户选择登录入口一或者二时，登录报错的BUG；
5、增加点击商品ID列表自动填写功能；
6、说明：如果之前有设置收货地址的账号，使用软件设置地址会保留上一次的默认地址，也就是会看到收货信息里有两个地址，新的默认地址是软件设置的新地址，这个并不影响。
[V2.0]
1、增加一键填写默认地址；
2、增加使用代理IP登录账号；（请导入足够数量的可用代理IP，最大不超过1000个）
3、修改导入账号为直接拖放账号文件到状态显示框；
4、增加右键单独对某账号设置地址或重新登录；
5、增加自定义停止热键，按热键停止所有操作；
[V1.9]
1、增加订单查询显示下单日期；
2、增加停止操作按钮；
3、增加右键单独取验证码功能，输入错误答案可以使用此功能进行修正；
4、上期3C因提交太快，华为官方删除了部分早期订单，以供后面其他人抢购，所以官网在10分左右都还能手动抢到，建议以后抢购时，自动提交提示抢购成功后，过5秒或10秒再次点击开始抢购，重新提交一次；
近期发现有人冒充作者进行行骗，现郑重声明：作者不会主动联系任何人收取钱财，战神已经停止招收代理，谨防上当受骗；
[V1.8.3]
1、修复可能出现部分验证码无限错误的BUG；
[V1.8.2]
1、修复订单查询显示价格错误；
[V1.8.1]
1、增加提前取码，请先打好码，等到抢购开始前10秒点击开始抢购；
2、畅玩版套餐代码：9990,9991，如果需要同时抢购，设置ID：1512|9990|9991
[V1.8]
1、针对华为改代码，增加计算题回答，请详细参考附带的教程；
[V1.7.1]
1、添加荣耀畅玩版ID；
[V1.7]
1、增加自动提交问题中带答案的问题；
[V1.6]
1、修复出部分问题报错；
2、增加自动粘贴答案到答题框，确认无误后点击提交或者回车提交；
[V1.5]
1、增加登录验证码自动打码；
2、增加自动回答抢购验证码常见问题，比如姓什么，笔画数，第几个字是什么；
[V1.4]
1、增加检测是否预约账号；
[V1.3]
1、修复入口4登录错误；
[V1.2]
1、增加登录入口四：电脑版快速通道，无验证码
[V1.1]
1、修复打开软件后回车键失效；
十八、潜伏暗战
与黄牛的战斗，还有潜伏式作战，一些兄弟伪装为黄牛，加入各黄牛群中，收集各种信息，通过这些信息，能较准确地识别出黄牛帐号，黄牛地址，可以更好地防范黄牛。最紧张的一次，是某个周二早上九点多，发现黄牛群中破解了我们的陷阱，可能是周一晚上线上测试时，被黄牛跟踪到的，连夜破解的。我们是紧急变招，在10点前完成上线，避免了全被黄牛抢光的恶性事件发生。当然，对我们也是极为紧张，在最短的时间里变招换版本，压力、风险都是很大的。随后，我们对线上测试进一步保护，减少被跟踪可能。
还有一些兄弟，从群中收集各种工具，进行反编译破解，了解对手招术。上面的版本变更，就来源于黄牛群中的文档。有兴趣的同学，可以在网上搜，黄牛软件还录了教学视频，非常之专业啊！
有些招术看上去土，但非常有效，无法防范，比如录制，完全就是模拟正常用户的抢购行为，可从公有云集群机器发起，威力很大，防不甚防，这也是为什么我们要不断变换验证码。有兴趣的同学，可以在淘宝上搜索“云打码”，可以了解到现在产业链的完善程度了。
高级的黄牛群，对于入群，会有些约束，弄不好就被踢出去了，要装得像，需要实际去动手，简直是现代版“投名状”，有兄弟努力多次，也未抢到小米，只能通过京东抢什么大神之类，混个文凭，进去打听消息。春江水暧鸭先知，手机冷热听黄牛！黄牛是直接面向最终用户，其市场敏感性比我们还强，商品的热度如何，通过黄牛群内的信息，可以有个基本判断。
黄牛群里，也会有欺诈存在，出现过收单不给钱的，这只能吃哑巴亏了，你和群主较劲也没用，这就是个灰色产业，见不得阳光，只能信任群主。
现在，我们有兄弟部队在尝试通过大数据分析来识别普通用户与黄牛，希望工具能早日发挥威力！若有此方面的高手，热烈欢迎！
给大家算个小帐，3C线下最高炒到过1400，价差有600之高，如果一次工具抢到1万台，利润空间600万！一周一次甚至二次抢购，还有其他各厂家类似抢购，最著名的自然是小米。这些黄牛每周会抢购多轮次，一周获利空间就是数千万！如此巨大的利润空间，推动的是整个产业链的发达。有专门开发工具的，有提供云服务的，有收单的，有抢单的，有卖号的，大黄牛甚至搞定区域快递员，约定某种暗号，就表示是他们的单！各种玩法，不亲身经历，以我们习惯的学院派玩法，都不知道别人在玩什么把戏。为了防止在收货地址上被识别，看下黄牛是怎么玩的：
XX小学前行100米左拐30米二楼王XX家。
广东省深圳市龙岗区 坂田街道 五和路四巷2号连扳档口肠粉店
广东坂田街道第三工业区C座麻酱面小吃部
龙岗 坂田小学⑤十栋 光明超市
叙宵魏霸颧疼稽双银大厦2004纯乘雌拖节顽 （要在海量订单中，找这样地址，不易啊）
认僧矾菱巩趋跋双银大厦2004捉徒瘪奉赐怕
吨悟由绩骏护堡双银大厦2004南梁充技敏筏
……
各种防识别手段，层出不穷啊。估计这些都是经历过小米、京东K单的黄牛，总结出了经验，具备很强的防K单手段。
勤奋的黄牛，真没办法，每次换的地址都难以识别。有技术大拿，给我们来个NB方案吧，现在相当一部分需要靠客服MM人眼凭感觉去识别。有些黄牛干脆给个垃圾地址，然后直接电话快递自提。曾有个黄牛不小心搞错了，货发到广州找不到具体地址，顺丰快递员一联系，黄牛直接从深圳开车去广州自提了！黄牛根本不希望商城知道，顺丰不说，我们也不知道。
十九、些许欣慰
下面是某次活动，在黄牛群的中截取的对话，能看到我们的变招产生了效果，就算是被黄牛骂了，也还是小有成就感，兄弟们也能感到些许的欣慰啊：） 为了安全起见，对黄牛帐号隐藏几位。
【大学】路人乙(94xxx0741) 14:46:32
三场我一台都没秒到
【博士】三生三世(976xxx748) 14:46:38
都显示了这样的，就是没有订单
坑
【大学】路人乙(94xxx0741) 14:46:51
客服怎么说
【博士】三生三世(976xxx748) 14:47:05
没问客服
不想问
【大学】路人乙(94xxx0741) 14:47:21
我是没看到这个页面 每次都显示抢购人数过多
唉
3x 感觉不会再爱了
【博士】结账红米(41xxx7381) 14:47:59
机智得华为
【博士】三生三世(976xxx748) 14:48:08
下次抢不用软件了
【博士】三生三世(976xxx748) 14:48:25
貌似我每次买抢购软件都废了
买一次，费一次
【博士】结账红米(41xxx7381) 14:52:04
，，哈哈
多少钱买的
【博士】 گوگو 靓 گوگو(85xxx6163) 14:52:17
你妹啊
【博士】三生三世(976xxx748) 14:52:24
10元买的周卡
由于利益空间的存在，就会有骗子的存在，估计在全球，骗子这个职业是个最古老而顽强的职业了！我们的客服遇到过多次用户上当受骗，过来投诉。有买了别人帐号，下了订单，支付后又被原帐号主人更改了收货人的。有中了钓鱼网站招的。各种情况，不一枚举。
为了减少这种欺骗带来的影响，后来决定用户抢购订单的收货人地址不允许修改，必须提前准备好缺省地址。其实很难有完美的方案，这个在减少欺骗的影响同时，也给普通用户带来不便，比如心声中就有很多人让客服美眉代修改订单收货地址。再后来，我们进一步优化，用户抢购中可以直接填写地址，订单提交前都可以更改，建议大家下单前仔细确认地址，让客服美眉修改，也是运营成本啊。随着系统优化的不断进行，性能的提高，体验方面也有基础去作些优化。
在我们认为通过限制订单不让给地址之后，杜绝了欺诈，可以有效限制黄牛，但实际上对收单黄牛更为安全。只要地址正确，黄牛就敢支付，免去判断帐号是否白号的问题。这样，黄牛不用再提供白号，普通用户愿意，完全可以用自己的帐号去抢，只要抢成功，将帐号、订单发给黄牛，黄牛就可以放心支付。这反而造成黄牛交易更简单。这也使得黄牛帐号变得更为分散，难以识别。
改进无止境，我们永远在路上！如果有兄弟在对付黄牛方面有好的想法，非常欢迎贡献智慧！前两天，JD和我们一起讨论如何防黄牛的问题，大家都很苦恼，按理JD比我们应该更好防一些，其用户相关数据比我们多很多，识别起来要有效多了。
对了，最近小米也学习我们，玩起了智力题：
这样类似的智力题库，每次若能有几千乃至上万道以上，对黄牛工具来说，杀伤力还是很大的，题目太少，只能防住一小会，大华为这多员工，在此征集一下这类智力题，要求很简单，是个人都能答，是个机器都不能答，也不能穷举：）也许到这儿，有人能理解，我们曾经搞5位数加减法吧，位数少了，机器可以硬穷举的。用过几次之后，也放弃了，对手很强大！因为数字太容易识别了，即使我们混入汉字，也易于识别，就那几个特定模式，识别率很容易提上去的。再加上云打码服务，数字题目基本就没用了。
验证码最神奇的故事，是我们遇到个千年老妖啊。该用户投诉说我们的智力题是骗人的，他答对了，我们判断错了，导致他没有抢到，要求赔偿精神损失。我们客服MM怎么沟通，都不行，最后我们说给他下个单，让他自己支付，这都不行，非要免费送他手机，如果不送，就去工商局告，说我们这是属于欺骗，要罚十倍。最后我们就只能让其去告了，罚十倍没事，罚千倍呗，反正他一分钱没花，一万倍也还是个0。类似的故事非常之多，运营部的兄弟姐妹，有机会也分享一下乐子吧。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
