西西河

主题:【原创】无责任推测12306网站遇到的麻烦 -- 代码ABC

共:💬135 🌺246
分页树展主题 · 全看首页 上页
/ 9
下页 末页
        • 家园 不知道我的理解对不对

          就是说12306也就是一个全国性普通的大型购物网站的级别。

          如果这样的话,做成这样子实在是不应该了,因为已经有不少国内成功先例了。

    • 家园 Scale up是不行滴

      还得scale out。Sharding/Partitioning就行了。

      主服务器只做路由,就象ZooKeeper那样。集群里的每台服务器按车次来排。每天全国运行图假设有1000个车次,那么每10个车次(大概有几万张票吧)存在一台服务器里。主服务器按路由表(甚至可以人工做出来这个路由表)把请求路由到各个服务器上。每个服务器做各自的transaction(比如信用卡交易等等)。如果定满了,通知主路由更新信息。

      每个车次订票请求先查主路由,看看是否已经定满,如果还有票,就让客户直接和分服务器联系(http redirect)。10个车次能有多少请求?每秒2000个请求左右吧。MySQL就够了。

      这样看来大概100 到200台服务器就差不多了(加上failover之类的情况),MySQL免费。那么大概硬件200万美元左右吧。

    • 家园 最主要的还有一点,要和现有系统整合

      网站售票部分的数据来源应该是票务车间的中心服务器,必须要考虑窗口售票系统对数据的lock,而且窗口系统的优先级应该是最高的,这样的话,如果窗口的机器已经lock车票,但是又没有购买,然后释放回车票池,这个对系统的冲击才是最大的。

      任何一个人或者团队如果能够解决铁路售票系统的话,都是一个牛人,绝对可以在软件史上留名。

      • 家园 软件史上哪那么容易留名

        铁路售票系统就算在春运期间,它的流量也远不如金融交易结算系统、通讯交换系统和大型网络零售系统,完成那些系统的开发人员谁在软件史上留名了?

        你说的售票窗口lock车票,是典型的分销终端实时性问题。过去很长一段时间都是用预测销售量然后划拨定量库存到终端的方法解决。IT化以后一般用几个手段:1.用软件手段实现划拨定量库存到终端;2.增加浅层数据库应对旁支商业逻辑,比如说“窗口的机器已经lock车票,但是又没有购买”的情况;3.根据项目实际情况拆分主数据库,即降低“车票池”的大小,这是保证系统实时性最根本的手段。

        2000年,该客票系统获得国家科技进步一等奖、“九五”国家科技攻关计划重大科技成果,同年在美国获得COMPUTERWORLD SMITHSONIAN国际信息技术奖。

        现在是2012年,12年过去了,这12年里面,软件科学没什么大进展,实践应用上的硬件、开发工具和技巧都换代了,还换了不只一代。12年前的难点今天不应该还拿来做托词了。

        铁科院昨天做了解释,归咎于带宽不足和需求预估错误----设计目标为日售票量100万笔,实际需求达到166万笔。这个解释就比较聪明,没有说什么东西特别难,做不到,而是老老实实承认自己出了错哪里做得不好。虽然写下错误需求的那个人是不会受到惩罚的,还是要鼓励他们至少能够承认自己并非完美的老实态度。

        • 家园 2000年,qq用户才2万人。。。。

          我就曾经有过2万多的QQ号

          结果密码忘了。。。

        • 家园 他的流量肯定超过单一金融系统

          非常肯定

        • 家园 对于流量的问题,不是很赞同

          我没有做过前端系统,主要的工作经验来源于设备网管。按照我的设想,铁路售票系统的case如下:

          1.登陆

          2.查询余票

          3.预定车票

          4.交易付款

          5.确认交易成功

          大量的数据交互应该在3和5步,在预定车票的时候应该已经在系统中将该数据lock,然后等待付款成功后将车票从系统中提出。如果出现预订后放弃的情况,该车票需要归还票池。

          按照上面的设定,使用cache不会有太多的性能提升,所有的查询,预订和出票应该都使用同一个数据库联接,如果有人出现交易失败一直在系统内试图交易的情况,负载将会急剧上升。而且他是一个实时系统,这样的压力不是说搞定就搞定的。

          再说了通信交换系统或者银行系统,核心机上数据交换都比较少,并且业务相对来说可以拆分,都比这个铁路订票要容易一些。

        • 家园 这个系统对华为中兴这样的真的就是小菜一碟
    • 家园 搞不懂这么简单的系统花这么多钱还不好用

      春运售票系统的商务逻辑是很简单的:买卖行为统一;库存可预设;退货量小...... 需要解决的不过就是访问量大而已。

      当然你非要先做一个淘宝出来,再拿它来卖春运票那也随你----估计铁道部的猪头们就是这么指挥的,而且指不定实现的时候还把数据生成文本自己写代码根据磁轨访问。

      像这样只卖一样货的系统我见过印度人是怎么干的,他们的做法符合KISS规则,干净利落:

      1.每天夜里留出半个小时做数据库维护和报表生成。

      2.绝不做multiple middle layer servers × multiple synchronized databases 的蠢事。大访问量用多个商务逻辑服务器解决,数据库那边最小数据单元为某一次车次在两个相邻车站间的某一座位,即车票为数据单元的组合。纵向拆分数据,每台数据库服务器专门负责一组车次的数据,相互独立。每台机器各自备份,各自生成查询报告。

      3.退票、划票、屏蔽/新增/调拨车次的数据用独立的数据库服务器完成,相关逻辑在中间层hardcode。

      这么做应该是一个几十万元的小项目。

      另外我觉得网上订春运票虽有利于维稳,却有损于社会公平。能够轻松在网上搞定这件事的人看着那些在寒风冷雨中排队的苦哈哈们,多少会带着轻视的目光,而后者心中则难免委屈或恨意。

      • 家园 失之偏颇

        而且真正大规模系统印度人就是失败的

        你把印度人当成偶像,有些孤陋寡闻

        举个例子,State Bank of India是印度最大的银行

        他们的系统相当于国内90年代水准

        • 家园 看见黑影就开枪

          不过说一个我看到的案例而已,你从哪里看出来我觉得印度人开发大规模系统很成功,又从哪里看出来我把他们当偶像了?

          欢迎你多写几个字,拿些和主题有关的数据和实例出来让大家学习、长见识,这样河里的气氛会好很多。

      • 家园 以阴谋论的眼光来看,其中有黑客侠影出现

        另外我觉得网上订春运票虽有利于维稳,却有损于社会公平。能够轻松在网上搞定这件事的人看着那些在寒风冷雨中排队的苦哈哈们,多少会带着轻视的目光,而后者心中则难免委屈或恨意

        说得好,所以,现在的网络定票,其时间应比窗口晚一天而不是早一天。即:这个系统只应当是节约跑路的时间,而不是方便有文化的人。但是,也许正是因为上头的人意识到了,批评的声音永远来自于文化人,所以呢,只要应对好了这一部分人,其它的便不再重要。再也闹不出大的响动来。

        想像一下,假如今年的票,系统非常完美,不闹出这个系统瘫换的事出来,然后,在第一天就把所有的票都顺利地卖给那些会在网上订票的人,那么,谁又来再关心那些只会在窗口排队却无票可买的人呢?

        再脑补一下,以一个典型的阴谋论者的眼光来看,必定是中间有一个意识到这个问题的伟大黑客,故意在其中做了手脚,来关心那些不会在网上订票的大众,伟哉善哉。

分页树展主题 · 全看首页 上页
/ 9
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河