|
用SwiftUI写了一个iOS过早客，4M左右，已上线 |
12306的技术难点在哪儿？
十一回家火车票没有抢到，无奈蹭的同事顺风车回。感觉今年明显12306抢票难了，而且系统感觉也没那么快了。如果说访问量特别大的话，可每一辆车次都是分开的，甚至每一个座位都几乎是独立的，服务器分开不就行了。到底哪些方面是技术上实现比较困难的？
共收到21条回复
北京到广州一列车，有7个车厢，每个车厢118个座位，中间停12个站，给郑州，武汉分别预留150个位子，请问应该怎样设计数据表存储，达到性能最优？一个座位有N种可能余票，每卖出一个座位，每种可能的余票都要刷新，这计算量就不小了。
最大的难点是在放票时能支持全民抢票，不出错不超卖，还得3分钟内卖光，12306的并发量远超淘宝，后端并发解决好才是重点，用12306的人关心的是买上票，把自己的id写进数据库。
这个系统是铁科院电子所做的吧，之前得了国家科技进步一等奖。12306确实有些地方做的不够好，但这些年一直在改进，已经比当初好用很多了。至于抢不到票，这个锅不归12306背。1万人要回家，只有5000张票，12306系统再牛逼，也还是有5000人买不到票，12306变不出票来。
抢不到票的根本原因不在于系统好不好用，而是供需关系。
12306用户体验上做的太差，比如查询正晚点，每次要返回来差车次，并且不能保留历史记录。
复杂度N*N/2，假设有26个站，判断一个票是否可买，复杂度N*N/2大约是300。每次购票时Lock验证，依赖内存操作。
淘宝上判断商品是否可买，复杂度是1。 12306与淘宝在订单处理余货验证上复杂度300:1。
这就意味着如果一个系统支持1亿个并发用户在淘宝上并发买货，12306上只能支持30几万个用户并发买票。
对单一订单处理这一操作，理论情况大致这个样子。实际12306可做下优化，淘宝购物场景可能更复杂，不说300，几十倍的复杂度差异还是要有的。
以下一篇文章可以大致看下数据，行业标跑不了。数据库GemFire，10台服务器，2T内存，不知道什么攒法。
https://pivotal.io/big-data/case-study/scaling-online-sales-for-the-largest-railway-in-the-world-china-railway-corporation
12306确实一直在优化，现在可以选座了
greenplum
就说一个很简单的场景， 你买了一趟北京发往广州的你在武汉上车的火车票，刚付了款你又后悔了退票了，前几个站点和后几个站点的该座位的票得全部重新计算排序，难吗？
不谈算法，并发量就够喝一壶了
没啥技术难点，跟淘宝京东根本不是一个数量级的。所谓的并发量也是瞎忽悠，大部分都是查询，做个读写分离就是了。
12306本身的场景非常复杂，说没难点的是自己无知了……
最近优化的手段就是那个16T的内存数据库，用钱砸出来的优化。。有钱任性
说没难度的，基本是没做过大型并发critical系统的
说12306不背锅的人也是幼稚的可以，以前电话订不到K字头车票，还可以到火车站排队买高铁坐票。现在倒好，要跑到网上抢高铁站票。
凡是可以用钱堆出来的东西都是没难度的，12306很好的验证了这一点。那些一味说12306的太复杂的，也是人云亦云。
突然感觉穿越了
