如果是你铁道部12306网站架构师,如何设计网站的软件架构和硬件系统架构

高榕 发布于 2012/01/06 13:42
阅读 21K+
收藏 31
如题,就是现在这个网站基本瘫痪了,看看大家如果作为一个系统架构师,如何去设计这么一个大规模,高并发的网站。
加载中
2
风林火山
风林火山

引用来自“japh”的答案

分省市
+1  复杂问题,细化颗粒,简单化最终所有的问题都是小问题。数据库纵向切割,按省市建表,横向切割,按时间区间建表,切割出来的表按照需要放在不同的数据库中。服务器按读写分离+前段缓存+均衡负载。差不多就能解决这些问题了。 另:数据库的切割会造成上层代码的复杂度,需要写个中间层进行透明转化。
Jetmark
Jetmark
哈哈,终于看到了,这个评论的分页了,评论好像也是不限字数的吧,谁能告诉我呢?
g
game+
test
无聊的人们啊
无聊的人们啊
test
l
lyq075353
回复 @诸葛非卿 : 学习了
l
lyq075353
不错
下一页
2
一号男嘉宾
一号男嘉宾
能搞这个单子的,国内怕只有腾讯淘宝这些大佬们了,别说火车票,在天朝,前段时间倭寇那边海啸,我们这边的抢盐那场面是我见过了,相当之壮观,何况是车票。
1
C_ZeroMap
C_ZeroMap
只要进网站就给票!!!!!!
1
BossKiller
BossKiller
先去摸清楚需求,考量每个缓解,找出瓶颈在哪里,然后再对症下药。空谈误国。
1
h
huanghenry

无语,经历过电信、证券、期货交易方面的系统建设, 觉得这种系统只是小儿科【自傲了】。机关和国企负责这个的,有几个懂得系统架构,优秀的人大多数不是出国了,就是郁闷的生活在这个神奇的国度。想起米国军事和太空项目的负责人一半是华人,偶只能再次无语!

花生酱土司
“米国军事和太空项目的负责人一半是华人”这个数据源自哪里?至少我会challenge一下
红叔
红叔
无语...
0
开开心心打酱油
肾虚公子
肾虚公子
要不能跨省买票估计又会引来一阵社会话题。。
自主创新
自主创新
回复 @GuoBoler : 加硬件,大集群&宽带。分布广未必管的过来
G
GuoBoler
@张亦俊 : 解决方案简单,不允许跨省买票就行了~~ 上海始发,就只能在上海网站买票
游客
游客
这种想法不行。
一号男嘉宾
一号男嘉宾
集群内部跳转?10来Y的流量那可不是搞着玩的。
下一页
0
戴威
戴威
充分利用缓存
0
张亦俊
张亦俊
这个真的十分困难,我觉得最大的麻烦在于巨大并发下的数据有效性和安全性。因为数据过于敏感,都是和钱相关的,这个就和人人、Facebook等有了显著的不同,数据不能出一丁点差错。这些必然以并发量为代价,所以关键还是在于数据库存储的性能优化上。一方面,尽可能使用I/O速度快的硬件。另一方面,数据库上尽可能少使用索引,减少数据更新的时间,当然,这是以查询时间作为代价的。当然,如果有可能,应该手工去设计适合的数据存储结构,而不是简单的使用市面上的通用数据库产品。
夕木
交易系统用的全是内存
hackee
hackee
@Binny : 对于数据和事务就是生命的交易型系统而言,重要的是稳定而不是创新
Binny
Binny
@CheckStyle : 如果我们的思维一开始就把缓存否定了,而只认为和钱有关的事务只能由数据库控制,那么就只能往数据库这条路走下去。也许基于内存的实现事务控制有更大的一遍天地,但我们没办法触及了。对于金融行业,老外已经设计一种新的架构LMAX,基于内存的架构,单线程每秒600万订单处理。 http://martinfowler.com/articles/lmax.html
hackee
hackee
对,交易类的系统基本不用缓存。 另外,我建议尽量利用异步处理模式,比如像证券交易里面,用委托和成交的概念来实现。
徐小达
徐小达
我觉得因该减少并发的可能,从源头简化系统,再考虑高并发的解决方案。
下一页
0
firstrose
firstrose
redis做缓存
0
浏览者
浏览者

看到楼上有两位说缓存的,除了那些做了CDN的东西,用户和已经存在的订单可以缓存一下,这两个东西命中率不大,最大的两个开销余票查询和购票,其实购票也是查询的一个分支,如果把余票做缓存的话,不过票务查询的命中率这么大。。。。就算后面加上队列,这个队列也不小了。就目前的情况来看,只能尽量的去节省资源吧。

1楼+1 ,分省市注意不错,细粒度的对待业务,尽量把不同区域的业务分离开,实现流量的分流。

返回顶部
顶部