这个时候，用云服务是否更合算一些？关键某几个时间段访问量大，一般情况下都不是很大滴。跑题了

我倒是觉得这种大型项目很适合用 erlang 做，erlang 的分布式，轻量级线程，鲁棒性，容错性都适合做这种海量同时访问的，erlang 最近好像出了一本关于 web 开发的书，Building Web Applications with Erlang，网上可以下到电子版，准备有时间看看。 不过瓶颈可能在数据库吧，想起来之前看的 wooga 的 slide，我觉得 erlang+zeromq+ruby+redis+mysql 确实挺强大的 erlang 负责处理海量的访问，zeromq 负责处理 erlang 与 ruby 的消息中转，ruby 方便测试，代码友好，绝对是最适合写逻辑代码的语言，redis 这种 Nosql 数据库查询速度快，Mysql 在最后做数据仓库负责 redis 数据的序列化。再高的处理量也只需要简单的 shard 数据库然后增加 ruby 的 worker 线程了 slide 在此： http://www.slideshare.net/wooga/at-scale-with-style

推荐云风的解决方案，在已有硬件条件下缓存排队很靠谱

alexa 不准的

性能是一个问题，一篇链接 robinlu http://www.robinlu.com/blog/archives/164

#1 楼 @googya 我觉得云方案可行性不高，毕竟 12306 的流量突发期和其他互联网服务商流量突发期重合度太高，大型节假日前后，它接受类 ddos 式访问的时候，像阿里这类能提供云计算的本身访问量也大到让快递屡屡爆仓

要和旧系统集成的，不是纯粹的 web 系统

#7 楼 @reus 是的，我始终觉得外界的说法也不太靠谱，公开信息说到这个项目是包括软硬件，相应的，监控运维系统之类也是不能缺少的，这时再考虑系统集成就不是那么简单了

当然，我仍然认为 12306 是有些浪费钱的，但不是从技术分析得到这个结论，而是从经济和项目实践估计，一般来说，国有背景下，产权不清晰导致低效是必然的，再考虑到现在 12306 并不是公开的招标，没有浪费甚至浪费不大都是不可想象的

我在想这个排队问题。是不是因为定下票和付款之间有一定的间隔，所以需要等待？

很不理解为什么需要排队，可以按先付款先得票的原则 下订单只是说要买车票，具体的几车几号等付完款以后再决定 也就是说订单里面只有日期，车次，几等座，乘客等信息，车票相当于库存，订单付完款以后再进行配票 (给订单分配车票),配票完成才减少车票总数，如果配票失败就直接退款，这样可以避免买票的人一直等待，没有票也可以赶紧买别的票 一旦出现因库存不足导致的退款，同日期，车次，座等的票就不能再下订单了，尾票和退票放到窗口去卖

给我 1 亿 就行了

据说高峰时期可以有几千万的 PV。nginx 做到 1 万并发的化，大概需要几千台服务器。一台服务器采购价格大概 2 万，光 web 服务器采购就需要 6000 万吧。1 亿后还有 4000 万怎么花？

@jimrokliu 一台 2w 的机器，支撑下 1w 的话还是有上升空间的，再说，一般这种地方不差钱 只是可惜税了

#13 楼 @neocanable 是有上升的空间，但是一般都会留有 40％的余量，这里还要考虑维护这些服务器的费用，空调，电力，监控，安保，场地，我们还没有计算后台的数据库中间件的费用。楼主能计算一下搞定要多少钱。中国没有亚马逊的云计算，这种突发计算的请求如果完全靠自己承担，系统使用费用绝对会高的受不了。所以，我觉得铁路如果在春运期间不向京东，淘宝租用计算资源的话，很难承受这么大笔费用。

3 亿对于铁道部来说 P 都不是，还不够修一公里高铁

@hlxwell @reye888 我能想到排队的合理性是一定程度上能防止代买火车票。当然其实排队这个并不是很合理..

#12 楼 @jimrokliu 几千万的 PV 和几千万的并发一样？

#12 楼 @jimrokliu 你弄错了，几千万 PV 不是指一秒中有几千万个请求，而且这里面最重要的绝对不是 web 前端机，瓶颈在有业务逻辑的应用服务器，更进一步，我们可以合理猜测瓶颈是遗留系统的能力，关键指标应该是 TPS

好的系统在一轮 ping 包之后就能同步所有数据。最多等待 10 秒。

@hlxwell 楼主，我觉得一天 1-2 千万的 PV 估算有问题吧，一天几千万 UV 还差不多，PV 肯定上亿；我们公司自己的小业务每天都 2 亿多的访问量，600 万的 UV，全国这么多上网用户，过节不管是回家还是出去玩，流动的肯定上亿人次。

@hlxwell 另外，超高并发的系统不会直接用 rails，它太臃肿了，只会用精简版的或者 sinatra 之类小框架，要不光内存消耗就吃不起

还有个业务一致性的问题，车票和实物库存有不同的地方，沿途每站都有组合的计算和释放。

据说峰值时日访问超过 10 亿。总体还是票太少了。现在崩溃少了。

有道理。我觉得上亿肯定有。而且他们估算是全国 6 亿的人口在同一时间使用。所以还需要有很大的冗余。 他们估计这样算的. 1w 的机器 (大批量购置需要便宜点吧) 12000 台 1 万人 2 台应该够了吧，包括 balancing。这样 10000 x 12000 = 120,000,000，balancer 防火墙 估计要几千万了吧，带宽什么的，管理人员每年的工资。开发系统，系统的维护成本。算算也有很多。

有重度国内“中底”用户的网站是不能用 Alexa 做流量估计的。这点上 Alexa 严重不靠谱。

新浪微博上喷 12360 都不是很专业，找的一堆问题都是外围模块的，跟订票没啥关系。

这种高并发的业务，比支付宝不相上下。短短 1 天，要接受上千万的订票需求。天极在这上面没多少积累。话又说回来，国内公司有几个有这种积累的？

另外 3 亿这个数字，如果是真的话，那铁道部真是”太廉洁“了，资金利用率最起码再 80% 以上，只拿 20% 的回扣？打死我不信。

楼上的童鞋看那篇 sql 注入的帖子了不 (

谢谢大家对政府的信任。相信他们一定不廉洁

#26 楼 @fleuria 你说的乌云那个？还是http://ww1.sinaimg.cn/large/7cc829d3gw1dxb5e12xacj.jpg 这个。乌云号称拿到漏洞但不敢下手。后者是铁道部网站货运服务的，跟订票的关系不大吧。

不过以网站的粗糙程度，不排除订票服务里也会手写 SQL。