转 :12306到底有多复杂?虽然网站做的真的很差,但大家作为程序员也要知其所以然

wyzc小胖胖 发布于 2012/09/21 13:39
阅读 4K+
收藏 1
2012年初,中国铁道部奉献给全国人民尤其是程序员一个精美的12306网站,在不负众望的过程中,再现了中国铁道部的辉煌,那么,这个系统到底有多复 杂呢?2000多万的硬件投入,到底能否支撑这个系统呢?我对这个问题非常的有兴趣,做了一些假设(考虑一个全新的系统,抛开一些细节),请各位IT精英 批判。

首先来看一个数字: 铁路部门表示,今年春运进入售票高峰期以来,平均每天有216万旅客成功通过网络购票和电话订票,占到购票总量的36%。这就是说,每天全铁路系统销售大约600万张火车票,其中216万通过网站/电话预订。

现在我们来计算一下这个系统的吞吐量:按每天只工作10小时计(铁道部是非常勤奋为全国人民服务的,据我所知,电话订票每天工作8:00-23:00约 15小时,网络订票每天6:00-23:00约17小时,服务窗口则包括24小时窗口,我们只按10小时计,看看这个数字有多大: 每秒处理166张票。如果按照平均每个订单2张票,那么每秒处理83个订单。

当然,大家都知道,12306虽然每天提交的订单不算很大,但查询量是极其巨大的,以及查询成功提交了订单,但提交失败的情况是非常严重的,我就曾经狂刷 过1个小时,也没有成功的提交一个订单,都是”系统忙“。按照这种比例,我们预计查询和订单的比例将会达到100倍甚至1000倍。看看alexa的评估 数据:至2012-1-12,日终IP访问量达到9,680,000,日终PV访问量达到:38,236,000,也就是说,如果这么多的查询都在10小 时内分担的话,每秒的PV数为1062,这个当然比订单总数多了很多倍了。再放大一些,假设每个PV为10个查询请求的话,每秒的查询量将达到 10,000。我们下面就按照这个数字来进行假设:

× 每秒处理10,000个查询请求
× 每秒处理 200个订单(其中成功率为41.5%,每秒可以成功完成83张订单)

我们这里先不关注WEB服务器的处理能力,带宽是否够的问题,我们只关注这个系统最为核心的数据库,需要一个什么样的架构才能支撑这样的一个系统呢?

1、我们采用一个MySQL数据库来作为核心的票务数据库(不关注用户这一块),这个数据库的唯一职能是快速处理订单。其中订单已明确了需要预订某个车 次、某个日期的从站A到站B的给定座位编号(假设站票也有座位编号),这个系统只需要在这个处理上进行同步,不要将同一个座位卖给两个不同的人。这个逻辑 会非常简单,数据操作也会是一个很小的处理,因此,处理能力我们估计一台终端数据库服务器,应可以完成每秒200个事务处理。
2、采用memcache或者redis,将所有销售车次座位全部保存在缓存中,假设火车销售期为12天,每天有1000万个座位,每个座位有最多32个 站,每个座位每个站段(从A站到B站)最少一个bit,最做一个字节,那么最少需要480M,最多需要3.8G的内存。我们为每一台这个缓存服务器配置 100G内存,那肯定够用了吧。
3、订单更新成功后,通过trigger或者mysql binlog或者应用通知的方式同步更新缓存,更新最新的座位可用情况。我们假定这个延迟时间最多会达到1秒的延迟,即一个订单成功后,相应的座位信息可能需要延迟1秒后才会更新到缓存服务器中。
4、我们在处理用户订单时,所有的可用座位分配和查询都在内存数据库中进行,查询包括剩余座位查询,以及在处理用户订单时,在可用座位中分配好可用的座 位,而后再想Mysql数据库发起预订请求。由于是完全内存数据库,且无需进行并发的锁等待处理,我们假设一台内存服务器每秒可以处理5000个这样的查 询请求。为了满足每秒10,000个查询请求,我们需要2台这样的缓存数据库。

上述的方案,3台中配置的服务器就足以满足这个系统最为核心的处理能力了。当然,我们并不差钱,数据库我们还可以进行分区管理,咱们为每个铁路局配置一个 数据库服务器,如果配置10台MySQL数据库服务器,20-50台内存数据库服务器,那么在这一块的处理能力还有10倍的富余空间。

至于这个系统的前端处理,面对每天接近1亿的PV,我们还需要一个很大的前端WEB服务器集群,包括CDN服务等。这里就随便估计一下,使用100台 WEB服务器,每个服务器的PV量在每天100万左右,这就是一个很小的数字了。当然,12306也完全可以采用一点点时尚的技术,比如说GWT等,大幅 度降低服务器端的Page请求,所谓的PV在概念上就可以降低一个很大的幅度。

另外一个概念是:12306真的有这么大的PV量吗?现在的PV这么大,那是因为我查询100次,1次也查不成功,所以我就不断的刷,这本身就是在逼迫全国人民对其进行Dos攻击。如果查询的成功率、订单的成功率提升了,估计PV会直线下降。

这么说来,12306其实是一个并不复杂的系统,可能其复杂性远远的低于一个weibo,低于一个taobao,甚至于低于一个在线游戏,只是,我们投入 了2000万的硬件,不知道投入了多少软件费用,不知道请了多少博导院士,最后却发现制造了2012年的第一个IT笑话呢?
加载中
0
BoYunfeng
BoYunfeng
12306,2012年的第一个IT笑话,果然果然,的确的确!
0
dedenj
dedenj
这篇文章看了,漏洞百出,毫无说服力,很多东西并没有考虑
0
hzajie
hzajie

他们做开发和设计的人缺乏实际经验,我认为应该将功能托管给任何一个家电子商务的公司都没有问题,如托管给淘宝处理。

0
wyzc小胖胖
wyzc小胖胖

引用来自“hzajie”的答案

他们做开发和设计的人缺乏实际经验,我认为应该将功能托管给任何一个家电子商务的公司都没有问题,如托管给淘宝处理。

不包出去的原因么大家也知道,但至少也不是随便什么人都能做的
hzajie
hzajie
这个我懂.
0
sxgkwei
sxgkwei
LZ,你忘记了一个作用力最大的实际情况。我们国家是:中国特色的社会主义。。你不懂?
sxgkwei
sxgkwei
回复 @小胖胖_要减肥 : 嘿嘿,懂就好,,嘿嘿
wyzc小胖胖
wyzc小胖胖
我懂,所以我没说他很简单,但做的也不好,钱么去哪里也不用说了
0
viwii
viwii
有个关于12306的帖子被封了,这个也快了吧
0
IdleMan
IdleMan
从站A到站B的给定座位编号 “是这么卖的么?怎么知道给定的编号还没有卖?如果2个编号一个买了咋办,又是竞争。。。
0
大东哥
大东哥
这篇文章会把MySQL打入万劫不复。
0
蛋蛋娃
蛋蛋娃

ctrl+f  依次键入 "假设","估计","可能”

足以证明.这是毫无根据,缺乏实际的贴子..都无需反驳了

"我们下面就按照这个数字来进行假设" 这句话成了亮点.

要理解 "real-time"

返回顶部
顶部