监理公司管理系统 | 工程企业管理系统 | OA系统 | ERP系统 | 造价咨询管理系统 | 工程设计管理系统 | 甲方项目管理系统 | 签约案例 | 客户案例 | 在线试用
X 关闭
学生管理系统

当前位置:工程项目OA系统 > 学校OA管理系统 > 相关系统 > 学生管理系统

IT一家言:12306已近技术极限

申请免费试用、咨询电话:400-8352-114

 声明:本文原作者“代码狗”,内容有删剪。12306问题背后,技术原因究竟占了几成?不管你信不信,我是通篇读完了。

 

        资深程序员现身说法

  我曾在淘宝写过一段时间代码,2012年在一家百强民企做电商副总,当时在极为艰苦的条件下带队开发了一个B2C网站,走支付宝和银联支付通道,年营业额千万级(当然实在太少了,我只是说这个网站投入了实际的运营)。

  也就在那个时候,我对“12306”嗤之以鼻,觉得他们做得太烂了,认为自己能带队花几百万元用半年时间做个好的出来。于是我狂妄地想做一个开源的订票系统给他们。我花了一个星期时间思考建立数据模型,思考到库存这一步的时候,我才发现,“12306”的库存复杂性比淘宝、京东高很多倍,运算量也大很多倍。传统的分布式数据库、缓存、负载均衡技术并不能恰好满足“12306”的需求。

  淘宝技术的确比“12306”强大很多倍,淘宝现在的系统也是花了10倍于“12306”的钱、时间和人力才做起来的。根本原因还是铁路运力不能满足春运需求,淘宝也解决不了这个问题。

  “12306”这一年来进步非常大。从前端动画验证码、分时段抢票,到后端去小型机、虚拟化、内存数据库的运用。可以说,这是中国官方部门做得最强大的网站(电商系统)。至于“12306”一期工程3个亿(含硬件)贵不贵我不评价,我只提供一个数字供参考:百度一年的研发费用(不含硬件)是10亿元,这来自百度财报。3亿元看起来好大一个数字,真用到超大型的电商系统、搜索引擎系统里面,其实也不算天文数字了。

  你不知道的“秒杀”

  为什么秒杀压力大,为什么“12306”的动态库存很复杂?

  先说秒杀。

  2013年12月25日前后,天猫搞了一个圣诞季积分兑换活动,持续几天。25日上午10时12分,放出了15000个天猫魔盒,从成交记录上看,19秒内全部抢完。

  实际上,我也参加秒杀了,那天的题目特别简单——请输入×××汉字的拼音首字母,我5秒内答题完毕并提交订单,结果系统告诉我排队的人太多,挤不进去,并提示14秒后重试。人太多就是因为题目太简单了,门槛越低,5秒内挤进去的人也越多,如果题目换成“2克浓度为3%的U235在大亚湾核电站能发多少度电”,5分钟之内都不会有1万5千人跟我竞争。

  我想,14秒以后哪还有我的事呀,于是重新答题秒杀,结果出现了服务器错误的页面。反复刷新几次,秒杀就已经结束了。

  淘宝是什么技术水平呢,淘宝有至少4000名技术人员,至少4万台服务器(这是两年前的公开数据)。2013年11月11日成交额351亿元,2012年全年成交额超过1万亿元。

  淘宝拥有各种自主研发团队:服务器、交换机;操作系统、Web服务器、Java语言虚拟机、数据库、负载均衡器、Java运行容器。淘宝还有数不清的开源项目和中间件,如高性能Java通信中间件HSF、分布式数据库中间件TDDL、异步消息系统notify等等。

  以淘宝这样的技术水平,都还不能做到秒杀时让每个用户都没有拥挤感,为什么?

  一是要尊重物理原理,一台服务器一秒钟能承受的计算量是有极限的,任你怎么优化,采用多高效的算法和编程语言,都突破不了某个极限,比方说汽车发动机驱动的F1赛车至今也不能突破400公里的时速。

  二是要考虑经济效益,“十一”黄金周的时候,北京主城区到八达岭长城的路堵得严严实实,但不能因为黄金周的高峰,就把这段路修成长安街那样10车道的高速公路,否则花费天文数字(“12306”那3个亿大概只够修1-3公里)修了一段路,平时晒谷子?

  淘宝目前的硬件和带宽数量,已经超出日常运营的需求了,目的就是留出相当大的余量给大促销。

  再说动态库存。

  淘宝秒杀天猫魔盒的时候,只有一个商品(SKU),它的库存是15000个。有一个人秒杀到了,库存就减1,19秒卖完的,每秒要成功产生789个订单。想象一下,你在广场上卖火车票,一秒钟内有8万人举着钱对你喊:卖给我!

  很多人都知道,比秒小的时间单位还有毫秒、皮秒、飞秒。但交易系统登记一个交易可不像电子绕着原子核跑一圈那么简单,它要做这些事:检查是否恶意访问、取到系统时间、取到顾客默认收货地址、核对顾客秒杀资格、生成订单号、把顾客ID系统时间订单号收货地址写入订单系统、扣除顾客天猫积分、商品库存减1、给顾客打标记(每人只能秒一个)等等等等,每件事都要花费毫秒级别的时间,这些操作加起来的时间可能是接近1秒级别的,但由于淘宝的服务器比较强悍,而且采用了分布式和集群技术,结果比1秒理想一点。但即使有1万台服务器,也不能把这个时间稀释成万分之一秒,因为,商品只有一种,它有15000个库存,对应的数据库记录只有一行,所有的交易请求都要到这里来处理。

  能不能把这15000个拆分成5000个商品并分配到5000台服务器上呢?那样不就可以5000台服务器同时处理了吗?答案是不能,首先,5000个商品,意味着有5000个商品详情页,5000个购买按钮,这对前期的营销、引流是个灾难。基本上就没法做引流入口了,显然这违背了商业管理原则,人为增加了信息混乱程度。其次,天猫魔盒秒杀也不是啥大事,即使按官方标价399元来计算,也就600万元的交易。如果600万的交易要花费那么大的配套成本,就太不划算了。再次,淘宝有十几亿商品,这十几亿商品的展示交易和管理,本来就是分布到上万台服务器上去了。没有必要再把每个商品按库存拆成多个商品了。

  这789人抢到了,还不一定会付款,所以就又带来订单取消重新恢复库存的问题。还有想要的消费者们,会认为还有机会,继续在前台刷一会儿,最终这个秒杀会被热情的消费者们猛刷30秒到1分钟。

  12306的“变态”库存

  好了,讲了半天淘宝,回到正题“12306”——我以北京西到深圳北的G71次高铁为例,它有17个站(北京西是01号站,深圳北是17号站),3种座位(商务、一等、二等)。表面看起来,这不就是3个商品吗?G71商务座、G71一等座、G71二等座。大部分吐槽的人就是在这里栽第一个跟头的。

  实际上,G71有136×3=408种商品(408个SKU),怎么算出来的?请看:如果卖北京西始发的,有16种卖法(因为后面有16个站),北京西到:保定、石家庄、郑州、武汉、长沙、广州、虎门、深圳……分别都是一个独立的商品。

  同理,石家庄上车的,有15种下车的可能,以此类推,单以上下车的站来计算,有136种票:16+15+14……+2+1=136。每种票都有3种座位,一共是408个商品。

  再看出票时怎么减库存,由于商务、一等、二等三种座位数是独立的,库存操作也是一样的,下文我就不再提座位的差别,只讨论出发与到达站。另外,下文说的是理论模型,不是说“12306”的数据库就是这么设计的。

  旅客A买了一张北京西(01号站)到保定东(02号站)的,那么北京西到保定东这个商品的库存就要减1,同时,北京西到石家庄、郑州、武汉、长沙、广州、虎门、深圳等15个站台的商品库存也要减1,也就是说,出一张北京西到保定东的票,实际上要减16个商品的库存。

  这还不是最复杂的,如果旅客B买了一张北京西(01号站)到深圳北(17号站)的票,除了北京西到深圳北这个商品的库存要减1,北京西到保定东、石家庄、郑州、武汉、长沙、广州、虎门等15个站台的商品库存也要减1,保定东到石家庄、郑州、武汉、长沙、广州、虎门、深圳北等15个站台的商品库存要减1……总计要减库存的商品数是16+15+14+……+1=120个。

  当然,也不是每一张票的库存都完全这样实时计算,可以根据往年的运营情况,在高峰时段预先对车票做一些分配,比如北京到武汉的长途多一点,保定到石家庄的短途少一点。我没有证据证实铁道部门这样做了,但我相信,在还没有“12306”网站的时候,就有这种人工预分配的策略了。

  再想象一下,8万人举着钱对你高喊:卖给我。你好不容易在钱堆里找到一只手,拿了他的钱,转身找120个同事,告诉他们减库存,而这120个同事也和你一样被8万人围着;也和你一样,每卖出一个商品要找几十个人减库存……这就是“12306”动态库存的变态之处。比你平时买东西的任何网站的库存机制都复杂几十上百倍。

  空谈技术无益解决问题

  防软件抢票,也不是加个图片验证码那么简单。图片验证码有6种机器暴力破解的办法,抢票插件用的是OCR识别。验证码设置得复杂一点行不行?有人又要提意见了:这只是便宜了大学生和办公室白领,农民工连26个字母都认不齐,怎么搞?搞动画验证码吧,也有人说,视力不好的人怎么办?最后验证码被搞得很简单,皆大欢喜。其实最高兴的是开发抢票插件的公司。

  就算采用了机器完全不可能识别的验证码,也防不住社会工程学的破解办法。招募一堆网吧打游戏的青少年朋友,每成功输入50个验证码给1块钱,或者等值的虚拟货币、游戏装备,我保证想赚这个钱的人数不胜数。这点钱对转卖车票的利润而言,是可以接受的成本。有没有什么技术可以防住社会工程学的破解办法呢?能防住网吧青少年的验证码只有——“2克浓度为3%的U235在大亚湾核电站能发多少度电”。

  以上讨论只是把“12306”当成和淘宝一样没有历史包袱从零起步的交易系统,实际上它不是,它后面的票池还有电话售票、火车站售票、代售点售票等多个传统渠道要服务。除了客运服务,“12306”还有全国最大(很可能也是全球最大)的大宗物资货运系统。架空政策(包括定价政策、警方打击“黄牛”政策、身份验证政策)谈技术,是不可能解决春运抢票困局的。

  还有人说,KFC的食品可以单卖,也可以卖套餐,为什么没像我一样搞出这么多SKU?那是因为,KFC门店的“人肉查询”频率非常低,没必要为了优化查询性能把库存结构设计成那样。

发布:2007-03-30 17:10    编辑:泛普软件 · xiaona    [打印此页]    [关闭]