超级军网铁道部网上订票系统是各种坑爹的集大成者
来源：百度文库 编辑：超级军网 时间：2024/04/27 22:59:35
从今天早上到现在 成功进入系统三次 一次是无法提交订单 莫名退回到 登陆页面 第二次是无法支付 现在登陆进去 后又没票可买 坑爹啊 是不是
从今天早上到现在 成功进入系统三次 一次是无法提交订单 莫名退回到 登陆页面 第二次是无法支付 现在登陆进去 后又没票可买 坑爹啊 是不是
从今天早上到现在 成功进入系统三次 一次是无法提交订单 莫名退回到 登陆页面 第二次是无法支付 现在登陆进去 后又没票可买 坑爹啊 是不是昨天成功在网上订到两张卧铺的飘过
说不定到最后当天的票反而没人买了，哈哈。
我在互联网行业混了11年，第一次看到有一个网站的稳定性和性能受到那么大的关注。
壮东风 发表于 2012-1-7 17:21 
我在互联网行业混了11年，第一次看到有一个网站的稳定性和性能受到那么大的关注。
这网站享受了一回极限压力测试啊
看这破界面和操作流程
开发成本撑死30W吧
我在互联网行业混了11年，第一次看到有一个网站的稳定性和性能受到那么大的关注。
这网站享受了一回极限压力测试啊
看这破界面和操作流程
开发成本撑死30W吧
TDB这个网站就像各大火车站的一个缩影，主页面就像火车站前的广场，订票页面就车站的预售大厅，订单提交就是售票窗口的那个小窗户
成都这边的情况类似，网络订票几乎崩溃。但电话订票很好订，分分钟搞定。
rcoolduck 发表于 2012-1-7 19:05
这网站享受了一回极限压力测试啊
看这破界面和操作流程
开发成本撑死30W吧
界面开发不值钱的，漂亮的界面也是吃处理器和带宽的。关键是架构和后台处理。现在的12306网站每分钟访问量就大的吓死人，各位算算自己登陆及查询平均一分钟几次？
按流量算前两天高峰有600多W用户的并发访问，这对所IT系统都是噩梦。问题关键1是票少人多，二是12天预售期搞得所有人都在同一时间去抢。
至少，现在的铁路售票系统比08北京奥运网上售票能力强多了。
从IT专业人士角度我理解12306目前的窘境，从买票者角度还是要对大批铁路不能开通使用导致今年买票如抽奖表示气愤。
这网站享受了一回极限压力测试啊
看这破界面和操作流程
开发成本撑死30W吧
界面开发不值钱的，漂亮的界面也是吃处理器和带宽的。关键是架构和后台处理。现在的12306网站每分钟访问量就大的吓死人，各位算算自己登陆及查询平均一分钟几次？
按流量算前两天高峰有600多W用户的并发访问，这对所IT系统都是噩梦。问题关键1是票少人多，二是12天预售期搞得所有人都在同一时间去抢。
至少，现在的铁路售票系统比08北京奥运网上售票能力强多了。
从IT专业人士角度我理解12306目前的窘境，从买票者角度还是要对大批铁路不能开通使用导致今年买票如抽奖表示气愤。
我同事前天趴在公司的公用机前趴了一整天，折腾到下午4点半竟然被他买到一张17号的软卧。大吼一声：今天晚上请大家吃饭，搞起！
从今天早上六点到9点，无数次的提交订单，就是说系统忙，靠！
昨天买张18号硬座，今天一张19号硬卧。
幸好回家只要坐坐地铁和公交，要不然过年的路程真是烦心啊
问一下专业人士，对于这种有季节性峰值访问特点的网站，可以临时租用服务器和带宽来增加系统客户容量吗？
系统冗余度太烂了
agora 发表于 2012-1-9 07:56
问一下专业人士，对于这种有季节性峰值访问特点的网站，可以临时租用服务器和带宽来增加系统客户容量吗？
后台处理系统可以设计成集群等容易扩展的架构，当处理需求超过限制时，就增加服务器部署应用就行了。不过出口带宽等限制资源必须要达到最大要求，因为调整不容易。
问一下专业人士，对于这种有季节性峰值访问特点的网站，可以临时租用服务器和带宽来增加系统客户容量吗？
后台处理系统可以设计成集群等容易扩展的架构，当处理需求超过限制时，就增加服务器部署应用就行了。不过出口带宽等限制资源必须要达到最大要求，因为调整不容易。
silverbeetle 发表于 2012-1-9 10:01
后台处理系统可以设计成集群等容易扩展的架构，当处理需求超过限制时，就增加服务器部署应用就行了。不过 ...
我倒觉得带宽问题好办，都是国有企业，临时拉1G线路过来很容易。
后台处理系统可以设计成集群等容易扩展的架构，当处理需求超过限制时，就增加服务器部署应用就行了。不过 ...
我倒觉得带宽问题好办，都是国有企业，临时拉1G线路过来很容易。
壮东风 发表于 2012-1-9 10:25
我倒觉得带宽问题好办，都是国有企业，临时拉1G线路过来很容易。
你也知道国有企业的效率的，拉根光线要一周，一周后，黄花菜都凉了。
我倒觉得带宽问题好办，都是国有企业，临时拉1G线路过来很容易。
你也知道国有企业的效率的，拉根光线要一周，一周后，黄花菜都凉了。
silverbeetle 发表于 2012-1-9 10:28
你也知道国有企业的效率的，拉根光线要一周，一周后，黄花菜都凉了。
这种事情要惊动上层的，绝对一天内搞定。
电信反应不慢，我家里光纤出的毛病，都是在很短时间内解决的。
但我觉得带宽不是问题，12306的图片极少，html、css也不大，主要还是处理能力不足。
你也知道国有企业的效率的，拉根光线要一周，一周后，黄花菜都凉了。
这种事情要惊动上层的，绝对一天内搞定。
电信反应不慢，我家里光纤出的毛病，都是在很短时间内解决的。
但我觉得带宽不是问题，12306的图片极少，html、css也不大，主要还是处理能力不足。
壮东风 发表于 2012-1-9 10:32
这种事情要惊动上层的，绝对一天内搞定。
电信反应不慢，我家里光纤出的毛病，都是在很短时间内解决的。 ...
你的意思是电信给你牵根光纤备用，忙你就用，给钱，不忙你就不用，不给钱。害怕有点理想了哦。
另外，带宽确实不是太大的问题，但是现在带宽看上去还是有问题的。
这种事情要惊动上层的，绝对一天内搞定。
电信反应不慢，我家里光纤出的毛病，都是在很短时间内解决的。 ...
你的意思是电信给你牵根光纤备用，忙你就用，给钱，不忙你就不用，不给钱。害怕有点理想了哦。
另外，带宽确实不是太大的问题，但是现在带宽看上去还是有问题的。
啥事一牵涉到政治任务，在国企中就不谈钱不钱的了。。。
没见512中，哪个国企还谈钱。。。
没见512中，哪个国企还谈钱。。。
其实这种情况使用专用客户端比用BS模式合适
今天折腾一天，登陆12306三次，但无数次提交订单都失败，最后电话搞定。
现在有点眼花，登陆什么网站都是“网络繁忙，请稍后再登陆”
现在有点眼花，登陆什么网站都是“网络繁忙，请稍后再登陆”
深空探索 发表于 2012-1-9 13:56
其实这种情况使用专用客户端比用BS模式合适
BS模式可以用，但要用肥客户端。
其实这种情况使用专用客户端比用BS模式合适
BS模式可以用，但要用肥客户端。
silverbeetle 发表于 2012-1-9 10:28
你也知道国有企业的效率的，拉根光线要一周，一周后，黄花菜都凉了。
铁通
不拉枪毙
你也知道国有企业的效率的，拉根光线要一周，一周后，黄花菜都凉了。
铁通
不拉枪毙
壮东风 发表于 2012-1-9 10:25
我倒觉得带宽问题好办，都是国有企业，临时拉1G线路过来很容易。
肯定不是带宽的问题
每天1Y访问量 打开网页比CD快多了
我琢磨着架一个刀片在那里 登不进去却不能阻塞崩溃 软件设计本身就是让你登不上去 登上了就很大概率买到票
否则票少人多 几百人同时抢一张票 刷出来都是无票 到时铺天盖地骂娘 说票都被倒了
我倒觉得带宽问题好办，都是国有企业，临时拉1G线路过来很容易。
肯定不是带宽的问题
每天1Y访问量 打开网页比CD快多了
我琢磨着架一个刀片在那里 登不进去却不能阻塞崩溃 软件设计本身就是让你登不上去 登上了就很大概率买到票
否则票少人多 几百人同时抢一张票 刷出来都是无票 到时铺天盖地骂娘 说票都被倒了
明明是想靠近 发表于 2012-1-10 01:13
肯定不是带宽的问题
每天1Y访问量 打开网页比CD快多了
我琢磨着架一个刀片在那里 登不进去却不能阻塞崩 ...
事实情况是登上的概率远大于订票成功的概率。我昨天成功登陆三次，大约试10次成功一次。但选票后递交订票单无数次，一次也没有成功。
肯定不是带宽的问题
每天1Y访问量 打开网页比CD快多了
我琢磨着架一个刀片在那里 登不进去却不能阻塞崩 ...
事实情况是登上的概率远大于订票成功的概率。我昨天成功登陆三次，大约试10次成功一次。但选票后递交订票单无数次，一次也没有成功。
silverbeetle 发表于 2012-1-10 00:08
BS模式可以用，但要用肥客户端。
肥客户端就没意义了
BS模式可以用，但要用肥客户端。
肥客户端就没意义了
agora 发表于 2012-1-10 07:38
事实情况是登上的概率远大于订票成功的概率。我昨天成功登陆三次，大约试10次成功一次。但选票后递交订票 ...
Where Visitors Go on 12306.cn
Subdomain
Percent of Visitors
12306.cn
96.35%
dynamic.12306.cn
26.15%
epay.12306.cn
6.10%
没搞错的话
成功提交订单进到支付页面的只有6%多一点，支付成功的估计只有6%
agora 发表于 2012-1-10 07:38
事实情况是登上的概率远大于订票成功的概率。我昨天成功登陆三次，大约试10次成功一次。但选票后递交订票 ...
Where Visitors Go on 12306.cn
Subdomain
Percent of Visitors
12306.cn
96.35%
dynamic.12306.cn
26.15%
epay.12306.cn
6.10%
没搞错的话
成功提交订单进到支付页面的只有6%多一点，支付成功的估计只有6%
agora 发表于 2012-1-10 07:38
事实情况是登上的概率远大于订票成功的概率。我昨天成功登陆三次，大约试10次成功一次。但选票后递交订票 ...
如果带宽不够，网页都打不开。
登录开销比较小，而下订单我猜想需要跟票务系统通讯，为了保证原有售票终端的响应，肯定有限制。
事实情况是登上的概率远大于订票成功的概率。我昨天成功登陆三次，大约试10次成功一次。但选票后递交订票 ...
如果带宽不够，网页都打不开。
登录开销比较小，而下订单我猜想需要跟票务系统通讯，为了保证原有售票终端的响应，肯定有限制。
明明是想靠近 发表于 2012-1-10 01:13
肯定不是带宽的问题
每天1Y访问量 打开网页比CD快多了
我琢磨着架一个刀片在那里 登不进去却不能阻塞崩 ...
html、css、js、图片都可以放在cdn，流量一定是不大的。
肯定不是带宽的问题
每天1Y访问量 打开网页比CD快多了
我琢磨着架一个刀片在那里 登不进去却不能阻塞崩 ...
html、css、js、图片都可以放在cdn，流量一定是不大的。
壮东风 发表于 2012-1-7 17:21
我在互联网行业混了11年，第一次看到有一个网站的稳定性和性能受到那么大的关注。
一天十亿的点击啊，多少电商作梦都不敢想的事情啊，没暴已经让我很佩服了。
订票网站其实是台人品测试仪。
我在互联网行业混了11年，第一次看到有一个网站的稳定性和性能受到那么大的关注。
一天十亿的点击啊，多少电商作梦都不敢想的事情啊，没暴已经让我很佩服了。
订票网站其实是台人品测试仪。
明明是想靠近 发表于 2012-1-10 01:10
铁通
不拉枪毙
铁通已经并给移动了，不过让它出点力肯定还是很容易的。事实上，铁道部还有自己的网络系统，我甚至认为这个订票系统就在铁路系统自己的IDC里。总之，带宽绝对不是问题，要多少有多少。
铁通
不拉枪毙
铁通已经并给移动了，不过让它出点力肯定还是很容易的。事实上，铁道部还有自己的网络系统，我甚至认为这个订票系统就在铁路系统自己的IDC里。总之，带宽绝对不是问题，要多少有多少。
深空探索 发表于 2012-1-10 08:35
肥客户端就没意义了
为什么没有意义了？
肥客户端就没意义了
为什么没有意义了？
silverbeetle 发表于 2012-1-10 11:29
为什么没有意义了？
BS的一个主要优势就是廋客户端
为什么没有意义了？
BS的一个主要优势就是廋客户端
深空探索 发表于 2012-1-10 12:14
BS的一个主要优势就是廋客户端
嗯，这个是我不太熟悉的领域。我一直以为采用浏览器+服务端就叫BS。话说在浏览器上采用JSP啊神马的做一个肥客户端有问题嘛？采用cache不能处理吗？
BS的一个主要优势就是廋客户端
嗯，这个是我不太熟悉的领域。我一直以为采用浏览器+服务端就叫BS。话说在浏览器上采用JSP啊神马的做一个肥客户端有问题嘛？采用cache不能处理吗？
silverbeetle 发表于 2012-1-10 12:23
嗯，这个是我不太熟悉的领域。我一直以为采用浏览器+服务端就叫BS。话说在浏览器上采用JSP啊神马的做一个 ...
我的看法是，对于铁道部的订票系统，相比BS模式，采用独立客户端＋服务器的方式，主要有以下好处：
1 可以定义比HTTP等更加简单、高效的通信协议，降低服务器端的处理压力
2 服务器端可以使用C/C++，比java更加高效
3 服务器端可以更加灵活配置，充分利用分布计算，提高处理能力
4 客户端的用户界面更加友好和迅捷
嗯，这个是我不太熟悉的领域。我一直以为采用浏览器+服务端就叫BS。话说在浏览器上采用JSP啊神马的做一个 ...
我的看法是，对于铁道部的订票系统，相比BS模式，采用独立客户端＋服务器的方式，主要有以下好处：
1 可以定义比HTTP等更加简单、高效的通信协议，降低服务器端的处理压力
2 服务器端可以使用C/C++，比java更加高效
3 服务器端可以更加灵活配置，充分利用分布计算，提高处理能力
4 客户端的用户界面更加友好和迅捷
深空探索 发表于 2012-1-10 12:45
我的看法是，对于铁道部的订票系统，相比BS模式，采用独立客户端＋服务器的方式，主要有以下好处：
1 可 ...
独立客户端也可以啊，例如网银的专业版客户端很多就是独立的。
1.没必要。你自己定义一套通讯协议兼容性太差，现有的http,https,socket足够12306折腾了。
2.你怎么知道他的服务端不是用的C/C++。如果不是，说明TDB不想花钱又想做高效的系统，这样子的话注定是一个茶几啊。而且这个采用BS和CS完全没有关系。
3.就是用群集，不过是否采用群集需要经过充分的论证。我觉得采用一台大机估计也够用了。不管采用什么方式，网络都必须好好设计一下。
4.这个也和BS模式没有关系，而是和实现有关系。业界的情况是采用JAVA做客户端比采用C/C++做客户端有优势。
我的看法是，对于铁道部的订票系统，相比BS模式，采用独立客户端＋服务器的方式，主要有以下好处：
1 可 ...
独立客户端也可以啊，例如网银的专业版客户端很多就是独立的。
1.没必要。你自己定义一套通讯协议兼容性太差，现有的http,https,socket足够12306折腾了。
2.你怎么知道他的服务端不是用的C/C++。如果不是，说明TDB不想花钱又想做高效的系统，这样子的话注定是一个茶几啊。而且这个采用BS和CS完全没有关系。
3.就是用群集，不过是否采用群集需要经过充分的论证。我觉得采用一台大机估计也够用了。不管采用什么方式，网络都必须好好设计一下。
4.这个也和BS模式没有关系，而是和实现有关系。业界的情况是采用JAVA做客户端比采用C/C++做客户端有优势。
是否要采用独立客户端需要考虑业务逻辑的复杂度，12306除了查询就是订票。最多再加点登陆退出，注册神马的，这个业务逻辑其实很简单吧。我觉得完全没必要搞成独立的客户端。只是需要将部分登陆数据和查询结果存放在本地cache中就可以了。
参考ISP的网上营业厅，也是采用的BS模式，也没见有什么问题啊。所以BS模式不是根本问题所在。
silverbeetle 发表于 2012-1-10 13:04
独立客户端也可以啊，例如网银的专业版客户端很多就是独立的。
1.没必要。你自己定义一套通讯协议兼容性 ...
1 这种自己定义、自己使用的协议无所谓兼容性，比HTTP效率高是肯定的
2 已有人分析出12306用的是struts框架
3 对于这种性能瓶颈的应用，服务器端的分布计算是一种有效的解决方式，而独立开发的服务器软件比基于web服务器的软件框架更加灵活和高效
4 基于桌面的应用可以比浏览器中的页面做得更友好，功能更强
web可以做很多事，但并不是所有的事都适合web去做
独立客户端也可以啊，例如网银的专业版客户端很多就是独立的。
1.没必要。你自己定义一套通讯协议兼容性 ...
1 这种自己定义、自己使用的协议无所谓兼容性，比HTTP效率高是肯定的
2 已有人分析出12306用的是struts框架
3 对于这种性能瓶颈的应用，服务器端的分布计算是一种有效的解决方式，而独立开发的服务器软件比基于web服务器的软件框架更加灵活和高效
4 基于桌面的应用可以比浏览器中的页面做得更友好，功能更强
web可以做很多事，但并不是所有的事都适合web去做