主题：【原创】身为码农，为12306说两句公道话 -- 代码狗

好文，花之！忍不住想要吐槽一下，我5号和6号分别在抢24号和25号徐州到广元的票，下午四点开始发售。5号那天放票的时候显示有6张卧铺，等我输完验证码，系统显示没有啦。不死心，坚持刷票刷到晚上8点多钟，除了零星放出的站票，其他的啥都没有。6号早上8点钟开始继续刷，刷到下午还是没刷到。等到下午四点开始放25号的票，再抢，抢到了一张硬座。抢了两天的票，5秒钟刷一次，连电脑都不敢离开，上洗手间都是一路小跑，生怕错过了（事实上是我想得太多）。那感觉真是一个累啊，身心俱疲！

铁路系统任重道远，一直都是中国的交通基干网络

牵一发而动全身

问问为啥北京的车牌不搞拍卖？

你就明白了，除非TG下台，墙倒了

今年网页版卡的不行，抢了几天毛都没捡到一根，没办法只好买了高铁票迂回回家。

好在别人推荐了个抢票APP，不错，顺利抢到了好几张想要的票。然后又退前面的票，这样不停买了退退了买肯定增加很多工作量。

我感觉每年12306情况都不一样，所以要多试，多抢几天各种方法都试一下就心里有数了。

其实都还好，就比速度么，淘宝秒杀的时候多练练就行。。。大家嚷嚷估计还是瞬间抢票的感受有点太刺激了，而且往往你忙活好几天啥都抢不到就会很烦躁。其实也没看哪个一心要回家过年的人最后回不去啊，总有办法的。

这个问题不错，是个懂技术的，但是基于的是对主流数据库的理解。

在商业数据库中，是有死锁的概念的，所以有回滚。但是并不会造成都把票减1。所以如果是商业数据库，你指出的是对的。

但在TAOBAO版的MYSQL中，为了使速度加快，就把这些措施都去掉了，这样在压力大的时候，就会出现LZ说的情况。这种做法在压力不大的时候也会出错，所以说TAOBAO技术如何如何，有点过头了。

可能TAOBAO也意识问题，自己写的OCEANBASE，把读写分开，专门有UPDATESERVER，都是些外行的想法。但应付TAOBAO的多读少写的场景应该有用。

春运太变态，长途都指望铁路，怎么改也不能完全满足需要。

总会有人买不到票。

12306无论如何改，只能尽量保证买票的机会尽量公平，避免暗箱操作。

抢票软件就是破坏这种规则，应该和游戏外挂或者黑客攻击差不多了吧？

更正一下，正明现在是高级研究员，相当于副总裁；和菲青是一个级别的。

其实12306的问题很简单，不过原因不能说，呵呵。

没这么恐怖吧

1.加强改革团体票预售，提前一个月做预售登记，购票团体必须是在当地连续三年有纳税记录的企业单位或登记有三年以上的事业单位。购票团体需提交购票人身份电话等信息且不能做更改。团体票持有人如果发生退票，钱款将无法退回，扣除15%手续费外，余款只能用于该身份证名下二次购票。火车票分两部分落实，登车日提前3天给确认短信，如果这个时候退票，就是按上面办法退，如果这个时候不表示退票，以后就无法退票，只能作废，第二步是用一个类似二维码的形式在开车前2小时发送到登记的手机上，凭这个在火车站打印车票或者直接检票上车。这样就很难将预定票再次倒卖。这样基本可以确保部分企事业单位有明确回家安排的人不用参与网上及窗口排队购票。根据我的了解，这部分人还是占春节回家人流的很大一部分。

其次，网络售票分时间放票，同天同次车不能在最远购票日一次性放出来，适合每天3-4个时段，分3-4天陆续放出来，这样会给购票人做出更理智抢票安排。相对分流一下抢同一班次的流量及针对退票等情况有更合理放票量。

第三，春运车次安排上我觉得取消软卧，减少硬卧，严格控制无座票发售，随着火车提速，其实大部分回家车次在48小时内都可以到，所以只要不是那种站满人的车厢，硬座回家并非非常艰难。

第四，部分高运量高铁可以考虑改变现有座椅，弄成条凳型，一排坐6个，降低票价，提高运力。这条貌似有难度。呵呵。

原本猜测是TAOBAO版本的MYSQL因为瘦身而出错，没想到是瘦身也不够，还要加内存数据库加速。

一言以蔽之，原来TAOBAO比我想的还要外行。

看网上有人说了12306的最终方案是全部都是内存数据库，这样就足够快了，比TAOBAO的方案更激进。

打个比方吧，在OS里有经典的缺页中断，利用少的内存和好的算法，可以让大多数的计算在内存中进行。内存数据库好比内存，MYSQL好比硬盘，TAOBAO就是这样提升了效率，这也是没有自己的数据库的悲哀。这样做当然就造成了内外不同步，在正常的情况下都有错误产生，如果垮掉，内存的数据就全完了。好吧，TAOBAO都是小买卖，出错也无所谓。

那么12306呢？出错就有所谓了，

可12306居然直接不用硬盘，全放内存里。如果垮掉，就是灾难性后果。估计是铁道部，被大家逼急了，先过关再说。

说到底这些问题都是因为没有掌握核心技术，而搞的外围手段。好处是见效快，坏处是风险太大了。

收到有同行质疑136个库存的合理性，他提出的方案是：

如果出一张01号站到17号站的票，就把SKU01/SKU02....SKU16这16个SKU的库存都减一。

这种做法是可以运行的。我原来参与设计的一个ERP系统就是这样的做的。

16个商品方案的优点是商品数会比较少，缺点在于查询性能较低，要查询16次才能知道【北京西到深圳北】还有没有余票。而136个商品的设计，穷举了所有出发和到达站点的组合，出票前只需要查询1次库存就知道还有没有余票。

大部分面向公众的网站，其业务特点都是读多写少。电商系统的库存查询次数更是远远多于库存修改次数的。在秒杀系统中，可能会出现99%的请求查库存1%请求改库存的情况。

像12306春运抢票这种场景，在秒杀工具（抢票软件）的推波助澜下，查询1万次库存才成功出一张票也不是没有可能。

还有人说，KFC的食品可以单卖，也可以套餐，为什么没像我一样搞出这么多SKU，那是因为，KFC门店的人肉查询频率非常低，没有必要为了优化查询性能把库存结构设计成那样。KFC网上订餐比门店的查询压力大一点，但只要不是像12306那样全站商品都秒杀，也是不需要为了优化查询性能把库存结构设计成那样的。

站能发多少KW的电”了

俺得COPY一下答复，说不定以后抢票能用上

1、把火车票的价格提升一倍，平时疯狂打折，在旺季就恢复原价；

2、多找几个携程这样的分销商，把压力往分销商身上排。

其实我举起双手赞成这样做，高于平时票价的盈余部分用于铁路基建。可是，在我们每时每刻都讲究政治正确的国度，这个方案有实行的一天吗？

因为某些软件公司违法，如果不打击这样的违法，将大大增加系统成本。

研发抢票软件属于恶性竞争，罚一罚就好了。