官方订票网站12306崩溃时的页面（资料图）
1月11日起，12306网站开始销售除夕当日火车票。每到此时，铁路系统唯一的官方购票网站12306就会成为众矢之的。今年也不例外，12306再次被淹没在一片埋怨声中。
1月5日，观察者网刊登了问答网站“知乎”上的用户王强的解答，回答“如果把12306外包给IBM或者阿里巴巴来做的话，能不能比现在做得好？”这一问题。
1月10日，一位ID名为“代码狗”的前淘宝工程师，后来在一家电商公司做技术副总的IT业内人士也在著名论坛“西西河”上发文，表达了他自己对12306系统的看法。
值得注意的是，“代码狗”在12306系统刚上线时也有过不少微词。为了证明12306系统很容易搭建，“代码狗”甚至曾经发起过一个名为“替12306设计系统”的开源项目。通过工作中的实践，“代码狗”对于12306系统也有了新的认识。
观察者网转载此文，供读者参考。
全文如下：
【原创】身为码农，为12306说两句公道话
作者：代码狗，时间：2014-01-10 01:36:31，发表于：西西河
（提示：作者后来重新修改、更新过本文，修正了一些错误，以下为修改过的新版！）
我曾在淘宝写过一段时间代码，2012年在一家百强民企做电商副总，当时在极为艰苦的条件下带队开发了一个B2C网站，走支付宝和银联支付通道，年营业额千万级（当然实在太少了，我只是说这个网站投入了实际的运营）。
也就在那个时候，我对12306嗤之以鼻，觉得他们做得太烂了，认为自己能带队花几百万半年时间做个好的出来。于是我狂妄地想做一个开源的订票系统给他们。我花了一个星期时间思考建立数据模型，思考到库存这一步的时候，我才发现，12306的库存复杂性比淘宝、京东高很多倍，运算量也大很多倍。传统的分布式数据库、缓存、负载均衡技术并不能恰好满足12306的需求。
在平时，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在大亚湾核电站能发多少度电】，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在大亚湾核电站能发多少度电】。
以上讨论只是把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张票
这个办法可以打击黄牛囤票再转卖
运行一段时间后，按账户余额弄个排行榜就知道谁是黄牛了
可惜这个需要车站设备改造配合。
-----更新-----
收到有同行质疑136个库存的合理性，他提出的方案是：
北京西（01号站）到深圳北（17号站）一共设置16个商品（SKU）：
SKU01：01号站 到 02号站
SKU02：02号站 到 03号站
...
SKU16：16号站 到 17号站
如果出一张01号站到17号站的票，就把SKU01/SKU02....SKU16这16个SKU的库存都减一。
这种做法是可以运行的。我原来参与设计的一个ERP系统就是这样的做的。
16个商品方案的优点是商品数会比较少，缺点在于查询性能较低，要查询16次才能知道【北京西到深圳北】还有没有余票。而136个商品的设计，穷举了所有出发和到达站点的组合，出票前只需要查询1次库存就知道还有没有余票。
大部分面向公众的网站，其业务特点都是读多写少。电商系统的库存查询次数更是远远多于库存修改次数的。在秒杀系统中，可能会出现99%的请求查库存1%请求改库存的情况。 像12306春运抢票这种场景，在秒杀工具（抢票软件）的推波助澜下，查询1万次库存才成功出一张票也不是没有可能。
还有人说，KFC的食品可以单卖，也可以套餐，为什么没像我一样搞出这么多SKU，那是因为，KFC门店的人肉查询频率非常低，没有必要为了优化查询性能把库存结构设计成那样。
（提示：由于作者后来重新修改、更新过本文，上边的是更新过的新版，以下为没有修改过的原版内容）
本人淘宝技术专家，2012年在一家百强民企做电商副总，当时在极为艰苦的条件下带队开发了一个B2C（企业针对个人开展的电子商务活动——观察者网注）网站，走支付宝和银联支付通道，年营业额千万级（作者注：当然实在太少了，我只是说这个网站投入了实际的运营）。
也就在那个时候，我对12306嗤之以鼻，觉得他们做得太烂了，认为自己能带队花几百万半年时间做个好的出来。于是我狂妄地想做一个开源的订票系统给他们。我花了一个星期时间思考建立数据模型，思考到库存这一步的时候，我才发现，12306的库存复杂性比淘宝、京东高很多倍，运算量也大很多倍。传统的分布式数据库、缓存、负载均衡技术并不能恰好满足12306的需求。
在平时，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万亿。
淘宝拥有各种自主研发团队：服务器、交换机（网上可以搜索到淘宝公开的绿色服务器开放标准）；操作系统（LinuxKerneltaobao版，yunos手机操作系统是阿里云的，暂时不计入）、Web服务器（Tengine）、Java语言虚拟机（JVMtaobao版）、数据库（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秒杀iPhone5S就不一定，有人可能网银有问题，有人可能改变主意不想要了），所以就又带来订单取消重新恢复库存的问题。还有想要的消费者们，会认为还有机会，继续在前台刷一会儿，最终这个秒杀会被热情的消费者们猛刷30秒到1分钟。
一分钟过去了，服务器终于可以喘口气了吧？等等，还有超卖，原来，某两台服务器在同一毫秒都拿到了锁，都去减了库存，15000个库存，被下了15500个订单，又得取消一部分订单。。。如果采用单线程独占锁，是可以做到同时只有一个服务器线程减库存的，但那样就对并发高峰的能力就差了好多了。8万人举着钱，可能只有8个人能下单成功，这个拥挤狂热的抢购就要持续10分钟以上。平时秒个天猫魔盒，10分钟也就10分钟吧，双十一就惨了，收银台一下子减少了90%，还想做到350亿，要么做梦，要么再加10倍服务器和带宽。所以，商业是不完美的，要在绝对正确和绝对的快速之间做个取舍，保证相对快速又极为正确，允许一定的库存错误和超卖（具体允许多少我也不知道）。
好了，讲了这半天淘宝，可以说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年春运的时候，技术已经不再是一票难求的主要问题。在铁路运力不可能神速增加的情况下，要做到春运更公平地买票，需要停靠政策调整。
下文针对的是春节国庆这种非常暑期。其它时期，大部分线路保持现状就行了，问题不大，极少部分票源紧张的线路可以按春运处理：
1、拍卖法，价高者得之
当硬座票拍出飞机票价格的时候，相信票就不难买了（可惜就是贵了），也没有那么多黄牛了。要说淘宝有什么能帮12306一下子搞定技术问题的，淘宝的拍卖系统可以帮忙，浙江省高院在淘宝拍卖一年多，成交26亿。
可惜这个方法不可能实行。现在的高铁票价都被媒体和意见领袖喷成啥样了，何况是拍卖。再说，火车票毕竟是生存之刚需，票价20年来不涨本来就有照顾补贴的成分在里面，全拍卖可能也是不妥当。
2、抽签法，运气好者得之
开车前2个月开放报名，开车前7天抽签，中途可取消。预存票款，抽不中退款。上传身份证和正脸自拍照，机器核对。
这样的话，拦截黄牛的成功率就高很多了，黄牛可以预存票款，可以找到大量真实身份证号，你黄牛再让每个给你身份证号的人把身份证照片和脸部自拍也给你试试？即使有人真想找黄牛，给身份证照片还是会犹豫一下吧。而且中间手工操作多了很多，黄牛成本提高，还不一定搞得到票。反正都是碰运气，我想真正的消费者还是会选择自己先去碰运气吧。
这个方法实施难度也大，无论怎么设计抽签规则，必然有人大叫“有黑幕，不要相信政府”。
开车前7天出抽签结果，改变行程的人应该在7天前就能决定改还是不改了。没抽到的也还有时间想别的办法。当然不一定是7天，15天，10天也可以，具体几天要有数据模型来算。
3、拍卖+抽签
软卧、高铁商务座等高价位的，拍卖，反正买这个的是经济能力相对较强的。那就拼谁经济能力更强吧。
硬座、站票抽签。
4、凭身份证进站，车票跟发票一样，是报销凭证，不是进站凭证；退票后钱进入12306账户，不可提现，只可该乘客下次乘车用；黄金周期间，个人账号最多订购10张票
这个办法可以打击黄牛囤票再转卖；运行一段时间后，按账户余额弄个排行榜就知道谁是黄牛，可惜这个需要车站设备改造配合。
参考资料：
前淘宝工程师发帖谈12306：曾嗤之以鼻 现在认为几乎是奇迹
相关内容：
各类吐槽：
西西河原帖吐槽：
紫色月亮 趋加追订 2014-01-10 03:47:02
忒专业了，好好学习。1
西西河牛人层出不穷，算为12306正名了。
从一普通百姓的使用经验和感觉，12306还可以了。
大胖子 趋加追订 2014-01-10 04:16:17
大胖子沙发
写的真好
szxy 趋加追订 2014-01-10 05:49:21
其实库存可以不必那么复杂
纸板票时代还不是预先划好了票额？还是抽签最省事，刷票、排队都是做无用功，负和游戏。
坚持的阿甘 趋加追订 2014-01-10 06:57:34
12306的宝
送花成功。感谢：作者获得通宝一枚。
吹西门的雪，2014-01-10 07:55:39
这篇技术上值得商榷8
硬伤比较多了。今天实在太忙。过两天写个详细的回应吧。
12306这样的网站的确难做，但是你说的东西里面错误太多了。最明显的，从文中可以看出来对distributed transactional的东西错误理解。首先：
还有超卖，原来，某两台服务器在同一毫秒都拿到了锁，都去减了库存，15000个库存，被下了15500个订单，又得取消一部分订单。。。如果采用单线程独占锁，是可以做到同时只有一个服务器线程减库存的，但那样就对并发高峰的能力就差了好多了。
SQL database如果不是设计失误，是不可能出现“同时都拿到锁”的情况的，这和单线程独占不独占关系不大。
冲着认真的写贴，先花你。
最后于2014-01-10 08:13:31改,共2次;
不远攸高 趋加追订 2014-01-10 07:58:30
高价票拍卖的方式超赞呀
抽签法我也想到了，也觉得ZF公信力是最大的挑战
青菜鱼 趋加追订 2014-01-10 08:04:57
其实看着有些晕
虽然每个字都认识，但是连在一起看着好复杂。
米爹，2014-01-10 09:19:11
好文。技术小白虽然不明觉厉，但多出主意总没坏处1
其实目前技术上来说，精准营销应该可以分担12306的一些压力。每年春运流动的主体仍然是民工和学生，这两块细分市场其实完全不必通过12306走票。
学生由学校提前登记安排购票，这应该是长久以来的惯例，不知现在有没有变化。
民工稍微麻烦些，但现在实名制之后，也有解决可能。铁道部可以对数据进行整理，然后与地方政府合作，提前对本地出门打工的人群发短信征求购票意向，然后根据需求安排出票（比如根据历史记录，优先销售给那些老客户）。京沪穗等出行大站就可以把更多精力放在临时客流和客运组织上。
只是一种没有数据支撑的设想。请专业人士拍砖。
三力思，2014-01-10 15:14:11
超卖其实问题不大,因为你可以限制登车一小时前网上停售车票
剩余票数就都只有窗口有售, 这就给你至少10%的预量操作. 窗口一小时用电话抽奖,内部消耗,卖掉剩余10%的票问题不大. 铁路没有必须有100%入座率的必要. 一趟800座的列车有十几个座位空着, 铁路也不至于破产. 一万个人抢800张票的当然是秒杀. 购票系统的变态就是, 特定时间段, 会出现所有商品一上线就都是秒杀的情况. 这个用户体验是作不好的. 不如未开票前,直接告诉用户,同车次已经有多少人在排队, 降低用户期望值更好一点. 秒杀相比排队抽奖其实区别不大. 限定三秒内挤上和中奖其实都是运气.
最后于2014-01-10 15:30:36改,共1次;
敲门，2014-01-10 21:01:58
我猜他隐含的技术背景是去IOE2
IBM ORACLE EMC
分别对应小型机，数据库，存储
淘宝这样规模的设施，这三个都是瓶颈，淘宝内部开源项目很多，都是为了解决这种场景的应用。
这里并非是数据库设计失误，而是在处理速度和数据精确上做了妥协，优选了速度，事后纠正，所以会出现所谓的超卖。
当然大大的投资设备，可以不必如此设计。最好的设计是适合的设计，而非教科书式的“正确”设计，他描述的问题可以在业务层面解决，你指出的瑕疵对他来说不是问题。
火车票是否有这样的业务概念，不得而知，铁路是否能接受这种，需要和客户沟通才知道。
我们只是在外面摸象，内部限于工作需要也不会在外面说。内部资料说的越多，给别人参考的就越多，比如奥巴马同学的网站，呵呵。
在真实的业务应用规模上，中国铁路，淘宝，还要....，确实是世界第一，过去的国外IT供应商，也是蛋疼。
胡一刀 趋加追订 2014-01-10 21:55:08
可气的是老有抢票软件横行，计算机图像识别如此先进了么？
整点儿斑点啥的都挡不住了
代码狗，2014-01-10 22:17:28
锁的描述确实不对13
文章基本是按科普的笔法来写的（例如用绑钱的竹竿比喻抢票插件），意在帮助非技术人员理解12306的复杂。但也有一些不恰当的描述，比如超卖的问题，其实不是两个线程同时拿到了锁。
是因为淘宝的秒杀，查库存在Tair（类似memcached）里，减库存在MySQL里。下单的程序要先更新MySQL，再更新Tair里的库存数（如果Tair保证不down机，就可以先更新Tair再更新DB了，甚至全部在Tair里），这两个操作不是原子的，也不能做成DB事务（因为超出了DB的范围，再考虑分布式DB中间层，读写分离的Proxy），所以在更新数据库和Tair缓存之间那一瞬间，就有可能超卖。
如果没有MySQL，全都在Tair里操作，是不会超卖的，也可保证较好的性能。如果全在MySQL里，MySQL自己的锁会保证事务的原子性，但性能就差不少了。12306应该是全在内存DB里读写库存的，应该不存在超卖的问题。
感谢批评指正，我也只是曾经在淘宝写过几天代码，技术不行，只是比同事更善于写科普文章一些。
通宝推：敲门,
三力思 趋加追订 2014-01-10 22:24:42
要是图像识别是唯一的瓶颈的话
用数据库一键填表的宏，一个人也能以2秒一份的速度抢票。正常手填是根本没机会的。
奶嘴老仙 趋加追订 2014-01-11 00:52:17
尺有所短，代码网友的关键的库存表示方法太笨重了。
可以有更好的库存表示方法，请代码网友先自己思考一下。
有空大家交流心得。
代码网友比大多数讨论12306的朋友水平高得多。
不明觉厉！
好文，花之！忍不住想要吐槽一下，我5号和6号分别在抢24号和25号徐州到广元的票，下午四点开始发售。5号那天放票的时候显示有6张卧铺，等我输完验证码，系统显示没有啦。不死心，坚持刷票刷到晚上8点多钟，除了零星放出的站票，其他的啥都没有。6号早上8点钟开始继续刷，刷到下午还是没刷到。等到下午四点开始放25号的票，再抢，抢到了一张硬座。抢了两天的票，5秒钟刷一次，连电脑都不敢离开，上洗手间都是一路小跑，生怕错过了（事实上是我想得太多）。那感觉真是一个累啊，身心俱疲！
关键词(Tags): 吐槽，抢票，累，
土拨鼠yuanap，2014-01-11 02:23:28
乃不怕铁总被口水淹死吗？
铁路系统任重道远，一直都是中国的交通基干网络
牵一发而动全身
问问为啥北京的车牌不搞拍卖？
你就明白了，除非TG下台，墙倒了
春天的小鱼，2014-01-11 04:32:25
今年感觉手机抢票比较快1
今年网页版卡的不行，抢了几天毛都没捡到一根，没办法只好买了高铁票迂回回家。
好在别人推荐了个抢票APP，不错，顺利抢到了好几张想要的票。然后又退前面的票，这样不停买了退退了买肯定增加很多工作量。
我感觉每年12306情况都不一样，所以要多试，多抢几天各种方法都试一下就心里有数了。
其实都还好，就比速度么，淘宝秒杀的时候多练练就行。。。大家嚷嚷估计还是瞬间抢票的感受有点太刺激了，而且往往你忙活好几天啥都抢不到就会很烦躁。其实也没看哪个一心要回家过年的人最后回不去啊，总有办法的。
whyshanghai，2014-01-11 05:00:06
这个问题不错2
这个问题不错，是个懂技术的，但是基于的是对主流数据库的理解。
在商业数据库中，是有死锁的概念的，所以有回滚。但是并不会造成都把票减1。所以如果是商业数据库，你指出的是对的。
但在TAOBAO版的MYSQL中，为了使速度加快，就把这些措施都去掉了，这样在压力大的时候，就会出现LZ说的情况。这种做法在压力不大的时候也会出错，所以说TAOBAO技术如何如何，有点过头了。
可能TAOBAO也意识问题，自己写的OCEANBASE，把读写分开，专门有UPDATESERVER，都是些外行的想法。但应付TAOBAO的多读少写的场景应该有用。
土八路，2014-01-11 05:46:36
归根结底，还是运力不足2
春运太变态，长途都指望铁路，怎么改也不能完全满足需要。
总会有人买不到票。
12306无论如何改，只能尽量保证买票的机会尽量公平，避免暗箱操作。
抢票软件就是破坏这种规则，应该和游戏外挂或者黑客攻击差不多了吧？
季侯 趋加追订 2014-01-11 06:50:46
作为正明的d出来冒个泡，，，
更正一下，正明现在是高级研究员，相当于副总裁；和菲青是一个级别的。
其实12306的问题很简单，不过原因不能说，呵呵。
奶嘴老仙 趋加追订 2014-01-11 07:36:57
这个d是啥意思，不是
奶嘴老仙 趋加追订 2014-01-11 07:42:09
id的意思？
没这么恐怖吧
天涯浪子，2014-01-11 08:28:44
对于春运火车票销售我有些想法供大家参考3
1.加强改革团体票预售，提前一个月做预售登记，购票团体必须是在当地连续三年有纳税记录的企业单位或登记有三年以上的事业单位。购票团体需提交购票人身份电话等信息且不能做更改。团体票持有人如果发生退票，钱款将无法退回，扣除15%手续费外，余款只能用于该身份证名下二次购票。火车票分两部分落实，登车日提前3天给确认短信，如果这个时候退票，就是按上面办法退，如果这个时候不表示退票，以后就无法退票，只能作废，第二步是用一个类似二维码的形式在开车前2小时发送到登记的手机上，凭这个在火车站打印车票或者直接检票上车。这样就很难将预定票再次倒卖。这样基本可以确保部分企事业单位有明确回家安排的人不用参与网上及窗口排队购票。根据我的了解，这部分人还是占春节回家人流的很大一部分。
其次，网络售票分时间放票，同天同次车不能在最远购票日一次性放出来，适合每天3-4个时段，分3-4天陆续放出来，这样会给购票人做出更理智抢票安排。相对分流一下抢同一班次的流量及针对退票等情况有更合理放票量。
第三，春运车次安排上我觉得取消软卧，减少硬卧，严格控制无座票发售，随着火车提速，其实大部分回家车次在48小时内都可以到，所以只要不是那种站满人的车厢，硬座回家并非非常艰难。
第四，部分高运量高铁可以考虑改变现有座椅，弄成条凳型，一排坐6个，降低票价，提高运力。这条貌似有难度。呵呵。
观察者网评论：
龙淼隐
谈春运的技术问题，工程师比一窍不通但偏偏好为人师的“无冕之王”们靠谱多了。到现在，媒体也只能呱噪开放市场和打破垄断等一些政治正确的口号。
祝强强
无聊而又笨笨的作者，是装傻吗？
38分钟前
abberican
billweng2小时前
这么说吧，这篇文章，还有另外一篇，要么是洗地，要么是作者在大规模集群或者高并发系统方面确实属于没入门的水平。
懂的自然懂，所以究竟为什么，我就不解释了。
如果没有最后六个字，也许还有人信信你，但有了最后六个字，你就是太傻必了
38分钟前
Alexandre20122012
中国铁路客票系统承受的春运压力应该是全球第一了。
45分钟前
阿牛
学习了！
56分钟前
健忘者
要实现一个12306，最少最少也是千万级别的硬件投入
58分钟前
带菜刀出门的诗人
1小时前
褐色海湾
billweng2小时前
这么说吧，这篇文章，还有另外一篇，要么是洗地，要么是作者在大规模集群或者高并发系统方面确实属于没入门的水平。
懂的自然懂，所以究竟为什么，我就不解释了。
哦，你真牛X！
1小时前
一生哈哈哈哈哈
billweng2小时前
外行果然是好骗啊 ............. ，这么说把，我从事技术工作 15 年以上吧，我知道研发人员最常用的一句假话就是 “这在技术上是不可实现的”，我知道，有些在技术上确实不可实现，但绝大多数时候，这不过是推卸责任的敷衍（在国企尤为常用）。如果我跟他说，实现不了，我就每个月扣你的工资，扣完你就给我卷铺盖滚蛋。那多半，这个技术问题是能解决的，而且能解决得很好。
即使是忽悠，别人好歹扯几个技术名词，而你的话除了吹牛逼就啥都没了。
2小时前
秦与汉唐
billweng2小时前
外行果然是好骗啊 ............. ，这么说把，我从事技术工作 15 年以上吧，我知道研发人员最常用的一句假话就是 “这在技术上是不可实现的”，我知道，有些在技术上确实不可实现，但绝大多数时候，这不过是推卸责任的敷衍（在国企尤为常用）。如果我跟他说，实现不了，我就每个月扣你的工资，扣完你就给我卷铺盖滚蛋。那多半，这个技术问题是能解决的，而且能解决得很好。
作者有说技术实现不了吗？成本呢？要不你也来写一个，专门发给该作者，如果是你确实厉害，我相信依该作者的品格，会承认你厉害向你学习，而不是会像你一样讥讥歪歪，废话大把。。再说12306不是在大进步吗？
2小时前
广博雅正梁簌溟
billweng2小时前
这么说吧，这篇文章，还有另外一篇，要么是洗地，要么是作者在大规模集群或者高并发系统方面确实属于没入门的水平。
懂的自然懂，所以究竟为什么，我就不解释了。
你懂，就赶紧上知乎上西西河去给他们拍砖，故弄玄虚太没意思了
秦与汉唐
billweng2小时前
外行果然是好骗啊 ............. ，这么说把，我从事技术工作 15 年以上吧，我知道研发人员最常用的一句假话就是 “这在技术上是不可实现的”，我知道，有些在技术上确实不可实现，但绝大多数时候，这不过是推卸责任的敷衍（在国企尤为常用）。如果我跟他说，实现不了，我就每个月扣你的工资，扣完你就给我卷铺盖滚蛋。那多半，这个技术问题是能解决的，而且能解决得很好。
作者有说技术实现不了吗？成本呢？要不你也来写一个，专门发给该作者，如果是你确实厉害，我相信依该作者的品格，会承认你厉害向你学习，而不是会像你一样讥讥歪歪，废话大把。。再说12306不是在大进步吗？
2小时前
广博雅正梁簌溟
billweng2小时前
这么说吧，这篇文章，还有另外一篇，要么是洗地，要么是作者在大规模集群或者高并发系统方面确实属于没入门的水平。
懂的自然懂，所以究竟为什么，我就不解释了。
你懂，就赶紧上知乎上西西河去给他们拍砖，故弄玄虚太没意思了
2小时前
碧海银剑
学习了，我还是太连清！
2小时前
唐少华TSH
易水菁华7小时前
作者，你这是有多爱大亚湾啊
还有1条评论
老家伙十一郎3小时前
少年，你觉得U235反应之后全部质量都转为能量了？
少年，你觉得U235反应之后全部质量都转为能量了？
2小时前
billweng
这么说吧，这篇文章，还有另外一篇，要么是洗地，要么是作者在大规模集群或者高并发系统方面确实属于没入门的水平。
懂的自然懂，所以究竟为什么，我就不解释了。
2小时前
billweng
外行果然是好骗啊 ............. ，这么说把，我从事技术工作 15 年以上吧，我知道研发人员最常用的一句假话就是 “这在技术上是不可实现的”，我知道，有些在技术上确实不可实现，但绝大多数时候，这不过是推卸责任的敷衍（在国企尤为常用）。如果我跟他说，实现不了，我就每个月扣你的工资，扣完你就给我卷铺盖滚蛋。那多半，这个技术问题是能解决的，而且能解决得很好。
2小时前
苦苦的湖水
我早就说了，美国五角大楼官方网站也顶不住中国的春运，比黑客还黑客。要人命的。
3小时前
老家伙十一郎
易水菁华7小时前
作者，你这是有多爱大亚湾啊
李莫白6小时前
质能方程呗，呵呵。这个在高中的物理中的知识就能解答。
少年，你觉得U235反应之后全部质量都转为能量了？
3小时前
mickeyme
完全认同。去年也曾笑话过12306，后来尝试构架数据库时，才发现问题比我们想象的要困难得多。特别是抢票这一环节，设计要考虑的因素太多。感觉专家的解读。完全支持！
3小时前
方建鹏
易水菁华7小时前
作者，你这是有多爱大亚湾啊
李莫白6小时前
质能方程呗，呵呵。这个在高中的物理中的知识就能解答。
文科生貌似没学过啊。。。还是忘了呢。。质量转成能量？
挡不住的深海
我还有一个办法，就是在12306上注册时必须同时注册手机号码，那么买票时就像淘宝一样给你注册的手机上发一个随机的验证码，输入验证码后台核实注册人和购票人的信息是否相符，然后在核准，票贩子就没招了！
3小时前
skyofstars
学习严谨的态度。
3小时前
黎明中2011
比较实事求是的态度。实际上自从美国的医保网站出问题，国内的公知们声音就小很多了。
4小时前
bst847
转载之！
4小时前
鹰击长空
本游戏行业从事人员可以很负责任的说，所谓抢票软件就是一种游戏外挂，基于按键精灵类的。本人早已深恶痛绝。
4小时前
ggg914097
还是有真正的明智者
4小时前
穿着围裙的稻草人
所以说经常自网上喷的一般就是文科生！！！理工科的还是比较理性些~~
5小时前
李莫白
易水菁华7小时前
作者，你这是有多爱大亚湾啊
质能方程呗，呵呵。这个在高中的物理中的知识就能解答。
6小时前
李莫白
以那个万邦为代表的文傻，啥都不懂就乱喷，说一些政治性正确的废话套话，还自我感觉良好，好像政治上正确了啥就解决了。文科生真可怕，以后坚决要反对文科生从事政治和国家管理，太不靠谱。
6小时前
见赜思玄
不错
6小时前
雷霆
这才是真正该给公知们看的
6小时前
Chemiholic
理性的声音
6小时前
稳健的平民
恶意抢票软件和人浪费的大量运算资源、造成了严重的社会成本支出。
6小时前
股神下凡
春节不必回家可真幸福
6小时前
非常一叶蓝
7小时前
御神木
总算有个理智、专业的声音冒出来了！
7小时前
龙淼隐
谈春运的技术问题，工程师比一窍不通但偏偏好为人师的“无冕之王”们靠谱多了。到现在，媒体也只能呱噪开放市场和打破垄断等一些政治正确的口号。
7小时前
易水菁华
作者，你这是有多爱大亚湾啊
7小时前
采莲西洲
不明觉厉。反正春节国庆最好不出门。
7小时前
2072
这思维能力俺羡慕
留言评论（旧系统）：