主题： 转贴 12306 外包给阿里巴巴、IBM 等大企业做是否可行？

team470

　　

发表人	内容 [<<]　[<]　[>]　[>>]
polluxli	主题： 转贴 12306 外包给阿里巴巴、IBM 等大企业做是否可行？ 分享给好友 发表时间： 2014-1-10 10:28:16　编辑　引用回复　快速留言　赠送鲜花　举报 每逢春运，铁路系统唯一的官方购票网站12306就会成为众矢之的，今年也不例外。今年12306并未出现大面积崩溃问题，但这并不妨碍它再次被淹没在一片埋怨声中。1月5日，有网友在问答网站“知乎”上提问，如果把12306外包给IBM或者阿里巴巴来做的话，能不能比现在做得好？我们来看看获得5千余名网友“点赞”的知乎用户王强的解答吧。 官方订票网站12306崩溃时的页面（资料图） 以下是王强的回复（有删节）： 12306首秀被骂的狗血喷头后铁道部找来IBM、阿里巴巴等大企业要解决方案，给出的条件是资金管够但是问题得解决。几大企业最后都拒绝了。 12306开始自己尝试解决问题。他们发现市面上可以买到的成套解决方案都不足以应付春运购票负载，所以只能自己改进已有的数据库以前12306用的是小型机，发现性能严重不足，遂改用x86系统+linux平台（原平台为HP Superdome小型机，UNIX系统，Sybase ASE数据库）。最后他们的核心系统用了十几个节点（现在应该是17节点）的多路Xeon E7（具体几路待考），每个节点配1TB内存，数据库全部在内存中运行。2013年春运，12306系统峰值负载11万tps，与2012年淘宝双11活动峰值负载相当，新的系统基本经受住了考验。 补充：以上内容是我在2013年7月得知的信息，彼时没有任何公开来源提到过12306新系统的技术细节。甚至，当时局外人没人知道12306已经在2012年开始做了技术改造。直到数日之前，铁总首次向媒体公开了技术改造的详情：分布式集群内存数据技术引领12306技术革命。这篇文章给出的细节，与我之前看到的内容完全一致。由此我可以确信信息来源是此次技术升级的核心人士。 另外，关于第三方合作对方给出的信息是IBM、Oracle、Sybase全部不能满足要求，主要是这些厂商的方案部署以后，要升级时不能做到不停机灵活扩展。也就是说，IBM没有做到是他们技术不足“搞不定”。阿里巴巴参与了改造，负责了排队系统。此外，虽然后端经受住了压力，前端却如大家所看到的那样还是频频卡死。到底卡死的原因是前端水平太低还是访问压力太大，暂时没有可靠的信息供判断。 淘宝的问题是其系统架构是分散度较高的，各个订单之间关联度不大；而12306每出一张票都要对全线路做数据更新（因为一条线路存在多个站点），因此系统负载相较淘宝来说集中很多，直接搬淘宝的方案也无法解决问题。淘宝的应用类型决定了阿里巴巴可以通过部署大量的服务器来分散压力，但12306就不行。其实他们的核心系统的硬件成本不过数百万，不是他们不想采购更多服务器，而是买更多的服务器也没什么用途。最后，在经过软件层面的优化之后，12306的瓶颈其实是核心节点的CPU、内存性能。但是这个性能的提升不是朝夕的事情，而是受限于摩尔定律，基本上每两年才能翻一倍多些。（这段话是我自己的分析，不过现在12306的后端数据库系统应付现有需求已经够用了） 补充：关于座位实时复用，我看到的信息明确表明12306出票时，每出一张区间票都要实时调整该线路其他受影响区间段的余票数量，且这是很大的压力来源；另外，对方表示所使用的GemFire数据库与简单的memcache/redis数据缓冲不同，有着本质区别。 然后我说点对铁路系统购票困难现象的看法： 一种商品只要出现供不应求现象，那么结果只有两种：大家排队购买；出现黑市，变相提高商品的流通价格并抑制需求。 12306这个事情，就是标准的限价商品供不应求之后出现排队与黑市现象的例子。因为供不应求，所以有了黄牛、抢票软件与秒杀。如果供应充足，一个车次直到发车前都有一两张余票，那么黄牛、抢票就毫无存在价值，旅客也用不着守在电脑前和其他人比拼手速和网速以及电脑性能网络性能了。 现在供应不足的前提下，12306就算把系统做的性能再高，也只是会加快热门车次票务秒杀的速度而已——而这更会刺激抢票软件，大家为了在更短的时间里成功抢到队列名额就会不断提升自己的抢票性能。打个比方说就是一个店门前排队，消费者为了增加买到商品的概率去雇人代排，每个消费者都雇了好多人，造成店门口的通道拥挤不堪。为了减缓拥堵，商家不断拓宽通道，但每次一拓宽消费者们就会增加雇佣的排队劳力把新增的通道空间占满，形成恶性循环。这样下去，只要还存在供不应求的现象，这种循环就不会有终止的时候。也就是说，12306的问题主要不是出在网站本身。 12306这个事情，网上有多少网友从一开始就献计献策了，也有不少网友提供了很不错的建议。但不得不说，很多网友在提建议时完全就是一种居高临下、自以为是的态度，上来就先认定需求简单可以轻松应付，随便有点经验的工程师就能搞定，12306出问题全怪体制太烂，国企效率低下，一帮人光拿钱不做事，技术水平太低…… 淘宝2013年双11活动，峰值流量是一秒钟完成1.3万笔订单。12306在2014年1月6日全天网络出票400万张。看起来双11流量完爆12306是吧？等等！别忘了12306这400万张票可不是全天悠悠闲闲平均地卖出去的，而是分成10个时段集中被抢走的。每个时段开始放票后数分钟之内大部分票就已经被抢光了。以每个时段40万票，峰值持续三分钟估算，高峰期一分钟出票在10万张以上毫不夸张。诚然，一分钟10万订单还比不上淘宝2013双11，但别忘了一年以前阿里巴巴也只是达到了一分钟15万订单的水平而已（并且在高峰期一样卡爆）。而且一分钟10万出票还满足不了需求的，以旅客购票的热情来看，达到一分钟50万票都不一定能让所有旅客满意。 淘宝在2012年双11时已经是业界顶尖水平了，其软硬件技术皆为自主研发，既便如此面对一分钟十几万的订单量都会卡死。请问，觉得12306“需求简单，问题可以轻松解决”的，是不是水平已经高到了阿里巴巴都要请你们去领导整个技术团队的级别呢？是不是你们的方案可以轻松应付每分钟数十万笔订单，达到全球一流水平了？ 淘宝面临的需求是业界从未有过的，所以淘宝的路很艰难。12306面临的需求是其他人遇到过的么？全世界哪个国家、哪种客运票务系统敢说自己的负载达到12306三分之一的水平？面对空前庞大的压力，诸位“技术高手”只是凭着自己一点程序员的经验，在电脑前一个人思考上一会儿就给出个“简单、实用、省钱、轻松应付”的解决方案——你们知不知道“自大”这两个字怎么写啊？ 还有一些人，看说IBM没做就一口认定是12306故意排挤IBM，认定IBM解决这问题肯定没压力。好嘛，IBM什么时候做过如此规模的票务系统了？你细节什么都不知就预设结论了？为啥淘宝当年没选择IBM作为方案提供商而是自主研发？IBM的大数据业务主要集中在金融领域，这不代表它在其他领域就样样精通好不好？它能拿出的方案无非是Power7小型机平台，Power7在数据库性能上又比Xeon E7强多点？然后Power7系统卖多少钱了解么？后续维护难度多大了解么？把适合银行金融行业的平台放到12306来真的合适么？说起来，不就是因为“12306”和“IBM”这俩名字放一起，诸位内心里首先就给前者打了负分对后者仰视么？要是把“12306”换成“nasdaq”，那结论就又是一回事儿了——哦正好nasdaq没用IBM方案，可见nasdaq是排挤IBM内部人赚黑心钱是吧？不过2013年工商银行系统升级故障，应该是和方案提供商IBM无关的，肯定是国企的体制问题无误！ 最后呢？12306还是做到了全球最强的客运票务系统。一贯被认为是因循守旧的国企，在选择技术方案时放弃沿用多年的小型机/UNIX平台去拥抱业界还是新鲜事物的基于x86/linux的大规模分布内存数据库系统，承受住了堪比2012年淘宝双11的压力。在这个领域，12306可以自豪地说自己是做的最好的案例。它还在卡，还是偶尔崩溃，页面还是难看，可是这些迟早会改进。这个过程中也还是会有冷嘲热讽，还是会有所谓的大牛指点江山，但最终解决春运高峰期一天数百万张秒杀售票的，还是12306自己。所以，走自己的路，让别人去说吧。 原文链接：12306 外包给阿里巴巴、IBM 等大企业做是否可行？
人面兽心负责总	发表时间： 2014-1-10 10:40:33　编辑　引用回复　快速留言　赠送鲜花　举报 这里面的灰色利益太大了，那么多钱弄个这破网站......
fercilu	发表时间： 2014-1-10 10:40:34　编辑　引用回复　快速留言　赠送鲜花　举报 12306的数据量。。阿里巴巴勉强应该可以试试 不过IBM，你敢把全国的居民信息放给美国人，我都不认为他有处理这么大量数据的能力
河南圣人	发表时间： 2014-1-10 10:52:57　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 fercilu 发表： 12306的数据量。。阿里巴巴勉强应该可以试试 不过IBM，你敢把全国的居民信息放给美国人，我都不认为他有处理这么大量数据的能力 铁总可以把票源一分为4,12306和淘宝京东亚马逊一家做1/4，这就很好的解决流量问题 至于IBM行不行，拜托去多读点书，IBM的历史可以说就是计算机的历史，他不行，笑话
fercilu	发表时间： 2014-1-10 11:03:53　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 河南圣人 发表： 此文由 fercilu 发表： 12306的数据量。。阿里巴巴勉强应该可以试试 不过IBM，你敢把全国的居民信息放给美国人，我都不认为他有处理这么大量数据的能力 铁总可以把票源一分为4,12306和淘宝京东亚马逊一家做1/4，这就很好的解决流量问题 至于IBM行不行，拜托去多读点书，IBM的历史可以说就是计算机的历史，他不行，笑话 IBM的历史只是历史，就没做过这么大量的经验，要是前美国国家安全局来我倒相信，这家有量的经验 至于票源分割给4家，短时都爆掉信不信，我现在电脑4个全开加刷；而且这种是和铁路总票池子交互的，根子上就是要改变过去的票务工作体系，以后和公安的居民身份证验证系统连起来时候，看看你准备怎么弄
河南圣人	发表时间： 2014-1-10 11:09:32　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 fercilu 发表： 此文由 河南圣人 发表： 此文由 fercilu 发表： 12306的数据量。。阿里巴巴勉强应该可以试试 不过IBM，你敢把全国的居民信息放给美国人，我都不认为他有处理这么大量数据的能力 铁总可以把票源一分为4,12306和淘宝京东亚马逊一家做1/4，这就很好的解决流量问题 至于IBM行不行，拜托去多读点书，IBM的历史可以说就是计算机的历史，他不行，笑话 IBM的历史只是历史，就没做过这么大量的经验，要是前美国国家安全局来我倒相信，这家有量的经验 至于票源分割给4家，短时都爆掉信不信，我现在电脑4个全开加刷；而且这种是和铁路总票池子交互的，根子上就是要改变过去的票务工作体系，以后和公安的居民身份证验证系统连起来时候，看看你准备怎么弄 铁总的这个12306只怕后台的数据库服务器是浪潮提供，而浪潮，给IBM提鞋也不配 还是那句话，IBM不能做这世界上就没有人能做 铁道部那点高峰流量，分成4份的话对于淘宝京东那就是不是事 还短时爆掉，还4个刷
西瓜雷	发表时间： 2014-1-10 11:51:57　编辑　引用回复　快速留言　赠送鲜花　举报 编的吧，ibm不行谁行？阿里巴巴？别逗了好么
迎风一刀	发表时间： 2014-1-10 12:01:42　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 河南圣人 发表： 此文由 fercilu 发表： 此文由 河南圣人 发表： 此文由 fercilu 发表： 12306的数据量。。阿里巴巴勉强应该可以试试 不过IBM，你敢把全国的居民信息放给美国人，我都不认为他有处理这么大量数据的能力 铁总可以把票源一分为4,12306和淘宝京东亚马逊一家做1/4，这就很好的解决流量问题 至于IBM行不行，拜托去多读点书，IBM的历史可以说就是计算机的历史，他不行，笑话 IBM的历史只是历史，就没做过这么大量的经验，要是前美国国家安全局来我倒相信，这家有量的经验 至于票源分割给4家，短时都爆掉信不信，我现在电脑4个全开加刷；而且这种是和铁路总票池子交互的，根子上就是要改变过去的票务工作体系，以后和公安的居民身份证验证系统连起来时候，看看你准备怎么弄 铁总的这个12306只怕后台的数据库服务器是浪潮提供，而浪潮，给IBM提鞋也不配 还是那句话，IBM不能做这世界上就没有人能做 铁道部那点高峰流量，分成4份的话对于淘宝京东那就是不是事 还短时爆掉，还4个刷 12306的后台数据库是浪潮提供的？？ 真敢说！ 数据库要么Sybase，要么Oracle，浪潮算什么东西。
ye	发表时间： 2014-1-10 12:03:37　编辑　引用回复　快速留言　赠送鲜花　举报 还有人认为淘宝比IBM厉害？IBM在没计算机的时代，就是帮美国政府做统计人口起家的。
猪二哥	发表时间： 2014-1-10 12:04:08　编辑　引用回复　快速留言　赠送鲜花　举报 我只能呵呵了
fercilu	发表时间： 2014-1-10 12:08:03　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 河南圣人 发表： 此文由 fercilu 发表： 此文由 河南圣人 发表： 此文由 fercilu 发表： 12306的数据量。。阿里巴巴勉强应该可以试试 不过IBM，你敢把全国的居民信息放给美国人，我都不认为他有处理这么大量数据的能力 铁总可以把票源一分为4,12306和淘宝京东亚马逊一家做1/4，这就很好的解决流量问题 至于IBM行不行，拜托去多读点书，IBM的历史可以说就是计算机的历史，他不行，笑话 IBM的历史只是历史，就没做过这么大量的经验，要是前美国国家安全局来我倒相信，这家有量的经验 至于票源分割给4家，短时都爆掉信不信，我现在电脑4个全开加刷；而且这种是和铁路总票池子交互的，根子上就是要改变过去的票务工作体系，以后和公安的居民身份证验证系统连起来时候，看看你准备怎么弄 铁总的这个12306只怕后台的数据库服务器是浪潮提供，而浪潮，给IBM提鞋也不配 还是那句话，IBM不能做这世界上就没有人能做 铁道部那点高峰流量，分成4份的话对于淘宝京东那就是不是事 还短时爆掉，还4个刷 铁路后台连着全国票务系统，是和窗口适时连接的。。最大的问题是火车数量不够，所以人从来比票多，这个不解决上什么都是假 瞬间访问量就有10亿加，涉及到具体的数据交换啥的，根本就是洪水，所以我说美国除了前国家安全局这样能同时监控整个西方世界的数据信息的才有处理这种的经验，
fercilu	发表时间： 2014-1-10 12:13:06　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 ye 发表： 还有人认为淘宝比IBM厉害？IBM在没计算机的时代，就是帮美国政府做统计人口起家的。 都是服务提供商，硬件啥的早就不是IBM的主业了，单纯短时到数据量的处理， 真心不看好IBM,没做过就是没做过 你们喜欢看历史，我说历史上，西方所有外国给我们提鞋都不够呢。。 统计人口？我们搞人口普查是什么时候来着，兔子的经验不是更足，这都什么和什么啊
frellwit	发表时间： 2014-1-10 12:14:34　编辑　引用回复　快速留言　赠送鲜花　举报 苏宁就是IBM做的吧 IBM在硬件及基础层的实力毋庸置疑，不过做一个特别的架构设计处理未必是他们的强项，他们也未必愿意趟这种浑水。 打个不恰当的比方，像ERP的财务甚至物流模块大同小异，遇上生产控制，那就填完一个坑再挖一个坑，填完了再挖……
河南圣人	发表时间： 2014-1-10 12:17:51　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 迎风一刀 发表： 12306的后台数据库是浪潮提供的？？ 真敢说！ 数据库要么Sybase，要么Oracle，浪潮算什么东西。 数据库和数据库服务器是两种东西
河南圣人	发表时间： 2014-1-10 12:24:41　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 fercilu 发表： 铁路后台连着全国票务系统，是和窗口适时连接的。。最大的问题是火车数量不够，所以人从来比票多，这个不解决上什么都是假 瞬间访问量就有10亿加，涉及到具体的数据交换啥的，根本就是洪水，所以我说美国除了前国家安全局这样能同时监控整个西方世界的数据信息的才有处理这种的经验， 今年12306的高峰流量不过1.2亿，这就崩溃了 这跟百度腾讯阿里比起来，弱爆了 估计百度的流量说出来能吓死你
河南圣人	发表时间： 2014-1-10 12:25:38　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 fercilu 发表： 铁路后台连着全国票务系统，是和窗口适时连接的。。最大的问题是火车数量不够，所以人从来比票多，这个不解决上什么都是假 瞬间访问量就有10亿加，涉及到具体的数据交换啥的，根本就是洪水，所以我说美国除了前国家安全局这样能同时监控整个西方世界的数据信息的才有处理这种的经验， 今年12306的高峰流量不过1.2亿，这就崩溃了 这跟百度腾讯阿里比起来，弱爆了 估计百度的流量说出来能吓死你
flea888	发表时间： 2014-1-10 12:27:10　编辑　引用回复　快速留言　赠送鲜花　举报 遂改用x86系统+linux平台 平台为HP Superdome小型机，UNIX系统，Sybase ASE数据库 要编故事,最好不要涉及细节,说的越多,漏洞越多.
合鞋	发表时间： 2014-1-10 12:27:15　编辑　引用回复　快速留言　赠送鲜花　举报 我咋记得当初IBM参与了12306投标的，结果铁道部选了另一个报价便宜的呢？
lidijia	发表时间： 2014-1-10 12:27:40　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 ye 发表： 还有人认为淘宝比IBM厉害？IBM在没计算机的时代，就是帮美国政府做统计人口起家的。 美国人口统计的难度远远低于天朝的吧？ 没有计算机的时代就更少了吧？
河南圣人	发表时间： 2014-1-10 12:31:15　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 flea888 发表： 遂改用x86系统+linux平台 平台为HP Superdome小型机，UNIX系统，Sybase ASE数据库 要编故事,最好不要涉及细节,说的越多,漏洞越多. 不是说政府采购优先国货吗，我还以为是浪潮或者联想呢 居然是HP

　　
　　=====================
　　
　　
　　
　　

发表人	内容 [<<]　[<]　[>]　[>>]
lidijia	发表时间： 2014-1-10 12:35:43　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 河南圣人 发表： 此文由 fercilu 发表： 12306的数据量。。阿里巴巴勉强应该可以试试 不过IBM，你敢把全国的居民信息放给美国人，我都不认为他有处理这么大量数据的能力 铁总可以把票源一分为4,12306和淘宝京东亚马逊一家做1/4，这就很好的解决流量问题 至于IBM行不行，拜托去多读点书，IBM的历史可以说就是计算机的历史，他不行，笑话 车票又不是固定的，也不是所有人买的都是全程票。一条线路，每出一张票，就要重新计算剩下的票，这个处理只能在一个系统里进行，卖票系统分得再多又有什么用？最后的数据都要返回到铁道部的系统里进行处理。 IBM造机器可以，但是处理这种天量数据，未必有足够的经验。不要拿统计米国人口说事，天朝人口比米国的高出一个数量级。复杂程度怕是至少要高出几个数量级吧。
法兰西9	发表时间： 2014-1-10 12:43:06　编辑　引用回复　快速留言　赠送鲜花　举报 Ibm都不行那谁都搞不定。
biermann	发表时间： 2014-1-10 12:44:14　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 fercilu 发表： 此文由 ye 发表： 还有人认为淘宝比IBM厉害？IBM在没计算机的时代，就是帮美国政府做统计人口起家的。 都是服务提供商，硬件啥的早就不是IBM的主业了，单纯短时到数据量的处理， 真心不看好IBM,没做过就是没做过 你们喜欢看历史，我说历史上，西方所有外国给我们提鞋都不够呢。。 统计人口？我们搞人口普查是什么时候来着，兔子的经验不是更足，这都什么和什么啊 那我们就来比一下，IBM和铁道部，或者说铁道部的外包公司（以下简称铁道系统）。 比员工素质，请问ibm和铁道系统孰优孰劣？ 比管理制度，请问IBM和铁道系统孰优孰劣？ 比专业技术，请问IBM和铁道系统孰优孰劣？ 任何一个方面，IBM都是完胜。 所谓铁道系统的经验优势，请问铁道部是怎么学会管理春运的？无非是90年代以后，随着中国人口流动暴增，铁道部在压力面前摸索出了些经验。 铁道系统这么差的素质，摸索几年也就明白了，以IBM的素质，你觉得搞明白春运过程要多久？ 大家都是在游泳中学会游泳的，无非是你先学了几年，但人家身体条件胜你十倍，就算人家暂时不会游泳，但站在池边，肌肉曲线一露，和你那肚腩一比，人人都知道他很快就会比你游得好。 所以IBM做没做过类似的我不知道也不感兴趣，我知道只要IBM做，99%的可能比他们做得好。
biermann	发表时间： 2014-1-10 12:56:10　编辑　引用回复　快速留言　赠送鲜花　举报 铁道部无非就是早接触了那么十几年春运，还就成了绝不外包的法宝了。 可笑，就这些计划经济企业笨拙的管理体制，你积累的那点经验，人家现代化企业经历过一次就全搞明白了。 南京熊猫是中国无线电的鼻祖，90年代后期拿了国家巨额资助去研发手机，屁也做不出来。 等到华为中兴宣布进军手机行业，还没做呢，老外就大惊失色，说完了，手机行业将重新洗牌。他们怎么不说华为中兴没经验啊？ 先进企业就是先进企业，就像任正非说的，华为改做拖拉机一样挣钱。 质疑IBM，以为IBM不如铁道部，不如太极浪潮的人，先去看看IBM的发展历史，看看IBM这近百年来转换过多少方向，看看IBM研究出过多少概念。人家这么多年，居然能始终站在世界科技进步的浪尖，这就是一个奇迹，IBM缺点再多，也不是一个苏联50年代体制的铁道部或者国内拉关系走后门吃政府饭的小IT公司可比的。 该内容由 biermann 在 2014-1-10 12:58:11编辑过
Gamma	发表时间： 2014-1-10 12:59:10　编辑　引用回复　快速留言　赠送鲜花　举报 这个是就像梁山108将个个好汉，合一块了就都鸟都不像，其实，有些事，不是想做就做的，有东西让你不这么做也不能这么做。这个才是本质。技术，其实在大多数情况下都没有问题。
河南圣人	发表时间： 2014-1-10 13:03:26　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 lidijia 发表： 车票又不是固定的，也不是所有人买的都是全程票。一条线路，每出一张票，就要重新计算剩下的票，这个处理只能在一个系统里进行，卖票系统分得再多又有什么用？最后的数据都要返回到铁道部的系统里进行处理。 IBM造机器可以，但是处理这种天量数据，未必有足够的经验。不要拿统计米国人口说事，天朝人口比米国的高出一个数量级。复杂程度怕是至少要高出几个数量级吧。 铁道部那算个J8天量数据，他那个属于数据库里最简单的一种，淘宝百度无论数据复杂程度还是数据量比他复杂NNNNN倍 从数据库的角度来说，最简单的划分办法就是按车次分， 整条线整条线的包出去，比如上海到乌鲁木齐这趟车包给京东，长春到昆明那趟包给淘宝，那么这次车的所有乘客都去京东或者淘宝买，不存在什么所有人买的都是全程票之类的问题
lotfan0623	发表时间： 2014-1-10 13:03:48　编辑　引用回复　快速留言　赠送鲜花　举报 支持,铁总已经做得不错了 这么大规模的春运,是任何国家从前都没有应对过的,美国人来了也一样 根本在旅客人数太多
frellwit	发表时间： 2014-1-10 13:07:37　编辑　引用回复　快速留言　赠送鲜花　举报 知乎帖子下面有个评论的意思还是对的，代码再优化硬件再增长，也不会多出一张票来。 具体到系统，看看苏宁那鸟样就知道了。 阿里巴巴刚起来的时候找IBM开发后来干脆把人挖过来自己开发。IBM想起自己要搞这一块了又到阿里去挖人。具体的项目大多外包给其他公司在自己的底层系统上搞开发。
国民汽车2010	发表时间： 2014-1-10 13:12:21　编辑　引用回复　快速留言　赠送鲜花　举报 就凭那JB恶劣到家的界面 就知道12306根本没有下功夫去做 就像当年铁道部号称火车实行实名制就会崩溃一样，JB扯蛋 不就是为了给黄牛留空间嘛 上面有人说得对，这种票务的数据库几乎就是最简单的一种，XX次就那么多票那几个站分得清清楚楚，别扯一张票就牵动全国的蛋。。。 别说什么一下子几个亿请求，多少亿请求有球用又不是每个都要处理。票就那么多，同时达成的数据量少得可怜，还真不是淘宝那几家瞧得起的。 该内容由 国民汽车2010 在 2014-1-10 13:24:27编辑过
狼牙山下的来客	发表时间： 2014-1-10 13:13:54　编辑　引用回复　快速留言　赠送鲜花　举报 就12306的业务量，对于电信行业boss系统来说真不算什么，就拿北京移动一个中等规模的省公司来讲，每月百亿的话单量，基本实现实时采集实时扣费实时停复机，这个系统也花不到12306那些钱。而中国的电信行业boss系统，现在基本都是国内厂商做的。
doublemint	发表时间： 2014-1-10 13:24:01　编辑　引用回复　快速留言　赠送鲜花　举报 就算12306服务器是286的，一张票都刷不出来，难道铁总就会把票砸在手里么？ 半夜排队去买房号的怎么不抱怨开发商没有网上卖房呢？
刚直清正朱镕基	发表时间： 2014-1-10 13:28:38　编辑　引用回复　快速留言　赠送鲜花　举报 两年多了，连个网站证书都搞不清楚 现在看不到安全提示反而不习惯了
尤文	发表时间： 2014-1-10 13:29:01　编辑　引用回复　快速留言　赠送鲜花　举报 电信行业的计费系统,比12306简单多了
钢架构	发表时间： 2014-1-10 13:31:21　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 河南圣人 发表： 此文由 fercilu 发表： 12306的数据量。。阿里巴巴勉强应该可以试试 不过IBM，你敢把全国的居民信息放给美国人，我都不认为他有处理这么大量数据的能力 铁总可以把票源一分为4,12306和淘宝京东亚马逊一家做1/4，这就很好的解决流量问题 至于IBM行不行，拜托去多读点书，IBM的历史可以说就是计算机的历史，他不行，笑话 苏宁网上商场就是IBM实施，结果大促的时候，直接卡死，成了业界笑柄，维护费一年几亿。 号称业界天坑。 IBM在企业级应用还可以，处理这个超级并发他玩不过来。 不然也不会再云计算领域给亚马逊和saleforce横扫。 alibaba可以 现在12306最大问题是峰值太高。
钢架构	发表时间： 2014-1-10 13:33:30　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 ye 发表： 还有人认为淘宝比IBM厉害？IBM在没计算机的时代，就是帮美国政府做统计人口起家的。 去查查CSC，这个才是美国政府最大的IT服务商。
钢架构	发表时间： 2014-1-10 13:37:39　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 河南圣人 发表： 此文由 lidijia 发表： 车票又不是固定的，也不是所有人买的都是全程票。一条线路，每出一张票，就要重新计算剩下的票，这个处理只能在一个系统里进行，卖票系统分得再多又有什么用？最后的数据都要返回到铁道部的系统里进行处理。 IBM造机器可以，但是处理这种天量数据，未必有足够的经验。不要拿统计米国人口说事，天朝人口比米国的高出一个数量级。复杂程度怕是至少要高出几个数量级吧。 铁道部那算个J8天量数据，他那个属于数据库里最简单的一种，淘宝百度无论数据复杂程度还是数据量比他复杂NNNNN倍 从数据库的角度来说，最简单的划分办法就是按车次分， 整条线整条线的包出去，比如上海到乌鲁木齐这趟车包给京东，长春到昆明那趟包给淘宝，那么这次车的所有乘客都去京东或者淘宝买，不存在什么所有人买的都是全程票之类的问题 错了，很复杂的流程。我们和阿里的同事讨论过。 就是业务的耦合度太高了。 京东和淘宝，可以很轻松把客户下单，发货，清款，退货分开 而铁路耦合太高，就是下单和退货，和退订票从新入库，基本要在5小时结清。还不算清账流程。 这个里面的流程分录可以达到400多个节点。
IQ50	发表时间： 2014-1-10 13:45:59　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 biermann 发表： 此文由 fercilu 发表： 此文由 ye 发表： 还有人认为淘宝比IBM厉害？IBM在没计算机的时代，就是帮美国政府做统计人口起家的。 都是服务提供商，硬件啥的早就不是IBM的主业了，单纯短时到数据量的处理， 真心不看好IBM,没做过就是没做过 你们喜欢看历史，我说历史上，西方所有外国给我们提鞋都不够呢。。 统计人口？我们搞人口普查是什么时候来着，兔子的经验不是更足，这都什么和什么啊 那我们就来比一下，IBM和铁道部，或者说铁道部的外包公司（以下简称铁道系统）。 比员工素质，请问ibm和铁道系统孰优孰劣？ 比管理制度，请问IBM和铁道系统孰优孰劣？ 比专业技术，请问IBM和铁道系统孰优孰劣？ 任何一个方面，IBM都是完胜。 所谓铁道系统的经验优势，请问铁道部是怎么学会管理春运的？无非是90年代以后，随着中国人口流动暴增，铁道部在压力面前摸索出了些经验。 铁道系统这么差的素质，摸索几年也就明白了，以IBM的素质，你觉得搞明白春运过程要多久？ 大家都是在游泳中学会游泳的，无非是你先学了几年，但人家身体条件胜你十倍，就算人家暂时不会游泳，但站在池边，肌肉曲线一露，和你那肚腩一比，人人都知道他很快就会比你游得好。 所以IBM做没做过类似的我不知道也不感兴趣，我知道只要IBM做，99%的可能比他们做得好。 你不是学计算机的，绝对不是！ 而且对计算机运行模式完全不了解！如果你不能或者说ibm不能改变计算机运行方式。要解决目前12306面临的数据洪水，唯一办法是改变买票规则
河南圣人	发表时间： 2014-1-10 13:53:00　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 钢架构 发表： 此文由 河南圣人 发表： 此文由 lidijia 发表： 车票又不是固定的，也不是所有人买的都是全程票。一条线路，每出一张票，就要重新计算剩下的票，这个处理只能在一个系统里进行，卖票系统分得再多又有什么用？最后的数据都要返回到铁道部的系统里进行处理。 IBM造机器可以，但是处理这种天量数据，未必有足够的经验。不要拿统计米国人口说事，天朝人口比米国的高出一个数量级。复杂程度怕是至少要高出几个数量级吧。 铁道部那算个J8天量数据，他那个属于数据库里最简单的一种，淘宝百度无论数据复杂程度还是数据量比他复杂NNNNN倍 从数据库的角度来说，最简单的划分办法就是按车次分， 整条线整条线的包出去，比如上海到乌鲁木齐这趟车包给京东，长春到昆明那趟包给淘宝，那么这次车的所有乘客都去京东或者淘宝买，不存在什么所有人买的都是全程票之类的问题 错了，很复杂的流程。我们和阿里的同事讨论过。 就是业务的耦合度太高了。 京东和淘宝，可以很轻松把客户下单，发货，清款，退货分开 而铁路耦合太高，就是下单和退货，和退订票从新入库，基本要在5小时结清。还不算清账流程。 这个里面的流程分录可以达到400多个节点。 复杂个J8，话撂着，铁道部这个属于数据库里最简单的一种，话说你肯定没学过数据库，这种一趟趟的车次，车次之间没啥关系的数据不要太简单。 就像我上面说过的，上海到乌鲁木齐，就这几十个站而已。其他的车次属于简单的叠加，相互之间没关系
IQ50	发表时间： 2014-1-10 13:53:13　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 钢架构 发表： 此文由 河南圣人 发表： 此文由 lidijia 发表： 车票又不是固定的，也不是所有人买的都是全程票。一条线路，每出一张票，就要重新计算剩下的票，这个处理只能在一个系统里进行，卖票系统分得再多又有什么用？最后的数据都要返回到铁道部的系统里进行处理。 IBM造机器可以，但是处理这种天量数据，未必有足够的经验。不要拿统计米国人口说事，天朝人口比米国的高出一个数量级。复杂程度怕是至少要高出几个数量级吧。 铁道部那算个J8天量数据，他那个属于数据库里最简单的一种，淘宝百度无论数据复杂程度还是数据量比他复杂NNNNN倍 从数据库的角度来说，最简单的划分办法就是按车次分， 整条线整条线的包出去，比如上海到乌鲁木齐这趟车包给京东，长春到昆明那趟包给淘宝，那么这次车的所有乘客都去京东或者淘宝买，不存在什么所有人买的都是全程票之类的问题 错了，很复杂的流程。我们和阿里的同事讨论过。 就是业务的耦合度太高了。 京东和淘宝，可以很轻松把客户下单，发货，清款，退货分开 而铁路耦合太高，就是下单和退货，和退订票从新入库，基本要在5小时结清。还不算清账流程。 这个里面的流程分录可以达到400多个节点。 对，估计除了登陆可以分出去，其他的运算都分不出去。其实可以改变买票规则。登陆时就预约。也就是排队系统。而且实名排队。估计能解决目前的困局
国民汽车2010	发表时间： 2014-1-10 13:55:08　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 钢架构 发表： 此文由 河南圣人 发表： 此文由 lidijia 发表： 车票又不是固定的，也不是所有人买的都是全程票。一条线路，每出一张票，就要重新计算剩下的票，这个处理只能在一个系统里进行，卖票系统分得再多又有什么用？最后的数据都要返回到铁道部的系统里进行处理。 IBM造机器可以，但是处理这种天量数据，未必有足够的经验。不要拿统计米国人口说事，天朝人口比米国的高出一个数量级。复杂程度怕是至少要高出几个数量级吧。 铁道部那算个J8天量数据，他那个属于数据库里最简单的一种，淘宝百度无论数据复杂程度还是数据量比他复杂NNNNN倍 从数据库的角度来说，最简单的划分办法就是按车次分， 整条线整条线的包出去，比如上海到乌鲁木齐这趟车包给京东，长春到昆明那趟包给淘宝，那么这次车的所有乘客都去京东或者淘宝买，不存在什么所有人买的都是全程票之类的问题 错了，很复杂的流程。我们和阿里的同事讨论过。 就是业务的耦合度太高了。 京东和淘宝，可以很轻松把客户下单，发货，清款，退货分开 而铁路耦合太高，就是下单和退货，和退订票从新入库，基本要在5小时结清。还不算清账流程。 这个里面的流程分录可以达到400多个节点。 流程分录能弄出400多节点？人才啊

　　
　　
　　==================
　　

河南圣人	发表时间： 2014-1-10 14:00:49　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 钢架构 发表： 此文由 河南圣人 发表： 此文由 lidijia 发表： 车票又不是固定的，也不是所有人买的都是全程票。一条线路，每出一张票，就要重新计算剩下的票，这个处理只能在一个系统里进行，卖票系统分得再多又有什么用？最后的数据都要返回到铁道部的系统里进行处理。 IBM造机器可以，但是处理这种天量数据，未必有足够的经验。不要拿统计米国人口说事，天朝人口比米国的高出一个数量级。复杂程度怕是至少要高出几个数量级吧。 铁道部那算个J8天量数据，他那个属于数据库里最简单的一种，淘宝百度无论数据复杂程度还是数据量比他复杂NNNNN倍 从数据库的角度来说，最简单的划分办法就是按车次分， 整条线整条线的包出去，比如上海到乌鲁木齐这趟车包给京东，长春到昆明那趟包给淘宝，那么这次车的所有乘客都去京东或者淘宝买，不存在什么所有人买的都是全程票之类的问题 错了，很复杂的流程。我们和阿里的同事讨论过。 就是业务的耦合度太高了。 京东和淘宝，可以很轻松把客户下单，发货，清款，退货分开 而铁路耦合太高，就是下单和退货，和退订票从新入库，基本要在5小时结清。还不算清账流程。 这个里面的流程分录可以达到400多个节点。 复杂个J8，话撂着，铁道部这个属于数据库里最简单的一种，话说你肯定没学过数据库，这种一趟趟的车次，车次之间没啥关系的数据不要太简单。 就像我上面说过的，上海到乌鲁木齐，就这几十个站而已。其他的车次属于简单的叠加，相互之间没关系
qmgod	发表时间： 2014-1-10 14:01:21　编辑　引用回复　快速留言　赠送鲜花　举报 10个人抢俩馒头，筷子好不好用都是次要的，主要是馒头不够。
qmgod	发表时间： 2014-1-10 14:10:09　编辑　引用回复　快速留言　赠送鲜花　举报 突然来个想法，铁道部可不可以分区域买票啊，例如，东北区，华北区，华南区……各个区各自独立，有交集的区域，再单独拿出来，这样12306是不是就不会崩溃？ 非计算机专业，啥也不懂，瞎说的，但我觉得思路也许对。
IQ50	发表时间： 2014-1-10 14:10:42　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 国民汽车2010 发表： 就凭那JB恶劣到家的界面 就知道12306根本没有下功夫去做 就像当年铁道部号称火车实行实名制就会崩溃一样，JB扯蛋 不就是为了给黄牛留空间嘛 上面有人说得对，这种票务的数据库几乎就是最简单的一种，XX次就那么多票那几个站分得清清楚楚，别扯一张票就牵动全国的蛋。。。 别说什么一下子几个亿请求，多少亿请求有球用又不是每个都要处理。票就那么多，同时达成的数据量少得可怜，还真不是淘宝那几家瞧得起的。 你有句话说错了，真的得每个请求都处理！一个查询过来。数据库就得返回个。有没有，有多少。而且这个数值还是动态的。1k查询就得并发1k条。加上刷票软件。这些请求将是天量！
费资本	发表时间： 2014-1-10 14:15:41　编辑　引用回复　快速留言　赠送鲜花　举报 这个不是我们看不起IBM，18摸的解决方案估计也就是上大机。 12306的问题是两块，一块是前端并发多。一块是后台数据大。 前端这种其实好办，就是拼命加机器,这个可以学淘宝。但是后端这种和淘宝的应用完全不是一个概念。 淘宝比如我下一单优衣库的黄色短T，假设表设计得很简单,sql就是upate uniqlo_store这张表，把其中符合黄色短T的这一行的storage_num这个字段减1就可以了。 12306不是,你要买上海到宁波的车票，并不单单是-1这个动作，而是你改变了这趟车的一张全票的拓朴.假如数据设计的很直接，你要去update这趟车某个位子上海到嘉兴，嘉兴到杭州，杭州到宁波这三行状态为unavailable,还有可能要关联下你的信息表，把你的身份证号码填充到乘客字段里去。这种做法好处是不需要后台处理这个座位变动的业务逻辑，坏处是数据会变得非常大。 大数据，高并发，还要保证数据一致性，这个真的是有困难的。如果从业务逻辑上把12306分拆开可能还好点。
IQ50	发表时间： 2014-1-10 14:15:53　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 qmgod 发表： 突然来个想法，铁道部可不可以分区域买票啊，例如，东北区，华北区，华南区……各个区各自独立，有交集的区域，再单独拿出来，这样12306是不是就不会崩溃？ 非计算机专业，啥也不懂，瞎说的，但我觉得思路也许对。 不是分区域，是可以分车次。服务器集群。甚至可以做到每车单独一个服务器
克莱茵瓶	发表时间： 2014-1-10 14:21:34　编辑　引用回复　快速留言　赠送鲜花　举报 什么玩意？ 第一句话就是三无消息。 原站上，后面多个答案质疑该说法的来源，该答主总是避而不答。
qmgod	发表时间： 2014-1-10 14:46:50　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 IQ50 发表： 此文由 qmgod 发表： 突然来个想法，铁道部可不可以分区域买票啊，例如，东北区，华北区，华南区……各个区各自独立，有交集的区域，再单独拿出来，这样12306是不是就不会崩溃？ 非计算机专业，啥也不懂，瞎说的，但我觉得思路也许对。 不是分区域，是可以分车次。服务器集群。甚至可以做到每车单独一个服务器 咱们就是提供一个思路嘛~~车次这也太多了，得多少个服务器……
国民汽车2010	发表时间： 2014-1-10 14:51:47　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 IQ50 发表： 此文由 国民汽车2010 发表： 就凭那JB恶劣到家的界面 就知道12306根本没有下功夫去做 就像当年铁道部号称火车实行实名制就会崩溃一样，JB扯蛋 不就是为了给黄牛留空间嘛 上面有人说得对，这种票务的数据库几乎就是最简单的一种，XX次就那么多票那几个站分得清清楚楚，别扯一张票就牵动全国的蛋。。。 别说什么一下子几个亿请求，多少亿请求有球用又不是每个都要处理。票就那么多，同时达成的数据量少得可怜，还真不是淘宝那几家瞧得起的。 你有句话说错了，真的得每个请求都处理！一个查询过来。数据库就得返回个。有没有，有多少。而且这个数值还是动态的。1k查询就得并发1k条。加上刷票软件。这些请求将是天量！ 那就是设计上的问题了，你这种设计只会让DDOS攻击到死的 正确处理就是有一千张票，就只接受一千个请求，后面的自动扔到一个排队系统里等捡漏吧 每个查询就进数据库搜索一次，那都不用几百万个点击，几万个点击就能让你服务器瘫掉。正确的做法是广播模式，是隔几秒把票务信息发到一个独立页面，那些查询刷多少亿次都和售票系统没啥关系。 该内容由 国民汽车2010 在 2014-1-10 14:52:40编辑过
钢架构	发表时间： 2014-1-10 14:56:18　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 国民汽车2010 发表： 此文由 IQ50 发表： 此文由 国民汽车2010 发表： 就凭那JB恶劣到家的界面 就知道12306根本没有下功夫去做 就像当年铁道部号称火车实行实名制就会崩溃一样，JB扯蛋 不就是为了给黄牛留空间嘛 上面有人说得对，这种票务的数据库几乎就是最简单的一种，XX次就那么多票那几个站分得清清楚楚，别扯一张票就牵动全国的蛋。。。 别说什么一下子几个亿请求，多少亿请求有球用又不是每个都要处理。票就那么多，同时达成的数据量少得可怜，还真不是淘宝那几家瞧得起的。 你有句话说错了，真的得每个请求都处理！一个查询过来。数据库就得返回个。有没有，有多少。而且这个数值还是动态的。1k查询就得并发1k条。加上刷票软件。这些请求将是天量！ 那就是设计上的问题了，你这种设计只会让DDOS攻击到死的 正确处理就是有一千张票，就只接受一千个请求，后面的自动扔到一个排队系统里等捡漏吧 每个查询就进数据库搜索一次，那都不用几百万个点击，几万个点击就能让你服务器瘫掉。正确的做法是广播模式，是隔几秒把票务信息发到一个独立页面，那些查询刷多少亿次都和售票系统没啥关系。 嗯，预定没有付款-退票，主动退款，退票重新回去库。这些都要优先 一旦有退票，比如北京到深圳中间一段，那么这个线路都要重置。
spedtech	发表时间： 2014-1-10 15:00:28　编辑　引用回复　快速留言　赠送鲜花　举报 除去各类硬件技术IBM有着强大的基础之外，数据库系统方面IBM同样是最强的吧。 对付铁道部的这套玩意儿，IBM要是做不好，谁还能做好？
国民汽车2010	发表时间： 2014-1-10 15:02:53　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 钢架构 发表： 此文由 国民汽车2010 发表： 此文由 IQ50 发表： 此文由 国民汽车2010 发表： 就凭那JB恶劣到家的界面 就知道12306根本没有下功夫去做 就像当年铁道部号称火车实行实名制就会崩溃一样，JB扯蛋 不就是为了给黄牛留空间嘛 上面有人说得对，这种票务的数据库几乎就是最简单的一种，XX次就那么多票那几个站分得清清楚楚，别扯一张票就牵动全国的蛋。。。 别说什么一下子几个亿请求，多少亿请求有球用又不是每个都要处理。票就那么多，同时达成的数据量少得可怜，还真不是淘宝那几家瞧得起的。 你有句话说错了，真的得每个请求都处理！一个查询过来。数据库就得返回个。有没有，有多少。而且这个数值还是动态的。1k查询就得并发1k条。加上刷票软件。这些请求将是天量！ 那就是设计上的问题了，你这种设计只会让DDOS攻击到死的 正确处理就是有一千张票，就只接受一千个请求，后面的自动扔到一个排队系统里等捡漏吧 每个查询就进数据库搜索一次，那都不用几百万个点击，几万个点击就能让你服务器瘫掉。正确的做法是广播模式，是隔几秒把票务信息发到一个独立页面，那些查询刷多少亿次都和售票系统没啥关系。 嗯，预定没有付款-退票，主动退款，退票重新回去库。这些都要优先 一旦有退票，比如北京到深圳中间一段，那么这个线路都要重置。 就像电影院买票，预定没付款只是霸了个坑位若干分钟后就重新释放了，票还没卖出何来退票。 更简单解决办法就是预付款，想买某车次票价格必然已定啊，排队前选好身份资料先预付，有票马上成交即可。
钢架构	发表时间： 2014-1-10 15:08:05　编辑　引用回复　快速留言　赠送鲜花　举报 这个就到最难得地方了。 通常销售流程是 下单-收款-发货-清账， 退货流程是 退货单-确认-退货-退款-清账 对于淘宝，或者京东。库存数字虽然有，并不是及时的。如果下单，最后发现没有库存，也可以退款 术语就是无库存销售。 但是12306必须要带库存销售，所以下单前要实时检索库存，下销售订单。如果45分钟客户没有发货，锁定的票就要 回库。回库后就要重组库存，上架。还有已经付款的退货，那就涉及退款。这个里面还没有考虑财务开票。 所以说说销售流程和退货流程是紧密耦合 由于铁路的特殊性，尤其是春运时，同时会有大量同时退货和下单，相互并发，而且是和时间竞赛。
国民汽车2010	发表时间： 2014-1-10 15:23:03　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 钢架构 发表： 这个就到最难得地方了。 通常销售流程是 下单-收款-发货-清账， 退货流程是 退货单-确认-退货-退款-清账 对于淘宝，或者京东。库存数字虽然有，并不是及时的。如果下单，最后发现没有库存，也可以退款 术语就是无库存销售。 但是12306必须要带库存销售，所以下单前要实时检索库存，下销售订单。如果45分钟客户没有发货，锁定的票就要 回库。回库后就要重组库存，上架。还有已经付款的退货，那就涉及退款。这个里面还没有考虑财务开票。 所以说说销售流程和退货流程是紧密耦合 由于铁路的特殊性，尤其是春运时，同时会有大量同时退货和下单，相互并发，而且是和时间竞赛。 呵呵，别忘了铁路大哥的站票 其实别管那么多，多少个位置就让多少人进场下单就是了，其余一律转入排队系统。那样就根本没有海量查询（只有进场的有实时库存检索，那么同时进行最多数万而已），排队的就看信息广播，刷几亿的屏也不影响数据库的。 有释放的就让排队的补上，加上预付款方式，进场立马成交，那么坑位的占用时间可以从几十分钟缩短到几秒。
Jason_wul	发表时间： 2014-1-10 15:30:31　编辑　引用回复　快速留言　赠送鲜花　举报 我来说两句，是哪个傻×公司做的大集中设计的，靠，谁说设备买再多没用的，分布式设计是这样做的吗， 用户注册、身份证校验、门户拆一块，查询线路信息为一部分；这部分不应该被挤爆； 铁路线路按线路来拆，按往返拆，全国春运期间真正热门的线路能有几条？？？ 用户需要选择指定线路和指定站点后才能查询 分布到不同的节点上，那么只会存在热门那几条线路出现单向查询购票出现负载过大而已，然后对其重点优化，限制同一用户在短时间内连续刷，但整体网站及反向冷门线路还是正常顺利运行和访问。 那个破烂校验码咋那么容易就被破解了呢～～～～ 该内容由 Jason_wul 在 2014-1-10 15:32:15编辑过
coolqjysm	发表时间： 2014-1-10 15:39:15　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 biermann 发表： 铁道部无非就是早接触了那么十几年春运，还就成了绝不外包的法宝了。 可笑，就这些计划经济企业笨拙的管理体制，你积累的那点经验，人家现代化企业经历过一次就全搞明白了。 南京熊猫是中国无线电的鼻祖，90年代后期拿了国家巨额资助去研发手机，屁也做不出来。 等到华为中兴宣布进军手机行业，还没做呢，老外就大惊失色，说完了，手机行业将重新洗牌。他们怎么不说华为中兴没经验啊？ 先进企业就是先进企业，就像任正非说的，华为改做拖拉机一样挣钱。 质疑IBM，以为IBM不如铁道部，不如太极浪潮的人，先去看看IBM的发展历史，看看IBM这近百年来转换过多少方向，看看IBM研究出过多少概念。人家这么多年，居然能始终站在世界科技进步的浪尖，这就是一个奇迹，IBM缺点再多，也不是一个苏联50年代体制的铁道部或者国内拉关系走后门吃政府饭的小IT公司可比的。 苏宁易购是IBM做的。。。。
coolqjysm	发表时间： 2014-1-10 15:40:21　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 biermann 发表： 铁道部无非就是早接触了那么十几年春运，还就成了绝不外包的法宝了。 可笑，就这些计划经济企业笨拙的管理体制，你积累的那点经验，人家现代化企业经历过一次就全搞明白了。 南京熊猫是中国无线电的鼻祖，90年代后期拿了国家巨额资助去研发手机，屁也做不出来。 等到华为中兴宣布进军手机行业，还没做呢，老外就大惊失色，说完了，手机行业将重新洗牌。他们怎么不说华为中兴没经验啊？ 先进企业就是先进企业，就像任正非说的，华为改做拖拉机一样挣钱。 质疑IBM，以为IBM不如铁道部，不如太极浪潮的人，先去看看IBM的发展历史，看看IBM这近百年来转换过多少方向，看看IBM研究出过多少概念。人家这么多年，居然能始终站在世界科技进步的浪尖，这就是一个奇迹，IBM缺点再多，也不是一个苏联50年代体制的铁道部或者国内拉关系走后门吃政府饭的小IT公司可比的。 苏宁易购是IBM做的。。。。
fercilu	发表时间： 2014-1-10 15:53:35　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 spedtech 发表： 除去各类硬件技术IBM有着强大的基础之外，数据库系统方面IBM同样是最强的吧。 对付铁道部的这套玩意儿，IBM要是做不好，谁还能做好？ IBM主业金融行业，不过NASDAQ没要它。。。。 另外你用过苏宁没
xie_min	发表时间： 2014-1-10 15:59:05　编辑　引用回复　快速留言　赠送鲜花　举报 记得12306刚开始时就否定了IBM。自己作系统。淘宝不错，已经完成了去IOE。但是也很辛苦。还在进一步摸索中。不过为什么不参考一下股票交易的撮合系统。那个据说很NB！好多年前就实现数据库完全跑在内存中了
warmanky	发表时间： 2014-1-10 16:01:36　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 flea888 发表： 遂改用x86系统+linux平台 平台为HP Superdome小型机，UNIX系统，Sybase ASE数据库 要编故事,最好不要涉及细节,说的越多,漏洞越多. 12306首秀被骂的狗血喷头后铁道部找来IBM、阿里巴巴等大企业要解决方案，给出的条件是资金管够但是问题得解决。几大企业最后都拒绝了。 12306开始自己尝试解决问题。他们发现市面上可以买到的成套解决方案都不足以应付春运购票负载，所以只能自己改进已有的数据库以前12306用的是小型机，发现性能严重不足，遂改用x86系统+linux平台（原平台为HP Superdome小型机，UNIX系统，Sybase ASE数据库）。最后他们的核心系统用了十几个节点（现在应该是17节点）的多路Xeon E7（具体几路待考），每个节点配1TB内存，数据库全部在内存中运行。2013年春运，12306系统峰值负载11万tps，与2012年淘宝双11活动峰值负载相当，新的系统基本经受住了考验。 有些人看都没看全就开愤。

　　
　　========================
　　

发表人	内容 [<<]　[<]　[>]　[>>]
warmanky	发表时间： 2014-1-10 16:07:19　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 河南圣人 发表： 此文由 钢架构 发表： 此文由 河南圣人 发表： 此文由 lidijia 发表： 车票又不是固定的，也不是所有人买的都是全程票。一条线路，每出一张票，就要重新计算剩下的票，这个处理只能在一个系统里进行，卖票系统分得再多又有什么用？最后的数据都要返回到铁道部的系统里进行处理。 IBM造机器可以，但是处理这种天量数据，未必有足够的经验。不要拿统计米国人口说事，天朝人口比米国的高出一个数量级。复杂程度怕是至少要高出几个数量级吧。 铁道部那算个J8天量数据，他那个属于数据库里最简单的一种，淘宝百度无论数据复杂程度还是数据量比他复杂NNNNN倍 从数据库的角度来说，最简单的划分办法就是按车次分， 整条线整条线的包出去，比如上海到乌鲁木齐这趟车包给京东，长春到昆明那趟包给淘宝，那么这次车的所有乘客都去京东或者淘宝买，不存在什么所有人买的都是全程票之类的问题 错了，很复杂的流程。我们和阿里的同事讨论过。 就是业务的耦合度太高了。 京东和淘宝，可以很轻松把客户下单，发货，清款，退货分开 而铁路耦合太高，就是下单和退货，和退订票从新入库，基本要在5小时结清。还不算清账流程。 这个里面的流程分录可以达到400多个节点。 复杂个J8，话撂着，铁道部这个属于数据库里最简单的一种，话说你肯定没学过数据库，这种一趟趟的车次，车次之间没啥关系的数据不要太简单。 就像我上面说过的，上海到乌鲁木齐，就这几十个站而已。其他的车次属于简单的叠加，相互之间没关系 这个傻帽连铁路商品性质都没搞清楚，就敢开口“铁道部这个属于数据库里最简单的一种”，一趟列车卖出的车票是不固定的，同一趟车有可能短途多，长途少，也有可能长途多，短途少，整个可售票都是弹性实时计算的，当然春运这种可以设定业务规则长途优先减少业务复杂程度，这比任何一种B2C模式的库存管理要复杂n倍，放taobao可以，每个店铺管一趟列车的库存，然后用户一个店铺一个店铺去搜，旺旺问吧
老子是壹块	发表时间： 2014-1-10 16:13:40　编辑　引用回复　快速留言　赠送鲜花　举报 IBM 数据库最强? 你把 ORACLE 扔哪里了? IBM 的硬件超强 数据库软件这方面在FSI也就是金融业超强 其它行业被 ORACLE  和 SAP (收购的) 爆的SHI都不剩
T34/85	发表时间： 2014-1-10 16:29:42　编辑　引用回复　快速留言　赠送鲜花　举报 国企和单位已有通知，不再采购ibm，oracle产品，安全原因
T34/85	发表时间： 2014-1-10 16:31:40　编辑　引用回复　快速留言　赠送鲜花　举报 国企和单位已有通知，不再采购ibm，oracle产品，安全原因。 经测试国产数据库已能实现oracle 95%功能
ACHTUNG	发表时间： 2014-1-10 16:43:24　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 T34/85 发表： 国企和单位已有通知，不再采购ibm，oracle产品，安全原因。 经测试国产数据库已能实现oracle 95%功能 国产哪个数据库。。
国民汽车2010	发表时间： 2014-1-10 16:46:41　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 warmanky 发表： 此文由 河南圣人 发表： 此文由 钢架构 发表： 此文由 河南圣人 发表： 此文由 lidijia 发表： 车票又不是固定的，也不是所有人买的都是全程票。一条线路，每出一张票，就要重新计算剩下的票，这个处理只能在一个系统里进行，卖票系统分得再多又有什么用？最后的数据都要返回到铁道部的系统里进行处理。 IBM造机器可以，但是处理这种天量数据，未必有足够的经验。不要拿统计米国人口说事，天朝人口比米国的高出一个数量级。复杂程度怕是至少要高出几个数量级吧。 铁道部那算个J8天量数据，他那个属于数据库里最简单的一种，淘宝百度无论数据复杂程度还是数据量比他复杂NNNNN倍 从数据库的角度来说，最简单的划分办法就是按车次分， 整条线整条线的包出去，比如上海到乌鲁木齐这趟车包给京东，长春到昆明那趟包给淘宝，那么这次车的所有乘客都去京东或者淘宝买，不存在什么所有人买的都是全程票之类的问题 错了，很复杂的流程。我们和阿里的同事讨论过。 就是业务的耦合度太高了。 京东和淘宝，可以很轻松把客户下单，发货，清款，退货分开 而铁路耦合太高，就是下单和退货，和退订票从新入库，基本要在5小时结清。还不算清账流程。 这个里面的流程分录可以达到400多个节点。 复杂个J8，话撂着，铁道部这个属于数据库里最简单的一种，话说你肯定没学过数据库，这种一趟趟的车次，车次之间没啥关系的数据不要太简单。 就像我上面说过的，上海到乌鲁木齐，就这几十个站而已。其他的车次属于简单的叠加，相互之间没关系 这个傻帽连铁路商品性质都没搞清楚，就敢开口“铁道部这个属于数据库里最简单的一种”，一趟列车卖出的车票是不固定的，同一趟车有可能短途多，长途少，也有可能长途多，短途少，整个可售票都是弹性实时计算的，当然春运这种可以设定业务规则长途优先减少业务复杂程度，这比任何一种B2C模式的库存管理要复杂n倍，放taobao可以，每个店铺管一趟列车的库存，然后用户一个店铺一个店铺去搜，旺旺问吧 除了黄牛，谁需要一个‘店铺’一个‘店铺’搜？正常人就关注一个方向上若干车次罢了
zergchn	发表时间： 2014-1-10 16:49:37　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 河南圣人 发表： 此文由 fercilu 发表： 12306的数据量。。阿里巴巴勉强应该可以试试 不过IBM，你敢把全国的居民信息放给美国人，我都不认为他有处理这么大量数据的能力 铁总可以把票源一分为4,12306和淘宝京东亚马逊一家做1/4，这就很好的解决流量问题 至于IBM行不行，拜托去多读点书，IBM的历史可以说就是计算机的历史，他不行，笑话 IBM行不行，你去问问苏宁就最清楚了，当初苏宁转型的时候可是被IBM害惨了。
费资本	发表时间： 2014-1-10 17:02:06　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 T34/85 发表： 国企和单位已有通知，不再采购ibm，oracle产品，安全原因。 经测试国产数据库已能实现oracle 95%功能 这话过了，也就几个小国企而已。你让工行不玩大机试试？
warmanky	发表时间： 2014-1-10 17:11:05　编辑　引用回复　快速留言　赠送鲜花　举报 此文由 国民汽车2010 发表： 此文由 warmanky 发表： 此文由 河南圣人 发表： 此文由 钢架构 发表： 此文由 河南圣人 发表： 此文由 lidijia 发表： 车票又不是固定的，也不是所有人买的都是全程票。一条线路，每出一张票，就要重新计算剩下的票，这个处理只能在一个系统里进行，卖票系统分得再多又有什么用？最后的数据都要返回到铁道部的系统里进行处理。 IBM造机器可以，但是处理这种天量数据，未必有足够的经验。不要拿统计米国人口说事，天朝人口比米国的高出一个数量级。复杂程度怕是至少要高出几个数量级吧。 铁道部那算个J8天量数据，他那个属于数据库里最简单的一种，淘宝百度无论数据复杂程度还是数据量比他复杂NNNNN倍 从数据库的角度来说，最简单的划分办法就是按车次分， 整条线整条线的包出去，比如上海到乌鲁木齐这趟车包给京东，长春到昆明那趟包给淘宝，那么这次车的所有乘客都去京东或者淘宝买，不存在什么所有人买的都是全程票之类的问题 错了，很复杂的流程。我们和阿里的同事讨论过。 就是业务的耦合度太高了。 京东和淘宝，可以很轻松把客户下单，发货，清款，退货分开 而铁路耦合太高，就是下单和退货，和退订票从新入库，基本要在5小时结清。还不算清账流程。 这个里面的流程分录可以达到400多个节点。 复杂个J8，话撂着，铁道部这个属于数据库里最简单的一种，话说你肯定没学过数据库，这种一趟趟的车次，车次之间没啥关系的数据不要太简单。 就像我上面说过的，上海到乌鲁木齐，就这几十个站而已。其他的车次属于简单的叠加，相互之间没关系 这个傻帽连铁路商品性质都没搞清楚，就敢开口“铁道部这个属于数据库里最简单的一种”，一趟列车卖出的车票是不固定的，同一趟车有可能短途多，长途少，也有可能长途多，短途少，整个可售票都是弹性实时计算的，当然春运这种可以设定业务规则长途优先减少业务复杂程度，这比任何一种B2C模式的库存管理要复杂n倍，放taobao可以，每个店铺管一趟列车的库存，然后用户一个店铺一个店铺去搜，旺旺问吧 除了黄牛，谁需要一个‘店铺’一个‘店铺’搜？正常人就关注一个方向上若干车次罢了 你还是没搞明白这种商品的特殊性，你让一个taobao店主去如何计算弹性的火车票库存，除非火车票类型只有一种起点-终点，这个库存就很好管理了，不过实际中除了极少数直达车有多少这类业务啊

　　
　　=====