在objective-C类中声明一个数组型成员变量的property

今年火车票网上售票的情况大家都见到了，如果让你来设计该订票网站，你会如何设计才能应对如此大规模以及高并发的情况呢？

邵辉
13 票



806

列车在线订票系统的业务逻辑比较简单，不用多说。可能的瓶颈有两个，一个是车次和剩余票量的查询，一个是下单。在设计软件架构之前，需要先研究产品需求、软硬件条件、网络环境以及关联系统的接口，但这些资料无从获得，所以只能做几点分析和假设，做为设计的前提条件。

1、2012年铁路春运是2.35亿人次，去程售票的那几天应该是订票的最高峰点，假设是3天内订出1.2亿张票，那么每天是4000万张。由于还有车站窗口、电话、代售点等渠道，所以每天通过网站售出的票应该小于4000万张，这里假设2000万张是由网站售出的。

2、如果2000万张票是在一天内均匀地订出，那么每秒钟大约是230张。中国排名前100位的网站应该都会超过这个事务量，不会有什么难题。问题是，订票网站是在一个固定时刻（早上6：00）开始放票，考虑一个极端的情况：早已守候在电脑前的2000万用户在准点开始按下按钮下单，并且都在1分钟时间内订到了票，那么系统需要每秒33万的事务处理能力，这至少需要上千台服务器的集群才能按时处理完。（按照网上有关12306建设资金的报道来看，服务器投入肯定远远不到这个数。）实际情况当然不会这么极端，但必须保证整个系统有非常好的横向扩展能力，以便在必要的时候添加设备扩展服务能力。车站窗口、代售点和电话售票之所以不会产生这样的峰值，原因是这些渠道都是有人工受理，效率足够低，低到用户需要排几个小时的队来等候，自然就把峰值给抹平了。

3、前面还不是最大的问题。铁道部应该还有个核心数据库，保存最权威的票务数据，网络订票系统、电话订票系统和代售点必须与这个数据库对接以提交订单记录和获得准确的车票余量信息。至于这个接口有多少条连接，每秒允许多少次事务，那就不得而知了。这里我们假定接口要么足够宽，宽到不会成为瓶颈，要么在事先已有固定数量的车票分配给了网络订票系统，这样网络订票系统就可以根据这个固定数量自主地接受订单，然后在后台慢慢地把订单数据传给核心数据库。否则，就好像8车道的马路一下变成了2车道，无论如何也不可能让用户畅通无阻地订到票。

有了上面的分析和假设，可以考虑以下设计方案。

1、车次和剩余票量的查询。考虑到车次查询量可能是订单数量的数倍至数十倍，不能让用户提交查询请求时直接去主数据库检索数据，而应该采用前端+缓存+检索+数据库的多层逻辑结构。数据库存放持久化的权威数据并保证数据的一致性；缓存层负责把车次、余量等数据放到内存中以保证最好的查询性能，并有比较好的横向扩展性；检索机负责定时（例如每5秒一次）去数据库检索所有车次信息并主动更新缓存机上的数据；前端负责响应来自用户的web请求。这个架构无法保证用户看到的车票余量是实时准确的（比如有数秒的滞后），但由于用户从看到车票余量到完成订单之间肯定是有时间间隔的，在订票高峰期和票量较少时本来就无法保证“在看到有票的情况下一定能订到票”（技术上能够实现这一点，但代价非常大），所以这个缺陷并不明显，是个很划得来的折中。注意是检索机负责将车票数据抓出来并更新到缓存机上，这是保护数据库并使缓存层能够线性扩展的关键方法。另外查询页面需要采取防频繁刷新的措施，这个在前端机上设置web server策略即可。

2、下单部分由于要更新车票余量，必须保证数据的一致性，扩展性不可能很好，因此是整个系统中最为脆弱的一环。实现的方法分同步处理和异步处理两种。同步处理就是用户选择完车次正式下单订票后，立即锁住车票记录并检查车票真实余量，如果大于1，那么余量减1，解除锁定并回复用户订票成功进入支付流程，否则解除锁定回复订票失败请用户选择其它车次。这是订票系统的标准流程，无论用户量大还是小，处理流程都是一样的。为了支撑春运这种极端情况下的高访问量，需要提高订单处理的并发吞吐量和单个事务的处理速度。提高吞吐量可以将不同车次的车票数据分拆到不同的物理服务器上，提高订单处理速度可以考虑取消关系数据库，将车次数据放到内存中并用原生语言实现订单处理逻辑。有一个比较值得考虑的措施是在用户下单前用图片或者短信的方式要求用户二次验证，这既可以防止刷页面，也可以使峰值变得更平缓。异步处理就是在用户提交订单时并不立即告诉用户订票成功或者失败，只是将订票请求放入队列里排队，订单成功处理后再通知用户。处理优先级上采用时间排序或者抽签都可以，不过抽签适合在非常时期采用，并不适合作为一个标准策略，这多少增加了系统开发的复杂度。采用异步的方式将会在最大程度上避免用户下单高峰造成的冲击，缺点是用户不知道什么时候能有结果，是否应该尝试其它车次，这对用户体验有一定程度的损伤。

硬件架构方面，负载均衡设备是必须采用的，除了扩展负载能力，也需要扛住DoS攻击。服务器用普通PC服务器就可以了。网络架构方面，内网应该设计成无阻塞的，外网引入三大运营商的BGP带宽，不要用静态带宽。

最后说一句，几千万用户同时下订单，即使是三大互联网巨头的系统，也不一定撑得住，12306网站崩溃并不算太丢人，但需要好好考虑架构优化方案，明年春运不能再倒了：）

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (1[/b]) • 链接 • 2012-03-31

0 支持
有个很大的问题，中国ZF机构的车票不可能放在同一个“权威”库中，各地铁路局都一定会有自己的数据库，虽然“全国联网”，但是肯定会因为各式各样的你想象不到的LY问题，而产生自己的“权威数据库”。 – zhouning13 2012-08-31

您的投票让 xixi5806 声誉值增加了10分。
支持投票，不仅能让回答用户获得声誉值，让好答案排序靠前，更能帮助社区筛选出好的内容，构建高质量的知识库。

xixi5806
8 票



212

我的前身是web测试,我来从几方面谈一下12306的网站

1)易用性.首先最简单的是UI,也是所有用户登入第一眼看到的,在易用性方面有很大差距,用户使用时带诸多的不便,因为全国售票系统是给不同层次阶层的人看的,必须是普通的即使是没有用过电脑的也应该进去可以至少了解流程,提示太少.

2)数据不是实时更新,做为全国最大的售票系统,实时更新数据是最重要的,剩余票数数据不真实导致很多人不知道没有票还在上面不断刷新,结果可想而知.

3)安全性.预订及购物网站最重要的就是安全性,12306网站可以注入js进行页面强刷,可想而知其安全性.

4)服务器处理速度太慢.纵使你有10M带宽,你进去了页面,可是一样买不到票,就是因为处理太慢.

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (0[/b]) • 链接 • 2012-01-09

您的投票让 李小蔚 声誉值增加了10分。
支持投票，不仅能让回答用户获得声誉值，让好答案排序靠前，更能帮助社区筛选出好的内容，构建高质量的知识库。

李小蔚
7 票



3166

这么大的数据访问量，一定要做各个地区级别的数据负载了。

1.数据库级别使用rac进行负载均衡，来分散压力

2.APP级别进行负载

3.对APP以及数据层直接增加缓冲层，使用memcache或者来减少数据库的压力

4.对于数据库加入连接池来控制连接数量

用户策略上：

1.增加排队机制，将目前排队人数按照一定时间进行同步到各地的分站DB或者其他Io介质中，按照用户申请的时间，来估算用户排队的位置

2.用户一旦排到了，就给三次机会进入连接池进行处理

3.增加操作时间的限制，如每个用户只能有30分钟的操作时间去操作

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (3[/b]) • 链接 • 2012-01-09

0 支持
他们的系统是java做的，数据库连接池肯定是用了的，不过效果为啥那么差，就不明白他们到底是不会用还是没用好 – 何远伦 2012-01-09

0 支持
如果是购票系统，数据层直接增加缓冲层，如何保证数据同步呢？

同一张票被卖两次及以上是不可接受的。。 – 张东新 2012-09-18

0 支持
我想这也是因为我们不能选坐的原因吧。。这么大并发量下，要保证同一张票不被卖两次及以上，由系统帮你完成选坐。在你订单完成前不知道坐位号，就是不知道你会得到哪张票。

极端情况下，可以只给出出发时间段和起始地点，由系统帮你决定坐什么车，要不要转车，可能更能解决数据冲突问题，而且更利于铁路调度。。 – 张东新 2012-09-18

您的投票让 于明俭 声誉值增加了10分。
支持投票，不仅能让回答用户获得声誉值，让好答案排序靠前，更能帮助社区筛选出好的内容，构建高质量的知识库。

于明俭
6 票



449

一个典型的阻塞问题。除了大家提到的硬件设施和分布式系统外，个人感觉风险仍然存在，一旦阻塞，就形成重复性请求，瞬间造成系统崩溃。

如果要避免重复提交，可以采用延迟处理方式，处理完成后通过其它渠道发给用户。比如说明系统可能在1小时后返回结果，用户就不再做重复性操作。

轻量级的前端只是记录用户请求，然后交给其它服务器去分布式处理。处理的过程中可以实时监控处理队列的繁忙和阻塞程度，采用追加服务器方式以避免过度延迟。

这样的方式把阻塞交给了后台处理，至少对用户留下了好的印象。

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (0[/b]) • 链接 • 2012-02-02

您的投票让 方汉 声誉值增加了10分。
支持投票，不仅能让回答用户获得声誉值，让好答案排序靠前，更能帮助社区筛选出好的内容，构建高质量的知识库。

方汉
5 票



1891

这个系统人为制造了很多瓶颈，首先是有票与否不在这个系统里，需要到票务中心查询，其次，有每天定点放票的时候大家狂刷新余票，下单，银行支付，全是高负载操作，整个 12306网站的投入是1000万人民币左右，相比淘宝之类的是很少的，在不能改变这个投入的情况下，优化购票流程，消除瓶颈是很重要的。

那么设计成不让查询车票余量，在票务中心给网上购票按现在设定的百分比留出一定数量的票源，提前12天用户可以凭自己身份证在网站上可以随意预定12天后单一车次车票，提前11天统一抽签，中奖几率跟预定顺序无关。中签者名单产生为静态页面当天公布到CDN上，到第7天中签不缴费的全部转入电话和窗口销售或给本期替补用户。同时设定一个身份证同一时刻只能预定一份车票。这种办法就没啥瓶颈，还彻底杜绝了刷票插件等高科技工具带来的优势。

在上述流程上，用户没有必要在特定时间点去订票，查余额，支付，所有这些操作都被平摊到1天之内了，同时同后台的票务中心只有一次批量购票的交互，这样只要应付常见的人为上网高峰早8点和晚8点即可，如果觉得不保险，再加一个简单的登录排队机制。

如果要提高用户感受，还可以上期未中奖用户自动转入下期同车次继续抽票，直到抽中为止。其实北京购车摇号就是这个机制，从来没有瓶颈。。。

方汉
编辑于 2012-02-02

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (3[/b]) • 链接 • 2012-02-02

0 支持
抽签这个想法很有意思，不过抽不中就回不去了也挺悲剧，还算是挺公平的 – 何远伦 2012-02-02

0 支持
买票比购车摇号稍微复杂一点，一个人可以有很多趟车次可以选择 – 何远伦 2012-02-02

0 支持
一个人只能定一趟车，同时让大家看到每趟车的中奖概率，这样就会有人自发去选择绿皮车，最后实际上能买到票的还是那么多人，但是对大家是公平的 – 方汉 2012-02-02

您的投票让 何远伦 声誉值增加了10分。
支持投票，不仅能让回答用户获得声誉值，让好答案排序靠前，更能帮助社区筛选出好的内容，构建高质量的知识库。

何远伦
5 票



7923

昨天用这个系统订票，反复下了几十次单，都没有成功，所有人都这样反复的重试，这不仅影响了系统服务效果，而且加大了系统负担，我觉得可以从以下几个方面加以优化：

1.限制一次性进入系统的总人数，比如二十万人，如果能达到平均每5分钟处理完一个人的选票订票，那么每小时也能处理两百多万人的订票了，比我昨天弄了两三个小时而无果强多了，暂时进不来的用户应该放到一个队列中，排队进入；

2.不知道他们现在的数据库是怎么设计的，但昨天看着明明有7张票，但反复下单就是不成功，车票信息表可以考虑每趟车次每天的数据放到一个表中，这个每个表的数据也就才几千，读写操作都会非常快，根据实际的请求数量，可以把这些表分到不同的库，不同的服务器上，另外这些信息完全可以同步放在Nosql类缓存里，用户查询，因为一般查询都只是查某天某车次的剩余票数，这个很好实现

3.分析系统瓶颈环节，采用多种手段进行优化，比如下订单这些操作，可使用队列进行排队操作，即使每个队列每秒钟处理100个下单，估计也比现在的处理能力强，另外在进行数据更新操作时可以应用一些无阻塞的更新技巧，比如一个订单是订某车次的3张票，那么就执行更新次车趟车次表里的未出售状态的最后的三条数据为已出售，当然根据具体情况，还有更多更复杂的一些处理方法

总之，就像车站排队买票一样，应该加快每个用户的处理时间，排除瓶颈，不要让所有人卡在某一个环节，加快处理速度，这样整个系统的处理能力也就上去了。

何远伦
编辑于 2012-01-09

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (0[/b]) • 链接 • 2012-01-09

您的投票让 寻花问柳 声誉值增加了10分。
支持投票，不仅能让回答用户获得声誉值，让好答案排序靠前，更能帮助社区筛选出好的内容，构建高质量的知识库。

寻花问柳
4 票



41

网络购票相比传统购票方便不少，这一点值得肯定。

但要严格满足如此夸张的高实时、高并发的极限要求，已经不只是一个良好的架构能够解决的问题了。

而且只有春运期间才具有高访问量，总不能为了满足极限要求，配置一堆精良的机器却大部分时间是处在休眠状态的吧。

要么春运期间采用租用计算或者处理集群的方式，要么就在性能要求和方便程度两者中间可以采用个折中的办法，比如多级缓冲，比如模仿传统购票中的排队机制。

毕竟网购只是其中一种方式，我想架构设计者没有很好的估算到大众对网络购票的需求程度。

菜鸟拙见~

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (0[/b]) • 链接 • 2012-06-15

社区维基
4 票



1345

一 静态资源的压缩优化及CDN分发策略

12306上涉及的图片及js、css等静态资源应进行压缩后传输，设置expires属性，在浏览器端缓存，减少对静态资源访问，提高页面访问速度。

同时高效使用CDN分发策略，像北上广等一线城市应尽量分流，减轻服务器压力，防止服务器因压力过大宕机或IO低效 崩溃。

二 缓存车次信息及余票

用户登上网站后，除了登录操作流程外最火的两个操作流程应该是购票和余票查询。余票查询应及时给用户返回查询信息。所以需要优化缓存结构。车次票价等信息因为不会发生经常性的变化，所以应常驻内存，结合cdn分发策略，将用户引导至最近服务器，返回查询信息。余票数据因为涉及到需要和当前售票情况相关，所以应在每卖出一张票后同步更新缓存数据.这里需要注意的是查询余票只需要读缓存即可，在缓存存在情况下不需要去访问数据库，同步缓存在买票阶段再说明。如果缓存没有可以直接访问数据库，如果访问分流设计到位，相信缓存穿透情况会比较少，也不会对数据库带来很大压力.

三 按车次进行购票队列设计

因为国内火车票热度关系，同时并发购票情况会非常突出,目前没有看到12306有队列的排队机制，难道网站设计者想让用户立即购买票么？！这个有些疯狂，这就导致很多人上去点购票，却打不开等等。

我的想法是按照车次进行队列设计，并在缓存中维护这些请求队列.一个用户过来比如买K51车次，系统应从后端缓存中获取该车次缓存信息，并将该用户id加入队列末端，设置时间戳，并返回给用户前面有多少人等信息。维护该队列的服务器应作为后端的一层进行设计，防止一个服务器崩溃导致用户无法访问或者直接穿透到下一层。用户浏览器可以1s为单位像这些缓存层访问，缓存队列接收到后同步更新队列中该用户时间戳。对于长久没有请求的id有过期清除机制.目前一般火车车厢15-20节左右。YW25G(硬卧)定员一般66人左右,YZ25G(硬座)定员118人,RZ25C(软座)定员80人，RW25(软卧)定员36人。所以每辆火车人数在1000-2000左右.当然买票的人数可能会超过这个数值，每天买同一车次人数也不会是一个天文数字。

四 售票逻辑

售票处理只负责从前面的队列中获取买票的用户id，并发卖多少张票视情况处理。这里涉及到铁道部以前的票务系统接口，很多业内人士也反映压力最大的就是该接口调用。假设并发处理可以容纳20个（这个值因为不是内部人士，无法确认，仅是假设），则取队列中20个id，进行并发处理。就像火车站开通了20个窗口一样，对来的20个人进行售票服务，直至完成.可能这个过程可以有优化的地方，因为毕竟每个用户花在真正买票的时间不一定，有的短，有的长。买票流程应尽可能优化，尽量缩短用户购票需要的时间，提高购票速度。

售票处理得到票务处接口返回后，即同步更新该车次余票缓存，返回给用户购票信息。

五 票数据库设计

火车票数据库层应该是使用铁道部以前的票务系统，这种底层的数据库就像银行一样不会随便变更，要知道很多银行系统等数据库设计基本是90年代由IBM等那时设计的，猜测铁道部可能也会类似这样。所以作为12306等这样的外层服务，只能调用其底层的接口做一些操作。

再回到上面谈到的票务系统接口，个人觉得应尽量减少该接口的调用。目前火车购票主要有三种渠道，售票窗口（火车站及各售票点）、电话购票、12306。下面设想可能不是合理，只供大家讨论。如果这三种渠道购票比例为40%，20%，40%（这个比例可能会调整），则完全可以确定网上购票每个车次票数。

如果确定，则可以根据车次进行分库。数据库层包含一些列数据库，每个数据库可能负责多个车次信息，具体车次数量由测试压力确定。售票操作由之前调用统一的票务接口转为了在各车次数据库操作。当然票务接口也会去访问后端数据库，貌似没有不同，但是这样处理后数据库压力已经分流，网站购票只要关心分配好的这些车次数据库就好。像热点车次也应该考虑请求会比其他普通车次要高很多情况，采用更高端的服务器进行处理，相信硬件在铁道部应该不缺.

售票层次应处理好对车次票额的同步机制。任何情况下，只允许同一车次同一个人来买，保证票数的稳定.

最后，总结一下自己的思想，主要是靠架构分层思想，将12306层次分为CDN分发层、静态资源处理层、动态资源的缓存层、排队缓存层、售票层及底层按照车次水平划分设计的数据库层，最终思想要靠分流、有效排队机制及车次水平划分设计数据库等减少对系统服务器的压力，同时保证购票的准确性。

引用：关于12306网络购票的架构方面思考

冯义军
编辑于 2012-03-02

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (1[/b]) • 链接 • 2012-01-09

0 支持
最好注明来源了。。 – 杨玉廷 2012-01-09

您的投票让 梦江南 声誉值增加了10分。
支持投票，不仅能让回答用户获得声誉值，让好答案排序靠前，更能帮助社区筛选出好的内容，构建高质量的知识库。

梦江南
2 票



44

时下不是到处在吹什么云端技术么，怎么一个春运就不灵了？服务器跟不上要求就别只扯什么云端技术

建议针对性强的问题尽量详细提供相关资料。

重点还是把拥堵问题解决

对这样的大项目要考虑线上线下的方方面面

各种蛋疼的春运政策是最不应该出现的，还有N多不该出现的细节，如人员爆满，却空着几节车箱留给后面的站；如非始发站只能定无座的……尼玛的铁道部，卖出去几张半路下车的票那个站不就可有几个座位么，有那么难实现么？车上改迁不能联网变更数据库么？铁道部人才真是牛啊，好多出现多年的问题都不去解决，提价倒来劲了。蛋疼的二代身份证设计出来了，需背面资料要复印两次。细节，越基础的细切，越决定成败，当年的鱼雷加木头偷袭珍珠港可见一斑。

网络是现实的缩影，人口众多决定了高并发就是网上国情。线下的就不详谈了，我们只是做网站的。

春运每年也就那么一阵子，先考虑峰值降低的可能性再言其它。

铁道部有多少定票窗口就有多少并发，这远小于千万级，所以他的定票系统没崩溃，大家也只能排队

负载均衡也必须要网民配合，分离和减少多余的查询。

1、时间：把6：00开始定票最好改为全天24小时可定票，把各车次开始定票的时间分摊开来，错开波峰，平稳过渡。手工网络定票难居然都可以用定票外挂搞定的事说明，晚上睡觉前先开个挂买到票自动关机完全可行。网站方就不能设计个外挂了么？垃圾网游自动打怪都成标配了……不要说外挂耗服务器资源，网民没买到票手工狂点你网站一样耗！

2、空间：一个站分成多个站，拆分票务数据库，各站数据能分离的尽量分离。可按相关车次和始发站全国分几个大区拆分数据库。比如不让定返程票，则所有对开的车次数据库都可以完全分离。

3、定票效率：能在客户端设计个分支选择树，这可以简简单单的在一个客户端页面实现。

一次输入一个车次查询和同时输入想定的多车次查询，你定票窗口都能这样，网站为什么不能这样？

4、预约定票：外挂耗服务器资源，可以这样，网友在客户端页面先做出各项分支选择，定好优先级什么的，如有优先买几号到几号某某车次哪到哪的，买不到则买……填个能收发短信的手机。网民只要提交一次有效“查询”，相当于在服务器内部安个“内挂”，条件满足时在服务器内部触发处理，发个通知确认短信即可。这个“内挂”得支持在线更改，需要身份认证即会员注册，非会员则附加个“内挂”有效时间即过期时间，这个网站可限制最多多长，对于同时有效火车票数少于预约需求情况：依下单时间先来后道，网友年龄段学生老人优先大家理解吧（由身份证号可知），前两个条件可限定人数，余下的随机摇号都行，有退票时对有效期内的需求再次核定。透明公平即可。不得搞什么竞价排名！尼玛的一到春运就涨票价，对得起人民么？

5、良好的网站平台界面设计。国民会上网不代表个个都是网络达人

6、提前让网友在春运前完成资料注册，填好手机号身份证号。避免注册抢带宽,提前宣传是必须的。

建议这个身份证和手机资料注册只在春运前某时间段开通，春运完就删除。骗子多骗术多，各种躺着中枪是国情啊国情。

7、先满足必要需求，少数特殊需求，平台挂不了再考虑。如什么站车风采页面，春运时先砍了再说，所有形象页面一个道理。

希望以上一家之言对网站设计者有所帮助

为思路不受影响，大家的发言我未细看，这些朋友大多不用春运去排队买火车票吧？希望设计者深入了解春运细节，对高并发，用最土最原始最简单最有效的办法先用合适的成本整低。我所说的也跟软硬架构几乎无关，再好的软硬架构，或许也只是治标不治本。为春运这个波峰投入N多固定资源，春运过后呢？



sonyanda 28
编辑于 2012-08-29

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (0[/b]) • 链接 • 2012-08-29

您的投票让 打酱油的 声誉值增加了10分。
支持投票，不仅能让回答用户获得声誉值，让好答案排序靠前，更能帮助社区筛选出好的内容，构建高质量的知识库。

打酱油的
2 票



2222

1：数据库读写分离

2：LVS架构，后方多台服务器轮循处理

大方向是这样··具体实施就要视需求而定

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (2[/b]) • 链接 • 2012-01-07

0 支持
数据同步很重要, 整套系统要保证不同地点同时订票的用户不会因为数据的更新问题而轮循 – 刘锡涛 2012-01-08

0 支持
赞同你的观点，数据库的设计是最重要的一个环节··根据需求来定义合理的数据库架构 – 打酱油的 2012-01-08

您的投票让 小飞 声誉值增加了10分。
支持投票，不仅能让回答用户获得声誉值，让好答案排序靠前，更能帮助社区筛选出好的内容，构建高质量的知识库。

小飞


2 票



6081

无意中看到一篇咨询，里面分析了一些原因，分享一下

1.带宽较小

访问量大增通常是导致网站瘫痪的主要原因，难以预计的突发访问量往往使网站措手不及，网络带宽难以满足多地点并发的访问的要求，每个人均分相应网速太小，网络使网页一直处于刷新状态，很难打开，解决此类的问题最彻底的办法就是增加带宽，错峰访问虽然能够缓解一下问题，但并不能根本上解决问题。

2.服务器超负载

服务器的处理能力往往影响一个网站打开的快慢，当访问量过大的时候，带宽仅仅是影响网站打开速度的一方面，服务器的处理能力往往是最关键的因素。当访问量过大时，服务器由于配置或其它问题难以满足来自四面八方的访问，处理能力长期处于超负荷状态，尽管有着所谓7*24小时支持服务设计，但长期处于这种超负载状态，难免有不能'招架'的时候，所以服务器配置升级是应对长期访问量过大的最根本手段。

3.内存泄漏

内存泄漏是主内存分配了部分内存后而没有释放，逐渐耗尽内存资源，导致系统崩溃。它的后果甚至是会影响到以后内存的正常运行或使用内存损坏，它主要是指程序中间动态分配了内存，但是在程序结束时没有释放这部分内存，从而造成那一部分内存不可用的情况，重起计算机可以解决，但是也有可能再次发生内存泄露，内存泄露和硬件没有关系，它是由软件引起的。

而在一般情况下无法轻易被发现的其实它也是轻易不是出现的，它就好象你坐在一个升降机里所在是13 楼而你还按下13 楼的按扭一样，内存泄露只会在这样的情况下出现的，不过内存泄漏说还是会比一个人站在13 楼还按要去13 楼的按扭这样的情况要多的多，因为有时内存泄漏会时常发生在用户使用某些较大且较复杂的程序中。

解决的办法也只有使用一些软件来测试内存有没有这样泄露的问题了，不过要是隐性式的内存泄漏就不太好办了。要根据当前发生一些问题或是一些操作来判断是否发生内存泄漏的问题。

4.磁盘已满

磁盘已满也可能是导致系统无法运行的原因。一个合格的网络管理员会密切关注磁盘的使用情况，隔一段时间，就需要将磁盘上的一些负载转存到备份存储介质中(例如磁带)。

日志文件往往会很快使用光所有的磁盘空间，Web服务器的日志文件，SQL*Net的日志文件，JDBC日志文件，以及一些相应应用程序的的日志文件均占用大量磁盘空间，可以采取相应措施将日志文件保存在其它文件系统中，日志文件系统空间已满时Web服务器虽然也会被挂起，但是机器自身被挂起的几率已大大减低。

5.黑客的侵袭

现在攻击网站的方法越来越多，手段也越来越高，危害也比以前大了，很多人中了木马却还不知道，要想保护好网站站点的安全，那么就要保护好服务器端口的安全。

6.感染病毒

病毒程序往往使网站应用程序无法正常运行，这样站点往往会因为各种病毒的侵袭而遭受重创，现在虽然杀毒软件很多，但是还没有一种能够确保网站不被病毒感染的杀毒软件出现， 所以在日常维护中，管理员要严格遵守相关管理规定，遵守操作流程，使病毒受侵袭的可能性降到最低。

7.多线程死锁

多线程带来的性能改善是以降低可靠性为代价的，因为这样有可能产生线程死锁状况。线程死锁时，第一个线程等待第二个线程释放资源，而第二个线程又在等待第一个线程释放资源。简单理解为：如人行道上两个人迎面相遇，为了给对方让道，两人同时向一侧迈出一步，双方无法通过以同样的迈步方式堵住了对方的去路。假设这种情况一直持续下去，这样就不难理解为何会发生死锁现象了。

解决死锁方法都很麻烦，这是由于使线程产生这种问题是很具体的情况，而且往往有很高的负载。大多数软件测试并不能产生足够多的负载，所以不能够暴露全部线程错误。在每一种使用线程的语言中都存在线程死锁问题。由于使用Java进行线程编程比使用C容易，所以Java程序员中使用线程的人数更多，线程死锁也就越来越普遍了。可以在Java代码中增加同步关键字的使用，这样可以减少死锁，但这样做也会影响性能。如果负载过重，数据库内部也有可能发生死锁。

如果程序使用了永久锁，比如锁文件，而且程序结束时没有解除锁状态，则其他进程可能无法使用这种类型的锁，既不能上锁，也不能解除锁。这会进一步导致系统不能正常工作。这时必须手动地解锁。

8.数据库中的临时表不够用

许多数据库的临时表数目都是固定的，临时表即保留查询结果的内存区域。在临时表中的数据都被读取后，临时表便会被释放，但大量同时进行的查询可能耗尽数目固定的所有临时表。这时，其他的查询就需要列队等候，直到有临时表被释放时才能再继续运行。

此外，还存在一些其他问题：设置的表空间不够用、序号限制太低，这些都会导致表溢出错误。这些问题表明了一个好的DBA对用于生产的数据库设置和性能进行定期检查的重要性。而且，大多数数据库厂商也提供了监控和建模工具以帮助解决这些问题。

除去上面的常见的原因，还有许多因素也极有可能导致Web站点无法正常工作。如：C指针错误、相关性、设备驱动程序不兼容、硬件老化、无意间锁住了关键的表等。

引用链接 一票难求 细数导致Web在线应用瘫痪因素

补充刚看到一篇文章，分析得很有道理：由 12306.cn 谈谈网站性能技术

小飞
编辑于 2012-01-17

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (0[/b]) • 链接 • 2012-01-11

您的投票让 李水祥 声誉值增加了10分。
支持投票，不仅能让回答用户获得声誉值，让好答案排序靠前，更能帮助社区筛选出好的内容，构建高质量的知识库。

李水祥
2 票



1872

采用高并发处理语言结合CDN分发，摘自百科。

Erlang特性：

　　● 并发性 - Erlang支持超大量级的并发进程，并且不需要操作系统具有并发机制。

　　● 分布式 - 一个分布式Erlang系统是多个Erlang节点组成的网络（通常每个处理器被作为一个节点）

　　● 健壮性 - Erlang具有多种基本的错误检测能力，它们能够用于构建容错系统。

　　● 软实时性- Erlang支持可编程的“软”实时系统，使用了递增式垃圾收集技术。

　　● 热代码升级-Erlang允许程序代码在运行系统中被修改。旧代码能被逐步淘汰而后被新代码替换。在此过渡期间，新旧代码是共存的。

　　●递增式代码装载-用户能够控制代码如何被装载的细节。

　　●外部接口-Erlang进程与外部世界之间的通讯使用和在Erlang进程之间相同的消息传送机制。

　　●Fail-fast（中文译为速错），即尽可能快的暴露程序中的错误。

　　●面向并发的编程(COP concurrency-oriented programming)

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (0[/b]) • 链接 • 2012-01-10

您的投票让 lily 声誉值增加了10分。
支持投票，不仅能让回答用户获得声誉值，让好答案排序靠前，更能帮助社区筛选出好的内容，构建高质量的知识库。

lily
2 票



61

像这种大数据请求并集中爆发的情况，个人认为快速有效的解决方案，主要有两个

1.搭建数据库整体架构时，进行地区划分，分地区进行处理请求。

2.想类似这样的政府行为确实可以向成熟的行业先行者请教和学习解决方案。

还有一个题外话的建议，可以把多种交通资源做一个整核，当请求过大处理不了时，可以推荐用户去购买汽车，飞机的有效链接，或是大家share拼车信息的平台

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (0[/b]) • 链接 • 2012-01-10

您的投票让 马瑜 声誉值增加了10分。
支持投票，不仅能让回答用户获得声誉值，让好答案排序靠前，更能帮助社区筛选出好的内容，构建高质量的知识库。

马瑜
2 票



5890

过2百万的IP，千万级的PV，如果同时爆发，其DDOS的效果并不比淘宝的双11差多少，这种规模百度或者阿里系的也不一定能搞定，我觉得技术再改善，问题也不会得到完美的解决，重点应该是把拥堵问题解决，我有二个建议：

应该做个线上排队，像这么大的并发，通吃的技术解决方案我认为没有，最好的例子像淘宝的双11不也排队了吗？

开放平台，提供API，把流量分流给携程、易龙、阿里等互联网有票务经验的公司，减轻负载。

引入成熟的技术方案，同百度、阿里系的进行技术合作，提供技术支撑。

如果跟了 携程易龙那些，会跟麻烦，数据一致性处理起来会更麻烦。



tarfly 1253
编辑于 2012-01-31

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (1[/b]) • 链接 • 2012-01-08

0 支持
PV已经达到10亿量级，IP也在千万量级 – 至尊宝 2012-01-09

您的投票让 82026547 声誉值增加了10分。
支持投票，不仅能让回答用户获得声誉值，让好答案排序靠前，更能帮助社区筛选出好的内容，构建高质量的知识库。

82026547
0 票



1

1.按区域处理数据

2.登陆人数限制和登陆时间限制

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (0[/b]) • 链接 • 2012-09-15

1 个答案被折叠？

被折叠答案待需改进：

答案负票过多会被折叠，而被投负票多因：

• 把对问答的评论当做答案发布

• 答案完全Copy他人内容，并未注明来源

• 答非所问

• 答案含有广告、垃圾或恶意破坏内容

您的投票让 徐彬彬 声誉值增加了10分。
支持投票，不仅能让回答用户获得声誉值，让好答案排序靠前，更能帮助社区筛选出好的内容，构建高质量的知识库。

徐彬彬
-3 票



1

其实，这个问题就是：多人，同一时间段，都到同一网站订票。这是没办法的事。除非你保证每个人在那一天之前订票就能得到票。

根据人多少， 发多少票就能解决这个问题

但是现在呢? 是根据票的多少选择人。

票的资源 有限，大家都去强。呵呵！

所以这个嘛？ 解决不了的。

该答案已被锁定，无法对其进行评论，编辑及投票。
（）

评论 (1[/b]) • 链接 • 2012-09-03

0 支持
应该还是有缓解压力的技术手段 ；）从技术角度讨论吧 – sonyanda 2012-09-03

转自：http://www.dewen.org/q/963/?ts=edm20120919&e=eWVtaW5nc0BzaW5hLmNvbQ%3D%3D