- 程序有所改变。发帖如还有问题请报告
- 【征集】西西河的经济学，及清流措施，需要主动参与者，『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【讨论】回应对12306.cn网站的技术质疑 -- 忘情
12306这个网站的流量和业务量是一种病态。问题的根源上是：火车票不足以满足所有人的出行需求，并且绝大部分人的需求在同一个时间段内都是刚性的。这样导致的结果是如果网站的处理能力足够的话票会在瞬间买完！这个是任何技术都无法解决的问题，就算能解决所需的代价就会让12306在平时成为一个奢侈品，受到其他“不明真相”者的另一番攻击。（好吧，这是我个人比较阴暗的判断）
嘿嘿，购票人进入了一个不太明显的囚徒困境。所有人都会第一时间抢票，任你预售时间多长都一样。因此12306的访问量集中在一个很小的时间点上。
解决这个问题应该是想办法让购票需求平摊开来，或者减少购票人的数量。同时从这两个方面下手效果应该不错。因此非技术解决方法是设计一个适合的交易模式，同时解决上面的两个问题。
如果让我紧急解决这个问题，我会暂时缩短网络的预售时间。一方面分流一部分人回到窗口买票，更重要的是减少预售时段覆盖的购票人群，减少网站不必要的查询请求。从数据上看12306瞬间访问量是很大，但是其中的水分在于这些访问量有很大一部分是重复的无效流量，是因为得不到所需回应时用户被迫的刷新。
当然了，这是一个馊主意，根本的解决方法是让所有人都不用担心买不到票。这又不是铁路一家的事情了。
你从北京到广州，沿途有多少站？各站都有人要上车，要买票，而沿途各站上来的旅客不一定都要求坐到终点，许多是中途下的。如果按目的城市分，得分出多少流来？如果还分为绿皮车，硬卧等，又得多加几倍。系统里还必须区分复用票。就是比如说这车从北京开到广州，中途在武汉有个空位，有人买了从武汉到长沙，那么到长沙后此人下车，这个位置又空出来了，系统得识别统计出来，从长沙站又得重复利用这个座位，这个数据量，工作量得有多大？你觉得现实吗？
比方12306就一个web portal你用户的登录地是山东的IP地址，就直接跳到山东的CDN进行就近处理。后台业务服务器采用多主-多备的形式，数据同步考虑到多CDN采用异步冗余，如果单点（某省CDN）访问有问题，切换到其他CDN访问，主CDN（按中国华中，华北，华南，西南）主要提供数据异步同步和CDN访问控制、切换访问等能力，考虑到平常访问量不大，做capacity planning 时和网通，电信机房采用他们ISP的云方案（弹性扩展）一应付节假日周期的高额访问量，当然演练是必不可少。前端做好大流量清洗设备的配置，如果发现访问过大来自于同个IP，在队列中自动将其踢出。
那个公司能把spanner搞定就很了不起了，另外--spanner解决的是数据库层面多数据库中心同步数据问题，在高并发上并没看出太厉害，前面的whyshanghai给出点论据好么--最近看了上海EMC研究院颜开的分析，也看了下bigtable和spanner相关论文，数据挖掘方面可能用的多？
网站技术我不懂，不过这不妨碍我去理解12306的问题，河里有很多网络高手，不过我觉得，诸位提出的解决办法只是在有限的票务分配上做文章，只是尽可能的让车票分配相对公平些，其实问题还是没解决。
spanner和ibm的那个不去说它，反正12306也不可能用。exadata看起来不错，data sheet和一些客户的应用实例已经达到十亿交易+/日级别的规模了，看起来似乎可以应付12306。不过上了exadata您可别嫌贵，一个X2.2的full rack的数据库和存储就得$3m，这还只是硬件和支持费用，估计再加乱七八糟其他费用，一个数据库得起码$4m，如果再加实施费用就得更多了。还不知道这玩意儿美国卖不卖给中国。不过话说回来，根据这个看起来这次升级要了2个亿￥好像也太过分了些，嘿嘿。。。
不过还是得考虑前端的web构架和动态查询订票程序的构架，这也得应付得了这么大规模的访问量才行。
花之。
希望这个合理化建议能够被忘情反映到铁道部。
首先指出一个明显弄错的地方“腾讯自称自己的最高日访问量是1.6个亿”。其实是腾讯的最高同时在线人数超过了一亿，最高日访问量必然比这个高1、2个数量级。否则，人均每天才访问一次，岂不荒唐？这个请忘情自己上网核实吧。
其次，这个明显是一个没有大规模数据处理经验（更别说超大规模）的软件专家。这种专家是啥都敢说敢干的（包括12306.cn）。
不过人家开始就是承认“本人有限的经验和了解”，不可过责。
如果忘情有点影响力的话，请铁道部联系腾讯、华为、淘宝、百度等公司会诊，保证能很快解决12306.cn的问题。
其实18个亿的点击中，真正卖出的票数，有百分之一吗？反正我是点了几百次才能买到一张票的。也就是说每天售出的火车票，可能也就几百万张而已。关键的数据处理量根本就不算太大。
这个工作，对有超大规模数据处理经验的公司并不困难，它们是从几千访问一步步做到几亿访问获得的经验。
但对没足够经验的，难如上青天！
这次大概哪个头头又以为升级了，万事大吉了，大家再同时起跑
我倒是觉得按始发站更合理，按发车时间的话，我要某天回家，那这一天啥事儿也干不了，隔几个小时抢一次票。虽然按始发站这情况，也得时时刷屏看有没有能捡漏的，似乎差不多，但我觉得还是始发站方式比较好，不是说有专用浏览器有余票自动提醒么，那至少还能做点别的。就是始发站别在弄得北京站和北京南站在两个时间点开始售票了，购票人挺难受的，但站在技术人员的角度，还真就该分开，两难呀
12天后购票人才去乘车，为什么要赶在购票人点鼠标后的几分钟内告诉他结果？
其实完全可以做到和奥运购票一样的，提前N天收集需求，提前M天按需求随机分配返回结果，提前X天付票款即可（N>M>X);区别其实仅仅在于，当时反馈结果拼的是机器、网速、运气；延时反馈结果仅仅拼运气而已
比如：提前12天收集需求（这个时间还可以更短，比如12小时），提前11天反馈结果买到没有（这个时间其实可以在收集需求结束后几个小时就行，理论上这种计算很快，比如2小时可以做完，完全可以把规矩定为8小时后全部反馈，甚至可以一个车次一个车次反馈），提前10天付款；如果订到了没付款再打回窗口售票（网络当然也可以，就是麻烦些）
挨骂当然是必然的，正如忘情所言，需求大于供给，总有人会买不到票，总有人会骂。说起来我这种方式和北京购车抽签方式其实也是一样的，只要有了大家认可的规则，骂声其实还小些
本帖一共被 2 帖 引用 (帖内工具实现)
他做软件，在业内就是笑话，不知道是否又外包了，估计不敢。
送花成功。恭喜：你意外获得 8 铢钱。1通宝=16铢
作者，声望:1；铢钱:0。你，乐善:1；铢钱:7。本帖花:1