身为码农,为12306说两句公道话

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

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

12306.jpg

在平时,12306也就是个正常的电商网站。但一到黄金周,12306就是一个全站所有商品都秒杀,所有SKU都是动态库存的变态。

即使不考虑线下既有的电话、代售点等渠道,要实现一个12306,最少最少也是千万级别的硬件投入(这是当时的估算,没有精算,可能与实际相差较大,总之,我说得不一定对,12306的业务也许没我说的那么复杂,但也绝不是某些人喷的那么简单),软件和人力另算。那些叫嚣只要40台服务器、只要2个架构师4个程序员、大谈分库分表和前端CDN的人们,只是纸上谈兵罢了。所谓初生牛犊不怕虎,做了三年CMS和BBS,就以这个经验来喷12306,未免太天真了。

媒体人喷12306,是他们不懂技术,没有能力和耐心来分析背后的难度。技术人员喷,则是因为大部分的技术人员在短时间思考时,容易陷入过于乐观的误区,经典的例子就是估算工作量,程序员们往往容易估算出一个超短的工期,把写程序的工作乐观地想象成了打字员照稿敲键盘的工作。

知乎那篇文章,我觉得不是洗地。排名第一和第二的答案都说得很客观。淘宝技术是比12306强大很多倍,淘宝现在的系统也是花了10倍于12306的钱、时间和人才做起来的。根本原因还是铁路运力不能满足春运需求,淘宝也解决不了这个问题。

12306这一年来进步非常大。从前段动画验证码、分时段抢票,到后端去小型机、虚拟化、内存数据库的运用。可以说,12306是中国政府机关做的最强大的网站(电商系统),能在短短一两年内做出这样的改变,几乎是个奇迹,就连一些市场化的民企都望尘莫及,甚至一些上市公司都比不上它!(比如51job和ctrip)。

事非经过不知难,在网上批判12306的人,大部分还是形成了【国企 = 垄断 + 腐败 + 低效 】的思维定势。小部分是真的轻视了它的难度。

至于12306一期工程3个亿(含硬件)贵不贵我不评价,我只提供一个数字供参考,百度一年的研发费用(不含硬件)是10亿,这个数字来自百度财报。网上能查到。3亿看起来好大一个数字,真用到超大型的电商系统、搜索引擎系统里面,其实也不算什么天文数字了。

再解释一下,为什么秒杀压力大,以及为什么12306的动态库存很复杂。

先说秒杀

2013年12月25日前后,天猫搞了一个圣诞季积分兑换活动,持续几天。25号上午10点12分,放出了15000个天猫魔盒(淘宝集市有人卖,大概190-230块),从成交记录上看,是19秒内全部抢完。

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

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

在群里问了一下同事,有不到10个人回答我,都说没秒到(也可能秒到的人闷声发大财,不回复我)。

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

淘宝拥有各种自主研发团队:服务器、交换机(网上可以搜索到淘宝公开的绿色服务器开放标准);操作系统(Linux Kernel taobao版,yunos手机操作系统是阿里云的,暂时不计入)、Web服务器(Tengine)、Java语言虚拟机(JVM taobao版)、数据库(MySQL内核 taobao版,google和facebook也有自己的版本,HBase淘宝版、还有自己全部从头开发的OceanBase)、负载均衡器(LVS,LVS始创人就在淘宝,担任研究员)、Java运行容器(Jboss,其创始人之一,王文彬,也在淘宝,担任副总裁)。

淘宝还有数不清的开源项目和中间件,如高性能Java通信中间件HSF、分布式数据库中间件TDDL、异步消息系统notify等等等等。

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

一是要尊重物理原理,一台服务器一秒钟能承受的计算量是有极限的,任你怎么优化,采用多高效的算法和编程语言,都突破不了某个极限,比方说汽车发动机驱动的F1赛车至今也不能突破400公里的时速(超音速推进号那个1千多公里的时速不能算,那是飞机引擎驱动的)。再往深了说,就不容易懂了。感兴趣的可以从著名的C10K问题开始看起。

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

淘宝目前的硬件和带宽数量,已经超出日常运营的需求了,就是留了相当大的余量给大促销(众所周知的是双十一,双十二,其实基本每个季度都有大促销,每个月都有促销,甚至天天都在促销——聚划算)。amazon当年就是为了应对黑色星期五的大促销购置了大量的服务器,平时订单量没那么大了,amazon就把富余的服务器拿来搞云计算了。顺便说一下,阿里云是当今中国第一世界数一数二的云计算服务商,和amazon走的路也有点像。

再说动态库存

淘宝秒杀天猫魔盒的时候,只有一个商品(行话叫做SKU),它的库存是15000个。有一个人秒杀到了,库存就减1,19秒卖完的,一秒要成功产生789个订单(下订单的请求可能是8万个,只是可能啊,非实际数字,也可能是1万个,用于说明一下壮观程度)。想象一下,你在广场上卖火车票,一秒钟有8万人举着钱对你喊:卖给我!

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

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

这789人抢到了,还不一定会付款(99积分换天猫魔盒还好一点,不需要去网银,成本也极低,大部分是会付款的,3999秒杀iPhone 5S就不一定,有人可能网银有问题,有人可能改变主意不想要了),所以就又带来订单取消重新恢复库存的问题。还有想要的消费者们,会认为还有机会,继续在前台刷一会儿,最终这个秒杀会被热情的消费者们猛刷30秒到1分钟。

(超卖这一部分科普笔法写得有错误,鉴于12306目前全在内存数据库中读写,没有产生超卖问题,先把这个段落删去。感谢@吹西门的雪 指正)

好了,讲了这半天淘宝,可以说12306了吧?

我以北京西到深圳北的G71次高铁为例(这里只考虑南下的方向,不考虑深圳北到北京西的,那是另外一个车次,叫G72),它有17个站(北京西是01号站,深圳北是17号站),3种座位(商务、一等、二等)。表面看起来,这不就是3个商品吗?G71商务座、G71一等座、G71二等座。大部分轻易喷12306的技术人员(包括某些中等规模公司的专家、CTO)就是在这里栽第一个跟头的。

实际上,G71有136 * 3 = 408种商品(408个SKU),怎么算来的?请看:

如果卖北京西始发的,有16种卖法(因为后面有16个站),北京西到:保定、石家庄、郑州、武汉、长沙、广州、虎门、深圳……都是一个独立的商品,

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

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

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

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

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

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

再说一下抢票插件

机器永远比人快,当你好不容易从8万人里突出重围,来到了柜台前,你发现,我操,来了10万根绑着钱的竹竿,而且当有退票出来的时候,你要闯过3层人肉才能接近柜台,竹竿在8个人身后一伸,钱就到了柜台前。你低头看了一眼手机,票就没了,竹竿却永远在那里伸着,永不低头,永不眨眼。如果没有这10万根竹竿,虽然你很可能还是抢不到票,但不至于沮丧成这样:我TM为什么总是手最慢的一个?!!

防机器人抢票,也不是加个图片验证码那么简单。我写过文章系统性分析过,图片验证码有6种机器暴力破解的办法,抢票插件用的是我说的第三种,OCR识别。Google采用的Wave波形字母已经能比较好地防住机器OCR了,ems.com.cn上的验证码就是反面教材,机器OCR成功率接近100%,12306的比ems的图片验证码强一点。不过,验证码设置得复杂一点吧,人们要喷:这只是便宜大学生和办公室白领,农民工连26个字母都认不齐,怎么搞?搞动画验证码吧,也有人喷,视力不好的人怎么办?最后验证码搞得太简单了,皆大欢喜了,其实最高兴的是开发抢票插件的公司。

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

没有历史包袱从零起步的交易系统?

以上讨论只是把12306当成和淘宝一样没有历史包袱从零起步的交易系统,实际上,它不是,它后面的票池,还有电话售票、火车站售票、代售点售票等多个传统渠道要服务。除了客运服务,12306还有全国最大(很可能也是全球最大)的大宗物资货运系统。

架空政策(包括定价政策、警方打击黄牛政策、身份验证政策)谈技术,是不可能解决春运抢票困局的,要想让春运的时候每个人在12306抢票都毫无拥挤感(但不一定能抢到票,铁路运力摆在那),那就是逼着12306买一大堆服务器对付春运,春运过去后,成为跟amazon一样牛逼的云计算服务商。和逼北京修一条10车道的高速公路去八达岭长城一个道理。

目前的12306技术上是还有问题,比如,抢票高峰,输入个身份证号和图片验证码都卡得要死(本人亲测),服务器端繁忙,你浏览器端卡什么呀。

但人家在进步。相信2014年春运的时候,技术已经不再是一票难求的主要问题。在铁路运力不可能神速增加(孙中山先生计划的20万公里铁路,土共修了快70年,才修到10万公里)的情况下,要做到春运更公平地买票,需要停靠政策调整。

非常时期有什么解决方案?

下文针对的是春节国庆这种非常暑期。其它时期,大部分线路保持现状就行了,问题不大,极少部分票源紧张的线路可以按春运处理:

1. 拍卖法,价高者得之

当硬座票拍出飞机票价格的时候,相信票就不难买了(可惜就是贵了),也没有那么多黄牛了。要说淘宝有什么能帮12306一下子搞定技术问题的,淘宝的拍卖系统可以帮忙,浙江省高院在淘宝拍卖一年多,成交26亿。

可惜这个方法不可能实行。现在的高铁票价都被媒体和意见领袖喷成啥样了,何况是拍卖。再说,火车票毕竟是生存之刚需,票价20年来不涨本来就有照顾补贴的成分在里面,全拍卖可能也是不妥当。

2. 抽签法,运气好者得之

开车前2个月开放报名,开车前7天抽签,中途可取消。预存票款,抽不中退款。上传身份证和正脸自拍照,机器核对。

这样的话,拦截黄牛的成功率就高很多了,黄牛可以预存票款,可以找到大量真实身份证号,你黄牛再让每个给你身份证号的人把身份证照片和脸部自拍也给你试试?即使有人真想找黄牛,给身份证照片还是会犹豫一下吧。而且中间手工操作多了很多,黄牛成本提高,还不一定搞得到票。反正都是碰运气,我想真正的消费者还是会选择自己先去碰运气吧。

这个方法实施难度也大,无论怎么设计抽签规则,必然有人大叫“有黑幕,不要相信政府”。

开车前7天出抽签结果,改变行程的人应该在7天前就能决定改还是不改了。没抽到的也还有时间想别的办法。当然不一定是7天,15天,10天也可以,具体几天要有数据模型来算。

3. 拍卖 + 抽签

软卧、高铁商务座等高价位的,拍卖,反正买这个的是经济能力相对较强的。那就拼谁经济能力更强吧。

硬座、站票抽签。

4. 凭身份证进站,车票跟发票一样,是报销凭证,不是进站凭证;退票后钱进入12306账户,不可提现,只可该乘客下次乘车用;黄金周期间,个人账号最多订购10张票

这个办法可以打击黄牛囤票再转卖。运行一段时间后,按账户余额弄个排行榜就知道谁是黄牛了

可惜这个需要车站设备改造配合。

1 收藏 69 评论

相关文章

可能感兴趣的话题



直接登录
最新评论
  • 相比去年要好了很多。
    最终还是实际春运问题。票少才这么难买。我同事回家的从上海到邵阳的车每天一班车,一班车只能坐2000人。就算网站访问是0延迟抢票都还是靠手速。

  • Roy   2014/01/11

    关于火车票的库存
    假设有以下9个站
    北京、保定、石家庄、郑州、武汉、长沙、广州、虎门、深圳
    对于一个指定的座位来说,库存商品应该只设9个就够了

    案例1
    假设旅客A买了北京——郑州的票,只要在北京、保定、石家庄三个商品上打上“sold”标记(郑州站旅客下车,所以此时座位没有被售出)
    此时如果旅客B想买保定——武汉的商品,会发现保定、石家庄均“sold”,就会提示“无票”
    此时如果旅客C想买郑州——武汉的商品,就会提示“有票”,然后将郑打上“sold”标记

    案例2
    旅客A买了郑州——广州的票,郑州、武汉、长沙被打上“sold”标记
    此时旅客B想买北京——武汉,发现郑州“sold”,提示“无票”

    就是说,商品只要列出站点,只要该座位在这一站有人坐,就需要打上“sold”标记,而不用考虑该乘客的起止站点,并不需要列出具体多少种卖法。价格问题:价格是固定的,不管票是否卖出去了,定价都是不会变的。所以G71的408种商品价格单独存放在一个表里就行,不需要和库存在一起

    • firezcl   2014/01/11

      这个哥们的评论 完全是胡说八道,请大家不要被他误导了。
      他这个设计师是专门为私人列车考虑的。一趟列车只能同时有一名乘客。
      希望是我理解错了。

      • nealx   2014/01/11

        我觉得是很好的方式,我也是这么思考的。至少ls的反驳说错了。
        明明说的很清楚 “对于一个指定的座位来说,库存商品应该只设9个就够了”
        也就是说一个指定的座位,同时只有一个人坐——这个是完全符合逻辑的。
        不知道ls怎么得出结论“一趟列车只能同时有一名乘客。”

        • BobC   2014/01/12

          方式并没有问题,但是其实算法反而复杂了。注意:“对于一个指定的座位来说,库存商品只设9个”,也就是说通过“是否”判断(即Sold/unsold的方法)扩展了无数个库存商品,而长文中的方法则是计数,简化了库存商品。

          一个小例子:假设一列火车100个座位,有北京,保定,石家庄三个站。
          那么从第0时起(也就是还没任何人买到票),对应从北京到保定的座位可以有100个。此时只考虑“北京-保定”线。

          此时若有人买到从北京到石家庄的车票,则北京到保定的车票减一,变为99个。对应的数据记录只有一行,变化的是其中的数量值。北京到石家庄/保定到石家庄的车票当然也各自减一,但此时只考虑“北京-保定”线。

          但是如果按照楼主的说法,需要给“北京-保定”的每一张票写一行数据,当车票减一时,需要更改其中一张票的“是否”属性。余下99行不变。操作量和数据量于是爆炸式增长,需要更多的服务器来容纳。
          说白了一句话,sold/unsold只适用单一判断,对于数量值大于1的库存商品无法适用。当然了,一定要写这个模型也没什么不可以。

          • fishenal   2014/01/13

            还没有12306 你在柜台买票的时候铁路系统早就解决这个问题了,以前那种慢车站点更多,电脑上一查就知道还有没有票,而且通常人一下去这一站的人就上来了。 肯定不用12306的工程师去操心这个,但是我觉得评论里的算法更合理,文章里算区段感觉比较麻烦

          • Dr. ROY   2014/01/16

            我觉得你的评论说的很对,给“北京-保定”的每一张票写一行数据这样无限扩大了数据量和查询量

            我想,如果把sold/unsold状态替换为座位余量呢?如果该列车一共有100个座位,北京——保定卖了50张,“北京”-50,北京——石家庄卖了50张,“北京”-50.此时查询北京——石家庄的余票,因为“北京”这站可售票是0,就不能销售。这样就只要统计每站的可售余票就好。

            说点别的。每张票上都印有座位号,这就表示每个座位都应该对应数据库里的一条记录,而且这个记录应该有一个表示“该座位是否可以销售”的状态。所以我认为,不管用哪种方法,这个数据量始终都是不可小视的

    • gogo1212a   2014/01/13

      对,lz想的方向错了

    • duguxy   2014/01/14

      这个办法对查询压力太大了,顾客查询从北京到深圳有没有票要把全部站全部座位的状态检查一遍,乘客一次查询要返回多个车次的结果,要经过几次查询才最后下单,应该优先保证查询的性能,毕竟查询的请求比下单的请求多得多,用户体验也更重要。

    • zxing   2014/01/21

      你所说的和楼主所述没有差别,复杂度一样。都是买一张票要在若干记录打标记。我倾向于楼主的假设,每个区段的票都分配好了,余下的,售票点买去吧

  • Roy   2014/01/11

    此时如果旅客C想买郑州——武汉的商品,就会提示“有票”,然后将郑州、武汉打上“sold”标记

    有误,武汉不需要“sold”标记,因为此站旅客下车

    假设旅客A买了北京——郑州的票,只要在北京、保定、石家庄三个商品上打上“sold”标记(郑州站旅客下课,所以此时座位没有被售出)
    旅客下车,笔误

  • Jonas   2014/01/11

    低端开发人员表示。好文章。又涨姿势了!

  • 不写可以么   2014/01/11

    当所有的互联网公司,使用的都是同一片公有云中架设出来的服务的时候,就不需要面临这种 峰值问题了.
    因为网民数量是相对稳定的, 你不可能在抢票的时候还跟人聊qq,看电影.发微博,写blog...

  • loopwizard   2014/01/11

    表示“呵呵”
    我猜12306的同事一定都在笑而不语
    神马一条线路上各种复杂计算,真实情况是——每一个站的票数是分配好的
    就是这么简单暴力,撸主真的想多了
    这就是为什么在线路A-----B-----C上,你在买不到A到B的情况下依然可以买到A到C的票

    • lin   2014/01/11

      会有一些预留的票,但不会是分配好的

      照你这种搞法,很容易被人发觉,你自己仔细想下就知道了

    • fishenal   2014/01/13

      铁路的票务系统早在12306成立之前就有了,是一套完善的系统,用了十多年了,轮不到12306的工程师考虑这个问题

  • ling   2014/01/11

    有些话不错,有些话跟你口中的那些年轻程序员一样……浅薄

  • Jation   2014/01/11

    服..stO..

  • 轻如纸张   2014/01/11

    成本根本不是问题,高铁每公里造价都是亿元级,就看他们想不想花这个钱,反正网站再烂票也都能卖出去,卖给谁不一样。

  • 假如你忍着不告诉别人你是xx副总裁,此文会不会就没有权威性了?会不没人看了?会沉了?单纯以技术说话,应该还是会有人能懂的吧。

  • Techni   2014/01/11

    比去年,卡顿感好了很多。
    12306不挨批是不可能的。
    毕竟,每个人都想回家,而12306给了人这个希望

  • 衡路文   2014/01/11

    理性的分析!

  • 赵明   2014/01/11

    对于刚刚步入码农行列的菜鸟而言,对撸主的敬仰之情滔滔不绝!之前确实觉得12306做起来很简单。不过,站台分票应该是准确的吧,按照往年春运进行分配很合理啊!实际点讲,春运期间看到车里没坐满,始终有空位子就代表是分配票了。

  • 衡路文   2014/01/11

    理性的分析!!当然不说也不是全是实际的。也存在一些问题。

  • 李翔   2014/01/11

    让12306和公安部联合起来。真的实名了,就不用怕什么黄牛了,没黄牛压力自然就降低不少

  • bugz   2014/01/11

    文章写车票计算方法完全是在意淫,虽然我不知道铁道部具体的计算方法,但是小站点卖的票只有站票。这就是为什么在大站点停站后车上有空座,小站点上来的人仍然挤在过道上的原因。

    关于最近买黄牛最新的招数,买完不付款的方式,实际上在淘宝等都遇上过这类攻击。都没有太好的解决办法。不管条件多么苛刻都无法分辨真实需求和恶意需求的人。

    解决问题的根本办法是增加人口本地就业机会,减少人口流动。从自己做起拒买黄牛票。能到这一天真的实现,再回头看12306只不过是个笑话而已。

    • nealx   2014/01/11

      解决办法是扩容,我们真的不需要再提速了,有这些速度要求的人去坐飞机吧。更重要的是先可以在短时间内把更多人送到家。举个很粗暴的例子,把一条线路上的动车座位全部拆掉,这条线路上的票子全是站票,运送能力提升为400%,速度降为50%。这样可以解决更多的人回家问题,如果每个人在最后一刻保证可以回到家的话,就不会有那么多人在网上买票开始的第一秒就开始抢票。网站峰值自然大幅降低,软硬件压力自然降低了。

      • zhanghc   2014/01/11

        有人回家要30个小时,你让人站着,好意思吗?提速是提升运力的一种方式。

  • bugz   2014/01/11

    其实解决买票占坑不付款的方法很简单,amazon的秒杀就用了这么一个机制:排队,即使订票名额已满,仍然可以排队,当有人取消订单或者没有及时付款,则车票轮询到下一个排队的人。这个方法至少能把现在黄牛问题解决掉。

    • lee   2014/01/11

      这个大哥说的最中肯。
      1、倒卖最大的解决办法就是回笼排队,先占用票也么有用。
      2、代购貌似真没有办法解决,这是一种代理行为,只不过是请了人去排队而已。

  • John   2014/01/11

    从字里行间感觉到你是一个技术大牛。你说的我不懂, 只是觉得这个一个基础设施, 应该在发布前做比较完善的测试和预测。 今年的黄牛刷票, 明显是12306的技术漏洞, 说明在方案论证的时候的确欠妥。 不管我们是发牢骚还是喷, 也得执行机构让他们改好才行, 而不是年年在检讨, 年年问题多。 并不是说他们不努力, 而是不够努力。 虽然我只做MCS51和cortex-M的程序, 但他们的作品的确让我们失望了!

    LZ, 你的建议除了最后一条我同意, 前面的三条会让整个社会的公平和效率被颠覆! 把基础设施的产能当收藏品来运作, 试问: 你怎么向纳税人交代? 因为区域经济发展的不平衡, 除了提高铁路运力和平衡发展区域经济, 其他idear恐怕还是不能解决回家难的问题。

    一个发光的小灯泡可以看做一个点光源, 在不同的半径上得到的光辉是不一样的, 在同一半径不同面积获得的光辉也是不同的; 人太多的时候,你还需要站得更高,更靠前才能得到光辉。

    好了,不写了。 怒其不争啊。

  • simonliu   2014/01/12

    文章没仔细看,我的观点就1个:投入1个亿,就做出来这等垃圾。

  • andy   2014/01/12

    怪不得12306做的烂了!

  • crazy4evth   2014/01/12

    从技术角度来看12306网站有其难度,12306从上线到现在,它时刻在进行更新升级,相比最初,有了很大的提升,这些都是有目共睹的。一票难求最根本的原因也不是网站所造成的,最根本的还是能够解决春运、黄牛的问题。

    但不管是出于什么原因对它的指责我想应该都是使其不断、迅速更新升级的最根本的原因,如果各位都满嘴含着理解、他们有他们的困难,我想12306很可能也会陷入没有危机的危机之中,使其停滞不前,最终被人唾弃。

    不管怎样,楼主一番话点醒了很多做技术的人,不管什么情况,在没有深入了解问题之前,多数人都会有站着说话不腰疼、妄加批评指责的时候。但是文章结尾楼主提出的所谓解决方案有些华而不实、哗众取宠之嫌。

  • luoxi   2014/01/12

    我觉得可以修该售票时间,比如客流量比较大得路线可以提前售票,阶梯式得方法,这样对服务器得压力会有所缓解

  • 山木   2014/01/13

    长篇累牍说了这些,还是不能让老百姓买到车票

  • 后面应该是15+14+13+...+1=120

  • skylove   2014/01/13

    楼主前面写的,给人的感觉是用心在写。
    但是最后的前三条建议,确实是有些欠考虑了。

  • 对数学 几乎没什么了解的人写的文章。
    作者学过组合数学没有?

  • 不懂数学的人写出的文章。
    还以为是什么大牛

  • 楼主有些东西没有去考察。
    A、B、C三站 一趟火车。
    A站到B站没有票
    A站到C站确有票。
    你怎么解释?

    • Alex   2014/01/14

      这个很好解释呀,票的总量是不变的,变的只有线路.例如北京到广州的需求量大,那么就提前多分配,A到C,而不分配A到B.

  • NGE   2014/01/13

    还是关于库存

    我想到这样子的方法,17个站把一条线分成16段,每一段一个数字,初始全部等于列车座位数。
    比如有人买了一张从始发站到终点站的车票,那就这16个数分别减一呗。从第一个站坐到第三个站,前两个数减1。前两个数不能同时成功减1,就表明没位子了。

    •   2014/01/16

      这种减1的方式最终会导致有的乘客一次乘车要换多次座位……

  • 韩路   2014/01/13

    我是来看评论的

  • ls你还是开发抢票插件吧,能买到票回去才是王道

  • 野枫   2014/01/13

    抽签,那么大家就开始骂天朝了,什么基础建设不够,黑幕等等。。。矛头扔给12306,让网友骂,这是最好的办法了吧。

  • good luck   2014/01/14

    淘宝的技术难点在于大规模的数据存储,有点像大数据问题。而12306是高并发量的问题。两个不能直接比较!

  • raven   2014/01/14

    库存那里是这么算的?
    我想说的是你可以重新考虑下整个事情了

  • Kantianqi   2014/01/15

    不得不说,12306刚出来那会确实很多问题,要不是手头很多活,而且我们有贼心没贼胆,现在就是外挂黄牛赚翻了。不过今年感觉好多了,除了唯独今年抢不到卧铺票要去买95折机票外。相信国家对铁路总公司也是提出了政治要求,铁路公司也狠下功夫,好歹现在也是股份制公司。

    对于互联网正能量资讯的帖子表示支持和感谢!~

    • Edward Shen   2014/01/15

      作为一个从业十多年的工程师,我只能说楼主虽然是淘宝出来的,但技术实现太差了!他根本不知道秒杀应该怎么做,分库应该怎么做。他做不了不代表我们做不了。

      秒杀,很简单,就是一个内存队列,往里插入数据。10亿人坐火车,难道是坐同一班火车吗?一切分,一列车就几千张票,往内存队列里一插,有多大负载?

      至于10亿人拼命查询有无座位,也简单得很。每列车,每一类座位在内存中就是一个key。这个key还存在就是有座位。座位卖光了,或者排队的人达到票数了,就从map中删除。

      所有操作都是可以根据车次切分到不同服务器上的。所有操作都是在内存中处理的。所有操作都是异步的。有多大负载?每天就算1000亿次查询,分布到100台,1000台服务器,全内存操作,能有多大问题?

      网络也许会阻塞。解决起来也简单。 交换机可以对同一个ip大量快速访问直接拒绝连接。这样,使用软件抢票的不能访问。网站用户还是能正常访问。 交换机很多都有这样的防DDOS攻击的功能。不懂,去问华为,思科和Juniper.

      • Dr. ROY   2014/01/16

        10亿人坐火车,难道是坐同一班火车吗?一切分,一列车就几千张票,往内存队列里一插,有多大负载?
        所有操作都是可以根据车次切分到不同服务器上的。所有操作都是在内存中处理的。所有操作都是异步的。有多大负载?每天就算1000亿次查询,分布到100台,1000台服务器,全内存操作,能有多大问题?

        这个逻辑是没错,但是“每天就算1000亿次查询”这个描述不准确。假设我想买郑州——广州的车票,所有郑州——广州的T字头列车都是9:00开卖,所有想买到广州车票的人都在9:00收着电脑刷。所以不是“每天xx次”查询,而是8:50——9:10期间就会有大量查询。
        “分布到100台,1000台服务器”这个如文中所说,12306可以去买1000台服务器来应付春运,那等到三月四月五月,服务器压力减小到100台服务器就可以满足运行需求,请问多余的900台拿来干嘛?
        虽然10亿人不是坐同一班火车,但是每个服务器也不可能只负责一列车的售票。一列车可能就1000张票,但是如果这个服务器需要负担10列车呢?内存队列总有一个上限吧?如果全用来处理卖票的业务,登陆、支付等业务怎么办?

        • Edward Shen   2014/01/21

          关于服务器的问题,第一,铁道部不差钱。 第二,如果考虑经济效益,春节期间可以去租借公有云的云主机。

          还有,有没有票的数据放在内存中,这个不需要持久化。 买票信息放在内存中,这个也不需要持久化。 这些数据都是临时放在内存中。

          真正处理买票事宜的,是后台异步的服务器。 后台服务器从内存服务器中依次获取订票信息,进行处理并更新数据库。

          那些内存服务器,处理每天10亿人同一时刻“秒杀”的信息,存入内存队列中。如每天10点10亿抢票信息进入。

          然后就是异步工作流处理的过程了。同1秒进入10亿信息。但我处理这10亿信息,可以1小时,10小时。 比如说,我可以向用户保证,你抢票后1小时内通知你订单是否提交成功。然后要求用户在24小时内付款。用户付款成功后,再进入后续处理。 完成后,再次通知用户订票成功。 所以,不管多大的流量,都是没有问题的。

          我的方案的核心就是两条:数据切片,内存,通过队列异步处理,通过工作流异步处理。

          • soul   2014/01/22

            抢票后一小时才知道抢没抢成?你开玩笑吧,用户会有这个耐性?
            顺带根据官方说法,铁道部春运亏钱的谢谢

  • 匿名   2014/01/15

    “目前的12306技术上是还有问题,比如,抢票高峰,输入个身份证号和图片验证码都卡得要死(本人亲测),服务器端繁忙,你浏览器端卡什么呀。"

    那是因为前台JS做的同步请求,没有使用异步请求加前台禁用相关按钮的方法,可能是为了避免你随便乱点造成过多请求之类吧。

  • For   2014/01/16

    说几点12306的功能,以管窥豹,看看和电商、淘宝的区别,当作头脑风暴

    1.同城:检索“北京”,则(北京、北京西、北京北、北京南)的车次信息和票额会出现,而同在“北京市”这个地理概念下的(黄村、石景山南、三家店、通州西、怀柔…)等却没有;相应的,检索“关林”,会得到在洛阳的其他几个车站的信息。
    2.限售和预留:试试T12/13的“沈阳—长沙”,说不定还有卧铺,而同一趟车,区间更短的“北京—长沙”,一张票也没有。某度据此,最近出了个“跨站购票”。“始发跨站”和“终到跨站”,或者始发终到都跨站,这个方法,送给部分买不到票的朋友。顺便说,这种限制也是会随时调整的。
    3.车次:同一趟车T12/13为什么要变换车次,还可以看看K804/805福州—重庆北,车次变换了几次。为这个对购票者无关紧要的功能,随便加个特殊处理,检索效率都要下降不少。
    4.价格:“新空快速”等级的硬座票,北京西—石家庄:43.5;石家庄—郑州:62.5。 那北京西—郑州呢?93。递远递减,票价和路程相关,有的路段执行统一价格,有的路段基础运价有上浮,还有学生票、孩票等折扣,具体怎么算的不清楚。
    5.窗口:窗口的功能更变态,不信去检索那张“东方红—太阳升”的票,通票和中转的问题更加复杂。当然,这是极少数,但是窗口和12306用的是一样的票池资源,两者基本功能要兼容。

    仅这几条乱七八糟的奇葩功能,在检索和出票的时候都要考虑进处理逻辑和数据结构,还要保证绝对的实时性。能把这几点做清楚,仅仅在代码层面就不简单。

    当然,之前爆出的后台安全问题,以及糟糕的前端和过程体验,是12306明显的短板。去年抢票插件都能把google拖慢,现在要接入公安的身份验证,可能很快会有公安系统垮掉的新闻。

  •   2014/01/16

    感觉12306的票是提前分配好的,同一时间同一车次,中间的段都买不到票了,始发站到终点站的却有很多余票……

  • 市场供求才是主要问题,买不到票,没地方发泄就只能喷网站,人之常情

  • athlon   2014/01/21

    后端难度有多大,不是很容易估计。但是网站前端的质量差到了极点:奇丑无比的页面,大部分浏览器不兼容,还有奇怪的网站证书。可以看出12306的前端开发团队极其业余,可以说根本就是外行。

    对于一个不差钱的项目,找一群菜鸟来开发前端,甚至整个团队没有一个人能对前端质量负责,可以想像这是什么样的项目机制。

  • 也许基于中心化的思路本身就是做的,无所谓好不好了。

  • Charlie   2014/01/23

    大家讨论从前端到后端、从软件到硬件、从数据库设计到项目架构,其实在我看来。最主要的问题还是在于私企的研发和国企的研发有质的区别,从人员技术、项目管理、企业文化等各方面,才是影响项目周期和项目质量的关键点。

  • 既然淘宝有大量的闲置服务器, 12306完全可以考虑租用淘宝的服务器,不用自己再投入大量的资金去购买服务器。

  • HJ   2014/02/14

    用百度狗哥搜索答案也是社会工程学吧~~

    次裂变反应平均可以放出200MeV的能量所以1g纯的U235裂变产生的能量约可以使1Mw的功率发电一天。
    所以2克浓度为3%的U235可以发电为0.06x1000KWx24h=1.44x10^3KWh(度)电

    http://zhidao.baidu.com/link?url=9seagnH8HXXHmz6oltv_me5nMW0oa0wdpMMNKScdfmEbtj0me1T-MQuw4M9JIrM6UGhbc3XyaCqakVLiNANoYRF1M9wDLHhIeEI_5hTwwIm

  • lv   2015/01/09

    当然不能按站点存票数,画蛇添足,按站点索引就行,维护每一个站点的票池,每个票池让客户按先来后到的顺序排队,票池线程数量固定,用actor的模型控制并发访问,用数据库存储状态,选票和支付分离,不需要服务器维护状态,先到先得,妈妈再也不用担心服务器挂掉

  • kohen   2015/02/02

    系统做的再好,票不会增多。还是有会有这么多人买不到票的。

跳到底部
返回顶部