声明：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和内存来提高。
- 网络，根据地点，业务分布到不同的节点进行购票，每个节点的网络吞吐可以控制，不会太高
分享到：
您还没有登录,请您登录后再发表评论
108 楼 zhangchuanle 2017-08-29 10:19
107 楼 jveqi 2015-02-03 16:53
106 楼 windshome 2014-06-13 11:27
把就业率和人员流失率做为当地政府的重要绩效考核指标，可以有效促进本地就业和发展，缓解大城市集中现象、老人村现象、空城现象、高房价现象等等，人员和就业带来的一系列问题；
总之如果好几亿人都要在仅有的几个城市里工作、学习、就业，那么势必会带来资源竞争问题，其核心的问题在于，“生我的地方养不了我，养得了我的地方无法落脚”；
构想一下：
你出生的地方，可以给予你良好的教育、就业机会，你会愿意离开父母亲人朋友到异地去吗？
你出生的地方，有房子、有地，价格也不高，你会背井离乡，租床位住地下室吗？
如果每一个地域的政府和人民都致力于建设自己的家乡，创建更好的生存环境，12306还是问题吗？高房价还是问题吗？
105 楼 cuckoo007 2014-06-11 10:14
把就业率和人员流失率做为当地政府的重要绩效考核指标，可以有效促进本地就业和发展，缓解大城市集中现象、老人村现象、空城现象、高房价现象等等，人员和就业带来的一系列问题；
总之如果好几亿人都要在仅有的几个城市里工作、学习、就业，那么势必会带来资源竞争问题，其核心的问题在于，“生我的地方养不了我，养得了我的地方无法落脚”；
构想一下：
你出生的地方，可以给予你良好的教育、就业机会，你会愿意离开父母亲人朋友到异地去吗？
你出生的地方，有房子、有地，价格也不高，你会背井离乡，租床位住地下室吗？
如果每一个地域的政府和人民都致力于建设自己的家乡，创建更好的生存环境，12306还是问题吗？高房价还是问题吗？
104 楼 djt 2013-07-22 18:47
成本太高了。
===========================================
目前估计有四千多趟车吧，一列车一台服务器，算10万的话，就4个多亿了，别说CDN的费用，还有软件开发费用了。
一个列车最多2000～3000张票，算上20天预售期，最多也就是60万张票的数据量。你那个10万钱电脑市面上1000块钱就差不多，剩下钱都被像你这样的贪污分子吃了吧
103 楼 cuishen 2013-07-04 12:52
然后登陆进去做1小时，2小时排队是个不错的建议，从业务角度缓解了高事务并发的压力。
前面大牛提到把session 放进内存数据库，这样应用层做到无状态，但是怎样保证用户认证呢？自己写个算法生成类似的session id，放进cookie？怎样保证安全性？
其实票面信息是不会改动的，高事务瓶颈也仅仅在余票数量上，可以把票面信息包括余票信息全部放进内存数据库，然后普通数据库里面的表仅有车次和余票数量两列，内存数据库和普通数据库通过车次进行外键关联，用户查询购票的时候永远都是查的内存数据库，真正事务处理成功后同步内存数据库的余票数量，当然普通数据库根据车次做水平切分，以减小IO竞争，如果必要的话内存数据库也可以分布式。
102 楼 webboy 2013-05-27 02:36
101 楼 windshome 2013-05-23 17:01
（1）没有彻底弄清楚到底需要做到什么程度。票（代表运力）和客流量大的矛盾，是靠什么系统都没有办法解决的，所以12306应该清楚的定位，这套系统，到底给人们带来什么，怎么样就是完成任务。
（2）上面的专家们提到先排队的机制很好，但是问题是，是否先查票，再排队？还是先排队，等排到了再查询自己可以买什么时候、哪趟车的票？从模拟现实的角度看，先排队，排到再查询票的机制要好一些。
（3）有些呼吁采用新技术（例如缓存、NoSQL）的朋友应该了解，铁路售票系统还需要和之前的老系统（例如车站售票、代售点）连接在一起运转，甚至很有可能都是基于同样一套数据库的，你让他们换个数据库，是什么样的代价和动静呢？
（4）再有，对12306来讲，确实应该进行足够的测试再开始上线，如果测试期间就发现无法支持全国的并发，应该在一些环节，使用排队机制来缓解，测试不充分，上线很快宕机，只能说明技术主导人员的职业素养存在问题。之前我做设计、带队伍，不经过足够的测试，绝对不能上线的。
100 楼 ccr1988 2013-04-22 15:16
那咋是危房啊，该买到票的都买到了啊！再说了那么大个系统，顶住那么大的压力，那点钱算什么，光硬件投入就不少钱。我们公司开发的系统才几十个人使用，都能卖几百万。如果要是几亿人使用，你想想得卖多少钱？
第一期3个亿，第2期5个亿 你告诉我你买什么硬盘？ 买什么型号的服务器？ 胡扯，别拿了钱又卖乖，国家的钱是我们纳税人的，别贪了钱又卖乖，没有人可怜， 系统架构出现问题，你就是买10亿的服务器也是没有用的，接不了单就别接，而且如果压力测试出现了问题就应该提前通知，告诉大家你们的系统能支持多大的并发量，别TM在这里装逼，国内大批人才，在并发上处理好的大型公司多的是，为什么不让他们接单？TM一群贪官不知道经过多少代理了。
99 楼 scjingying 2013-04-11 09:34
98 楼 runfriends 2013-03-14 11:47
那咋是危房啊，该买到票的都买到了啊！再说了那么大个系统，顶住那么大的压力，那点钱算什么，光硬件投入就不少钱。我们公司开发的系统才几十个人使用，都能卖几百万。如果要是几亿人使用，你想想得卖多少钱？
你那几百万都是虚的，泡沫。
就跟现在楼市一样
97 楼 xiexifeng113 2013-03-14 11:16
那咋是危房啊，该买到票的都买到了啊！再说了那么大个系统，顶住那么大的压力，那点钱算什么，光硬件投入就不少钱。我们公司开发的系统才几十个人使用，都能卖几百万。如果要是几亿人使用，你想想得卖多少钱？
96 楼 zui4yi1 2013-03-04 16:41
95 楼 ccr1988 2013-03-04 15:03
94 楼 xiexifeng113 2013-03-01 09:43
93 楼 amb_hbj 2013-02-28 15:22
92 楼 xuqiao2009 2013-02-25 13:52
我也做过电子政务系统很多年，他不等同与电子商务和网站系统，首先网站是一个老总（技术总监，他可以支配整个技术的设计）说的算，并且硬件的设计和安排都可以及时到位并且一大堆的技术人员可以参与各个环节的开发维护，电子政务（铁路系统）首先要解决的就是关系问题和业务敲版问题这其中有：1、硬件的集群部署方案的审核；2、业务及技术设计的审批审核（全局业务需要解决的问题，这最重要，因为这就是高层是否权利支持例如淘宝那样的给予你全全部售票系统专用专权）；3现状的分析（例如原有售票系统数据及接口的衔接等）；4、技术的实施；5、程序的设计等等
我觉得最重要的是前两步，至于技术只要有钱什么系统都设计的出来，关键问题开支在哪里，是否抛开一切利益和社会关系只谈系统实现和处理问题。
铁道部门这么多年的客运和货运都能作出负资产，我觉得首先要处理的就是贪污受贿和作风整治问题，其次就是像移动那样改体，并且创造很多增值业务，彻底焚毁关系人和多谋取个人利益和亲属带来的黄牛党问题，这些问题解决了我觉得只要多相信和依靠系统完成人工办理业务（银行都可以直接视频发卡了及业务办理了，铁道部门还需要窗口办理排队售票的业务吗？只要定了票身份证和本人查票就可以了，都不要出票这问题，何来贩卖车票和车票紧张问题，退票需要身份证和本人手纹才可以退票，这样系统外的事情就减少），其次我们才可以谈技术实现，其实售票不就是个排队分销系统嘛，移动的华为做的传呼不是也可以解决排队问题，那么多年不都处理的好好的。
什么技术漏洞，我觉得还是做的项目的时候基本上就是分包后到下面没有盈利了，所以系统自然就不了了之了，其实淘宝都能解决的问题，投资上亿早就可以挖出很多淘宝的高手技术人员，或者外包给强大的公司做了。。。。
我觉得最大的问题是铁道部门还是没有确定是否现状就彻底的解决现有的现象，系统做好再没有二期可以做了。
91 楼 rtttyu23 2013-02-22 10:20
不到一分钟，票就没了。如果说，在网上购票，大家都是公平的，那么一分钟就没票了，这不能怪12306网站。
不公平体现在，一：信息没公开。什么预留票的，到底网站出售多少票，是否有内部规则。
二：给了抢票软件空隙。一个商业网站，既然可以随便的给其他人安装插件破坏其原有的运行模式，只能说，垃圾。要么你自己开发个官方插件也比现有模式好。
个人建议，把购票改成，提前半小时，大家统一输入买票的信息，然后，利用计算机摇号的规则分配票。这样大家购买到票的机会都一样了，也不会存在什么高并发。
如果某列车次票没了，通知没买到票，可进出下一轮其他车次的摇号。
计算机如何摇号？这就得需要信息公开。
90 楼 rtttyu23 2013-02-22 10:03
高铁 是发展的趋势，是社会的需求。
把高铁布局好点，十年内就可解决问题。高铁 贯穿东西南北各个人流量多的地方。
高铁、动车、普通列车、汽车综合运用。解决换乘容易点，下了高铁就可以坐上汽车直到目的地。
89 楼 rtttyu23 2013-02-22 09:55
因此，在当前情势在，12306要做的应该是，怎样让大家公平的买票。每张票，对大家来说，买到的机会是均等的，无论有钱人、有权人、有学识人、有技术的人。
还有一点，火车的运营方式应该也有改进的地方。
在春运期间应该 把不必要的过站取消。多开只有始发站——终点站。当然，路途远的，可以考虑在中间的重要地点停下，补给水、油、粮。
88 楼 rtttyu23 2013-02-22 09:50
假设12306技术完美无缺，1s可以卖1e张票
结果就解决问题了吗？
现在的问题是有1w个人要买1k个位子，你1分钟卖掉或者1个月卖掉，总是1k个人买到，9k个人买不到。
是运力不足！一群屌丝老是扯着系统有什么意义
和我想的一样。现实社会在那，空想的美好世界也就那样。
春运人流量大、而平时少，地区发展不平衡，才是问题的关键。
87 楼 rtttyu23 2013-02-22 09:47
因此，在当前情势在，12306要做的应该是，怎样让大家公平的买票。每张票，对大家来说，买到的机会是均等的，无论有钱人、有权人、有学识人、有技术的人。
86 楼 gugu_abrams 2013-02-20 15:37
票务本身业务的复杂程度都不去考虑？光看到网站这层皮的表明现象？
85 楼 FlyAway2 2013-02-19 22:33
感觉超不好！
84 楼 hpgyy 2013-02-17 23:31
83 楼 hpgyy 2013-02-17 15:58
成本太高了。
===========================================
目前估计有四千多趟车吧，一列车一台服务器，算10万的话，就4个多亿了，别说CDN的费用，还有软件开发费用了。
82 楼 hpgyy 2013-02-17 15:53
个人认为框架不是关键，即使后者比前者效率更高，所带来的性能改善也是微忽其微。
我们不能惟框架论，不能说什么框架一定不好，什么一定好。
hibernate struts如果用的好一样能做出高效的程序。
jdbc springmvc用的不好，效率一样很烂。
个人认为框架永远不会成为性能瓶颈，即使它们可能会慢一些，但远远达不到无法忍受的程度，也永远不会成为性能优化的首选项目，牺牲极少的性能换来更高的开发效率完全值得，这些性能方面的牺牲完全可以在硬件、系统架构、代码风格和代码规范上得到弥补。相反如果这些方面做的不好，就是完全抛弃框架也做不出什么高效的程序。
===============================================================
赞同。
那些说道性能就要换框架的，有没有计算过成本？
而且12306的性能差是体现在页面渲染加载吗？就他那几个页面把struts换成spring能提高多少访问时间？1S怕是都很难做到吧。
================================================================
选择某个框架只是一个实现需求的一个方式，性能方面不会说有翻天覆地的变化的。只是不是一个解决问题的重点方向
81 楼 hpgyy 2013-02-17 15:51
这样感觉就像是高考填志愿，然后再招生，反正名额就那些，也省得大家干等。
http://www.12306.cn/mormhweb/zxdt/tlxw_tdbtz37.html
公平性如何保证是个问题，另外还牵扯到网上只是铁路售票的一部分，大部分还是在窗口卖的，如果网上都预约了，农民工是个问题。
如果预约了有不要的，同样存在抢剩票的问题
80 楼 hpgyy 2013-02-17 15:47
A:买过票，非节日期间体验可以，购票顺畅，一般情况下几分钟之内可完成整个流程。高峰时期看运气了，从心理上来说，买上票了体验就好，买不上票体验就差,唯心论了。
需要改进的地方怎么说呢，就是需要从心理学的角度出发，要考虑如何降低大家的期望值，并且让大家使用时比较顺畅，这样才可以有比较本质的改善。如果非得要说要改进的细节点，前端需要再优化一下，流程也需要再分析。
2、12306在去年国庆之前进行了改版，加入了排队系统，您认为排队系统的增加目的是什么？
A:排队系统本质上起到一个流控的作用，从实际上来看，从加入排队系统以后，12306确实运行的较为稳定了，
3、12306在系统、业务设计上，还存在哪些问题与挑战？
A:最大的挑战，就是紧缺商品而且是必需品如何在不能满足需求的情况下，最大化用户体验，貌似无解。
4、通过12306的现状您认为高性能并发系统架构应该如何设计？关键是什么？
高性能并发系统技术实现的关键是什么？
A:12306网站不是关键，关键是核心系统性能的提升，减少对核心的访问，尽可能提高效率。
高性能并发系统架构没有一个放之四海而皆准的准则，至于使用hibernate还是jdbc等都不是重点，如果目前盯在这个地方，只能说还没有从全局来看问题。
但是一般都要考虑几点
1）易于扩展，能够在线扩展系统能力，对用户体验没有影响
2）有限流措施，高并发系统一旦发生问题，必须有处理措施，否则雪崩效应直接导致系统崩溃
5、有人提议12306采用NoSQL存储，您认为是否可行？
A:NoSQL存储可以再12306上进行应用。但是在核心交易环节应用还需要慎重。
从目前来看，您认为12306需要着重改善哪些方面？如果让您来设计，您会如何做？
其他您想说的话！
A:可以对前端先进行改善，比如大家吐槽的js压缩、合并、请求数等，不过从实际上对用户体验提升有限。另外业务流程需要优化。
QT：12306最大的问题是业务问题，但业务问题也比较复杂，包含了线上、线下业务，涉及到不同的利益群体考虑、农民工、学生、军人等，与电商还是有一定区别。
彻底解决估计是有一天没有春运的时候了。或者说铁路运能非常充裕。
另外：从这次插件之争也可以看出12306和其他电商的区别，实际上系统做的体验再好，插件一样会存在的，春节，大家不关注体验，关注的是如何能增加买票概率。
79 楼 runfriends 2013-02-17 14:05
我不是惟框架论者。反过来考虑你说的问题其实很好理解。
1. ssh的代码贡献者几乎全部都是老外。说明还是老外用的多。
2. ssh如果只有我们国内在用，而我们对它们的贡献几乎没有，这些项目早就没有了。
3. 我曾经参与过用它们实现的天pv超百万的应用。
4. 很多公司确实不问你懂不懂这些东西，足够大的公司确实有很多都采用了自己的框架。但是这跟ssh是不是适合开发高并发应用是两回事。开发自主框架的公司是基于其它原因。凡是采用java做web开发的数据库、缓存、key-value这些东西不谈，还是ssh或springmvc springjdbc是主流，这里面不乏高并发的应用。
5. 数据结构和算法这些基础，确实很少人愿意深入了。但这不是ssh的罪过。
6. 作为用户，我就算狗.屁不懂，但是我用的不爽，我还是有骂的权利的。卡车司机不必懂的发动机和杀车系统的原理，但是卡车性能不好司机还是有权利骂的。
7. ssh的意义在于从更高层的意义上考虑业务逻辑和实现，而更少关注底层。如果你的公司在用自己的框架开发应用，你就应该知道，有专门的团队在维护框架，具体业务还是由其它团队在做的。