西西河

主题:【原创】身为码农,为12306说两句公道话 -- 代码狗

共:💬137 🌺892 🌵3
分页树展主题 · 全看首页 上页
/ 10
下页 末页
    • 家园 其实只要跟航空系统学两招,现在火车票问题立即根除

      1、把火车票的价格提升一倍,平时疯狂打折,在旺季就恢复原价;

      2、多找几个携程这样的分销商,把压力往分销商身上排。

      其实我举起双手赞成这样做,高于平时票价的盈余部分用于铁路基建。可是,在我们每时每刻都讲究政治正确的国度,这个方案有实行的一天吗?

      • 家园 你是汪三公子的信徒?

        把火车票的价格提升一倍

        这个不够,座位票应该提高10倍,起码要贵过飞机票才行,把坐火车变成小资的特权。至于其它P民如果春节想便宜回家,可以学阿三那样开闷罐子车,甚至卖“挂票”,跟阿三这样的“民主国家”接轨嘛!这样不管需求会不会大幅降低,铁总起码可以大赚一笔,也不用担心铁路债务高了。

        但是如果真按你的计策行事,你不怕人民群众用口水淹死你?

        • 家园 汪三公子算个屁,你老人家可不要乱戴帽子

          春运期间,客运需求量极大,火车票的性价比明显偏高,才会出现一票难求的情况。目前看来,扩大铁路基建以满足人民的需求在近期是不可能实现的,还不如降低火车票性价比,顺便给火车基建筹集基金。

          反正老百姓买不到车票是骂,车票过贵买不起也是骂。对铁路系统而言,后一种被骂远胜前一种被骂。

          • 家园 好好看看你的观点,这是乱扣帽子?

            你和三公子有何区别?可谓是“一涨解千愁”啊!佩服!佩服!!

            • 家园 你放那种气体!

              就算我支持铁路涨价,汪三公子也支持铁路涨价,只是表明我跟他在这一点的观点上一致而已。在阁下的眼里,怎么我就成为了汪三公子的信徒?

              比如汪主席认为人是要吃饭的,阁下也认为人是要吃饭的,那么阁下就是汪主席的信徒吗?

              我倒想问一问你这个有办法的非汪三公子信徒,你有什么好办法解决一票难求的局面?

    • 家园 百度知道已经有人问“2克浓度为3%的U235在大亚湾核电

      站能发多少KW的电”了

      俺得COPY一下答复,说不定以后抢票能用上

      一次裂变反应平均可以放出200MeV的能量所以1g纯的U235裂变产生的能量约可以使1Mw的功率发电一天。

      所以2克浓度为3%的U235可以发电为0.06x1000KWx24h=1.44x10^3KWh(度)电

    • 家园 为什么G71每种座位是136个商品,而不是16个

      收到有同行质疑136个库存的合理性,他提出的方案是:

      北京西(01号站)到深圳北(17号站)一共设置16个商品:

      SKU01:01号站 到 02号站

      SKU02:02号站 到 03号站

      ...

      SKU16:16号站 到 17号站

      如果出一张01号站到17号站的票,就把SKU01/SKU02....SKU16这16个SKU的库存都减一。

      这种做法是可以运行的。我原来参与设计的一个ERP系统就是这样的做的。

      16个商品方案的优点是商品数会比较少,缺点在于查询性能较低,要查询16次才能知道【北京西到深圳北】还有没有余票。而136个商品的设计,穷举了所有出发和到达站点的组合,出票前只需要查询1次库存就知道还有没有余票。

      大部分面向公众的网站,其业务特点都是读多写少。电商系统的库存查询次数更是远远多于库存修改次数的。在秒杀系统中,可能会出现99%的请求查库存1%请求改库存的情况。

      像12306春运抢票这种场景,在秒杀工具(抢票软件)的推波助澜下,查询1万次库存才成功出一张票也不是没有可能。

      还有人说,KFC的食品可以单卖,也可以套餐,为什么没像我一样搞出这么多SKU,那是因为,KFC门店的人肉查询频率非常低,没有必要为了优化查询性能把库存结构设计成那样。KFC网上订餐比门店的查询压力大一点,但只要不是像12306那样全站商品都秒杀,也是不需要为了优化查询性能把库存结构设计成那样的。

      • 家园 为什么要查16次呢

        在这里SKUn的查询只需要有一个实时更新的SKU1~SKUn-1的最小值,最小值大于1就可以出一个SKUn了啊。是不是只要对SKUn的商品配以一个SKU1到SKUn-1的最小值,然后只查这个值就可以了,不过这个值的同步是个问题。

        • 家园 这样本质上就是在维护136种组合的最小值

          和136种商品没本质区别

          • 家园 16和136种商品维护的难度一样吗

            差了一个数量级啊,这套系统的关键之一不就是维护量的庞大吗?

            • 家园 你的方案和楼主本质上是一样的

              你的方案还需要维护136个最小值。。。

              假设有n个站,你和楼主的方案读操作的时间复杂度都是O(1),写操作的时间复杂度都是O(n^2)(某个商品减少时,会需要要求修改O(n^2)个相关的最小值),所以本质上是一样的。

              如果不维护136个最小值,那就是16个商品的做法。这样读的复杂度是O(n),写的复杂度也是O(n)。

              所以楼主的说法没错,如果读的请求远远大于写的请求,用牺牲写操作性能来增加读操作性能的方案更优。

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


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

Copyright © cchere 西西河