锁定老帖子 主题:讨论火车票订购网站架构
精华帖 (6) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (5)
|
|
---|---|
作者 | 正文 |
发表时间:2012-01-06
还是设计合理业务流程来提升系统的易用性才是王道
|
|
返回顶楼 | |
发表时间:2012-01-06
最后修改:2012-01-11
|
|
返回顶楼 | |
发表时间:2012-01-07
简单说一下我的观点:
这个架框可能得需要考虑多方面的因素。 从硬件上考虑:需考虑服务器群(数据库服务器群,应用服务器群)的配置、考虑交换机的交换速度、考虑带宽。 从软件上考虑:得考虑服务器应用的操作系统(32位、64位(注32位的系统内存只支持3G多点儿的内存)),数据库集群,应用服务器集群以使软件能够负载均衡。 从应用程序上考虑:则需要考虑内存缓存,是否要用MEMCACHED等相关的缓存服务,考虑是否要用一些FIFO算法,消息服务等去处理相应的东东。 玩儿游戏的人深有体会,为什么我们玩游戏时,要选择相应的区(一区、二区等),并且每个区都有一定的人数限制。 小弟也只是个码工,考虑不全,还望指点。 |
|
返回顶楼 | |
发表时间:2012-01-07
我不知道象铁道部这样的网站到底用没有交易中间件,
如果没用,那什么都不用说了,纯粹的面子工程啊! 如果用了,就这破系统,尼玛啊,坑爹伤不起啊! |
|
返回顶楼 | |
发表时间:2012-01-08
SuseLinux 写道 我班门弄斧,来画个架构图,嘿嘿
看附图。 另,提交订票订单的处理流程如下: 1)用户通过浏览器访问系统URL 2)界面集群F5将请求转发至某一节点,通过比较用户数据库的内容进行身份鉴权。 3)鉴权成功后进入订票,提交订票订单(查询流程暂不讨论)界面显示请等待 4)订票消息被发送至总线部件(接口可用web Service、RMI、甚至自定义协议都可以) 5)总线收到订票消息、去Cache集群查询相关车次 6)Cache根据自身维护的车次余票表,返回查询结果,如果有余票,转7)。如果无票了,则总线返回界面集群“没票了”,界面提示用户明天再试。 7)若有余票,则总线返回界面集群“正在出票,请等待”,并将订票请求压入队列。且发消息至Cache,告诉CACHE将订票请求加入队列。 8)Cache收到总线队列增加1个的消息,将自身维护的对应车次余票数减1个。 9)总线另一线程负责从队列中取消息,并发送至出票部件。 10)出票部件产生订票结果,并修改数据库,发送“订票成功”消息回总线。 11)总线将订票成功消息直接回传至界面集群。 12)用户看到订票结果。 铁路的车票不是淘宝的商品只论个数的 |
|
返回顶楼 | |
发表时间:2012-01-09
bestxiaok 写道 jiuyuehe 写道 最主要的还是负载均衡吧,我觉得可以将数据分布到各个省的数据中心去,然后各做各的负载均衡!当然估计还是承受不了的,所以还需设置一个队列系统,让用户排队。最后限制在线时长!!!而不是一直说用户忙,用户多之类的!! 主要是游击队做的软件,负载均衡估计啥都没做。。。
这个系统上线了就更不能改了,负载均衡是一方面,主要还是架构的地方太乱了,竟然post那么大的网页,也不压缩下,很显然是游击队做的。。。。 |
|
返回顶楼 | |
发表时间:2012-01-18
引用 关键点来个理论值就一笔带过,理论好歹也得是同一数量级吧。 如果这项目是你来做,估计是一个德行。 这系统,京东不行,淘宝也够劲。铁道部是疯了,全国这么多人,运力还不够,再加上那么多秒杀程序。。。 你说的客观,这个全是事务的系统比想像的要复杂N多倍。 大部分人提出的建议都是网上随便搜出来的大规模架构的东西,其实没什么可参考性。 |
|
返回顶楼 | |
发表时间:2012-01-18
从我使用的过程中的体会啊。这个系统的关键问题不在页面做的差,而是后台的问题。
铁道部在带宽上面肯定下了血本了。 |
|
返回顶楼 | |
发表时间:2012-01-19
如果按网上说的1000万能做成这样已经不错了,大家看看08年奥运会订票系统,出来1小时就挂了,那并发量有这个高,先从业务流程着手,然后运力,其次才是技术和架构什么的
|
|
返回顶楼 | |
发表时间:2012-01-27
12306能在这么短的时间内,做到现在的状况已经非常不错了
别拿淘宝和腾讯说事,这些年还是业务逐步增长,中间挂了多少回大家都清楚;而且,这个的构架和他们的差异很大,让淘宝和腾讯在短时间(半年)去做,结果未必乐观很多,隔行如隔山,有时候是很有道理的 这个坛子上有很多淘宝、阿里、腾讯个的高手的,貌似没一个出来吱声的 |
|
返回顶楼 | |