主题：【原创】无责任推测12306网站遇到的麻烦 -- 代码ABC

查询报告可做成服务接口，供管理服务器调用即可。数据库部分做成这样，其负载是很小的，可控的。比如一台入门级服务器专门负责某天发车的某一车次，其数据量是很小的。可根据使用情况调节，比如某一车次所有未来N日内车票，或者几个车次的票。这样的小负载，就是普通入门级服务器+MYSQL数据库都很够用了。

数据部分解决后，就是商务逻辑服务器和WEB服务器集群的事了，也没有大的难题。DNS负载均衡服务器+多地点（分散带宽要求）的多个WEB服务器集群把流量分散到多个商务逻辑服务器集群，即可基本实现。

不过阿里的DBA团队确实有够彪悍 在O基础上的两次集团调优和系统架构选型采购大战中 让各大IT原厂们见识到了神马叫中国最强团队

彻底抛弃小型机和oracle中，，，，

网站售票部分的数据来源应该是票务车间的中心服务器,必须要考虑窗口售票系统对数据的lock，而且窗口系统的优先级应该是最高的，这样的话，如果窗口的机器已经lock车票，但是又没有购买，然后释放回车票池，这个对系统的冲击才是最大的。

任何一个人或者团队如果能够解决铁路售票系统的话，都是一个牛人，绝对可以在软件史上留名。

可否借用飞机登机牌的经验？

买票的时候，确定是否有票，硬卧上、硬座下、有座位或无坐。

实际上火车前，按照先来后到的原则，打印出卧铺号或者坐位号。

铁路售票系统就算在春运期间，它的流量也远不如金融交易结算系统、通讯交换系统和大型网络零售系统，完成那些系统的开发人员谁在软件史上留名了？

你说的售票窗口lock车票，是典型的分销终端实时性问题。过去很长一段时间都是用预测销售量然后划拨定量库存到终端的方法解决。IT化以后一般用几个手段：1.用软件手段实现划拨定量库存到终端；2.增加浅层数据库应对旁支商业逻辑，比如说“窗口的机器已经lock车票，但是又没有购买”的情况；3.根据项目实际情况拆分主数据库，即降低“车票池”的大小，这是保证系统实时性最根本的手段。

现在是2012年，12年过去了，这12年里面，软件科学没什么大进展，实践应用上的硬件、开发工具和技巧都换代了，还换了不只一代。12年前的难点今天不应该还拿来做托词了。

铁科院昨天做了解释，归咎于带宽不足和需求预估错误----设计目标为日售票量100万笔，实际需求达到166万笔。这个解释就比较聪明，没有说什么东西特别难，做不到，而是老老实实承认自己出了错哪里做得不好。虽然写下错误需求的那个人是不会受到惩罚的，还是要鼓励他们至少能够承认自己并非完美的老实态度。

几十万的小项目@#￥%&*（

生意是不大，一天一百多万笔交易……，不大，不大不大……？？？

可是有多少人在上面反复的查啊查啊查啊

交易量的话，你可以查一下淘宝在光棍节的交易量。

查询量大的情况有很多种解决办法，我用过的一个简易方法是主数据库定时归总和生成报表，之后的交易留在浅层数据服务器中的数据库和内存中，生成查询结果就在内存中完成，不动硬盘。用这种方法只要带宽和DNS跟得上，系统本身应付大流量查询不怎么吃力。

客票系统的查询有两个很大的优势，它不需要应付语义查询，没有定制路线的跨车次查询的任务。

铁道部有两个票务系统，中间有一个接口。这次是中间数据库的连接件的并发能力被超过了极限。现在已经修改了。当然，这个信息来源我也不能完全肯定。

整个票务系统不是你想象的那样是一个简单的数据库设计或者网站架构问题，这方面在国内的论坛上有很多讨论了。淘宝的那个交易量也和这个不一样，淘宝上的卖的东西和火车票不一样。火车票你查到有，你就会下单，这个票会被上锁，淘宝基本上没这个问题。当然这个问题不是这次故障的原因。

还得scale out。Sharding/Partitioning就行了。

主服务器只做路由，就象ZooKeeper那样。集群里的每台服务器按车次来排。每天全国运行图假设有1000个车次，那么每10个车次（大概有几万张票吧）存在一台服务器里。主服务器按路由表（甚至可以人工做出来这个路由表）把请求路由到各个服务器上。每个服务器做各自的transaction（比如信用卡交易等等）。如果定满了，通知主路由更新信息。

每个车次订票请求先查主路由，看看是否已经定满，如果还有票，就让客户直接和分服务器联系（http redirect)。10个车次能有多少请求？每秒2000个请求左右吧。MySQL就够了。

这样看来大概100 到200台服务器就差不多了（加上failover之类的情况），MySQL免费。那么大概硬件200万美元左右吧。

上次光棍节可是不比春运卖火车票轻松啊。

麦加朝圣，大家都想着要立刻跟家人通话，那么小个地方，几万几十万人啊，但是不也成功了。