从奥运订票系统瘫痪说起——谈FastCGI 与IT 架构
作者：用户
本文讲的是从奥运订票系统瘫痪说起——谈FastCGI 与IT 架构，
2008年，对于首都人民来说，没有什么比奥运会更大的事情了。如何买到一张称心如意的比赛门票，也成了很多 人的一个梦想。然而，在奥运官网抢票购买的时候，这个梦想却轻易地被网上购票系统的瘫痪击成碎片，很多充满热情的老百姓们
2008年，对于首都人民来说，没有什么比奥运会更大的事情了。如何买到一张称心如意的比赛门票，也成了很多 人的一个梦想。然而，在奥运官网抢票购买的时候，这个梦想却轻易地被网上购票系统的瘫痪击成碎片，很多充满热情的老百姓们也因此郁闷无比。由于搜狐承担了 奥运的官网，我又在那里工作过相当长一段时间，很多兄弟抢票失败，于是便认定是搜狐的系统太烂，而找我抱怨。其实当时我也很是郁闷：首先这个系统并非 搜狐开发；其次我也不在搜狐了。虽然如此，和我同行的一些朋友，又开始问我如何解决类似问题。我也反反复复讲了很多次，为了让广大读者能够深入了解背后的 原因和机制，写出来，大家一起讨论可能效果会更好。当然，这并不是我说的架构就一定能解决问题，仅仅是抛砖引玉而已。
在说架构之前，我先说一个老的技术，FastCGI。因为这个技术在后面的结构阐述中将起到非常重要的用处，原以为应该会有不少人会知道，但后来发现好像并非如此。
关于FastCGI的历史我就不再赘述，好像自1993年便有了。目前最热门的视频网站YouTube体系结构中，就有fast-cgi的模块。它支持很 多httpd服务器，在官方网站上列了很多，如apache，aXesW3 ，Microsoft IIS，Zeus，近几年才出的lighttpd没写，其实这个新的httpd也支持，但我个人觉得，支持最好的，可能还是Apache。
先讲讲FastCGI的原理，它和现在常用的运行请求不同，维基百科上有一个术语形容它，这里借用一下：◆
短生存期应用程序◆
长生存期应用程序
CGI技术的机制是：每次当客户请求一个CGI的时候，Web服务器就请求操作系统生成一个新的CGI进程；当CGI满足要求后，服务器就杀死这个进程。并且服务器对客户端的每个请求都要重复这样的过程。
而FastCGI技术的机制为：FastCGI程序一旦产生后，它可以持续工作，一直保持满足客户的请求直到自己被明确终止。如果你希望通过协同处理来提高程序的性能，你可以请求Web服务器运行多个FastCGI 应用程序。
由此CGI就是所谓的短生存期应用程序，FastCGI就是所谓的长生存期应用程序。
由于FastCGI程序并不需要不断产生新进程，可以大大降低服务器的压力。并且产生较高的应用效率。如今，流行的Java语言Servlet技术，在设计上就是参考FastCGI技术。FastCGI 配置运行一般来说分三种，这三种都需要Apache的mod_fastcgi 进行处理。1、Standalone FastCGI Server， 应该是独立的服务器。首先是需要把fastcgi作为单独的守护进程：
$ script/myapp_fastcgi.pl -l /tmp/myapp.socket -n 5
以下是这个fastcgi的守护进程的参数：-d -daemon #作为守护进程-p -pidfile #管理进程的PID写入到到文件的名称-l -listen #SOCKET的路径，机器名:端口, 或者端口-n -nproc #起始接受请求的进程数然后把下面的代码加入Apache的HTTPD.CONF：
FastCgiExternalServer /tmp/myapp -socket /tmp/myapp.socketAlias /myapp/ /tmp/myapp/# Or，
可以使用root的身份运行
Alias / /tmp/myapp/# Optionally，（使用rewrite模块）
RewriteRule ^/myapp$ myapp/ [R]然后重启Apache就OK了
2、Static mode：静态模式， 一般是用于单一确定的模式，就是在Apache 的httpd.conf 中间加上：
FastCgiServer /usr/local/apache/count/count.fcg -processes 1
Alias /c /usr/local/apache/count/count.fcg
此处建议再使用REWRITE的方式 重写整个的URL匹配， 使之看起来像一个静态页面。
RewriteRule read-(.+)-(.+)-(.+).$ /c?id=$1&sid=$2&port=$3 [L]
3、Dynamic mode：动态模式，可以使用各种各样的fastcgi，加入到httpd.conf中间去，比如：AddHandler fastcgi-script .fcgi 还有一个关键的设置：
&Directory /path/to/MyApp&
Options +ExecCGI&/Directory&
这个配置建议放在cgi-bin
这种类似的目录里面。
请注意第二种，服务器起几个进程，是由-processes 1 这个参数来控制的，所以起多少你可以自己来定，我们在下面的一个关键模块中将使用这个模式。
下面放一段FastCGI程序的C代码，来说明一下：
#include &fcgi_stdio.h&#include &string.h&
void main(void){int count = 0;while(FCGI_Accept() &= 0) {printf("Content-type:text/html ");printf(" ");printf("&HTML& ""&HEAD& "&TITLE&FastCGI&/TITLE& ""&META http-equiv="Content-Type" ""content="text/
charset=utf-8"& &body& " "Hello world!&br& ");printf("Request number %d.",count++);printf("&/body&&/html& ”);}exit(0);}
这是一个很简单的例子，就是简单的计数， 大家可以注意这一句：while(FCGI_Accept() &= 0)
这就是它和普通的短周期程序最大的不同，一般CGI都是运行完就退出了，这个FastCGI，在处理完一个请求完毕后，会回到初始状态等待下一次请求；如 果这个程序被设置成为只能启动一个，那么无论是否访问这个页面，都是在前一个的基础上加一，而不会又产生新的进程；从而后来者是从零开始。当然，很多人也 都注意到，此处就是一个死循环在不断处理；如果程序比较复杂，存在内存泄露的问题，此处产生的问题也要比普通CGI要严重得多，所以使用它对于程序员的要 求也更高。
上述方案应该是所有的Web应用解决方案中，执行效率和速度最高的。官方数据是说比一般的高15倍左右，在我的机器上测试，基本上每秒能够处理大概2400次请求。
再回到我们说的正题：奥运订票系统的瘫痪，关于访问量，当时的说法是800万/小时，那么平均到每秒就是超过2200次。这对于订票系统来说，确实是一个 非常大的考验。毕竟这种状况下，数据库是肯定承担不住这个量级的访问了。如何进行架构设计，是我们都需要面对的问题。
如果设计要应对这种高负载、高访问量的结构，首先考虑这个系统的需求。其实具体过程比较简单：1.用户认证2.查看所有可以订票的项目和票的数量3.选择项目，放入购物车4.确认并提交订单5.订单成功扣款过程虽然简单，但其实里面的东西也不少。
由于用户的数据量很大，注册用户数百万以上；而且这种系统，登录用户在操作时应该不存在普通应用的2/8原则。在抢票的当天，绝大部分注册用户都会登录， 而且时间会非常集中，所以并发会非常大。你如果预算充足，放一万台服务器来做这个事情，做一个分布算法，然后每台服务不超过十万个用户，这样你就能充分保 证你的用户感受和体验。可我想实际上没有哪个公司和系统会这么做，即使是财大气粗的奥组委。
这个时候，很多人可能会想：上面提到的FastCGI这种高效率的程序就是针对类似状况的解决方案，其实这是很常见的错误。我想这个订票之所以会瘫痪，就 是由于部分设计过于高效，而部分不可能那么高效的缘故。比如登录这个模块的效率估计就非常高，因为登录只是在数据库对比一下用户名和密码，而且数据更新也 不频繁，完全可以用分布式数据库来解决。但用户登录后，所有的压力会全部压在后面的功能上，从而造成系统的瘫痪。这个时候，由于人太多，你无论怎么高效， 在执行到后面复杂的购买功能时，都会出现瓶颈。而如果真的放一万台服务，你的数据如何分布同步，然后真的做到先来先得，会很难，如果设计的不好，和抽签也 就没什么两样了。
所以这个系统设计的策略应该是：如何做到在保证用户感受的情况下，合理控制进入系统的人数，这样你后面的设计和开发的压力会小的多，而且成本的控制非常清楚。
那么剩下的做法就很清晰了：系统的重点是用户登录，而不是一般理解的后面购票提交的系统功能。如何控制进入的人数，我觉得不妨参考银行的叫号方式来设计：系统先给用户发号，然后当了解到有资源空出来时，再让用户登录。
这个结构的重点就在呼号中心和序列号的分配上面。1. 序列号分配中心，技术重点在于高效和唯一性。也就是说当用户访问数达到海量之后，你需要非常迅速地分配唯一的序列号给登录的用户。这种状况 下，其他很多技术无法承担这种需求。开始提到的FastCGI，就是这个模式下的唯一选择。我们在开始安装的时候，就可以使用这种只起单个进程的模式，所 以分配用户的序列号只会是唯一的。由于FastCGI的高效率，从而保证登录的用户可以迅速分配到一个号，然后离开。当然如果你还不放心的话，还可以在前 面再加一个负载均衡的设备，完成对几个不同服务器负载分配，然后每个机器加不同的步长，并且起始数字不一样。比如：如果你有2台机器做发号工作，第一台起 始数字为1，第二台为2，步长为二，就是每次累加2，这样用户在不同的机器上也会得到唯一的号，而效率就能提高两倍。
至于记录用户序列号的方式，可以用cookie记录在客户端，然后进行加密。用户记录后，进入呼号中心，比对手里的号和前面排队的人数，然后提示用户前面 排队人数。比方说，你上来就是排号在3千万以后了，前面有2千多万人，我想如果这个人头脑正常的话，就不会说这个系统太烂，只能说自己起晚了，然后感叹中 国人实在是太多，就不会再上去反复不停地登录。2. 呼号中心，这里大概是最麻烦，也是最关键的地方。由于订票系统是B/S结构，服务器端有动作的时候，如何通知客户端是一个要点。也就是说， 当有人订票完毕，从系统中退出，此时，中控中心知道后，会通知呼号中心呼叫下一个。呼号中心如何找到应呼叫的号码，有两种解决方法，具体实现都不妨通过 AJAX的局部刷新达成。第一种，和叫号系统的号进行比对，如果发现匹配成功，就通知客户端进入系统。第二种，判断这个用户前面的排队数量，如果发现为零，就触发进入这个系统的动作。
还要注意一点，就是刷新时间长短和叫号的失效问题。时间太短，服务器压力会很大；时间太长又会容易造成这个用户感觉没有变化，从而感受很差。所以这个时间 的设置，个人觉得在5-15秒之间调整会比较合适。然后压力需要分摊，也就是叫号服务器需要设置多个。这样的话，用户刷新会命中不同的服务器，此时需要对 数据的同步进行特殊处理，其架构如下：
这个消息接受模块可以有两种模式取信息：短连接，每隔一段时间来传递信息；长连接，就是在消息接受和中控服务器中建立一个长效的消息通知机制。由于对于信息及时性的要求比较高，所以采用长连接比较合适。
消息接受模块和中控服务器之间需要进行序列号的交换。由于你不知道捏着这个号的用户命中哪台服务器，所以失效机制需要在几个服务器上同时进行。也就是说， 当一个用户退出，中控服务器知道后，开始确认最后一个登录号，然后发给所有前端，前端要能保证通知到用户，然后向用户发出通知，说明如果在给定次数内用户 还不进行登录或者认证，就提示后端此号失效，系统再分配下一个号给前端进行通知，
如果要设计得更加精巧，还可以建立前端服务器之间的消息通知机制。就是当一台服务器发现这个号在自己上面，就通知几个前端，不再对这个号进行判断，尽量节约资源。3. 中控服务器。我在开发社区和直播间的时候，都用到了这种方式，此处也用到了。不过在这个系统中，中控服务器不必使用单独的物理服务器，这里可以只是一个模块，它的主要用途是通知这些叫号服务器。由于数据很简单，所以中控的分发比较容易，不用设计特别复杂的协议。4. 认证中心：唯一需要改动的，就是判断用户的序列号是否可用并且是真正的号码。5. 购票中心：此处有很多种分布的方法，有很多可以借鉴的结构，这里就不赘述了。在这个架构中，购票唯一需要确认的就是可以同时承担多少人同时在线购买
前三个部分是这个架构的核心部分，由于进入的人数可以控制，后面的系统就还可以使用老的订票系统，只用确认同时放进来多少人就可以，也就是窗口没变，只是大家不再一拥而上，都是文明人，请排队拿号。当然后面的架构还可以重新进行优化和设计，从而尽可能提高放进来人的数量，在进行设计购票功能时还可以借鉴这方面的模式。比如：篮球是爱好观众比 较多的运动，大家都想到现场看看科比同学的扣篮，进来人后，可能大家都会一拥而上先抢这个，从而造成局部的数据瘫痪，影响整个系统。此时也可以在里面暗含 这个模块。买票的人少，拿号看不出来，拿了就能进去；一旦人数到了极限，对不起，也请排队。
限制人员进入后，未进入的人和购买的人不在同一个系统中，从而不会妨碍进入的人，买的人也会很快解决，他们可以迅速完成订单。提交后，系统发现这个人无法再订其他球票的时候，就可以认为再放一个人进来，或者干脆做绝一点，马上将其踢出去，以节约资源。
而且，由于你可以控制进入的用户数量，从而系统其他部分的设计简单多了。多大的钱办多少事，如果领导想快一点了事，预算充足，那么放入的人就多；如果心里 面没底，那么可以先放很少人进来，或者说大概估计一下，只放多少号，如就卖10万张票，那么只放50万个号，放完了就没有了。用户来晚了，连号都没有，也 只能慨叹自己不够及时，这样比系统瘫痪要好得多。
对于这个架构，其设计重点就是把系统整体的资源处于可控的状态。很多类似系统，如：报名，考试，短时间抢购等等实际应用系统，都可以采用类似的方式解决。好的架构，并不是说能解决所有的问题，而是很清楚自己能做什么，不能做什么。
以上是云栖社区小编为您精心准备的的内容，在云栖社区的博客、问答、公众号、人物、课程等栏目也有的相关内容，欢迎继续使用右上角搜索按钮进行搜索数据库
，以便于您获取更多的相关知识。
弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率
40+云计算产品，6个月免费体验
稳定可靠、可弹性伸缩的在线数据库服务，全球最受欢迎的开源数据库之一
云服务器9.9元/月，大学必备
云栖社区(yq.aliyun.com)为您免费提供相关信息，包括
，所有相关内容均不代表云栖社区的意见！热点：&&&&
南京长途车站售票系统突然瘫痪 因光纤故障(图)
昨天售票系统发生故障后，中央门长途汽车站售票大厅里挤满了等待买票的旅客 快报记者 顾炜 摄
　　长途车站售票系统突然瘫了
　　南京几大汽车站无一幸免，其间旅客滞留乱成一团
　　昨天是周末，南京的几大长途汽车站分外忙碌。下午2点40分左右，几大汽车站的电脑系统突然瘫痪，电脑售票、检票无法进行。尽管车站采取了手工撕票、旅客先上车后补票的办法，但由于手工撕票太慢，各个车站都滞留大量旅客，乱成了一锅粥。
　　事故发生后，南京市运管处第一时间启动应急预案，采取了人工售票及“Intel”传输式售票，同时积极排查，找出了原因：原来是“光纤”惹的祸。
　　经过紧急抢修，更换设备，系统故障在近17点时彻底排除，售票系统终于恢复正常。
　　中央门站和长途东站都乱了
　　中央门车站：
　　售票厅挤得满满当当
　　昨天下午近4时，记者在中央门长途汽车站售票大厅看到，14个售票窗前全站满了黑压压的旅客，一直排到大门口。准备到宿迁的李女士擦着额头的汗说，“我下午两点多就来排队了，电脑坏了，一直没有卖票，一连站了快两个小时。”几位到盐城的旅客也在抱怨，原以为电脑很快就修好，哪知道等了一个多小时还没好。
　　下午4时许，车站广播说，“电脑售票系统已恢复正常，请大家耐心等候。”人群里发出一阵欢呼，许多人长吁一口气。可电脑售票没一会儿，又死机了。
　　记者注意到，每个售票窗口排队人数约有100人，大厅里挤了1000多人，水泄不通。许多乘长途车的人背着大包小包，眼看天色暗了下来，担心当天走不了，急得团团转。
　　长途东站：
　　满员客车干等难发车
　　昨天下午4时40分，记者在长途东站看到，20多辆开往各地的长途客车齐刷刷地停在检票口外，每辆车都坐满了乘客。
　　司机们说，由于电脑系统瘫痪，车上旅客都没有买票，先上车坐下，等工作人员上来收钱撕票，给司机开单子后才能发车。“下午3点多钟人就坐满了，已等一个小时，还没来人开单子。”司机焦急地说。
　　到泰州、仪征、镇江、丹阳等地的车子还停在检票口外，等着工作人员上车收钱撕票，检票大厅内，到这几个地方的窗口前又围着几十个人，在等下一班车。有的检票口，工作人员在出售手撕票。由于速度太慢，旅客们急得连声催促。
　　一辆南京发往刁铺的客车满载，司机站在门口，工作人员拿着手工撕票和剪刀过来问，“到刁铺多少钱？”司机答，“到刁铺47元，到中间停的一个站46元。”工作人员说，“手撕票费事，全卖47元吧。”乘客们都没意见，工作人员便上车逐个收钱撕票。
　　启动应急机制：
　　内勤上阵也难保效率
　　电脑突发故障后，各汽车站都启动了应急预案，主要采取销售手撕票和先上车后补票两种办法。但由于手工撕票速度太慢，工作人员显得严重不足。
　　中央门长途汽车站相关负责人说，下午约2点40分电脑就坏了，持续约一个半小时没恢复正常。电脑系统坏了后，车站开始销售手撕票。由于是周末，下午乘长途汽车的人太多，造成不少旅客没能及时购票发车。
　　长途东站负责人介绍，发生故障后，车站立即启动应急机制，开始人工手撕票。下午4时左右电脑恢复正常了，可一会儿又坏了，一直到下午4时48分才恢复正常。担心再次瘫痪，车站也不敢用电脑，干脆继续采取人工手撕票的办法。正常情况下，只要一个人就可以收钱卖票，改用手撕票后，必须一个人收钱，另一个人拿着剪刀撕票，速度也慢多了。“我们动员所有工作人员全上去了，连内勤、保安也出动了。”
　　快报记者 赵守诚
　　原来是光纤设备出了问题
　　[应急措施]
　　第一时间启动应急预案
　　昨天，南京几大长途汽车站售票系统同时出现故障，无法售票。问题发生后，南京市运管处紧急启动应急预案，售票大厅广播告知旅客售票系统出问题了，同时启用备用售票方式，另一方面紧急安排技术人员排查原因。
　　据介绍，南京各大汽车站都有一种备用的“Intel”传输式售票，一般每个车站有两条这样的线，虽然看上去跟平时的电脑售票差不多，但相关人员透露：“速度慢多了。”记者获悉，市民们平时在公路客运站售票大厅买票时，都是通过“光纤”传输信号，车票信息显示非常快，一张票售出大概只要十几秒，但是换成“Intel”传输的话，敲一个键就要等一会，一张票售出差不多要一分钟左右。考虑到周末客流量大，这种售票窗只有两个窗口，因此各站还推出了人工售票，即手撕式备用票。
　　相关人士表示，昨天受影响的旅客在上千人，“正好周末，客流量比较大，尤其东站，学生比较多。”记者了解到，故障排除后，长途东站积压的旅客也一直到17：40左右才差不多疏散完。
　　[查出原因]
　　光纤传输设备出了问题
　　记者了解到，目前，南京市所有公路客运站的售票系统都是联网的，而联网售票主要依靠光纤连接，从联网中心接到各大客运站，“简单地说，就是联网中心发出的信号，通过光纤转换设备传输到各站的售票系统，这样就可以实现联网售票。”相关人士告诉记者，虽然听起来一点都不复杂，但是涉及的设备还是比较多，后来通过一一排查，发现不是市运管处自身设备的问题，而是“光纤”出了问题。
　　找到原因后，市运管处立即向相关部门汇报，相关部门立即派人赶到王家湾的“联网中心”。经过检查，原来是光纤传输设备出现故障。于是，相关部门紧急进行了维修，大约在15：50，恢复了售票系统的正常。可是短短的10多分钟后，售票系统再次瘫痪，“不能再修了，马上更新设备。”相关部门在20多分钟内就紧急调来了一台新设备，换上后，差不多接近17：00，故障彻底排除，各大客运站售票系统真正恢复正常。
　　[汲取教训]
　　定时安检避免再出意外
　　此次事件发生后，南京市运管部门与相关部门紧急开会协商，酝酿建立“定时安检”计划。
　　据介绍，本次事件发生前，市运管处自身设备比如服务器、网站、路由器等，他们都有检修机制，每天24小时都有人值班，值班人员需要对这些设备的运转情况进行检查并记录，“除此之外，我们还会不定期检查。”相关人士表示，“就是没想到光纤传输设备也会出问题。”
　　记者获悉，市运管处与相关部门初步达成共识，今后双方会形成一个完善的检修机制，避免类似意外的发生。同时，记者了解到，2011年春运前，他们将对所有设备进行检修更新，保证“零意外”。快报记者 毛丽萍(责任编辑：侯俊杰)
沈阳男子曾令军在这不足20平方米的厕所小家生活了五年，还娶了媳妇，生了大胖儿子……
竟然是孩子的妈……
温家宝总理在记者会上表示，现在改革到了攻坚阶段…[]
汪成荣面临的奖金被收回再分配难题，并不是一个单一事件。[]
数字之道：
搜狐论座：
慢画慢活：
搜狐侃事：
这样逛街图什么呢……
近期热点关注周杰伦演唱会狂老金赚奶粉钱，售票系统一度瘫痪，门票被炒成天价，还是卖空了！周杰伦演唱会狂老金赚奶粉钱，售票系统一度瘫痪，门票被炒成天价，还是卖空了！梅姑娱乐圈百家号3月28日，2017周杰伦天津演唱会门票开售，一时间，售卖周杰伦演唱会的大麦网一度瘫痪，许多网友都表示，12:30刚开始销售，就再进不去大麦网，此次大麦网售卖周杰伦演唱会门票只通过APP售卖，电脑端为开启售卖。而大河票务网显示，最便宜的看台380元和480元的票已经售空。　　2017周杰伦天津演唱会门票多少钱?据大麦网显示，此次周杰伦演唱会天津站门票共设置了6档，看台票有三档，价格分别为：380元、480元和680元，内场票也分三档，价格分别为：1080元、1580元和1880元。据大河票务网显示，目前周杰伦天津演唱会的门票几乎快被炒成天价了，380元和480元的票分别卖680元和780元，而内场1880元的票被炒到了3080元，即使这样，最便宜的两档票也还是缺票。可见，周董是多么的火爆。　　2017周杰伦天津演唱会的行程安排是怎样的?据整理，周杰伦天津演唱会时间定在了5月27日，地点在天津奥体中心体育场。　　2016年，周杰伦推出最新专辑《周杰伦的睡前故事》，收录了《前世情人》等10首歌曲，讲述了自己初为人父的心路历程，充满了温情与感动。而今年情人节，周杰伦更是难抑心中喜悦，宣布妻子昆凌身怀二胎，并证实是个男宝宝，与粉丝分享自己的喜悦。本文由百家号作者上传并发布，百家号仅提供信息发布平台。文章仅代表作者个人观点，不代表百度立场。未经作者许可，不得转载。梅姑娱乐圈百家号最近更新：简介:一个具有娱乐精神的女屌丝作者最新文章相关文章股票/基金&
12306售票W站三天c纱
　　本笥（者 ）^12月24日之後，昨天12306官方票W站再次“c”，原因仍是“C房空{系y故障”。由於目前正是展とT申A2013年春\Fw票的PIr期，W站三天啥取鞍c”，在人著急。而2013年春\1月26日拉_帷幕，不少旅客模骸12306W站F在就"不行"了，接下淼拇哼\怎麽k呀？”　　12月24日下午，不少旅客反映o法登F道部12306W站票。12306W站l公告Q，“因硬件O涔收希M修，和售票服铡保迷诋天W站票就重新恢正常。事後，12306W站Q故障原因是“空{O涔收稀币l。　　H隔了一天，12306又出F故障。昨天，12306W站又l布了《P於和；ヂW售票服盏墓妗罚娣Q，“因C房空{系y故障，正在eOM修。目前和；ヂW售票、退票、改I铡Ｄ赏ㄟ^A日以溶票，也可在站售票窗口或代售cI日以鹊能票。退票、改I眨您到站窗口k理。o您聿槐悖凑猓　　　故障至昨天下午4rS排除，W站恢正常。不^，令人疑惑的是，12306W站此前已“明”第二次“c”也是由空{故障引l的，但昨天W站恢正常後，W站首又出F了一行字L犹崾荆骸敖www.12306.cnW上售票系y升改造，o您淼牟槐憔凑狻！焙孟瘛安槐恪笔怯上到y升改造引起的。　　空{系y“三天深^”模燮毕到y升改造也不是一次纱瘟耍12306的“不狻痹俅巍坝|痛”了旅客“脆弱的神”：“希望春\备叻r段正常一c吧。”
12/27 07:4812/26 08:0812/25 09:1712/24 19:0612/22 11:1312/18 12:0412/15 13:4711/28 10:34
科技精品推]
　　【免明】本文H代表作者本人^c，c和WoP。和W站ξ闹嘘述、^c判啾３种辛λ热莸蚀_性、可靠性或完整性提供任何明示或暗示的保C。x者H作⒖迹K自行承控任。辽宁全省福彩系统昨瘫痪俩小时 选好号却打不出票_网易新闻
辽宁全省福彩系统昨瘫痪俩小时 选好号却打不出票
用微信扫码二维码
分享至好友和朋友圈
&&& 选好了彩票号码打印不出来 省彩票发行中心:中央处理系统出现了故障,全省的福彩系统都受到了影响
“选好号了,却打不出票来,还不知道啥时能修好,你说愁人不?”
昨日中午,沈阳不少福彩彩民都遇到了这样的麻烦。彩票站老板表示有两个小时左右的时间,系统就是进不去,他们也没办法。
系统进不去 选好的号码打不了
昨日13时许,沈阳市民崔先生告诉记者,他刚刚去了好几个彩票站,中国福利彩票都卖不了了。
15分钟后,记者来到位于皇姑区辽河街和宁山路上的四家彩票站,老板称彩票机的系统出故障了,福彩现在暂时卖不了。
“不知道什么时间坏的,不过在12时40分左右的时候,有个男的来买福彩双色球,选完号了,可打票机却怎么也打不出票来。”这位李老板赶紧退出了系统,想重新登录,就再也没进去过。
彩民朱先生:“号都选好了,出来买菜合计正好买回去,看来晚上还得再来一次。”
另一家彩票站的老板也说,12时的时候有人来买还好使,再后来的人就都没打出票。13时30分许,他又一次登录了系统,可等了近一分钟后,屏幕上依然显示“连接失败:主机IP或端口错误”。他表示,从坏了开始,他每隔两分钟,就试一次。“得盯着点,要不然好用了都不知道,我家只卖福彩,这一中午就走了20来个顾客,确实有影响。”
李老板向记者介绍,虽然彩票不能打票,但并不影响当天晚上的双色球等几种玩法的开奖,因为开奖和打彩票的不是一个系统。
省彩票发行中心:系统出问题影响全省福彩
随后,记者走访了沈阳市沈河区、皇姑区、大东区的8家福彩彩票站,他们都表示中午彩票系统确实不好使了。
刘老板经营福彩彩票站已经五年多了,在他印象中,这么大范围这么长时间的系统故障以前只遇到过一次。
“往常也有系统进不去的时候,不过再次登录就好使了,不像这回时间这么长。”刘老板回忆道,“前两年有过一次上午就不好使,晚上停售前才可以打票,坏了能有七八个小时。”他说,因为彩票系统使用的网络是联通的,有时候联通网络出现问题,他们也会受到影响。
记者拨打了联通的客服电话,工作人员对此表示暂时没有收到联通系统在这方面有故障的通知,应该还是福彩中心的系统出现了问题。
辽宁省彩票发行中心的工作人员则表示,已经接到了很多投诉电话,中午的时候确实有一段时间,福彩的系统是登录不上来的。
工作人员解释:“主要是我们的中央处理系统出现了故障,不仅仅是沈阳市,全省的福彩系统都受到了影响,不过不到下午三点,系统已经得到了恢复,全省的系统都可以正常使用了。”&&& 记者 杨薇
本文来源：华商网-华商晨报 。更多精彩内容
请登录华商网()
责任编辑：王晓易_NE0011
用微信扫码二维码
分享至好友和朋友圈
加载更多新闻
热门产品:　　　
:　　　　　　　　
:　　　　　　　　　
热门影院：
阅读下一篇
用微信扫描二维码
分享至好友和朋友圈