主题：【原创】好吧，给一个铁道部订票系统的正确答案 -- 布老虎
家园 作为开发人员，你这么说是可以理解的。 但是你这么说是不大可能和客户一起坐下来讨论问题，解决问题的。
对开发人员来说，能负的，就只有技术责任。
但是对客户来说，是有政治责任的。
这中间的区别在于，这么说可能有点冒犯：所有的只能负技术责任的人，都是在向需要负政治责任的人，讨饭吃。
因为决定项目给谁，不给谁，技术走 A ，还是走 B 路线，就是一个政治决策过程。当然，这个政治的级别很低，低到往往只需要在两三家做权衡就可以了。
但是因为谁做的决定而出了问题，比如春运售票，那么，技术公司没有人能承担责任，或者会承担责任。因为这个责任太好推卸了。如兄台在楼里洋洋洒洒的技术分析一样。
但是这些都没用。因为所谓的政治责任就是在一定的时间里用替罪羊来尽快地平息事态，并且以最小的代价缓解，注意不是解决，而是缓解问题。
在这个时候，技术，真的不是首要考虑的方向。同时，外面的技术（团队）的的确确就是不如内部的技术团队能够理解，行动，来搞定事情。
这么说可能会让兄台不喜欢。但是还是那句话，你厉害，我承认。但是我不找你，可以吗？
没有任何冒犯之意。见谅。
家园 花，中国的即是世界的，再吹得怎么天花乱坠， 其实就是一个请求分流的问题。
家园 你纯属被PPT忽悠瘸了，开口闭口政治责任 我还以为大家在谈技术。
你搞销售的吧，要不就是做外包的？外包公司嘛，自己完全没有开发能力，纯粹的堆代码做业务逻辑，简单地说就是做field mapping的，没有见识过什么叫真正的软件开发。而且还是在国内干，自己开发水平很低，完全依靠厂商，处于用户态。啥数学证明？现在Wall street的trend,是big data,Memcache,MongoDB，Hadoop/HBase,Apache Kafka,而不是EMS/Oracle。大家都是搞交易系统十几年的老鸟，你这开口闭口政治责任的，糊弄一下外行差不多。Knight Capital是做HFT的，他们的cache就是自己开发的。
Postgresql,我不说别的，你看过那个公司用postgresql来处理大数据量的？笑掉大牙。
家园 你赢了 本想和你认真探讨，可是看来，跟你分析问题，写了也白写，和你说了半天，只看到一堆技术名词，没有看到一个切实可行的能够具体的业务的解决方案，各种技术的优劣利弊也没有任何评价。难怪SUN垮台了，估计就是被所谓的技术人员搞垮的。
我从软件行业出身，接触过金融、电信业务，现从业电力行业，参与过很多外围业务系统的开发和部署，深知一个系统从技术方案到实现远不是几个技术名词的堆砌就能解决的，需要解决实际问题非常之多，像你这样的只讲名词，不讲原型和业务解决方案的，在银行、电力系统里都是直接轰下台，根本不会有人在乎的。
从你说话的内容看，就能够估计出你大约处于一个什么层次。和你探讨问题简直毫无收获。以后不会再回应你的质疑。
希望铁路部门能够采纳你的有效方案，证明你的方案是正确的。投标去吧。你更适合去做销售，因为你比我见过的供应商更加会忽悠名词。销售的典型特点就是：脱离业务讲技术优势，堆砌名词。
实践是检验真理的唯一标准
关键词(Tags): #实践是检验真理的唯一标准， 通宝推：刹那芳华,廣雅疏證,- 复 你赢了
家园 送花成功。感谢：作者获得通宝一枚 - 复 你赢了
家园 嘿嘿 送花 关闭
送花成功。恭喜：你意外获得 4 铢钱。1通宝=16铢
作者，声望:1；铢钱:0。你，乐善:1；铢钱:3。本帖花:1
- 复 你赢了
家园 我实在没有时间debug你的thinking proce 可以看出来你根本看不懂我老的雄文，完全不理解具体的设计思路，也不理解这里面的关键所在，不明白这里面为什么会有挑战性，更不明白为什么铁道部的网站会crash。
你最后居然哆哆嗦嗦拿出一本Postgresql来建议大家好好研究，我靠，开了眼了，你这大数据的处理方法（如果还能叫方法）居然不是分布式处理，你让铁道部用postgresql，接着买几百个核的服务器？？难怪2千万美刀打不住。你这预算，估计得宰上亿美刀。
你把google的那些mapreduce/spanner的paper好好读明白了再来这里讨论。从你的帖子看，你不懂分布式数据处理。
家园 要用分布式系统处理的巨大流量，你居然能整出一单机版来 也算人才啊。
难怪我看半天总觉得不对劲。你对铁道部，就这阶级感情？
家园 我理解也是减库操作是瓶颈 相信只读操作大家都会用cache解决，但有复杂逻辑的减库操作才是性能瓶颈。假设一列车经过20站，共1000个位子，可以用一个1000x20的二维数组来表示，每张票就是同一行的一个连续区间[0,20)。假如减库针对这个二维数组来，那只能一次减一个，但可以将这个数组按照热门票（如[3,5),[1,18))拆分为若干个票仓，订票请求根据票面区间去特定的票仓减库，这样可以一定程度上实现并发减库。然后每隔一段时间冻结所有请求，销毁所有票仓重新合成二维数组（其中若干位已经被占用，代表售出的票)，重新拆分为若干个票仓，如此往复。这样的逻辑，我觉得不一定要用多高级的数据库，只要拆票算法做的好，能根据客户请求自主学习，拆出的票命中率高，还是能实现较好性能的。
通宝推：铁手,家园 这两天热议的美国健保网站也出现同样问题 就是奥巴马care的网站，花了近亿美元，流量顶不住了。
家园 楼主这个想法很简单 楼主忽略了一个很大的问题，售票这个事情你完全不可预测用户的需求，所以跟数据库offline可能不行，你想要的车票库存信息可能需要消耗大量数据库资源。为什么有这个问题呢，因为列车售票是一个弹性资源，比如从广州到北京1000个座位，可能1000张广州到北京，也有可能500个广州到北京，剩下的500个座位就被各种短途需求拆分了，定期去库存数据这个想法恐怕就很难实现了，因为你不知道用户要买一张坐几站的票。