免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
最近访问板块 发新帖
楼主: 无风之谷
打印 上一主题 下一主题

如何设计高并发高流量的12306在线票务系统 [复制链接]

论坛徽章:
0
91 [报告]
发表于 2012-01-18 16:34 |只看该作者
无牙 发表于 2012-01-18 15:55
我们可以先从网上订票的流程分析一下。

网上订票至少会有如下几步:


这些差不多都是只要是带宽,网线,交换机等都能解决的
主要还是在看架构上的一个设计,如果涉及到细节,不是说用了什么就可以,而是说怎么用,怎么调才可以,像你说的分库,分表,读写分离,表引擎,字段等
IP限制,session限制,时间失效性,这也都是需要设定一个会更的值

论坛徽章:
0
92 [报告]
发表于 2012-01-18 16:34 |只看该作者
除了前面说的,有朋友也指出了队列的问题,我认为队列处理也是一个非常重要的问题。
在线订票和在窗口买票的原理、过程都一样,就是排队。如何处理好这个队列,十分关键。

论坛徽章:
0
93 [报告]
发表于 2012-01-18 16:39 |只看该作者
Gray1982 发表于 2012-01-18 16:34
这些差不多都是只要是带宽,网线,交换机等都能解决的
主要还是在看架构上的一个设计,如果涉及到细节 ...


目前,系统在出问题以后采用的解决方案就是硬件堆积,同样问题没有得到解决。可见问题的根本是软件系统的架构。

论坛徽章:
0
94 [报告]
发表于 2012-01-18 16:40 |只看该作者
看来各位忽视了一个严重的问题:
本人对现状非常满意:
------------------------------
原因如下:
现在主要矛盾是春节突然增加的人流量与现有的动力之间的矛盾。
池子里的票远小于出行选择火车的需求。
因此,网络订票系统这样的实现,对多数人是公平的。
反过来说:如果这个系统如TAOBAO一样,响应充分。
会有什么结果:
就是一些人将身份证号给订票的“机构”,专门的这些“机构”会发挥集中处理的功能。
而像一些ITER或者白领。没有那个时间和人力来与这些“机构”竟争。

最后这帮人还要去排除和黄牛。
-----------------------------------------------
回到现状,现在网上放票的量是一定的,最终全部是订完了,那不断点击,或者有运气成分的情况下。
人们的机会的较为平等的。

论坛徽章:
0
95 [报告]
发表于 2012-01-18 16:41 |只看该作者
云风也在他的blog中谈到了队列问题,大家可以参考下。
我们来说说排队系统是怎么做的:

其实就类似我们去热门馆子吃饭拿号。只不过要防止别人伪造号插队而已。

如果你来一个人(一次 HTTP 请求),我就随机产生一个我做过一些签名处理的号码返回给你。暂时称为 ticket id 。这个 ticked id 是很难伪造的。

系统在内存里开一个大数组(32G 内存够排上亿人了吧),就是一循环队列。把这个 ticket id 放在队列尾。

用户现在拿着 ticket id 向网关发起请求。网关利用一次 hash 查询,在内存中的数组队列里查到它的位置,立刻返回给用户。用户的前端就可以看到,他在这个网关(售票大厅)前面还有多少人等着。

这里的关键是,整个队列都在本机的内存中,查询返回队列中的位置,可以实现的比一个处理静态文件的 web server 还要高效。静态文件至少还要去调用文件 IO 呢。静态文件 web server 可以处理多少并发量,不用我介绍了。

同时,前端会控制用户拿着 ticket id 查询队列位置的频率。高负载时可以 1s 一次,甚至更长时间。为了防止用户自己写脚本刷这个请求(虽然没有太大意义,因为刷的多也不会排到前面去),如果见到同一个 ticket id 过于频繁的查询。比如 10s 内查询了 20 次以上。就直接把这个 ticket id 作废。持有这个 ticket 的人就需要重新排队了。

对于最后排到的人,系统会生成一个唯一的不可伪造的 session id ,用户下面就可以通过这个 session id 去做实际的购票流程了。可以连去真正的购票服务器,也可以通过网关中转。非法的 session id 会立刻断掉,用户一旦知道伪造 session id 几乎不可能,只有通过 ticket id 排队拿到,除非是恶意攻击系统,不然不会有人乱拿 session id 去试。

我们再给每个 session id 设置一个最长有效时间,比如半小时。如果超过半小时还没有完整购票流程,那么就重新去排队。

至于同时开放多少个 session id ,也就是相当于开放多少个购票窗口,就取决于购票系统能承受的负载了。不过简单计算一下,就知道有排队系统保证了良好的次序,再以计算机的吞吐能力,解决不过几亿人的购票请求,即使这些人都同来排队,也就是一组机器几小时的处理量而已。

论坛徽章:
1
CU十二周年纪念徽章
日期:2013-10-24 15:41:34
96 [报告]
发表于 2012-01-18 16:49 |只看该作者
这还真不是设备就能解决的问题。 这个系统不可能盲目的扩展,这个系统其实上线已经有一段时间了,不就是春运的时候大家才抱怨这个网站不行。

现在最大的问题是12306这个网站的构架是什么样的?是通过什么搭建的?

LZ能不能找个了解这个网站结构的人介绍一下?我在网上搜了一下,还真没有这方面的资料。

否则大家的讨论没有一点意义。  



论坛徽章:
1
CU十二周年纪念徽章
日期:2013-10-24 15:41:34
97 [报告]
发表于 2012-01-18 16:50 |只看该作者
kingstar 发表于 2012-01-18 16:40
看来各位忽视了一个严重的问题:
本人对现状非常满意:
------------------------------


我也有同感

论坛徽章:
0
98 [报告]
发表于 2012-01-18 16:57 |只看该作者
无牙 发表于 2012-01-18 16:49
这还真不是设备就能解决的问题。 这个系统不可能盲目的扩展,这个系统其实上线已经有一段时间了,不就是春运 ...


对,我们目前的状况是,只知道系统有问题,具体是哪方面的问题不得而知。也就没办法做到具体问题具体分析了。

论坛徽章:
0
99 [报告]
发表于 2012-01-18 17:21 |只看该作者
泱泱大国,充斥着酒囊饭袋。

论坛徽章:
0
100 [报告]
发表于 2012-01-18 20:01 |只看该作者
本帖最后由 QQ_921 于 2012-01-18 20:34 编辑

我认为系统性能需要从底层进行设计:

各个省级别系统设计:
网络:利用CDN、动态DNS等技术实现网络高可用和负载均衡。
      高性能防火墙(DDOS)、路由器、交换机,最好使用类似F5的负载均衡设备,从网络层将请求分流。
      每个服务器4块网卡绑定加大网络带宽。      

服务器
WEB服务器: 使用PC SERVER 利用F5进行分流之后,可以使用比较成熟的Nginx、MemCatch、中间件等软件实现区域性的负载均衡和高可用。  
数据库服务器:可以使用小型机。利用各种同步、复制等技术实现读写分离等 高性能数据库系统。

存储:保证系统读写性能的同时,利用SAN网络,将数据分级,各个级利用存储的同步、异步技术实现高性能本地、异地存储。

总部数据中心:
全国各个省级别数据库同步到总部数据中心。做好数据的异地灾备。

软件参数优化:
操作系统、WEB软件、中间件、数据库软件等;存储设备参数等。

在上线之前最好进行大量的压力测试,尽量让结果贴近真实。或者写一套全流成测试程序,利用高性能服务器进行压力测试。
-----------------------------------------------------------------------------------------------------------
高能的系统绝对不是单凭大量的硬件可以堆出来的,所有功能也不是那些开源软件都可以实现的。
最好是将开源软件的优势与成熟的硬件产品结合起来,可以达到更好的效果。
-----------------------------------------------------------------------------------------------------------
程序我不懂,不敢吓白话了。

最近在找工作,有机会搞搞铁路的售票系统就好了。    :》
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP