我想买号从上海南站回到湖南益阳的车票，请问我什么时候才能在12306网站网上订到车票？具体时间_百度知道
我想买号从上海南站回到湖南益阳的车票，请问我什么时候才能在12306网站网上订到车票？具体时间
我想买号从上海南站回到湖南益阳的车票，请问我什么时候才能在12306网站网上订到车票？因为我不知道网站什么时候才开始放票，求购票高手帮忙
自日起：00起订最新一日的车票。上海南站15、电话订票预售期延长至20天（含当日），代售点和车站部分售票窗口预售期延长至18天（含当日），互联网
来自团队：
其他类似问题
为您推荐：
其他3条回答
12306最早提前10天预订·-2533可以提前1个月预订
现在网上订票时间预提前20日您看哪一天您闲有空即可订票取票哈哈祝愉快路途！
1月14日下午15点就可以买了
您可能关注的推广
12306的相关知识
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁铁道部12306耗资1.9亿，1.9亿能造出啥样的网站？ | Geek笑点低小组 | 果壳网 科技有意思
910140人加入此小组
+ 加入我的果篮
的话：我怀疑你连售票终端长什么样都没见过其实很多人真的没见过……有些车站或者窗口的设计就是那样的……
的话：这里要区分OLAP系统和OLTP系统的需求是不同的，12306除了有超高的并发外，更主要的是其每个并发都有很强的互斥要求和及时要求，而且是要UPDATE数据的。hadoop如果有高并发的修改而不只是添加，应该也是没有很好的办法的。指标，我一开始就提到指标了。通过指标，就可以把“互斥”的范围尽量缩小。所谓指标，就是事先为每个车站锁定一批票，这样该车站卖票就无需其他车站知道，互斥只在这个车站范围内得到保证即可。每当一个周期过去（根据种种迹象，过去的周期应该是一天），所有车站释放锁，然后重新锁定一批可卖的票；如此反复。通过指标，总库只有1000左右的并发（每车站一个单位）；每车站再处理自己的并发。这个机制甚至可以进一步扩充，比如把指标更新周期缩短到1～5分钟；比如把车站库当总库，把每个窗口（或者虚拟窗口）当分库，给每个窗口分配指标。这样，就形成了若干级的锁，而每级都只有很少的并发。
事实上，考虑现实中的商品零售问题：苹果不可能让富士康直接网售手机，富士康忙不过来，甚至苹果都忙不过来。所以，它会把手机批发给零售店，每个零售店卖完就再进货，卖不完就不进货甚至退货，通过零售店，就可以把手机出售问题分解，变成零售店规模的问题。
的话：指标，我一开始就提到指标了。通过指标，就可以把“互斥”的范围尽量缩小。所谓指标，就是事先为每个车站锁定一批票，这样该车站卖票就无需其他车站知道，互斥只在这个车站范围内得到保证即可。每当一个周期过去（根据种种迹象，过去的周期应该是一天），所有车站释放锁，然后重新锁定一批可卖的票；如此反复。通过指标，总库只有1000左右的并发（每车站一个单位）；每车站再处理自己的并发。这个机制甚至可以进一步扩充，比如把指标更新周期缩短到1～5分钟；比如把车站库当总库，把每个窗口（或者虚拟窗口）当分库，给每个窗口分配指标。这样，就形成了若干级的锁，而每级都只有很少的并发。另外车站拆分其实还有一个问题，中国特色的，中国的票的分布不是均匀的，而是向大站集中的，北上广三地就集中的全国1/3-1/5的运力。在首都，每当长假，东北方向想回家的人就有百万人，但车票一共就几十万张，总要面临多对一的情况，不过分了车站，确实速度能快点。
的话：事实上，考虑现实中的商品零售问题：苹果不可能让富士康直接网售手机，富士康忙不过来，甚至苹果都忙不过来。所以，它会把手机批发给零售店，每个零售店卖完就再进货，卖不完就不进货甚至退货，通过零售店，就可以把手机出售问题分解，变成零售店规模的问题。商品可以，火车票虽然可以，但因为是人多票少，如果让京东淘宝代理，那么这帮人不会私自截留么？扯远了，这不是一个技术的问题了，就跟苹果店门口排队的黄牛党一样，火车票也要面对。
的话：我自始至终，说的就是用单服务器，而是要设计线性扩充机制——不管是网页前端还是数据库后台。看不懂么，亲？过去的人工售票，每天会定时/不定时放票，就是在执行我前面帖子提到的map-reduce机制。正是这个机制，使得google可以每天遍历整个互联网，也使得过去的人工售票得以实现。正是这个机制，保证了每个请求的复杂度不会很高、保证了国家规模的问题可以拆分成车站规模的问题——和什么N*N没关系。定时放票？我3点钟要买一张，说卖完了，3点10分隔壁同事买又有了？广大群众还不怀疑里面到底有多少暗箱猫腻？你这是修改需求，而且这个需求变更合理性很低，不会被领导采纳的
总之，这种规模的问题，首先要做的一定是问题分解和水平扩展；而不是搞一个巨大无比的数据库然后头疼每秒上千万的锁。后者是完全不动脑子的结果。
的话：商品可以，火车票虽然可以，但因为是人多票少，如果让京东淘宝代理，那么这帮人不会私自截留么？扯远了，这不是一个技术的问题了，就跟苹果店门口排队的黄牛党一样，火车票也要面对。中肯
计算机系研究生，硬件开发工程师
楼上的引用
的话：商品可以，火车票虽然可以，但因为是人多票少，如果让京东淘宝代理，那么这帮人不会私自截留么？扯远了，这不是一个技术的问题了，就跟苹果店门口排队的黄牛党一样，火车票也要面对。还有个问题就是火车票有时间有效性，到货之后过期了得问题手机不存在。但是票有时间限制
的话：定时放票？我3点钟要买一张，说卖完了，3点10分隔壁同事买又有了？广大群众还不怀疑里面到底有多少暗箱猫腻？你这是修改需求，而且这个需求变更合理性很低，不会被领导采纳的过去恰恰就是这么做的。好多人的亲身经历。不过，那是人共售票时代的惨剧了。现在计算机化了，指标更新频率完全可以变得更高，30分钟或5分钟更新，对总库的1000并发压力来说，实在太轻松了。或许1分钟/30秒甚至10秒更新都能做到。
的话：楼上的还有个问题就是火车票有时间有效性，到货之后过期了得问题手机不存在。但是票有时间限制春运提前10天开卖；而且，每天放一次指标。这个方式很有效。至少比搞一个大库然后硬顶每秒上千万锁轻松太多。
的话：定时放票？我3点钟要买一张，说卖完了，3点10分隔壁同事买又有了？广大群众还不怀疑里面到底有多少暗箱猫腻？你这是修改需求，而且这个需求变更合理性很低，不会被领导采纳的我也想说这个
的话：春运提前10天开卖；而且，每天放一次指标。这个方式很有效。至少比搞一个大库然后硬顶每秒上千万锁轻松太多。一旦把这个机制计算机化，放指标的频度就可以缩短到30分钟、5分钟、1分钟甚至30秒。车票在打出来前，就是空对空的虚拟物品。对计算机就是数据，计算机的批发货物/退货不过就是些数据传来传去而已。这可能只需几个毫秒。而人工商店少说也得半天。
的话：过去恰恰就是这么做的。好多人的亲身经历。不过，那是人共售票时代的惨剧了。现在计算机化了，指标更新频率完全可以变得更高，30分钟或5分钟更新，对总库的1000并发压力来说，实在太轻松了。或许1分钟/30秒甚至10秒更新都能做到。秒级更新不太现实，毕竟还要面对每秒上万（从百万降低到万）级别购票请求，分钟级别的更新可以做到，但是有一个公平性的问题，这个问题我昨天就遇到了，比如，请求排成一个队列，到某个位置，票没了，大家一看票没了，取消等待，换另一个车次，到另一个队列里等，好嘛，过了几分钟，又有了，原来队列里没走的人，这下买到票了，走的人又得重新排队。排到后面的人买到了，排前面的没买到。你也可以说“谁让你先走的”，但是用户恐怕不会支持这个想法，如果让所有人都等着，等待队列又会很长，虽然量级降低了，但是无形中增加了很多负载
甚至，认真考虑这个机制——把人工算法改成计算机算法，当然不是直接拷贝就算的。比如，人力无法完成更复杂的管理，而计算机就像吃饭喝水一样简单。我可以：1、把车票分成1万个“票包”，票包内部车票由程序动态生成，但总数量有上限（比如1000张）2、全国1000个车站每次最多能锁定2～3个票包3、当一个票包卖完后，车站更新总库，然后从总库申请新的票包4、前一个车站释放的票包，可以打散后，把可用里程起点站相同的打成新的票包，等待下一个车站申请这样一来，首先总库无需支持千万并发了——1000并发足以；其次指标更新会快得让人感觉不到。
的话：甚至，认真考虑这个机制——把人工算法改成计算机算法，当然不是直接拷贝就算的。比如，人力无法完成更复杂的管理，而计算机就像吃饭喝水一样简单。我可以：1、把车票分成1万个“票包”，票包内部车票由程序动态生成，但总数量有上限（比如1000张）2、全国1000个车站每次最多能锁定2～3个票包3、当一个票包卖完后，车站更新总库，然后从总库申请新的票包4、前一个车站释放的票包，可以打散后，把可用里程起点站相同的打成新的票包，等待下一个车站申请这样一来，首先总库无需支持千万并发了——1000并发足以；其次指标更新会快得让人感觉不到。这个算法肯定不是最好的算法；但它至少：1、分解了问题2、具备水平扩充能力3、解决了人工指标管理的“票假售空”和“突然来票”问题
的话：甚至，认真考虑这个机制——把人工算法改成计算机算法，当然不是直接拷贝就算的。比如，人力无法完成更复杂的管理，而计算机就像吃饭喝水一样简单。我可以：1、把车票分成1万个“票包”，票包内部车票由程序动态生成，但总数量有上限（比如1000张）2、全国1000个车站每次最多能锁定2～3个票包3、当一个票包卖完后，车站更新总库，然后从总库申请新的票包4、前一个车站释放的票包，可以打散后，把可用里程起点站相同的打成新的票包，等待下一个车站申请这样一来，首先总库无需支持千万并发了——1000并发足以；其次指标更新会快得让人感觉不到。有一个疑问，你这个票包是什么概念？针对车次的？针对车站的？还有，终端机上，本来往某个方向有几十趟车，可你只给用户显示几个，那么用户不得抗议啊，这不是算法问题，这是需求问题
的话：这个算法肯定不是最好的算法；但它至少：1、分解了问题2、具备水平扩充能力3、解决了人工指标管理的“票假售空”和“突然来票”问题如果你是按照车次划分，比如变态的北京南，一天有百十来趟车，那一趟车只能分到十几张票，而用户对车次也是有需求的，比如，我就想坐某某车次，而你的模型里，这个车次在当前包里用完了，但实际是这个车还有票，那么你怎么调度？这种需求很现实，比如去东北，都想29号晚上走，那车次选择只有3个，几十万人抢1000张票，那是多么恐怖的事情。
的话：有一个疑问，你这个票包是什么概念？针对车次的？针对车站的？还有，终端机上，本来往某个方向有几十趟车，可你只给用户显示几个，那么用户不得抗议啊，这不是算法问题，这是需求问题一个车站一次可以拿到的最大票数。这个设计相当于要求每个车站有一个buffer，票包就是buffer的大小。当buffer内的票即将卖完或者已经卖完，需要先把buffer内的数据更新到总库并释放锁，然后才可能从总库拿到另外一批票以充实自己的buffer。至于给用户显示，只显示有没有就行了。而且可以把每趟车组成一个包，车站可以拿的包数和经过自己的列车班次相当（或者成正比，比例系数可以根据出票量动态决定）。
的话：钱是我坑的，你能怎么样？12306我花5W就能搞一个出来……2亿 呵呵当然不包含硬件说不定为了提高安全性数据是放在飞机里全球移动，飞机还有隐形技术，外加2个师飞机的轮值护航数据交换中转35颗卫星，122个中继站，746台dummy spot外加35层防御装甲，9台泛用人形决战机器以及15个装甲师的物理保护确定基本谁也进不来从这个角度讲，2亿真心不多
的话：如果你是按照车次划分，比如变态的北京南，一天有百十来趟车，那一趟车只能分到十几张票，而用户对车次也是有需求的，比如，我就想坐某某车次，而你的模型里，这个车次在当前包里用完了，但实际是这个车还有票，那么你怎么调度？这种需求很现实，比如去东北，都想29号晚上走，那车次选择只有3个，几十万人抢1000张票，那是多么恐怖的事情。这个设计就是在这几分钟内想出来的。你能希望它一下子给出所有问题的解答吗？而且，看我前一贴，能不能解决这个需求？提出这个算法的目的，就是说明，要面对的问题是死的，但解决问题的思路是活的；一个数据库迎万变是不行的。只需一个好的算法，就能把国家规模的问题变成车站级别。这就是程序员的价值所在。而在讨论一个问题的规模时，显然不应以数据库为参照——就好像你不会用数据库去估算google算法的复杂度一样：不过这只是因为人家的解决方案被你看到了——而应该以解决问题的态度、能解决问题的方案去估算。当你用数据库估算12306时，那是几千万级别的锁、且锁相互影响，造成了O（N^2）级的复杂度；但以这个算法来估算12306时，那是总库1000级别的锁和若干车站——而每个车站都可以用类似方式扩展，复杂度就一下子降到了O(ln(N))。
的话：一个车站一次可以拿到的最大票数。这个设计相当于要求每个车站有一个buffer，票包就是buffer的大小。当buffer内的票即将卖完或者已经卖完，需要先把buffer内的数据更新到总库并释放锁，然后才可能从总库拿到另外一批票以充实自己的buffer。至于给用户显示，只显示有没有就行了。而且可以把每趟车组成一个包，车站可以拿的包数和经过自己的列车班次相当（或者成正比，比例系数可以根据出票量动态决定）。这里还有一个问题：请求量大多集中在几个大站（北上广），而大站又是车次多的地方，如果拿到的票包数跟车次数不等，那么用户会抱怨显示信息不正确，明明有车却没有票；如果票包数等于车次数，那就基本上跟原来的类型相似，但确实锁库的代价是会小很多（只锁一个站），但是因为总请求量还是集中在某地，那么还是会出现排队很长很长的情况（就像现在12306这样），因为：库缩小了十倍以上，但抢票过过程可能就是由100万人在5分钟内抢1000，变成100万人在1小时内抢100+100+100.。。，只不过登录没那么困难了，并且用户体验会稍微好点。
的话：这个设计就是在这几分钟内想出来的。你能希望它一下子给出所有问题的解答吗？而且，看我前一贴，能不能解决这个需求？提出这个算法的目的，就是说明，要面对的问题是死的，但解决问题的思路是活的；一个数据库迎万变是不行的。只需一个好的算法，就能把国家规模的问题变成车站级别。这就是程序员的价值所在。而在讨论一个问题的规模时，显然不应以数据库为参照——就好像你不会用数据库去估算google算法的复杂度一样：不过这只是因为人家的解决方案被你看到了——而应该以解决问题的态度、能解决问题的方案去估算。当你用数据库估算12306时，那是几千万级别的锁、且锁相互影响，造成了O（N^2）级的复杂度；但以这个算法来估算12306时，那是总库1000级别的锁和若干车站——而每个车站都可以用类似方式扩展，复杂度就一下子降到了O(ln(N))。成本呢？说到底还是2个亿的问题，2个亿建设一个1000个节点的矩阵，貌似不太够，一个节点20万，一个刀片机服务器就的几万块钱，还不算这里的布线、电路、网络费用。我也没一梆子打死说这个问题是无解的，我前面说了，是有条件的可解，我说过我已经仔细研究过售票系统的数据库特点，然后才得出的这个结论。
的话：只学3天VB，不耽误半瓶子出来扯淡。但识别这种半瓶子醋很简单：看他有没有常识，看他是否反对最基本的事实。现在的事实就是： 前年的车票还是人工卖的。这种不涉及人工智能的问题，只要人能做，计算机就能以上亿倍的效率以同样的策略做到。任何实现，至少不能低于这个效率。直接这么比有点不合适。因为人工售票，因为售票员的处理能力是有限的，所以实际上对后端系统的压力其实也就在时间维度上分散了。就好比如果现在全国买火车票的都只能去指定的售票亭的电脑上买，而且那些电脑都是用56k的modern上网，那么我想信12306的负载会低了不止一个数量级。
的话：这个设计就是在这几分钟内想出来的。你能希望它一下子给出所有问题的解答吗？而且，看我前一贴，能不能解决这个需求？提出这个算法的目的，就是说明，要面对的问题是死的，但解决问题的思路是活的；一个数据库迎万变是不行的。只需一个好的算法，就能把国家规模的问题变成车站级别。这就是程序员的价值所在。而在讨论一个问题的规模时，显然不应以数据库为参照——就好像你不会用数据库去估算google算法的复杂度一样：不过这只是因为人家的解决方案被你看到了——而应该以解决问题的态度、能解决问题的方案去估算。当你用数据库估算12306时，那是几千万级别的锁、且锁相互影响，造成了O（N^2）级的复杂度；但以这个算法来估算12306时，那是总库1000级别的锁和若干车站——而每个车站都可以用类似方式扩展，复杂度就一下子降到了O(ln(N))。搞这么大一个东西，全国车站编号一共是5000多个，一个节点按20万投资，算下来，钱不少花，但也就是解决了春运和长假的售票问题，值得不值得，很难说。
的话：跟访问量没关系，跟带宽也没关系，甚至大幅提高网页端的性能也没有用，性能瓶颈在数据库上，出库模型的限制在那摆着呢。少儿不宜网站要同时处理支付，社交，下载，视频播放，这些东西，你看看他们服务器压力小吗？？？说真的我怀疑真的是大学生期末作业，尼玛12306交给淘宝，亚马逊做都做得比太极好。
的话：12306自建立以来，非议就一直不断。其实在我看来，所有的指责其实都仅仅停留在技术层面，网民们鲜有人去想一想这背后的深层次的，最根本的原因是什么。其实很简单，就是在特定时期，有效供给不足的问题。在这个问题上，有些人一厢情愿地认为可以用制度的办法来保证绝对公平。但我要说的是，这只是没有实际社会经验的人主观想象中的美好愿景，实际上并不可能真正实现。即
有人说12306如何技术落后，如何脑残。可是，就算是二十二世纪的超前技术，也无法解决只有一百张票，却有两百人想买，你能用技术手段让这两百人都买到称心如意的票的难题。无论怎么做，都有一百人买不到票，只要买不到票，这一百人肯定吐槽你技术落后，暗箱操作，设置脑残。不从根本上解决有效供给问题，这个难题永远无解。
至于系统漏洞，任何系统都不例外，就是美国国防部的网站，也不照样让人渗透成筛子吗？如果有效供给充足，大家都很容易地就买到票，哪还有人会管你有没有系统漏洞？ +1买车票困难，归根结底还是供需问题
的话：这里还有一个问题：请求量大多集中在几个大站（北上广），而大站又是车次多的地方，如果拿到的票包数跟车次数不等，那么用户会抱怨显示信息不正确，明明有车却没有票；如果票包数等于车次数，那就基本上跟原来的类型相似，但确实锁库的代价是会小很多（只锁一个站），但是因为总请求量还是集中在某地，那么还是会出现排队很长很长的情况（就像现在12306这样），因为：库缩小了十倍以上，但抢票过过程可能就是由100万人在5分钟内抢1000，变成100万人在1小时内抢100+100+100.。。，只不过登录没那么困难了，并且用户体验会稍微好点。1000个车站，10000个票包，票包比车站多10倍——我“处心积虑”的提出这俩数字，就是要解决大站需要快速更新数据问题^_^。另外，这只是一个可行的问题分解方案而已。但不管怎么说，这个O(ln(N))的方案至少比O(N^2)可行得多吧。另外，对一些荒僻的小站，可能几十个站甚至上百个站用一台服务器就够了；当然，对北上广这样的大站，可能得上百服务器。并且，服务器并不一定要分布到各个车站。统一放机房也可以，反正是互联网访问。这样甚至可以设计动态平衡机制，未必需要每个车站和一个机组一一对应。至于1.9亿多不多，根据这个O(ln(N))方案算，应该得几千台服务器——一台普通think server服务器大概两万，5000台就是一个亿（不过5000台应该怎么也够用了，没仔细估算过）；剩下软件、布线、人工才9000万，所以这个数字不算离谱，甚至可以说是便宜。当然，值不值，要看最终能不能彻底解决问题了。
假设成只有一个巨大库然后查询还要锁库这样的模型就是最不科学的了, 从这个模型出发做任何分析必然都是低效的. 首先, 为什么只能有一个库? 不同的车次互不相干为什么不能放在不同的库里? 其次, 查询不可能还要锁库, 查询有余票一提交就没了也不是没遇到过. 设计合理的数据库和购票流程有时比添加硬件来的有效
的话：直接这么比有点不合适。因为人工售票，因为售票员的处理能力是有限的，所以实际上对后端系统的压力其实也就在时间维度上分散了。就好比如果现在全国买火车票的都只能去指定的售票亭的电脑上买，而且那些电脑都是用56k的modern上网，那么我想信12306的负载会低了不止一个数量级。这就是排队系统要解决的问题了： 云风估算过，貌似100万人排队可以轻松跑在一台普通服务器里。通过排队系统，就可以保证后端的处理能力，也就相当于所有电脑都以56K猫上网。其实一共才多少票啊。不挤，每个请求都拖妥帖帖处理了，用户体验怎么会差？WOW排两个小时也没人有怨言啊。而且，过去人工都卖完了，现在怎么也能卖完吧——只要你能把排队做到WOW的水平，让他们排到就能买到票（而不是现在这样诡异的、无法预测的行为模式）。
其实你们设计来设计去，都没人整理一下需求。需要支持什么样的查询购买需求，需要什么样的响应方式。所以几分钟就能出一个方案，然后被批还很不爽。先把需求整理清楚，然后说，要满足这些需求怎么做！？
果然这帖子分区也没错，回帖本身很多就是笑话。太极中这个标，涉及内容具体我不知道，但是看他那个公告，涉及的也就只是硬件供货、安装、维护及其机房弱点集成建设部分。1.9亿不过是硬件方面一部分成本而已，你们各位扯的软件、网站站点建设是属于应用集成范畴的，其中应用集成也会涉及数据库、中间件的采购，更重要的就是应用软件系统的开发、采购、安装、维护。这方面的水因为各种关系才是真正深的，整个12306涉及这次太极同一个项目肯定不止1.9亿那么多。应用集成这部分前面有人说铁道部曾说过不会让外人做，那么我只能认为应用集成是铁道部自己的某个大team，或者是铁道部下属的中铁信去做的，而且不是投招标，而是内部拨款。其实现在来看，12306应用部分的确是有很多可改善可提高的空间的。即使说数据库方面，可能还能有优化，但是不会提升太多，淘宝养了国内最顶尖的一些数据库专家，他们薪资多少我不知道，但是肯定不是3、40w/year可以打发的，可以参考的是DB2专家牛新庄曾经年薪百万的传说。铁道部的数据库主要应该是Oracle RAC，技术方面我不多说，Oracle RAC理论上可以支持32节点，常见都是2节点的RAC，4节点偶尔能见到，但是纯粹的多节点不意味着性能的线性提升，甚至很多4节点性能不如2节点，这里面就涉及调优和优化的问题，可以说能把4节点优化做得很好的人是少之又少的，淘宝当初建过20节点的RAC，但是他们真正能优化下来用得很好的，也就8节点。所以去年曾传闻铁道部求援淘宝的team过。哪怕很多人说可以用刀片+MySQL，很多游戏和互联网都是这么做的，事实上大部分这样做的企业之类出于成本考虑，到淘宝、Google之类的不使用商品化产品而自己开发，实际人力的成本并不会比商业化产品低，何况后者使用非商品化产品，涉及的因素也很多（举例一下，你觉得你现在50w per year，做公开非独有的技术，20年之后50岁，你精力体力不如从前了，有后来者虽然不如你，但是只要40w per year，你没自己的东西老板原不愿意花这么多钱养你呢）我昨天因为要睡觉，忘记我真正想说的两句话了。这帖子笑话有二：一，自己并非行内，完全不在其中，却侃侃而谈的人不少，回帖中自己以为瞄得很准，实际打到的都是躺着的人。很多“IT网站”，涉及到我这部分的都这样，非“专业”网站就会更多了。例如果壳以前文章中关于“沃森”的就有不少，我当时懒得回复。二，一边抱怨自己是廉价劳动力，一边跳出来说自己人力费用低的人也不少。有点社会常识也应该知道，企业付出的人力成本肯定不止给你的工资那么简单，公司性质不同投入也有所不同，某些行业人均人力成本在工资十倍并不夸张。我无非是因为连续加班，昨天休息无聊临睡前才回帖的，实际上大多时候我真的是在当笑话看很多网上的文章和帖子。
这是一个神奇的网站！呵呵
guokr的5毛越变越多了
的话：搞这么大一个东西，全国车站编号一共是5000多个，一个节点按20万投资，算下来，钱不少花，但也就是解决了的售票问题，值得不值得，很难说。涉及到回家就值的，想必你是本地人，不用去管外地人回家的事情
的话：少儿不宜网站要同时处理支付，社交，下载，视频播放，这些东西，你看看他们服务器压力小吗？？？说真的我怀疑真的是大学生期末作业，尼玛12306交给淘宝，亚马逊做都做得比太极好。你还是没有理解售票的数据库模型跟其它模型的区别，售票的最重要步骤是锁库，就是保证数据的一致性，目前看，是加一把大锁，这样就需要后面几百万人一起等着解锁，也就是说，目前的售票系统数据库，是一个不可并发的系统，而账户支付，锁的范围仅限于你自己的账户内，其他人不必等你，不用排队，可并发，至于下载，都静态的东西，静态的东西并发个几十万个很容易，也不用排队。我前面总结过很多次了，瓶颈不在带宽，也不在CPU负载，在数据库的瓶颈，也就是那一把大锁，百万人去排队的大锁是最大的瓶颈。至于亚马逊，亚马逊一天最高订单才600多万，跟12306持平，况且它是分国家部署的服务器，不同国家之间的商品不共享库存，而12306一天100万请求是在共享库存，存在竞争互斥的前提下实现的（至少当前是这样的）。所以真把亚马逊的模型直接套到12306上，也未必撑的住。
的话：涉及到回家就值的，想必你是本地人，不用去管外地人回家的事情从考上大学以后就一直离家在外，最近的时候也在1000公里以上，对于我来说，肯定希望多投钱，我也想买票回家，从上大学开始到现在，有记忆的就有三次春节没回家，但铁道部愿不愿我就不知道了。毕竟供需不平衡，人家高高在上，没办法的事情
分流不行么，淘宝京东这么多购物平台，都可以把票分到别的平台上吖
的话：你还是没有理解售票的数据库模型跟其它模型的区别，售票的最重要步骤是锁库，就是保证数据的一致性，目前看，是加一把大锁，这样就需要后面几百万人一起等着解锁，也就是说，目前的售票系统数据库，是一个的系统，而账户支付，锁的范围仅限于你自己的账户内，其他人不必等你，，可并发，至于下载，都静态的东西，静态的东西并发个几十万个很容易，也。我前面总结过很多次了，瓶颈不在带宽，也不在CPU负载，在数据库的瓶颈，也就是那一把大锁，百万人去排队的大锁是最大的瓶颈。至于亚马逊，亚马逊一天最高订单才600多万，跟12306持平，况且它是分国家部署的服务器，不同国家之间的商品，而12306一天100万请求是在，的前提下实现的（至少当前是这样的）。所以真把亚马逊的模型直接套到12306上，也未必撑的住。哦，那可不可以试试分流，让淘宝，亚马逊，京东承担一部分售票业务？？？
铁道部太丢人了，一群败家子儿。
能打造一个还不够全国人民一人一脚（角）的网站呗
1.99亿。。。就那网站，估计不要。。。人一多，容易打不开。。。
的话：哦，那可不可以试试分流，让淘宝，亚马逊，京东承担一部分售票业务？？？你可以简单理解成这样：现在是没电脑的时代，全国的人都只能到唯一的一个售票厅购票，购票大厅窗口不算少，但是也就几千个（假设5000），每个窗口有售票员和记录员。一个普通人购票流程大概是1.购票者在窗口对售票员提出购票申请。2.售票员告诉记录员有人要买北京到上海的票，记录员去一个唯一的账本上去查。3.记录员确认是否XX列XX次，哪些有票，有告诉售票员，售票员再告诉购票者。4.没有的情况就不说了，如果有，则购票者提出购买某XX列XX次。5.售票员告知记录员去他们这个账本上记录。这账本只有唯一的一个，放到一个大的桌子上这个账本5000个记录员同时写显然不可能，这个账本是活页的，记录员要写的时候则把XX列XX次那一页拿下来以便其他人查询写入其他班次使用。传统方式，其实是预分发票，而且定点，零售行业当然也这样。淘宝京东之类如果不是使用铁道部的终端，必然也是自己当黄牛那样先冒充顾客买票，然后票到手以后一直放在自己兜里面，最后客户要的时候直接给他。否则是绕不出这样的流程的。预分发不能完全定向估计需求，比方说有A-C的火车，途径B地，A有人要到B，B有人要到C，难道他们必须要买A-C地的票呢？如果都买全程通票，铁路运力自然降低数倍，本身铁道部主要问题就是高峰期运力不足，预分发售票等于就是砸了钱搞个购票系统，然后运力一点没解决。
的话：你可以简单理解成这样：现在是没电脑的时代，全国的人都只能到唯一的一个售票厅购票，购票大厅窗口不算少，但是也就几千个（假设5000），每个窗口有售票员和记录员。一个普通人购票流程大概是1.购票者在窗口对售票员提出购票申请。2.售票员告诉记录员有人要买北京到上海的票，记录员去一个唯一的账本上去查。3.记录员确认是否XX列XX次，哪些有票，有告诉售票员，售票员再告诉购票者。4.没有的情况就不说了，如果有，则购票者提出购买某XX列XX次。5.售票员告知记录员去他们这个账本上记录。这账本只有唯一的一个，放到一个大的桌子上这个账本5000个记录员同时写显然不可能，这个账本是活页的，记录员要写的时候则把XX列XX次那一页拿下来以便其他人查询写入其他班次使用。传统方式，其实是预分发票，而且定点，零售行业当然也这样。淘宝京东之类如果不是使用铁道部的终端，必然也是自己当黄牛那样先冒充顾客买票，然后票到手以后一直放在自己兜里面，最后客户要的时候直接给他。否则是绕不出这样的流程的。预分发不能完全定向估计需求，比方说有A-C的火车，途径B地，A有人要到B，B有人要到C，难道他们必须要买A-C地的票呢？如果都买全程通票，铁路运力自然降低数倍，本身铁道部主要问题就是高峰期运力不足，预分发售票等于就是砸了钱搞个购票系统，然后运力一点没解决。谢谢
的话：这就是排队系统要解决的问题了： 云风估算过，貌似100万人排队可以轻松跑在一台普通服务器里。通过排队系统，就可以保证后端的处理能力，也就相当于所有电脑都以56K猫上网。其实一共才多少票啊。不挤，每个请求都拖妥帖帖处理了，用户体验怎么会差？WOW排两个小时也没人有怨言啊。而且，过去人工都卖完了，现在怎么也能卖完吧——只要你能把排队做到WOW的水平，让他们排到就能买到票（而不是现在这样诡异的、无法预测的行为模式）。所以我的看法是：1：排队系统比需要做的，全部人都挤到购票系统中，绝对受不了2：你所谓的预先分站点buffer在业务上是很难接受的3：比较好的办法就是用类似ajax等方式，分批开闸，这样既保证压力，也能让用户减少不停刷新的操作（每一次页面，就让你重新排一次队）4：数据库后端别自己瞎折腾了，花大价钱，让oracle/ibm搞定吧
的话：那是指标管理问题。指标卖完就不能卖了。通过指标限定，正是人工解决问题（分解问题规模）的方式。看这个帖子看了1个小时，对你这种人相当厌恶。登陆上来表达对你的不屑，不管你有多高端，多牛逼。如果你有好的想法好的思路，你可以写出来大家看，写详细点，不要害怕大家看不懂。请不要随口就叫别人小白，叫别人傻X，你真的欠教养。
的话：定时放票？我3点钟要买一张，说卖完了，3点10分隔壁同事买又有了？广大群众还不怀疑里面到底有多少暗箱猫腻？你这是修改需求，而且这个需求变更合理性很低，不会被领导采纳的这位兄弟/妹纸，有退票这一说的，前两天刚退了一张29号的普快
的话：看这个帖子看了1个小时，对你这种人相当厌恶。登陆上来表达对你的不屑，不管你有多高端，多牛逼。如果你有好的想法好的思路，你可以写出来大家看，写详细点，不要害怕大家看不懂。请不要随口就叫别人小白，叫别人傻X，你真的欠教养。那你就继续厌恶吧。呸。
的话：所以我的看法是：1：排队系统比需要做的，全部人都挤到购票系统中，绝对受不了2：你所谓的预先分站点buffer在业务上是很难接受的3：比较好的办法就是用类似ajax等方式，分批开闸，这样既保证压力，也能让用户减少不停刷新的操作（每一次页面，就让你重新排一次队）4：数据库后端别自己瞎折腾了，花大价钱，让oracle/ibm搞定吧1、同意。我甚至怀疑一个优秀的排队实现就能解决所有问题。甚至可以先付款，把买票委托到队列中，排到就自动出票，排不到就退款。2、预先分站点给指标正是已经运行了几十年的老办法。我觉得取消这种老办法才是很难接受的。3、是的。通过UI设计消除无意义的刷新可能能节约七八成的流量。4、这个才便宜。oracle/ibm的东西才叫贵。12306就是因为ibm要价太高而谈崩的……另外，看这个：铁道部高层告诉记者，12306网站属于外网，其数据并不是直接连接自铁路客票发售和预订系统，而是存在内网与外网的数据转换。“数据交换的时间不知道是多长，听说在10分钟左右。” “在互联网上，只要能提升百分之几的效率，那么网络与服务器的压力就能降低很多。”一位互联网知名技术工程师建议，12306网站只要在关键部分进行改进，那么就能大大地提高效率。比如，12306网站“余票查询是每10分钟更新一次”。这10分钟就是可以进行静态处理的，只要网站做好这10分钟，那么网络拥堵的情况就能够大大降低。所以，现在不是10分钟要不要做，而是要不要取消掉，然后回归笨笨的数据库……
的话：三千两百万买两百个刀片服务器先。。。。平均一个服务器承担五十万人的【排队】业务。。。。一个队列而已。。。根据排队号hash得所在位置。。。一点压力没有。。。。50W请做个网站。。（给你变成十倍啊有木有）。。剩下的归我了。。。哦也~~!~!~!
(C)2013果壳网&京ICP备号-2&京公网安备