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

gotolinux

我估计很多朋友还没有使用过这个系统，对购票的流程也不是很清楚。
购票的几个环节，大体上分，就是6个环节：
注册->登陆->查询->预定->订单确认->支付

具体在哪个环节出问题，哪些环节容易出问题，才是解决问题的关键。

不如一切

:wink:恩，学习了。。。

safedead

无牙 发表于 2012-01-19 15:24
后端的数据库服务器一点也不忙

AppServer确实不是很忙
但是Radware前面的WebServer忙的都粉碎性蛋疼了

minyoni

业务逻辑恰恰是技术人所往往忽略的，在极短的时间内，要求承载海量的请求，这个业务就欠缺考量，

首页并不马上进入订票缓解，打出广告例如“10：00~10:30”受理 津京地区至湖广地区的 车票。先让大家有个有个理性的印象，不要一窝蜂的涌进来。

“按时间段发放区间路段的车票进行在线的订购，或许是个缓解的方法。”

呵呵，当然，12306 本身做的比较不给力是主要的原因。估计铁道部的领导们也想不到他们的“产品”会如此的受“欢迎”

minyoni

回复 124# minyoni
做下补充，没有运行团队来做支撑。铁道部很难把这次 项目称作项目啊

   

wzs993636

我觉得吧，正如前面兄弟所说的，这个系统的核心数据库还是旧的，只是提供相关API给网站使用，所以问题也不能单单归咎于网站本身。

wzs993636

毕竟整个系统不单单是只有网上订票一种，柜台订票，电话订票仍然占了很大一部分，而且如果有分优先级的话，柜台的优先级应该还是最高的！

gotolinux

wzs993636 发表于 2012-01-20 09:25
毕竟整个系统不单单是只有网上订票一种，柜台订票，电话订票仍然占了很大一部分，而且如果有分优先级的话， ...

这个跟柜台、电话没关系，柜台和电话订票的诟病是很难解决的，而网络订票就不一样了。

无牙

wzs993636 发表于 2012-01-20 09:20
我觉得吧，正如前面兄弟所说的，这个系统的核心数据库还是旧的，只是提供相关API给网站使用，所以问题也不能 ...

网络订票的核心和以前的客票系统已经是不一样的了。

网络订票用的是Oralce RAC，老客票用的是Sybase。

fengyun530

     看到了几个问题，页面结构可以进一步优化，感觉这类公共类站点，读的信息肯定要远高于写的信息量，所以前端缓存是必须的，关键是用什么方式，这个应该是最核心的地方，其次就是安全问题了。
     虽然现在用了CDN加了速度，不过将来也一样会遇到问题。
      CDN铁道部信息技术中心选择了51的，我觉得51实力很一般，请看一下：http://www.chinanetcenter.com/pro_idc_fwqzy_zyys.html，页面品牌里的后台程序语句都暴出来了。可见公司其实力了