如何设计高并发高流量的12306在线票务系统

yahoon

yuhongchun 发表于 2012-01-17 17:52
这只是一个提供理论值而矣

我觉得最高并发是远高于这个数的 至少从24点到7点半之前,感觉访问的量不会特别大的

yahoon

Gray1982 发表于 2012-01-17 17:55
数据库要改的N多，最主要的不能是总直接查询库，要有缓存；读写还得分离，库、表的设计也要跟行上，字段 ...

据我实际使用发现,现在他查的方式就是缓存

yahoon

sania9 发表于 2012-01-17 17:43
亿级别的架构确实要考虑的太多，从编码规范到前端缓存、db压力，甚至带宽等等。
不过这会的优化可以先从业 ...

中签这个有点意思
感觉跟北京汽车摇号一样

我顶一下

同样是拼人品和运气,摇号总比这样哄抢好.
另外,必须是第三方机构负责摇号

lltlk

头两天，是网站打不开，如yanyangtian4502所说，应该要优化web代码。CDN是必须的，事实上也是上了CDN。

用户登录，可以对用户进行分区，认证模块用内存+文件的cache。用户登录时利用索引路由到分区的认证模块。session可以用专门的session server管理，而不是web app管理。
上亿注册用户，每天百万级别的活跃用户，目前没大问题，也可随意扩容。
个人见解。

hjk857

政府网站一向既难看又难用，一点都不顾及用户的感受，费用支出却是最高的。
非常赞成基础架构没做好的说法，基础没弄好其它的都白扯。

gotolinux

我认为这篇讨论大部分地方可以参考：http://bbs.chinaunix.net/thread-3626937-7-1.html

主要值得提出来的地方，我认为有以下几点：
1.流量分析，其实这个在应用上架前就能做好，铁道部可以从以往的人口流量映射访问流量。当然这样会有一定的偏差，同时也涉及到地域性流动人口的知识架构。
不过现阶段的工作是改进，对于已经运行这么长时间的系统，流量的掌握应该已经到了比较精确的地步。
下一步就是cache服务器的部署、CDN的选择、各种负载均衡系统的选择等等问题，这些都可以参照以前的讨论《千万级pv高性能高并发网站架构与设计交流探讨帖》http://bbs.chinaunix.net/thread-3626937-7-1.html。

2.应用本身的架构，也就是此次讨论的主旨——在线票务系统的架构。
首先，就是开发语言的选择，从页面上来看，应该是java。
其次，开发框架的选择。
再次，脚本服务器的选择，从曾经出错的信息上看有网友说是JBoss。
换架构可以说是不可能的是，只能优化、优化、再优化。

3.应用的部署
扯开分布式部署、负载均衡等技术不说。我认为，这个大规模的应用完全可以采取省级部署的方式，分别用二级域名来引导进入不同地域进行购票。比如：广东就用gd.12306.com，湖南就用hn.12306.com，把整个系统划分为多个小系统，并在后端集中。

4.其他方面
（1）系统忙会造成用户强行退出，用户不得不多次登陆，这也增加了系统的负载，同时也成就了大量的刷票软件的存在。
（2）支付方面，需要在一定时间内完成付款，否则订单取消。其实可以做个充值功能，用户先查好所需车票的金额，冲入账户，如购票失败则可随时申请退款。
（3）数据库方面。12306的数据库主要涉及两方面：用户信息和票务信息。这两方面的数据分离我认为是必须的，即减轻系统负载，也增加系统相应。读写分离、cache、负载就不多说了。

gotolinux

曾经接触过一个政府的项目，要求由一国产的中间件换成websphere，给了一个月的时间，硬是没完成，最后也只能将就着用。
政府项目有其特殊性，有其特殊的招标渠道、有指定的投标商。
其实这些不可避免的“人文因素”往往会照成系统的“弱应用性”。

kns1024wh

回复 1# 无风之谷


    "是否是无证程序员"

老男孩linux培训

回复 36# gotolinux
我认为这篇讨论大部分地方可以参考：http://bbs.chinaunix.net/thread-3626937-7-1.html

主要值得提出来的地方，我认为有以下几点：
1.流量分析，其实这个在应用上架前就能做好，铁道部可以从以往的人口流量映射访问流量。当然这样会有一定的偏差，同时也涉及到地域性流动人口的知识架构。
不过现阶段的工作是改进，对于已经运行这么长时间的系统，流量的掌握应该已经到了比较精确的地步。
下一步就是cache服务器的部署、CDN的选择、各种负载均衡系统的选择等等问题，这些都可以参照以前的讨论《千万级pv高性能高并发网站架构与设计交流探讨帖》http://bbs.chinaunix.net/thread-3626937-7-1.html。

2.应用本身的架构，也就是此次讨论的主旨——在线票务系统的架构。
首先，就是开发语言的选择，从页面上来看，应该是java。
其次，开发框架的选择。
再次，脚本服务器的选择，从曾经出错的信息上看有网友说是JBoss。
换架构可以说是不可能的是，只能优化、优化、再优化。

3.应用的部署
扯开分布式部署、负载均衡等技术不说。我认为，这个大规模的应用完全可以采取省级部署的方式，分别用二级域名来引导进入不同地域进行购票。比如：广东就用gd.12306.com，湖南就用hn.12306.com，把整个系统划分为多个小系统，并在后端集中。

4.其他方面
（1）系统忙会造成用户强行退出，用户不得不多次登陆，这也增加了系统的负载，同时也成就了大量的刷票软件的存在。
（2）支付方面，需要在一定时间内完成付款，否则订单取消。其实可以做个充值功能，用户先查好所需车票的金额，冲入账户，如购票失败则可随时申请退款。
（3）数据库方面。12306的数据库主要涉及两方面：用户信息和票务信息。这两方面的数据分离我认为是必须的，即减轻系统负载，也增加系统相应。读写分离、cache、负载就不多说了。
=======================
老男孩评：考虑的很多，赞！
能事先分析需求，并按地域分域名思路很不错，不过这个不同地点购票可能难做，这个要和现有的不同地区的铁路售票系统节点对接（资金太大），
找几个核心骨干的售票系统对接就好。
之所以堵，这个和对接的铁路售票系统 的节点多少及铁路售票系统整个吞吐有关。网络除了并发大，还要连续刷新。是平时各个点售票并发的好多倍。
比如平时北京也就上千个售票点，大家排队就是队列。。。现在在这个队列没了，海量的人直接打开页面刷。并发页面访问10几万都有可能。
考虑到铁路的实际售票系统的吞吐情况，提交数据 使用队列 可能是必须的，否则，就得改造传统的售票系统了。
除了和售票系统对接交换数据外，网站本身也需要一个分布式的数据库。

先写这么多。
扔个分布式票务架构模型图：
   

kns1024wh

回复 3# yuhongchun


    如果是j2ee的应用，很多项目的实施中是不会考虑前端的web应用服务器采用Nginx调度，多数是直接用j2ee的应用平台的。而且此类大型系统比人是要用到小鸡的，目前国内的行业基本上是如此。开源技术多数是在互联网领域应用很多的。