声明：ITeye精华文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！
由于春运，铁道部官方订票网站12306流量暴增，其Alexa排名一度进入前200，网友戏称，12306已经成为“全球最大、最牛的电商网站”。由于流量激增，12306系统频频瘫痪，一度出现登不上去、登上去抢不了票、抢到票需排队、排队后出票失败等局面。系统的用户体验、性能遭到用户大量的不满。
我们邀请了几位系统架构方面的专家，请他们从技术的角度为你剖析12306（我们会陆续增加其他几位专家的回复）。同时我们还从论坛活动（
畅聊12306，赢精美礼品）中选取了一些精彩回复。如果您对这些问题有独到的见解，欢迎在本文中评论或参与论坛讨论。
您是否在春节/国庆期间在12306上买过票？谈谈该系统的用户体验！
春运和国庆期间没有买过。但去年夏天在12306上面买过票，结果没有买到票，改买了飞机票。
我只用过一次，体验不深。感觉系统不太稳定，我访问的时候看到过Java出错抛出的错误堆栈信息。
有。界面很象是企业MIS，显得很粗糙，交互性，体验性都感觉很次。
我知道它很难用，所以我从来没用它买过票。去年国庆节查询个票，慢的要命。
从sql的拼写到页面优化，从程序架构到服务器架构都需要全面重构。居然不是参数化查询sql，而是查询参数拼到sql里的，完全是一群业余选手的习作。
应该采用js、css、图片、html都应该启用gzip压缩，所有css应减少到一个，js文件该合并的合并，能重用的重用，页面背景图应尽量合并成一个文件。尽量减少http请求数。
12306在去年国庆之前进行了改版，加入了排队系统，您认为加入排队系统的目的是什么？缓解了哪些问题？
对具体情况我不太了解。我猜测，实时购票是一个高并发的在线事务处理系统，需要通过排队系统来缓解事务并发造成的锁定吧。
排队是缓解资源并发的一次不错的策略，可以在后端资源不足时，将客户端请求暂存在池中，方便系统资源的调度。
刚开始的时候看到网上很多人说它有一个巨大的事务。后来又加入了排队系统。至于为什么个人猜测可能是为了降低数据库压力。
而实际上，用户并发量并没有变化，排队导致大量访问不能尽快返回，占用了大量系统资源。实际上这样做降低了系统吞吐量。数据库压力有没有降低先不说，系统吞吐量肯定会降低。
我认为增加这个功能的意义在于，当你不能立即买上票时，不用再不停的反复刷新提交了，相当于银行里发给你一个“号码”，等叫你时你过来买票就是了，不用站那儿傻等。一方面增强了用户体验感，另一方面也能节约反复请求带来的压力。
但我认为买票难根本原因不在于这个，12306网站的压力自然是大的，但这表面的背后却隐藏着更多的问题，为什么一票难求？ 我们问自己一个问题：究竟一列火车有多少张票可卖？ 你会发现没有答案！ 如果真的没有答案，那即便你把12306刷到爆，也无济于事。
所以我认为，在系统设计上不是问题，像淘宝、天猫一样有大量的访问者，解决方案也不是就一个。 问题还是在于业务的设计上，只有把出票规则定合理了，系统才能更好的为大家服务，我们也不用去刷网站了，压力自然也会因此而小一些。
无论是从新闻上了解的，还是我亲身经历的，都证明从始点站开始买票会相对容易些，因为开始出票时，票数还是较多的（虽然也不是很多，大家都似懂非懂的），但从中间站点开始买票，票数少的可怜，甚至是０（网络延迟造成的）。这里面有一个二次售票的概念，怎么把这个二次售票的问题解决了才可能改善购票难问题。
二次售票我相信有它存在的理由。 但问题时它存在的理由真的注定它只能是现在这样的方式存在吗？ 我也相信这个业务规则一定有改进的地方。
公交车，火车，长途汽车，在售票方式与运输距离，输送量上有很大差别，但运输本质没有差异。我们是不是能参考公交运输中的一些优点呢？比如是不是有可能增加同一线路的车次？ 如果不能增加车次，是不是可以考虑沿途换乘方案？
12306春运购票，与淘宝、天猫在双11期间的促销有什么异同之处？
相同之处应该都是高并发的在线事务处理系统，我猜测主要不同之处在于12306背后的票务系统可能不是一个集中式的系统，而可能连接各个铁路局票务系统，数据同步的实时性和一致性可能更复杂一些。当然这些都仅仅是猜测，可能很不靠谱。
淘宝一天就处理了1亿零580万，而12306一天处理的交易仅仅166万条 ，如果从并发性上来说，淘宝的并发量远比12306大，但天猫的商品信息，促销数据都可以做缓存，做CDN，而12306的“商品”是一个个座位，这些座位必须通过后端数据库即时查询出来，状态的一致性要求很高。
从这点上看，12306的商品信息很难利用到缓存，因此12306查看“商品”的代价是比较大的，涉及到一系列的后端数据库操作，从这个角度讲，12306的复杂度是高于天猫的。
淘宝、天猫是如何应对这种超大规模并发的？如何hold住暴增的流量？
这是一个系统性的功能，简而言之就是：分布式和缓存。
您认为这些经验中哪些可以应用到12306？
据我个人了解的八卦，去年春运12306宕机之后，曾经求教过阿里，当时阿里派出了一支技术团队去了解情况和提供建议。 实事求是的说，12306相比一年前还是有所进步的，不知道是不是背后有阿里系专家的贡献。
参见第7条。
12306在系统、业务设计上，还存在哪些挑战？
我觉得12306面临的主要挑战就是两个方面：
- 一、实时高并发在线事务处理；
- 二、如何和各个铁路分局票务系统对接，保证数据同步的实时性和一致性。
淘宝的商品相对独立，而12306商品之间的关联性很大，由于CAP定律限制，如果其商品的一致性要求过高，必然对可用性和分区容错性造成影响。
因此，业务设计上，如果找到一条降低一致性要求时，还能保证业务的正确性的业务分拆之路。举个例子，火车票查询时，不要显示多少张，而是显示“有”或“无”，或者显示>100张，50~100,小于50等，这样就可以减小状态的更新频率，充分使用缓存数据。
12306网站的技术问题或许有多种解决方案（虽然可能并不完美），但最难解决的是业务问题！
一列火车总共有多少张票？恐怕这个就难回答，即使是铁道上的人也不见得能回答的十分清楚。
火车跟公交有几分相似，都有固定站点，每个站点都可能有人上下。不同的是，公交车可以先上车后买票，火车只能先买票后上车。我想这才是问题的根本。公交上去了就上去了，上不去可以等下一趟。火车得先有票才能上车，可是卖票规则却成了难解之题。
您认为高性能并发系统架构应该如何设计？关键是什么？
高性能并发系统其实分很多种类，是并发读，并发写，并发长连接，还是并发事务？不同类型的架构设计是不同的。具体到12306就是并发事务，在这个领域，我个人没有什么经验。
1) 优化前端网页
- 充分利用CDN，使JS、图片等静态资源的请求能够就近访问（顺便说一下，如果12306订票插件能从google提供的http://cdnjs.com中引用JS，而不去直接引用github的JS，就不会把github搞瘫了）。
- 将JS、CSS合并，最小化请求数。将JS和CSS压缩，最小化数据传输
- 启用gzip压缩网页。
2) 群集分发和调度
据说12306是采用集中式构架的，集中式构架很难应对高并发，也很难水平扩容，分布式不是仅仅将调度服务器，应用服务器，缓存服务器，数据库服务器分开就行，应该进行更细的服务级划分，对业务进行服务细分，做成一个个松散耦合的服务，然后把这些服务独立分布式部署。
3) 采用分布式会话
为了可以进行灵活的请求调度，不应采用weblogic、websphere这些应用服务器自身的session管理用户会话，而应该自己管理会话，如将会话保存在独立的集群memcached服务器中，这样每个应用服务就都无状态了，会话的请求可以随意分发给不同的服务器。这也是我的ROP开源项目没有使用HttpSession，而专门抽象出一个SessionManager接口的原因，开发者应该自己去实现这个接口实现分布式会话管理。
4) 关于数据库设计优化
数据库往往是系统瓶颈所在，首先应该对数据库进行分库设计，可采用两级水平切割，如首先切割成几个物理库，然后在物理库内部再采用表分割，一般是通过某个业务ID进行取模切割，降低单库及单表的并发性，提高TPS。
合理采用读写分离技术，做到读写分离，可以一写多读，有效降低数据库的负载，数据的同步可以视情况采取应用层同步写，读取数据库日志更新或直接使用mysql读写分离技术等。
此外，业务服务化、服务解耦化是关键。
个人认为针对不同的系统要有不同的设计方案。
虽然12306可以归类为电商领域，但是跟通常意义上的B2C还是有巨大的差异。所以单纯从12306上面讨论高性能并发系统架构并没有通用意义。
不过，有一个思想应该贯彻。那就是所有访问力求分散到不同的服务器处理，不同类型的资源要坚持使用不同的集群服务。动静分离、读写分离，减少一次页面访问的请求数和数据库访问次数，保持小事务粒度，注意线程安全，避免大数据量的查询，建立索引（多表联合、union、非参数化sql、笛卡儿积计算、返回大数据集等数据库操作应该避免）。
对于变化较小的查询操作可将查询工作交给专门的索引服务器完成。不过个人感觉像12306这样的业务，引入索引的意义不大也没有必要。
12306的业务需求乍一看似乎都是同一类型的资源，但是我们可能根据车次、卧、软、硬、站、时段、线路等信息将车票这个12306要处理的惟一类型的资源分成若干子类，不同的子类请求由不同的集群处理。
有人提议12306采用NoSQL存储，您认为是否可行？
NoSQL的优势在于海量无模式数据存储和查询，12306的挑战在于并发事务处理，所以用NoSQL无助于解决12306面临的问题。
纯用NoSQL个人认为现在还不成熟，毕竟NoSQL的状态一致性不好。一条可行的路子是MySQL+NoSQL，通过nosql缓解后端MySQL的压力。
当然这涉及到很多业务流程的优化设计，降低数据一致性要求后才能合理使用NoSQL。
事务的粒度应做到购买行为是原子性的，即保证两个人不会买到相同的票即可。每个票种的优先级是一样的，应不同的查询条件保证能尽快的返回。
实际上每天出售的票种总和远达不到海量的程度。但是每年有几个时段并发量特别大。如果使用大量nosql数据库集群，票量一致性恐怕难以保证；如果使用单台nosql，恐怕吞吐量和实时响应也会像mysql一样难以做到。
不论什么数据库，都难以完成这么少的数据量却要完成这么大并发量的情况。
个人认为还是把不同票种分散在不同票池服务器中，完全由程序操作内存完成查询和购买更合适一些，虽然数据结构可能要复杂很多。
最后根据每个票种的余票量要限制每个票种的查询和购买并发量。超过的就拒绝访问，以节省资源。早死早超生，而不是所有人都耗在买票这个事上。
12306 如果使用开源来实现，您有什么建议？
其实用WebLogic应用服务器，Oracle数据库，SSH框架和C3P0连接池都是OK的，但要解决12306面临的并发事务问题，需要系统在基础设施和架构上做很多专门的调整和开发的工作， 这些才是解决问题的关键，和用什么软件和框架关系不大。
预算很大一部分都要来买weblogic、oracle的授权了，好钢用在了刀背上。完全可以用jboss代替weblogic，用mysql代替oracle，把这些省下的钱请技术专家，远比买这些东西好用。
另外，这种高并发的互联网的应用不建议使用Hibernate，建议直接使用Spring JDBC，毕竟Hibernater操作数据库往往不够细粒度。另外还建议使用Spring MVC替代Struts，Spring MVC比Struts更高效性，页面尽量使用客户端的技术而不要使用服务端的技术实现，如使用客户端的requirejs+underscore客户端模块就比使用服务端的JSP或Freemarker要好，毕竟这样就让客户机来负责页面渲染了，且可以有效地使用CDN。
从目前来看，您认为12306需要着重改善哪些方面？如果让您来设计，您会如何做？
12306从前端页面上来看用户体验就比较差，至少从页面设计和前端JS代码上来说就有巨大的改进空间了。后台架构上需要解决高并发事务处理，和分布式数据同步的实时性和一致性问题，在这两个问题上，我个人也没有太多相关实践经验，有一些个人的想法，但还是不误人子弟了，这些方面可以请阿里系的专家来解答。
- web前端要大笔优化，采用requirejs+jquery+backbone+underscore框架，web应用要进行部署优化js合并，js压缩；
- 所有业务SOA化，以便可以将业务分布式部署；
- 数据库分库，二级切分,实现读写分离，从业务流程调整上降低对数据一致性的要求；
- 充分使用nosql技术，通过流程优化和调整，使nosql承担大量的数据访问请求，使nosql成为保卫后端mysql的一道坚强的保障。
铁道部应该对每节车厢、每个车次要卖出多少站票、软座、硬座、卧铺有一个规划。购买同一车次和票种的人不会造成太高的并发。因此关键在于查询和买票服务器集群的设计和实现。
设计一个票池系统，按照车次、线路、区域划分票池，按照车次、站、软、硬、卧分类不同票种，将每个票种分配到票池集群的某台服务器上。买票时肯定已经确定了票种，通过一致性哈希准确定位指定票种所在的服务器。票池系统完全采用内存储存预售票票种、票量信息。
查询、购买分开不同的集群，两个集群之间实现余票量同步。保证每个操作迅速返回，不必保证查询和购买实时同步，也不必保证查到的票在购买的时候一定能买到。
庄表伟：与12306相关的一些思考
铁路购票的12306网站，我也在上面购买过火车票，虽然的确存在着各种各样的问题，但是最终确实成功的买到了票，而且也顺利的坐上了火车。也许因为不是在春运期间购买的缘故，说实话，我对它的印象没有那么糟糕。
当然，如果我们看看网络上的新闻，搜索微博里的各种人对12306的批评、责骂与嘲讽...是的，他们做得糟透了。
但是，在我看来，痛骂他们的技术如何垃圾，并没有追踪到问题的本质，本文试着继续深入的追究下去。
一、不要外包
分布式系统的第一原则是：不要分布式！而外包系统的第一原则是：不要外包！前一句，有很多高人说过，后面这一句，是我杜撰的。而我之所以会提到这个问题，是因为网络上有很多类似的观点，似乎是因为这次的外包开发没有找好，如果将这个活包给淘宝、支付包、京东、亚马逊之类的大型成熟电商来做，就万事大吉了。事实上，这些成熟电商之所以成熟，恰恰是经过了长期的改进完善之后的结果，而且，一定是他们自己的开发团队完成的。另一个近在眼前的例子，想想苏宁易购吧。直接一点说，如果这事外包给淘宝来做，就算淘宝有人有时间也愿意接这个活，也肯定干不好。
为什么外包通常搞不好呢？因为他们不是自己人，他们没有跟着一个企业同步成长的体会。因为他们希望获得整理明白后的一本“需求汇总”，他们害怕反复不断变动的需求。当然，我这个观点，可能存在着某种偏见，但是，越是变动复杂，极其核心，影响巨大的系统，我都强烈的不建议交给外包来完成。
二、循序渐进
一个非常庞大的电商网站，都不是一天建成的，淘宝不是一天建成的，亚马逊、京东也不是一天建成的。我们怎么能够希望12306在第一次推出的时候，就能够支撑春运购票这样变态的需求呢？
为了限制需求，其实可以有很多种办法：比如限制特定的班次（只卖高铁票、卧铺票、只卖从起点到终点的票等等）、比如网络购票加价，比如只在平时提供使用而不是在春运期间投入使用。总之，不需要一开始就服务所有的用户，选定一个较小的范围，先服务好，再循序渐进，逐步扩大服务的范围、提升服务的效率与质量，才是较为稳妥的办法。
三、排队系统
在12306网站推出之前，我们的购票体验同样糟糕，客观的说，只怕更糟。但是为什么反而没有什么人来骂呢？很多人在说，因为12306的用户体验做得不够好，但是我想要反其道而谈之。如果网站的用户体验能够像当初的实际购票一样差，只怕反而更加好一些。
回顾一下传统的购票流程吧：来到购票大厅，首先要选择一个窗口排队，运气不好的时候，自己选择的那一队恰恰是最慢的。经过几个小时甚至十几个小时的排队，我们来到了窗口前，遇到的是心烦意乱的售票员大妈，她们通常态度恶劣却动作迅速，到哪里？没有！卖完了！只有站票了，要不要？不要就换下一个！看清楚了吗？确认我就出票了。
窗口前的购票者，在身后巨大的目光压力之下，在面前不耐烦的语言压力之下，做着迅速的购买决定。这种购票体验，真的是太烂了。唯一的好处是：当我们拿到了那张纸片，就放下心来，肯定能回家了。
假设，我们一开始就把12306做成一个售票大厅的模式，总共就100个窗口，每个人都登录以后先排上10个小时的队，一旦排上了，轮到自己了，购票时间不会超过2分钟。那么，虽然是漫长的10小时的等待，却不需要时刻守在电脑前站着。这种体验，我想就足够了。
从12306的角度而言，完全可以将系统按照每个城市一个售票大厅的方式来部署，一开始假设只有100个窗口，人再多也是这么排着。等到系统稳定了，能力上去了，再慢慢的增加窗口的数量，缩短排队的时间。痛骂的人，将会少很多很多。原因很简单，不要一开始就给用户一个很高的期待值，然后再让他们失望，而是基于现状，小步快跑的做着改进。反而会有较好的效果。
这种做法，其实在网游行业是基本常识，随着用户数量的增加，新增一组一组的服务器，以容纳更多的玩家，而不是一开始就放开让所有的人进来玩。宁可不让他们进来，也不是让他们进来以后，在游戏场景里玩排队的游戏。
四、代售机制
火车票代售网点，其实在很多年前就已经出现了。我认为这个模式其实很不错，是一个分散客流提高效率的好办法。假设，我们不做12306的网站，而是开办成千上万，甚至上百万的火车票代售网店，情况会变成什么样子呢？假设，我们降低火车票代售点的准入门槛：交XX万押金，下载一个代售点客户端，自备电脑，自寻场地，自寻客源，自己去做生意。搞一个简单的审批流程，每年新增批准10万个个体户代售点。
这样的好处是：每个企业，每个公司，每个街道办事处，都可以自己申请成为一个代售网点，然后解决身边人购票的难题。在最大限度内，减少集中排队的压力。另一方面，由于审批流程可以控制代售点的数量，同时也就保证了系统的压力始终以可控的方式增长。
我在内心默默推理了一下，似乎是一个较为简单可行的办法。
五、抓大放小
说起用户体验糟糕，每个人都可以滔滔不绝的说很多话。我们常常会看到这样一种言论：铁道部的官员，他们用12306吗？如果他们也用，难道不会更加促使12306网站更快的改进吗？
其实，从技术人员的角度而言，怕的就是大老板亲自抓用户体验。当然，比这个更加糟糕的，则是每个领导，都对用户体验，说三道四。
对于12306的改进，我想不必过于关注细节，追踪一些统计数据的变化情况就好。比如：平均购票等待时间；退票率与废票率；列车上座率等等。至于如何提高这些数据，领导们千万不要事无巨细的参与讨论，大家各自努力就好。有更多的事情得靠领导们努力：比如切实提高运力……
六、架构演进
在网络上，我们常常能够看到很多给12306支招的方案，总之各种前卫，各种先进。但是，在我看来，越是复杂的系统，越是怕这种“革命”，哪怕过去的架构再不合理，也最好不要贸然引入过于激进的架构，在原有的架构下逐步演进，逐步扩展，逐步寻找小范围的、能够被改进的点来推进，才是较为合理的做法。
我能够看到的很多对于12306的批评，常常是一直站着说话不腰疼的姿态，说实话，并不可取。就目前来看，我们最乐观的估计是，12306能够顶住压力，逐渐改进、完善，在3~5年之后，渐渐淡出人们的视线，成为一个普通的，日常必须使用的，生活服务类网站。
其他
第一：专业的事就应该找专家来做。不论招标也好，还是私下里寻找合作伙伴也好，都应该挑选有高并发、高吞吐量这方面的专家完成。而这样的人只存在于大型电商公司。铁道部花了那么多钱却没去找正确的人来做这件事。
第二：关键在于目的是什么。目的是花钱，还是为了方便买票，还是其它目的？
第三：关于抢票插件的问题。如果网站本身响应迅速，抢票插件也没什么市场了。关键在于要去考虑怎么改善用户体验，而不是要去禁抢票插件。上头意识从来都没有做正确的事。
酷壳博主说，就为了一年那么几次，十几天的高访问量，花那么多钱开发一个购票网站，也就铁道部能做的出来了。
个人觉的，更好的做法是。铁道部应该可以把购票api开放出来。让所有人都可以通过这些api开发购票网站。让这些网站之间形成竞争。
这样访问压力分散到了不同公司的服务器，而铁道部就是做了一个平台。这样做的效果更好。就像现在很多类似携程这样的网站都可以在上面订飞机票一样。
另外，通过云计算将根据一年中不同时段的压力弹性改变计算资源，也可以节省成本。
问题瓶颈（Front to Backgroud）：
- Web端，每天请求上亿，压力很大，包括html js css img等，需要占用大量带宽
- 身份证认证，可能会用到第三方的认证，或者铁道部协议，获取到身份证信息，这个查询量也很大
- 交易，银行性能应该不在瓶颈
- 订票记录，采用按照车次分表，应该是集中控制集群，分表 分区 索引，速度不会太慢
- 查询余票，每次交易成功，更新订票数据，更新量较大
分析：
- 网站的内容可以分布式部署，采用apache＋xxx分发，后台多个镜像分担请求，进行冗余;图片、css、js、html、动态jsp、后台业务，分别部署;并且对web进行部分优化，压缩，合并，缓存等。
- 每次订票数据流量在2M，每天1200w/8h/60min/60s，每秒420个订票请求，840M/s的网络流量，根据分布6种文件140M/s，一般光纤网络就可以了;每种文件下面分布几个cluster，性能足以支持，每秒70个请求。并不大
- 身份证第三方只要支持每秒1k＋的并发请求就足以支持订票了。很容易
- 如果本地验证身份证，根据省份、建立表，根据城市建立分区表，速度也会非常快，用身份证做主键，一条身份证信息0.2k，全国13亿＝260G的数据量，easy，做个RAC就足以支持这种压力了
- 银行不考虑
- 车次，订票记录，余票记录，每天7kw的记录，14G/天，保存20天，才280G
- 订票业务按照省份分布，每个省份单独结算
- 整体采用SOA架构，都是服务，每个服务专注自己的业务，优化自己的服务
- 银行交易需要大量校对和核实业务，也许要一些投入，算成本;需要对仗，异常情况分析等，属于不是直接业务的处理，不能省略。
- 硬件IO，视情况而定优化，EMC盘阵，RAID;数据分布存储，根据数据量划分group。
- CPU，内存通过简单增加刀的CPU和内存来提高。
- 网络，根据地点，业务分布到不同的节点进行购票，每个节点的网络吞吐可以控制，不会太高
分享到：
您还没有登录,请您登录后再发表评论
18 楼 minimu 2013-02-06 11:24
其他的人要么浅尝则止，要么天马行空。包括范**。
就12306的事情中，有大规模电商经验的人（或团队）反而非常谨慎。
17 楼 bighou 2013-02-06 11:18
这样感觉就像是高考填志愿，然后再招生，反正名额就那些，也省得大家干等。
16 楼 bighou 2013-02-06 11:10
15 楼 0dragon 2013-02-06 11:02
14 楼 henghengdh 2013-02-06 10:10
个人认为框架不是关键，即使后者比前者效率更高，所带来的性能改善也是微忽其微。
我们不能惟框架论，不能说什么框架一定不好，什么一定好。
hibernate struts如果用的好一样能做出高效的程序。
jdbc springmvc用的不好，效率一样很烂。
个人认为框架永远不会成为性能瓶颈，即使它们可能会慢一些，但远远达不到无法忍受的程度，也永远不会成为性能优化的首选项目，牺牲极少的性能换来更高的开发效率完全值得，这些性能方面的牺牲完全可以在硬件、系统架构、代码风格和代码规范上得到弥补。相反如果这些方面做的不好，就是完全抛弃框架也做不出什么高效的程序。
===============================================================
赞同。
那些说道性能就要换框架的，有没有计算过成本？
而且12306的性能差是体现在页面渲染加载吗？就他那几个页面把struts换成spring能提高多少访问时间？1S怕是都很难做到吧。
13 楼 henghengdh 2013-02-06 10:05
=======================================================
这个数据怎么得来的？
你计算的是成功订票数据吧？事实上是每个人都能一次订到票吗？我觉得资源的耗费主要在那些一次次的订票失败或者订不到票的人身上，所以你这个数据要用n次方再次计算才合理。
如果说我要去订票，一次成功了或者失败了我就放弃了，不再访问这个网站了，那所有问题都好办多了。
12 楼 charles751 2013-02-06 08:19
这句话现在已经不再适用了！
很多系统由于用户量和数据量的问题都需要设计成分布式系统了。
11 楼 runfriends 2013-02-06 00:50
成本太高了。
10 楼 ansjsun 2013-02-05 23:10
9 楼 runfriends 2013-02-05 21:16
不过最晚从3.6版开始，hql已经支持update和delete了，而且对查询操作也做了很多增强，比如支持子查询和复杂的关联查询等等。可以说hql已经支持绝大多数sql特性，不过为了保证跨数据库，很多数据库特有的函数hql没有提供支持。现在已经能够使用hql完成大多数查询、删除、修改操作，那些不支持的sql特性也不推荐使用sql去实现，因为一样涉及到太多表关联和复杂的sql，要占用太多的数据库系统资源。反倒不如使用程序解决更好。
8 楼 runfriends 2013-02-05 18:44
但是单数据库实例又不能支撑高峰期那么大的并发。
不如把车票数据加载到内存，直接操作内存数据。
但是这样一来数据一致性和灾备就比较困难。
实在是难以兼顾。
如果车票数据全部操作内存数据，最好的数据一致性和安全性方案就是做好操作日志，记录每次车票数据变更，便于数据恢复，同时定时将车票数据刷新到数据库。
这种日志就类似redis或mysql的数据日志，可利用它们恢复数据。
不过像车票这种时效性很强的商品，又必须保证恢复快速，否则就没有意义了。最好能做到实时恢复。
7 楼 runfriends 2013-02-05 18:36
hibernate也能直接使用sql。
其实对于12306来说，个人认为直接把票量加载到内存直接操作内存数据更合适。
关键点肯定不在用jdbc或struts,只是在提到12306的框架的选择时，我就把能想到的这些细节一并说了。Hibernate站得太高，在做细度控制时比较困难，而JDBC直接面对数据库相对来说好控制，所以对于对性能关注很大的网站，我一般是不建议使用Hibernate了，这个好像论坛中也谈论很多了，应该说是仅是一个个人经验的建议吧。
6 楼 stamen 2013-02-05 18:18
个人认为框架不是关键，即使后者比前者效率更高，所带来的性能改善也是微忽其微。
我们不能惟框架论，不能说什么框架一定不好，什么一定好。
hibernate struts如果用的好一样能做出高效的程序。
jdbc springmvc用的不好，效率一样很烂。
个人认为框架永远不会成为性能瓶颈，即使它们可能会慢一些，但远远达不到无法忍受的程度，也永远不会成为性能优化的首选项目，牺牲极少的性能换来更高的开发效率完全值得，这些性能方面的牺牲完全可以在硬件、系统架构、代码风格和代码规范上得到弥补。相反如果这些方面做的不好，就是完全抛弃框架也做不出什么高效的程序。
关键点肯定不在用jdbc或struts,只是在提到12306的框架的选择时，我就把能想到的这些细节一并说了。Hibernate站得太高，在做细度控制时比较困难，而JDBC直接面对数据库相对来说好控制，所以对于对性能关注很大的网站，我一般是不建议使用Hibernate了，这个好像论坛中也谈论很多了，应该说是仅是一个个人经验的建议吧。
5 楼 runfriends 2013-02-05 17:41
第一次爆料说是三亿多。
后来李开复又写一篇微博并提供了一些文章说其实这三亿多以前还花了很多钱买硬件之类的，先后共五亿多
4 楼 黑土豆Dean 2013-02-05 17:27
3 楼 runfriends 2013-02-05 16:47
v3.6以上的版本已经能操作很细看粒度了。不论增删改查，都能细化到字段级，也支持复杂的多表联合查询和子查询等等各种操作，而且hql也支持update delete了。实在不行hibernate也支持sql访问。
2 楼 runfriends 2013-02-05 16:38
1 楼 runfriends 2013-02-05 16:35
个人认为框架不是关键，即使后者比前者效率更高，所带来的性能改善也是微忽其微。
我们不能惟框架论，不能说什么框架一定不好，什么一定好。
hibernate struts如果用的好一样能做出高效的程序。
jdbc springmvc用的不好，效率一样很烂。
个人认为框架永远不会成为性能瓶颈，即使它们可能会慢一些，但远远达不到无法忍受的程度，也永远不会成为性能优化的首选项目，牺牲极少的性能换来更高的开发效率完全值得，这些性能方面的牺牲完全可以在硬件、系统架构、代码风格和代码规范上得到弥补。相反如果这些方面做的不好，就是完全抛弃框架也做不出什么高效的程序。