瞎扯淡 3 亿的 12306.cn 你说用 Rails 多少能搞定?

hlxwell · 2012年09月23日 · 最后由 dazuiba 回复于 2012年09月28日 · 7818 次阅读

早上看新闻看到 "铁道部网络购票系统一期工程总价超 3 亿仍买票难" http://news.sina.com.cn/c/2012-09-23/014025232225.shtml

然后随便查查它的流量: http://alexa.chinaz.com/?domain=http%3A%2F%2Fwww.12306.cn

我觉得一天大概估计一天有个 1-2 千万的 PV3-5 百万的 UV。

你们觉得你们多少台服务器,多少的人员开发成本就可以搞定?以及维护成本。

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

我倒是觉得这种大型项目很适合用 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。

需要 登陆 后方可回复, 如果你还没有账号请 注册新账号