西西河

主题:【讨论】回应对12306.cn网站的技术质疑 -- 忘情

共:💬187 🌺697 🌵3
分页树展主题 · 全看首页 上页
/ 13
下页 末页
    • 家园 估计我说的是废话

      首先指出一个明显弄错的地方“腾讯自称自己的最高日访问量是1.6个亿”。其实是腾讯的最高同时在线人数超过了一亿,最高日访问量必然比这个高1、2个数量级。否则,人均每天才访问一次,岂不荒唐?这个请忘情自己上网核实吧。

      其次,这个明显是一个没有大规模数据处理经验(更别说超大规模)的软件专家。这种专家是啥都敢说敢干的(包括12306.cn)。

      不过人家开始就是承认“本人有限的经验和了解”,不可过责。

      如果忘情有点影响力的话,请铁道部联系腾讯、华为、淘宝、百度等公司会诊,保证能很快解决12306.cn的问题。

      其实18个亿的点击中,真正卖出的票数,有百分之一吗?反正我是点了几百次才能买到一张票的。也就是说每天售出的火车票,可能也就几百万张而已。关键的数据处理量根本就不算太大。

      这个工作,对有超大规模数据处理经验的公司并不困难,它们是从几千访问一步步做到几亿访问获得的经验。

      但对没足够经验的,难如上青天!

      • 家园 我也觉的12306的数据库设计有问题

        但是没有实际数据 没法说。

        高峰时期IT压力,应该是可以分流的,查询和下单负载要分开,不同车次的负载也可以分开呀。

        我看过淘宝的IT人员写的负载均衡的数据库的设计 还有网通的,我觉得应该是有这种技术的,只不过铁路的人员没有找到正确的方法。

        我去年12月份用的12306买票,感觉操作不像taobao那样顺畅,怎么说呢,感觉不像一个成熟的软件公司写的东西,的确,taobao是分散的店家,但是他们不是分散的数据库,所有的买卖,减少库存也是对杭州的服务器读写的,不是在各个卖家的数据库读写的。我记得比较清楚是他们的it设计是每个大城市群是有前置服务器担任镜像的任务

      • 家园 太极公司是做硬件集成的,

        他做软件,在业内就是笑话,不知道是否又外包了,估计不敢。

        • 家园 硬件公司开发软件?

          对没有超大规模数据处理经验的公司来说,即使软件水平很高,12306网站做起来也是非常困难的。有人说这个东西很容易做,纯粹胡说八道。

          但对具有超大规模数据处理经验的公司来说,就没多大难度。

          这篇文章,等于随便拉个大夫来,说病人没救了,治不好没有责任。

          其实是蒙古大夫。

    • 家园 这不是一个单纯的技术问题

      12306这个网站的流量和业务量是一种病态。问题的根源上是:火车票不足以满足所有人的出行需求,并且绝大部分人的需求在同一个时间段内都是刚性的。这样导致的结果是如果网站的处理能力足够的话票会在瞬间买完!这个是任何技术都无法解决的问题,就算能解决所需的代价就会让12306在平时成为一个奢侈品,受到其他“不明真相”者的另一番攻击。(好吧,这是我个人比较阴暗的判断)

      嘿嘿,购票人进入了一个不太明显的囚徒困境。所有人都会第一时间抢票,任你预售时间多长都一样。因此12306的访问量集中在一个很小的时间点上。

      解决这个问题应该是想办法让购票需求平摊开来,或者减少购票人的数量。同时从这两个方面下手效果应该不错。因此非技术解决方法是设计一个适合的交易模式,同时解决上面的两个问题。

      如果让我紧急解决这个问题,我会暂时缩短网络的预售时间。一方面分流一部分人回到窗口买票,更重要的是减少预售时段覆盖的购票人群,减少网站不必要的查询请求。从数据上看12306瞬间访问量是很大,但是其中的水分在于这些访问量有很大一部分是重复的无效流量,是因为得不到所需回应时用户被迫的刷新。

      当然了,这是一个馊主意,根本的解决方法是让所有人都不用担心买不到票。这又不是铁路一家的事情了。

    • 家园 潜水员回复一篇

      看忘情的帖子,确实积累了不少技术的经验。

      可惜多为工程经验,浮于表面。

      就如你分析别人对铁路网站的攻击浮于表面一样,你对数据库的理解也限于了主流产品对你们的洗脑。

      俺给你推荐三个东西,看对你是否有启发

      1 exdata

      2 nettezza

      3 spanner

      如果还有问题,欢迎交流。

      • 家园 不懂

        exdata 和 nettezza, 还有Green Plum 之类的,是用在data warehouse, decision support, 和大规模的OLTP没有什么关系吧。

        Spinner 很有意思,但是全世界有能力搞出类似产品的公司屈指可数吧。

        • 不懂
          家园 如果除了google公司

          那个公司能把spanner搞定就很了不起了,另外--spanner解决的是数据库层面多数据库中心同步数据问题,在高并发上并没看出太厉害,前面的whyshanghai给出点论据好么--最近看了上海EMC研究院颜开的分析,也看了下bigtable和spanner相关论文,数据挖掘方面可能用的多?

    • 家园 外行提合理化建议

      网站访问量这个问题很容易解决-----分流。

      火车票的一大特点是点对点。那么可以按照出发地或者到站地来分流访问。比如按照目的地城市来分,你想买到武汉的票,那么就上12306wuhan.cn,买到银川的票,就上12306yinchuan.cn,等等。对于大站甚至还可以分成绿皮车,硬卧,等等。

      不知道是否可行。

      • 家园 我也想过,但是再一想似乎也不合适

        我也想过,但是再一想似乎也不合适。不管是否网站分开,你都需要在一个唯一的数据库里搜索车票,否则你需要考虑多个数据库之间的数据同步,这更难搞定。

      • 家园 按IP访问划分入口

        比方12306就一个web portal你用户的登录地是山东的IP地址,就直接跳到山东的CDN进行就近处理。后台业务服务器采用多主-多备的形式,数据同步考虑到多CDN采用异步冗余,如果单点(某省CDN)访问有问题,切换到其他CDN访问,主CDN(按中国华中,华北,华南,西南)主要提供数据异步同步和CDN访问控制、切换访问等能力,考虑到平常访问量不大,做capacity planning 时和网通,电信机房采用他们ISP的云方案(弹性扩展)一应付节假日周期的高额访问量,当然演练是必不可少。前端做好大流量清洗设备的配置,如果发现访问过大来自于同个IP,在队列中自动将其踢出。

      • 家园 全国有多少个客运站?

        你从北京到广州,沿途有多少站?各站都有人要上车,要买票,而沿途各站上来的旅客不一定都要求坐到终点,许多是中途下的。如果按目的城市分,得分出多少流来?如果还分为绿皮车,硬卧等,又得多加几倍。系统里还必须区分复用票。就是比如说这车从北京开到广州,中途在武汉有个空位,有人买了从武汉到长沙,那么到长沙后此人下车,这个位置又空出来了,系统得识别统计出来,从长沙站又得重复利用这个座位,这个数据量,工作量得有多大?你觉得现实吗?

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


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

Copyright © cchere 西西河