|
锁定老帖子 主题：畅聊12306，赢精美礼品——已结束
精华帖 (1) :: 良好帖 (0) :: 灌水帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2013-02-01
通过12306的现状您认为高性能并发系统架构应该如何设计？关键是什么？
高性能并发系统技术实现的关键是什么？ 这两个问题忘了回答。 感觉这三个问号似乎是一个问题。 个人认为针对不同的系统要有不同的设计方案。 虽然12306可以归类为电商领域，但是跟通常意义上的B2C还是有巨大的差异。所以单纯从12306上面讨论高性能并发系统架构并没有通用意义。 不过，有一个思想应该贯彻。那就是所有访问力求分散到不同的服务器处理，不同类型的资源要坚持使用不同的集群服务。动静分离、读写分离，减少一次页面访问的请求数和数据库访问次数，保持小事务粒度，注意线程安全，避免大数据量的查询，建立索引（多表联合、union、非参数化sql、笛卡儿积计算、返回大数据集等数据库操作应该避免）。 对于变化较小的查询操作可将查询工作交给专门的索引服务器完成。不过个人感觉像12306这样的业务，引入索引的意义不大也没有必要。 12306的业务需求乍一看似乎都是同一类型的资源，但是我们可能根据车次、卧、软、硬、站、时段、线路等信息将车票这个12306要处理的惟一类型的资源分成若干子类，不同的子类请求由不同的集群处理。 |
| 返回顶楼 | |
|
发表时间：2013-02-01
就这么几个人回复，iteye该关门大吉了。
|
| 返回顶楼 | |
|
发表时间：2013-02-02
刷新验证码是ajax方式吗 好像不是哦
|
| 返回顶楼 | |
|
发表时间：2013-02-02
个人认为应该允许插件存在，取消验证码和用户注册
|
| 返回顶楼 | |
|
发表时间：2013-02-02
•12306在去年国庆之前进行了改版，加入了排队系统，您认为排队系统的增加目的是什么？
我认为增加这个功能的意义在于，当你不能立即买上票时，不用再不停的反复刷新提交了，相当于银行里发给你一个“号码”，等叫你时你过来买票就是了，不用站那儿傻等。 一方面增强了用户体验感，另一方面也能节约反复请求带来的压力。 但我认为买票难根本原因不在于这个，12306网站的压力自然是大的，但这表面的背后却隐藏着更多的问题，为什么一票难求？ 我们问自己一个问题：究竟一列火车有多少张票可卖？ 你会发现没有答案！ 如果真的没有答案，那即便你把12306刷到爆，也无济于事。 所以我认为，在系统设计上不是问题，像iteye,csdn,淘宝,京东一样有大量的访问者，解决方案也不是就一个。 问题还是在于业务的设计上，只有把出票规则定合理了，系统才能更好的为大家服务，我们也不用去刷网站了，压力自然也会因此而小一些。 无论是从新闻上了解的，还是我亲身经历的，都证明从始点站开始买票会相对容易些，因为开始出票时，票数还是较多的（虽然也不是很多，大家都似懂非懂的），但从中间站点开始买票，票数少的可怜，甚至是０（网络延迟造成的）。 这里面有一个二次售票的概念，怎么把这个二次售票的问题解决了才可能改善购票难问题。 二次售票我相信有它存在的理由。 但问题时它存在的理由真的注定它只能是现在这样的方式存在吗？ 我也相信这个业务规则一定有改进的地方。 公交车，火车，长途汽车，在售票方式与运输距离，输送量上有很大差别，但运输本质没有差异。我们是不是能参考公交运输中的一些优点呢？ 比如是不是有可能增加同一线路的车次？ 如果不能增加车次，是不是可以考虑沿途换乘方案？ |
| 返回顶楼 | |
|
发表时间：2013-02-02
1. 12306的业务性能要求比淘宝的双11还要高！
2. 12306加入了排队系统，其实只要针对抢票即可，比如淘宝针对秒杀做排队系统 3. 秒杀其实很简单，全内存操作 4. 12306的事务处理，肯定不能用NoSQL来做，其他处理，内存比NoSQL更好，日志等可以用NoSQL 5. 核心购票事务的并发，只能排队慢慢处理，但数据库可以做切分以增加并行性，同时非核心数据可以多多冗余以增加并发 6. 辅助信息可以提前全部获取，使用客户端应该相对更合适，比如PC客户端和手机客户端 7. 需要抢票的和不需要抢票的可以分开处理 |
| 返回顶楼 | |
|
发表时间：2013-02-03
最后修改：2013-02-03
其实用户体验可以不管，只要能保证我能有一张回家的票，用户体验再差我表示亦可接受。说不需要什么用户体验是因为如果保证了大家都有票的话，大家都不会停留在上面过多时间，可能几分钟？所以也谈不上什么用户体验了.
用户体验再好、网站速度再快、完全不要排队。。。但没有票，又有什么用呢！大家都都不会是为了登陆上去感受一下几个亿砸出来的响应速度与用户体验吧。 去年是登陆问题遭人诟病，今年是排队，如果明年把排队问题解决了，一点预定的时候就弹出“对不起，无票”，接下来该解决什么！？ 解决问题，只有从根本问题着手，否则只是停留在表面，不断的救火，永远也救不完，耗费人力物力财力做无用功 只有将根本矛盾解决了、根本目的达到了，再谈其它的才有意义——当一个人胃疼的时候，不应该是只吃几片止痛药，而应该查查是不是有胃炎是不是有胃溃疡——否则一切都是空谈，空谈误事，空谈误国 那么怎么解决这样的根本问题？ 1、加大运力 2、加大各落后城市乡镇的发展力度，家门口有好工作，想外出的人自然少了 ------------------------------------------------ 下文实属摘录，主要来自网友 yulihua49 的记录，以下最初的讨论内容来自2012年1月，现在情况应该已经有了一些的不同。 引用 1.数据库与平台
12306的架构比较复杂，基本售票系统是SYBASE，网络订单数据库是ORACLE。 最初性能低下的原因不在数据库，而在安全网闸。 原来一个网闸处理全国业务成了瓶颈，将来每个局一个网闸和一个出口带宽，有望缓解。 铁科研那帮人搞了这么多年的大并发处理，经验还是有的。能想的办法都想了。 关键是SYBASE不给力，换ORACLE难了，全是存储过程，移植到ORACLE，前几年试过，不敢上线。 但就一般情况来说，数据库还不是瓶颈，仅仅在某些极端状况下是数据库。 网售更不是数据库瓶颈，网闸那儿档着，请求都进不来，数据库根本不忙。 有人，还号称是专家，说关系数据库不灵，要用TPF什么的劳什子，更是屁话，在相同配置下TPF比ORACLE慢几十倍，试过的。 2.关于网络订票只能买到上铺的说法 关于订票分配的规定： 一张：中，2张：上下，3张：上中下。 但是实际，卖乱了，就乱七八糟碰运气了。 窗口可以选铺别，有时为了多完成收入指标就先把下铺卖光了。 网售在窗口之前，还不至于被抢光 3.关于前期开发和设计 人员就是清华的一帮。网站开发是铁科院和清华易程竞标，清华没中标。 他们想用IBM的TPF，就是航空订票的那个60年代的东西，太古老了。实际上根本不适用。 95年IBM就找到我们推销TPF，被我们否了，09年又来了，撺掇易程。5个人花了3个月，测了一下，根本不成。 4.关于Oracle数据库 关于基本订票系统Oracle替换Sybase，铁科院试过了，可以但是不敢用。 一个是已经买断了SYBASE的版权，再花钱买ORACLE，给个理由，领导说。 一个是大规模的移植和培训。 一个是谁也不敢说不出娄子。 SYBASE用了10年刚刚使系统稳定下来。谁敢说改ORACLE能稳定？ 16年来，几代人在SYBASE上写了数千个存储过程。没人知道那个有用那个已经过时了。 后来问了一下铁科院，存储过程可以查孤儿，所以没用的都剔除了，但是常剔常出，还是有。 另外剔除孤儿很危险，如果一个应用在SQL里写了一个调用孤儿的就。。。。。。 http://www.eygle.com/archives/2012/09/12306_oracle_sybase.html |
| 返回顶楼 | |
|
发表时间：2013-02-03
12306网站的技术问题或许有多种解决方案（虽然可能并不完美），但最难解决的是业务问题！
一列火车总共有多少张票？ 恐怕这个就难回答，即使是铁道上的人也不见得能回答的十分清楚。 火车跟公交有几分相似，都有固定站点，每个站点都可能有人上下。不同的是，公交车可以先上车后买票，火车只能先买票后上车。我想这才是问题的根本。公交上去了就上去了，上不去可以等下一趟。火车得先有票才能上车，可是卖票规则却成了难解之题。 北京的城铁要先进一步，虽然它像火车一样先买票后上车，但是你可以一票通吃，车车相连，一票到达（甚至你愿意的话还可以坐过去再坐回来）。 同样，它还具备了公交车的优势，这一趟坐不上还可以等下一趟。 比较之下，会发现就火车表现的最差。即没有公交和城铁的运力，也没有公交和城铁的方便。 如果网闸是12306网站的瓶颈，那售票规则就是列车的瓶颈。如果我们不能改变列车先上车后买票，也不能同一车次增加频次的话，那是不是可以改变下售票的规则呢？ 把售票规则中减少一点点对收入的考量，多一点点人文关怀？ 看了楼上同学发的内容，我回到itpub上看了看，突然想把之前的想法再说详细一点。这段话无论对itpub上那个帖子还是对本帖，我觉得都还算合适的。 也许我们讨论的内容不见得真得能起到作用。但呼声大了，也许还是能有一些影响吧。毕竟真理越辩越明嘛。 |
| 返回顶楼 | |
|
发表时间：2013-02-03
最后修改：2013-02-03
本座认为12306本年的表现还不错的。
本来想发一贴，讨论关于15亿pv的实现方式的。 对于一个卖票的系统，第一任务是卖票，第一任务都没做好，谈什么其他的功能？谈什么UI?只有在第一任务完成好后，你增加的其他功能才会有价值。 15亿PV扛住了，好样的！实现这一目标的团队很棒。本座去年做的项目要调优至pv1个亿，那个过程真是痛苦而难忘的。 UI嘛，还过得去，我就是来买票的，买到就完事，下一次再看它可能得最少半年之后，界面丑不是导致你买不到票的原因。铁道部要是再黑一点，像宾馆一样，从3星升级到4星，房费加200呢?(/坏笑) 12306要优化的，我觉得是: 1，性能在目前的基础上进行稳定，稳定后，再提高。分阶段来。 2、要是能主动通知就好了，有票的时候你就告诉我“可以订票鸟”，不要让我一直刷，这样服务器和我都挺累的。 3、一个系统的成功往往是需要行政手段来干预的，退票功能给黄牛又留了后门了。希望在这一方面做一些努力,让票能直接到第一志愿的人的手里。 高性能方面，我觉得陈皓兄总结的非常棒。 当然，我还是要喷，铁道部你做的这个网站真TM烂！ 喷子是社会进步的基石，只有不停的喷，生活才会越变越好。 一定要喷，这是我们做为公民的权利和也是我们应尽的义务。 |
| 返回顶楼 | |
|
发表时间：2013-02-04
12306在去年国庆之前进行了改版，加入了排队系统，您认为排队系统的增加目的是什么？
增加排队系统目的是控制更多的人同时拥入买票，相当于设置了个关卡，但是这样恰恰给那些刷票软件制造了机会，同时增加了服务器的压力，得不偿失，只是让那些熟悉计算机的人更容易买到票而已。 总的来说，花那么多的钱做出那样的网站，养的却是一群白眼狼，苦B了程序员。 |
| 返回顶楼 | |
