l*****9
发帖数: 9501 | 1 从12306来看，国内IT水平不高
铁道部说，资金管够，问题给解决就行。简直是IT公司的梦想啊，结果竟然找不到一个
承包商。最后铁道部自己开发系统，搞了17个节点，再多也不会提高performance,感觉
是强耦合的系统。
我觉着，设计的关键是分解强耦合，这样系统performance可以通过增加节点来提高。
系统自动出联票的计算量很大，代之以用户提出组合票，牺牲的可用性不大，而系统计
算量大大降低。不要和航空公司订票系统比，12306工作量要大几个量级。
====下面是我的老帖子
铁路订票系统怎么强耦合了？12306绝对架构错了
对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
可分。这个数据量，大概只好用nonsql了
具体到12306设计：查票订票购票网站分开
查票网站
1。不实时，结果正确性不保证。
2。不回答联票查询。比如昆明到哈尔滨是否有票？没有直达车就说没有。
3。回答组合查询，比如（昆明到北京；北京到哈尔滨）是否有票。组合逻辑由用户提
出，每部分之间客户给出时间间隔，比如尽快或48小时，简化了应用。
客户登记网站：接受客户实名信息和支付办法
订票网站：只有已登记的客户可以使用
1。 直接接订单，用户可以选择订票成功自动购买。
2。 用户自己组合联票，比如（昆明到北京101次；天津到哈尔滨），组合逻辑由用户
提出，每部分之间客户给出时间间隔，比如尽快或48小时，简化了应用
后台订票服务器：50台，每台处理限定车次
订票综合服务器：200台，每个用户的同一个订单去同一个服务器，订票结果电邮用户
。订票限时作废。
购票退票网站：用户接受订票成功结果的话，一键购票。不接受的话，一键取消定票。
一键退票。
防止黄牛：客票实名制，上车时票证一起检查。不能改票，可以退票但不全额退款。 |
j********x
发帖数: 2330 | 2 算了吧，看本版每天吵架，你会觉得天朝IT起码领先美国50年 |
t****t
发帖数: 820 | 3 结果竟然找不到一个承包商。最后铁道部自己开发系统
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~LOL 很傻很天真 |
m**********j
发帖数: 8645 | 4 没戏，在春运面前，在4000万人南北大移动面前，这是完全无力的。
你知道4千万人在同一时间内查询订票是个什么概念吗?
【在 l*****9 的大作中提到】
: 从12306来看，国内IT水平不高
: 铁道部说，资金管够，问题给解决就行。简直是IT公司的梦想啊，结果竟然找不到一个
: 承包商。最后铁道部自己开发系统，搞了17个节点，再多也不会提高performance,感觉
: 是强耦合的系统。
: 我觉着，设计的关键是分解强耦合，这样系统performance可以通过增加节点来提高。
: 系统自动出联票的计算量很大，代之以用户提出组合票，牺牲的可用性不大，而系统计
: 算量大大降低。不要和航空公司订票系统比，12306工作量要大几个量级。
: ====下面是我的老帖子
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
|
s*********4
发帖数: 1980 | 5 楼主有没有搞清楚为什么是铁道部的一个小破设计院拿下这项目啊?如果这个前提都没
搞清楚,太天真幼稚了. |
h*d
发帖数: 19309 | 6 12306找IBM来的，结果IBM说作不了。
amazon AWS问题造成netflix都当了好几次了，facebook/gmail最近也都出过一些问题。
【在 l*****9 的大作中提到】
: 从12306来看，国内IT水平不高
: 铁道部说，资金管够，问题给解决就行。简直是IT公司的梦想啊，结果竟然找不到一个
: 承包商。最后铁道部自己开发系统，搞了17个节点，再多也不会提高performance,感觉
: 是强耦合的系统。
: 我觉着，设计的关键是分解强耦合，这样系统performance可以通过增加节点来提高。
: 系统自动出联票的计算量很大，代之以用户提出组合票，牺牲的可用性不大，而系统计
: 算量大大降低。不要和航空公司订票系统比，12306工作量要大几个量级。
: ====下面是我的老帖子
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
|
z****e
发帖数: 54598 | 7 哪有，当时ibm是很贵，铁道部不同意
题。
【在 h*d 的大作中提到】
: 12306找IBM来的，结果IBM说作不了。
: amazon AWS问题造成netflix都当了好几次了，facebook/gmail最近也都出过一些问题。
|
h*d
发帖数: 19309 | 8
http://www.zhihu.com/question/22451397/answer/21426532
12306首秀被骂的狗血喷头后铁道部找来IBM、阿里巴巴等大企业要解决方案，给出的条
件是资金管够但是问题得解决。几大企业最后都拒绝了（其中阿里巴巴最后负责了排队
系统的建设）。12306开始自己尝试解决问题。他们发现市面上可以买到的成套解决方
案都不足以应付春运购票负载，所以只能自己改进已有的数据库（注：其实是改用
VMware SQLFire/GemFire，这里我之前理解错误）。以前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这个事情，网上有多少网友从一开始就献计献策了，也有不少网友提供了很不错
的建议。但不得不说，很多网友在提建议时完全就是一种居高临下、自以为是的态度，
上来就先认定需求简单可以轻松应付，随便有点经验的工程师就能搞定，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这个问
题上就是：12306是国企，是铁总下属机构，所以它出了问题一定是自身原因。票务系
统做不好一定是铁路方面不懂技术，把该用来请大企业做方案的钱自己贪掉了，一定不
可能是大企业都没信心解决这问题。旅客普遍使用抢票软件也是12306的责任，不是供
应不足的原因……
最后呢？12306还是做到了全球最强的客运票务系统。一贯被认为是因循守旧的国企，
在选择技术方案时放弃沿用多年的小型机/UNIX平台去拥抱业界还是新鲜事物的基于x86
/linux的大规模分布内存数据库系统，承受住了堪比2012年淘宝双11的压力。在这个领
域，12306可以自豪地说自己是做的最好的案例。它还在卡，还是偶尔崩溃，页面还是
难看，可是这些迟早会改进。这个过程中也还是会有冷嘲热讽，还是会有所谓的大牛指
点江山，但最终解决春运高峰期一天数百万张秒杀售票的，还是12306自己。
所以，走自己的路，让别人去说吧。
=======================================================
下面我说说12306系统改进面临的一些问题，一些网友提出的解决方案的可行性。
1.“超级计算机能不能用于12306？”——不能，详情见这个页面；
2.“能不能用一个服务器甚至一个集群处理一个车次来加快速度？”——没有意义，处
理速度在硬件上主要受限于每个CPU线程获得的内存带宽与延迟，其中内存延迟更重要
一些。一个核心处理还是一台服务器处理，内存延迟这个参数是没什么区别的；
3.“能不能在多地建立集群，分别处理某地的车次？”——道理同上；
4.“能不能取消座位实时复用，降低处理压力？”——如果所有区间站的票数都是预先
确定的，那么到最后必然会出现有的冷门区间座位空置的情况，这是旅客不希望看到的；
5.“能不能把座位实时复用改为延时复用，热门车次第一次放票后，根据区间之间的情
况在下一个放票点调整各区间票额？”——这样做可以减轻计算压力，但是会让大量旅
客在第一次订票失败后等待下一次放票，增加下一次放票的负载。而且这会干扰旅客的
抢票计划，原来是一个车次没票后就去找下一个车次，现在是一个车次要抢两次甚至更
多，反而让旅客更累；
6.“能不能改成预先排队抽签，放票前订票旅客在网上选择进入队列，放票后抽签决定
，避免争抢”——很多人提出类似这样的主意。注意热门车次放票被抢光后，没买到票
的旅客会立刻去找其他车次是否有票。也就是说即便有这个预排队功能，也不能阻止没
去排队的旅客在放票开始之后去买票。对于热门车次而言，参与预排队的旅客抽签失败
的概率非常高，而他们抽签失败后多数会失去对这个功能的信任，转而继续选择抢票的
方式，于是很快大多数人都会放弃抽签。如果设定为只有参与预排队的旅客才能买到票
，那么抽签失败的旅客就失去了对其他车次的选择权，结果更是一场灾难。希望提出类
似方案的网友好好思考我上面这些内容。
7.“12306的负载不是比淘宝小很多么？”——淘宝2013年双11峰值订单数量一分钟79
万笔，12306每次放票按500热门车次算，根据央视直播春运火车票抢票 这篇报道，热
门车次峰值抢票速度在每分钟500票左右。很容易算出现在12306的峰值订单量在一分钟
10万-30万的级别，与淘宝双11峰值是相同数量级。
我在前面提过供求关系是12306面临的核心问题，可能很多没有经济学基础的网友不太
明白，我这里再详细解释下。
任何限价商品出现供不应求情况时，最终获得商品的大多数消费者支付的成本都是要超
出商品本身的标价的。一个简单的例子，超市限量出售半价鸡蛋，大批顾客去抢购，虽
然排队买到的顾客为鸡蛋本身花的钱少了，但是这些顾客付出了在那里排队的时间和人
力成本。排了很久队才买到鸡蛋的顾客，为鸡蛋支付的时间与人力成本甚至可能超过了
他买半价鸡蛋省下的金额。于此同时，限量供应的条件下必然有一些排队者最终没能买
到鸡蛋。之所以有人买到鸡蛋有人没买到，大多数情况下是因为前者比后者付出了更多
的成本；排队者是在跟其他排队者竞争，那些看到长长的队伍就放弃的潜在消费者就是
竞争的失败者。
12306的情况也是如此。在现有的车票限价限量供应体系下，在某些高峰期有乘车需求
的旅客数量大大超过了铁路系统在这些时间段的运输能力。在这个前提下，必然会有大
量旅客无法在这些时间段买到车票，被迫改变出行计划或者出行方式；而买到票的旅客
为车票支付的成本，大多数情况下都是高于甚至远高于车票本身的标价的。超出的这一
部分成本，可以体现为向黄牛买票支付的溢价，可以体现为在车站售票口排队付出的时
间精力，而到了12306的时代，就可以体现为为了抢到票而付出的等待成本。
因此，12306无论怎么改进，都不可能降低因为供求关系而产生的旅客获得车票的额外
成本。12306改进的结果只是会改变这种额外成本的形式。以前没有网络订票，大家去
售票厅排队或者一次又一次打电话；现在有了网络订票，大家在网上卡到骂娘。但大家
吐槽12306的种种缺陷时，其实原因并不是旅客真的特别重视网站的美观程度、重视网
页的代码是不是高水平，而是还有很多人没能按自己的心意买到车票。旅客对12306的
需求只有一条——买到旅客需要的车票；可是12306无法解决这个需求。对于旅客来说
，卡三个小时但买到了票的体验是60分，三次放票时每次都一秒钟就被告知票已售完的
体验是0分。
于是12306的未来就会很麻烦。随着系统的改进升级，整套系统的负载能力会越来越强
大。可是性能的提升意味着热门车次放票后售空的速度越来越快。上面引据的例子里，
一个车次一分钟就卖掉500张票；性能改进后，最终达到的效果可能是5秒钟就卖掉全部
票额。而对于旅客来说，卖票速度提升并不会减少他们为了获得车票而付出的额外成本
——以前是买一张票卡10分钟半小时，现在一个订单几秒钟就确认了，但是为了能在几
秒钟里抢过其他旅客，你需要提升你的电脑性能，增加你的网络带宽，降低你的网络延
迟；你需要更强大的抢票软件，一秒钟内发起更多的请求……最后，你在硬件设备上增
加的投入就是你付出的额外成本，相比之前你在等待网页响应时付出的时间成本来说只
是换了形式。以前售票厅时代大家比拼谁去排队排的早，以后大家比拼谁的网络性能好
。而且，12306的响应速度越快，旅客之间的设备军备竞赛也就会越激烈。最后，大家
会为了降低几十毫秒的延迟购买国内的vpn通道，改用表现更好的网卡，跑到号称能提
供更高抢票性能的网吧去抢票……然后还是会有大量用户因为竞争不过其他旅客而被迫
改变出行计划或出行方式。而且当旅客纷纷提升自己设备的性能时，对12306的压力也
会越来越大，12306自己也必须同步增加性能，投入越来越高的成本。从技术的角度讲
，12306面对的是一个随着它自身性能增长而同步甚至更快提升的需求，具有这样残酷
要求的类似案例就只有股票、期货电子交易市场而已。甚至，12306最终的压力可能会
超过这些市场。
回到最开始的问题：12306包给知名大企业是否会更好？答案是，无论谁来做，最终结
果都是一样。
2014-01-10 1869 条评论
【在 z****e 的大作中提到】
: 哪有，当时ibm是很贵，铁道部不同意
:
: 题。
|
h*d
发帖数: 19309 | 9 发信人: helloterran (hello), 信区: ITExpress
标 题: 12306毫无疑问是人类历史上最牛鼻的电商网站
发信站: 水木社区 (Thu Jan 24 09:31:06 2013), 站内 [累计积分奖励: 100/0]
2011年美国疯抢touchpad，我也参和了一下
有个找deal 的论坛叫slickdeal，上面有人实时发帖告诉大家哪里还有货
问题是，这个帖子发出来以后两分钟内，该目标网站一定瘫痪。一时间slickdeal变成
了大规模ddos的指挥中心，打哪指哪，横扫了一大批在线零售站点
第一个倒掉的是hp自己的hp store
然后bestbuy
然后newegg
接下来连ebay也down掉十几分钟
等他们恢复访问，那一定是已经OOS了
唯一一个在有货时一直可以访问的是amazon。当然amazon有自己的云服务，对爆发式的
访问没有那么不堪一击。但是事后大家发现，amazon超售了好几倍的量。显然他家的这
次交易是不加锁，没有一致性检查的
最后，这个横扫整个IT界的touchpad，总出货量多少呢？100万出头而已，其中还只有
一半是在线出售的。
给大家一个参考 |
k**o
发帖数: 15334 | 10 40m就不行了？那facebook一天728m daily active user登录他网站，
还不得给吓尿了？
【在 m**********j 的大作中提到】
: 没戏，在春运面前，在4000万人南北大移动面前，这是完全无力的。
: 你知道4千万人在同一时间内查询订票是个什么概念吗?
|
|
|
h******t
发帖数: 80 | 11 12306可能水平是不高，不过熬过这段出来的工程师绝对以后是大拿，在美国有几个人
能有这么大流量的工作经验啊。 |
y****i
发帖数: 12114 | 12 根据美国政府医保网站的表现看，这类网站的水很深的，远不是纯技术的问题。 |
l*****9
发帖数: 9501 | 13 除amazon和ebay外，这些网站设计思想就不是为了对付海量用户海量成交量的，当掉很
正常。
【在 h*d 的大作中提到】
: 发信人: helloterran (hello), 信区: ITExpress
: 标 题: 12306毫无疑问是人类历史上最牛鼻的电商网站
: 发信站: 水木社区 (Thu Jan 24 09:31:06 2013), 站内 [累计积分奖励: 100/0]
: 2011年美国疯抢touchpad，我也参和了一下
: 有个找deal 的论坛叫slickdeal，上面有人实时发帖告诉大家哪里还有货
: 问题是，这个帖子发出来以后两分钟内，该目标网站一定瘫痪。一时间slickdeal变成
: 了大规模ddos的指挥中心，打哪指哪，横扫了一大批在线零售站点
: 第一个倒掉的是hp自己的hp store
: 然后bestbuy
: 然后newegg
|
L******w
发帖数: 5407 | 14 怎么不和obama care的网站比一比？
访问量和复杂性都低几个级别，花了几十亿，整出个什么弱智东西来？
【在 l*****9 的大作中提到】
: 从12306来看，国内IT水平不高
: 铁道部说，资金管够，问题给解决就行。简直是IT公司的梦想啊，结果竟然找不到一个
: 承包商。最后铁道部自己开发系统，搞了17个节点，再多也不会提高performance,感觉
: 是强耦合的系统。
: 我觉着，设计的关键是分解强耦合，这样系统performance可以通过增加节点来提高。
: 系统自动出联票的计算量很大，代之以用户提出组合票，牺牲的可用性不大，而系统计
: 算量大大降低。不要和航空公司订票系统比，12306工作量要大几个量级。
: ====下面是我的老帖子
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
|
L******w
发帖数: 5407 | 15 复杂程度根本不可比。
【在 k**o 的大作中提到】
: 40m就不行了？那facebook一天728m daily active user登录他网站，
: 还不得给吓尿了？
|
z****e
发帖数: 54598 | 16 给钱和不给钱两个概念
fb那种不给钱的僵尸用户
p用没有，随便搞点垃圾web server就可以打发掉了
【在 k**o 的大作中提到】
: 40m就不行了？那facebook一天728m daily active user登录他网站，
: 还不得给吓尿了？
|
z****e
发帖数: 54598 | 17 因为蛤蟆care要给钱，涉及到金钱操作
所以系统一般都很难搞
【在 L******w 的大作中提到】
: 怎么不和obama care的网站比一比？
: 访问量和复杂性都低几个级别，花了几十亿，整出个什么弱智东西来？
|
c*******u
发帖数: 1657 | 18 是同一个时间登陆吗？
买火车票的可是一放票的头一分钟40M刷票
【在 k**o 的大作中提到】
: 40m就不行了？那facebook一天728m daily active user登录他网站，
: 还不得给吓尿了？
|
k**o
发帖数: 15334 | 19 obamacare网站访问量可能没那么高，巅峰大概只有几百万的级别，平时大概
也就不到十万。但是复杂程度绝对高。首先这是个注册ID，然后填表的网站，
有几十个field，还得检查信息对错。其次信息填完了还得跟别的机构联网调查，
查ss#，查eligibility，查身份，查VA状态。然后做计算，给quote。
复杂程度比买张火车票，那确实不是一个级别的。
【在 L******w 的大作中提到】
: 怎么不和obama care的网站比一比？
: 访问量和复杂性都低几个级别，花了几十亿，整出个什么弱智东西来？
|
l*****9
发帖数: 9501 | 20 obamacare访问量低几个量级，复杂性要高于12306
【在 L******w 的大作中提到】
: 怎么不和obama care的网站比一比？
: 访问量和复杂性都低几个级别，花了几十亿，整出个什么弱智东西来？
|
|
|
s*****r
发帖数: 43070 | 21 IBM贵而无用，没听说哪个网站用IBM支持
【在 z****e 的大作中提到】
: 哪有，当时ibm是很贵，铁道部不同意
:
: 题。
|
z****e
发帖数: 54598 | 22 travelport
在科罗拉多有一个dc
【在 s*****r 的大作中提到】
: IBM贵而无用，没听说哪个网站用IBM支持
|
l*****9
发帖数: 9501 | 23 IBM给12306开价多少？软件10亿，硬件百亿？其实这个价钱不出格，自己开发肯定低很多
【在 z****e 的大作中提到】
: travelport
: 在科罗拉多有一个dc
|
z****e
发帖数: 54598 | 24 不知道，新闻说太贵，多少你去问铁道部
这种钱肯定不是一次性费用
你图羊图森破了
很多
【在 l*****9 的大作中提到】
: IBM给12306开价多少？软件10亿，硬件百亿？其实这个价钱不出格，自己开发肯定低很多
|
c*****a
发帖数: 1638 | 25 我还真不信所谓资金管够的情况下这个会做不出来。估摸着就是没人敢接免得得罪那个
搞这个网站的太子党。
LZ说的也不太对，这个本身和大数据啥关系没有（别说4千万用户了，就算再加10倍，
也算不了啥大数据的问题）。不过用nosql可以提高并发读的扩展性。事实上铁路数据
本身很小，直接cache就完了，available的ticket部分存到cassandra里面（cassandra
在写并发啥是不是号称最好的nosql？）
关键是，查询部分是只读的情况，只有reserve票的时候涉及事务。模式和机票类似，
走eventually consistent就行了。
耦合是关键，很明显他们的系统是没法扩展的，给铁道部洗地的文章里面也说到只能做
到说scale up（提升节点硬件和软件）而不是scale out（增加节点）。所以就是说他
们那个破框架设计本身到20个节点自己不行了
这种情况下，只能重做
他这个东西和淘宝还是不能比的，他的业务其实简单多了，后台数据的查询路径基本是
固定的，比起来淘宝那个网站要实现的用户需求比他这个难很多个数量级。
确实来说，国内IT水平其实挺高的都在几个大公司里面，断档太明显了（除了几个好公
司以外，别的公司的待遇根本不足以吸引有基础的程序员钻研技术）。
【在 h*d 的大作中提到】
: 发信人: helloterran (hello), 信区: ITExpress
: 标 题: 12306毫无疑问是人类历史上最牛鼻的电商网站
: 发信站: 水木社区 (Thu Jan 24 09:31:06 2013), 站内 [累计积分奖励: 100/0]
: 2011年美国疯抢touchpad，我也参和了一下
: 有个找deal 的论坛叫slickdeal，上面有人实时发帖告诉大家哪里还有货
: 问题是，这个帖子发出来以后两分钟内，该目标网站一定瘫痪。一时间slickdeal变成
: 了大规模ddos的指挥中心，打哪指哪，横扫了一大批在线零售站点
: 第一个倒掉的是hp自己的hp store
: 然后bestbuy
: 然后newegg
|
T*T
发帖数: 1386 | 26 从奥巴马的healthcare.gov来看，那美国IT水平咋办？ |
l*****9
发帖数: 9501 | 27 美国政府IT水平很差，IT项目一贯质低价高
【在 T*T 的大作中提到】
: 从奥巴马的healthcare.gov来看，那美国IT水平咋办？
|
g*****g
发帖数: 34805 | 28 Obama care 好弄，我说过只要一个一个州 roll out, 就解决了90%的问题。
【在 L******w 的大作中提到】
: 怎么不和obama care的网站比一比？
: 访问量和复杂性都低几个级别，花了几十亿，整出个什么弱智东西来？
|
f****s
发帖数: 5631 | 29 政府的it，能叫IT吗？
【在 l*****9 的大作中提到】
: 从12306来看，国内IT水平不高
: 铁道部说，资金管够，问题给解决就行。简直是IT公司的梦想啊，结果竟然找不到一个
: 承包商。最后铁道部自己开发系统，搞了17个节点，再多也不会提高performance,感觉
: 是强耦合的系统。
: 我觉着，设计的关键是分解强耦合，这样系统performance可以通过增加节点来提高。
: 系统自动出联票的计算量很大，代之以用户提出组合票，牺牲的可用性不大，而系统计
: 算量大大降低。不要和航空公司订票系统比，12306工作量要大几个量级。
: ====下面是我的老帖子
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
|
c**u
发帖数: 550 | 30 层层转包的垃圾项目，豆腐渣，其实高手很多，高手做这项目一样歇菜，就是领导捞钱
的项目，国内那会儿接了个2w的项目，两个人做，后来才知道原来政府外包出来开价几
百万，最后就我们两个人干，而且还是兼职干的私活 |
|
|
r***y
发帖数: 4379 | 31 2008北京奥运的官方网站, 没记得down过, 当然主要功能是发布, 不过也兼卖票. 大家
怎么看.
【在 l*****9 的大作中提到】
: 从12306来看，国内IT水平不高
: 铁道部说，资金管够，问题给解决就行。简直是IT公司的梦想啊，结果竟然找不到一个
: 承包商。最后铁道部自己开发系统，搞了17个节点，再多也不会提高performance,感觉
: 是强耦合的系统。
: 我觉着，设计的关键是分解强耦合，这样系统performance可以通过增加节点来提高。
: 系统自动出联票的计算量很大，代之以用户提出组合票，牺牲的可用性不大，而系统计
: 算量大大降低。不要和航空公司订票系统比，12306工作量要大几个量级。
: ====下面是我的老帖子
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
|
d********f
发帖数: 43471 | 32 别搞了，就从巴马健保网站看，我觉得天朝的IT水平已经领先美帝50年了
【在 l*****9 的大作中提到】
: 从12306来看，国内IT水平不高
: 铁道部说，资金管够，问题给解决就行。简直是IT公司的梦想啊，结果竟然找不到一个
: 承包商。最后铁道部自己开发系统，搞了17个节点，再多也不会提高performance,感觉
: 是强耦合的系统。
: 我觉着，设计的关键是分解强耦合，这样系统performance可以通过增加节点来提高。
: 系统自动出联票的计算量很大，代之以用户提出组合票，牺牲的可用性不大，而系统计
: 算量大大降低。不要和航空公司订票系统比，12306工作量要大几个量级。
: ====下面是我的老帖子
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
|
d********f
发帖数: 43471 | 33 你在搞笑吧，健保那网站根本不用给钱，只是采录信息，连验证都是人工做的，这玩意
跟cssa的论坛水平差不多
【在 z****e 的大作中提到】
: 因为蛤蟆care要给钱，涉及到金钱操作
: 所以系统一般都很难搞
|
g*****g
发帖数: 34805 | 34 你说的这些当机，都是应用升级的时候有bug造成的，难以避免。但跟12306高峰来一次
当一次是本质区别。
题。
【在 h*d 的大作中提到】
: 12306找IBM来的，结果IBM说作不了。
: amazon AWS问题造成netflix都当了好几次了，facebook/gmail最近也都出过一些问题。
|
g*****g
发帖数: 34805 | 35 你这个帖子说了一大堆，基本上就是说明了为什么下单和出票一旦耦合，就搞不定。
但下单和出票为啥一定要耦合呢？
【在 h*d 的大作中提到】
: 发信人: helloterran (hello), 信区: ITExpress
: 标 题: 12306毫无疑问是人类历史上最牛鼻的电商网站
: 发信站: 水木社区 (Thu Jan 24 09:31:06 2013), 站内 [累计积分奖励: 100/0]
: 2011年美国疯抢touchpad，我也参和了一下
: 有个找deal 的论坛叫slickdeal，上面有人实时发帖告诉大家哪里还有货
: 问题是，这个帖子发出来以后两分钟内，该目标网站一定瘫痪。一时间slickdeal变成
: 了大规模ddos的指挥中心，打哪指哪，横扫了一大批在线零售站点
: 第一个倒掉的是hp自己的hp store
: 然后bestbuy
: 然后newegg
|
L******f
发帖数: 5368 | 36 核心问题是数据库问题。
如此大容量，大密度的query，
任何商业数据库系统都会崩溃。
而且系统投入使用前，
系统测试查不出这问题。
唯一的办法就是自己开发
distributed database
query system。
Obamacare的问题也是一样。
Google有这个技术，
愿意不愿意做是另一回事。
【在 l*****9 的大作中提到】
: 从12306来看，国内IT水平不高
: 铁道部说，资金管够，问题给解决就行。简直是IT公司的梦想啊，结果竟然找不到一个
: 承包商。最后铁道部自己开发系统，搞了17个节点，再多也不会提高performance,感觉
: 是强耦合的系统。
: 我觉着，设计的关键是分解强耦合，这样系统performance可以通过增加节点来提高。
: 系统自动出联票的计算量很大，代之以用户提出组合票，牺牲的可用性不大，而系统计
: 算量大大降低。不要和航空公司订票系统比，12306工作量要大几个量级。
: ====下面是我的老帖子
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
|
m****a
发帖数: 2593 | 37 http://www.ccthere.com/article/3965719
我曾在淘宝写过一段时间代码，2012年在一家百强民企做电商副总，当时在极为艰苦的
条件下带队开发了一个B2C网站，走支付宝和银联支付通道，年营业额千万级（当然实
在太少了，我只是说这个网站投入了实际的运营）。
也就在那个时候，我对12306嗤之以鼻，觉得他们做得太烂了，认为自己能带队花几百
万半年时间做个好的出来。于是我狂妄地想做一个开源的订票系统给他们。我花了一个
星期时间思考建立数据模型，思考到库存这一步的时候，我才发现，12306的库存复杂
性比淘宝、京东高很多倍，运算量也大很多倍。传统的分布式数据库、缓存、负载均衡
技术并不能恰好满足12306的需求。
在平时，12306也就是个正常的电商网站。但一到黄金周，12306就是一个全站所有商品
都秒杀，所有SKU都是动态库存的变态。
即使不考虑线下既有的电话、代售点等渠道，要实现一个12306，最少最少也是千万级
别的硬件投入（这是当时的估算，没有精算，可能与实际相差较大，总之，我说得不一
定对，12306的业务也许没我说的那么复杂，但也绝不是某些人喷的那么简单），软件
和人力另算。那些叫嚣只要40台服务器、只要2个架构师4个程序员、大谈分库分表和前
端CDN的人们，只是纸上谈兵罢了。所谓初生牛犊不怕虎，做了三年CMS和BBS，就以这
个经验来喷12306，未免太天真了。
媒体人喷12306，是他们不懂技术，没有能力和耐心来分析背后的难度。技术人员喷，
则是因为大部分的技术人员在短时间思考时，容易陷入过于乐观的误区，经典的例子就
是估算工作量，程序员们往往容易估算出一个超短的工期，把写程序的工作乐观地想象
成了打字员照稿敲键盘的工作。
知乎那篇文章，我觉得不是洗地。排名第一和第二的答案都说得很客观。淘宝技术是比
12306强大很多倍，淘宝现在的系统也是花了10倍于12306的钱、时间和人才做起来的。
根本原因还是铁路运力不能满足春运需求，淘宝也解决不了这个问题。
12306这一年来进步非常大。从前段动画验证码、分时段抢票，到后端去小型机、虚拟
化、内存数据库的运用。可以说，12306是中国政府机关做的最强大的网站（电商系统
），能在短短一两年内做出这样的改变，几乎是个奇迹，就连一些市场化的民企都望尘
莫及，甚至一些上市公司都比不上它！（比如51job和ctrip）。
事非经过不知难，在网上批判12306的人，大部分还是形成了【国企 = 垄断 + 腐败 +
低效 】的思维定势。小部分是真的轻视了它的难度。
至于12306一期工程3个亿（含硬件）贵不贵我不评价，我只提供一个数字供参考，百度
一年的研发费用（不含硬件）是10亿，这个数字来自百度财报。网上能查到。3亿看起
来好大一个数字，真用到超大型的电商系统、搜索引擎系统里面，其实也不算什么天文
数字了。
再解释一下，为什么秒杀压力大，以及为什么12306的动态库存很复杂。
先说秒杀。
2013年12月25日前后，天猫搞了一个圣诞季积分兑换活动，持续几天。25号上午10点12
分，放出了15000个天猫魔盒（淘宝集市有人卖，大概190-230块），从成交记录上看，
是19秒内全部抢完。
实际上，我也参加秒杀了，那天的题目特别简单（请输入xxx汉字的拼音首字母），我
应该是5秒内答题完成并提交订单，结果告诉我排队的人太多，挤不进去，并提示14秒
以后重试。人太多就是因为题目太简单了，门槛越低，5秒内挤进去的人也越多嘛，如
果题目换成【2克浓度为3%的U235在大亚湾核电站能发多少度电】，5分钟之内也不会有
1万5千人跟我竞争。
我想，14秒以后哪还有我的事情呀，于是重新答题秒杀，结果出现了服务器错误的页面
。反复刷新几次，就告诉秒杀结束了。
在群里问了一下同事，有不到10个人回答我，都说没秒到（也可能秒到的人闷声发大财
，不回复我）。
淘宝是什么技术水平呢，淘宝有至少4000技术人员，至少4万台服务器（这都是两年前
的公开数据了，按规定可以谈论），2013年11月11日成交额351亿，2012年全年成交额
超过1万亿。
淘宝拥有各种自主研发团队：服务器、交换机（网上可以搜索到淘宝公开的绿色服务器
开放标准）；操作系统（Linux Kernel taobao版，yunos手机操作系统是阿里云的，暂
时不计入）、Web服务器（Tengine）、Java语言虚拟机（JVM taobao版）、数据库（
MySQL内核 taobao版，google和facebook也有自己的版本，HBase淘宝版、还有自己全
部从头开发的OceanBase）、负载均衡器（LVS，LVS始创人就在淘宝，担任研究员）、
Java运行容器（Jboss，其创始人之一，王文彬，也在淘宝，担任副总裁）。
淘宝还有数不清的开源项目和中间件，如高性能Java通信中间件HSF、分布式数据库中
间件TDDL、异步消息系统notify等等等等。
以淘宝这样的技术水平，也不能做到秒杀时让每个用户都没有拥挤感，为什么呢？
一是要尊重物理原理，一台服务器一秒钟能承受的计算量是有极限的，任你怎么优化，
采用多高效的算法和编程语言，都突破不了某个极限，比方说汽车发动机驱动的F1赛车
至今也不能突破400公里的时速（超音速推进号那个1千多公里的时速不能算，那是飞机
引擎驱动的）。再往深了说，就不容易懂了。感兴趣的可以从著名的C10K问题开始看起。
二是要考虑经济效益，十一黄金周的时候，北京主城区到八达岭长城的路堵得严严实实
，但不能因为黄金周的高峰，就把这段路修成长安街那样10车道的高速公路。否则的话
，花费天文数字（真的是天文数字，12306那3个亿大概只够修1-3公里）。修了一段路
，黄金周是可以飙到80公里/小时了，可平时呢，拿来给两边的居民晒谷子？
淘宝目前的硬件和带宽数量，已经超出日常运营的需求了，就是留了相当大的余量给大
促销（众所周知的是双十一，双十二，其实基本每个季度都有大促销，每个月都有促销
，甚至天天都在促销——聚划算）。amazon当年就是为了应对黑色星期五的大促销购置
了大量的服务器，平时订单量没那么大了，amazon就把富余的服务器拿来搞云计算了。
顺便说一下，阿里云是当今中国第一世界数一数二的云计算服务商，和amazon走的路也
有点像。
再说动态库存。
淘宝秒杀天猫魔盒的时候，只有一个商品（行话叫做SKU），它的库存是15000个。有一
个人秒杀到了，库存就减1，19秒卖完的，一秒要成功产生789个订单（下订单的请求可
能是8万个，只是可能啊，非实际数字，也可能是1万个，用于说明一下壮观程度）。想
象一下，你在广场上卖火车票，一秒钟有8万人举着钱对你喊：卖给我！
上过大学的人都知道，比秒小的时间单位还有毫秒、皮秒、飞秒。但交易系统登记一个
交易可不像电子绕着原子核跑一圈那么简单，它要做这些事：检查是否恶意访问、取到
系统时间、取到顾客默认收货地址、核对顾客秒杀资格（当时的规定是天猫T2.T3达人
）、生成订单号、把顾客ID系统时间订单号收货地址写入订单系统、扣除顾客天猫积分
、商品库存减一、给顾客打标记（每人只能秒一个，下次不能秒了）等等，这每一件事
都要花费毫秒级别的时间，这些操作加起来的时间可能是接近1秒级别的，但由于淘宝
的服务器比较强悍，而且采用了分布式和集群技术，结果比1秒理想一点。但即使有1万
台服务器，也不能把这个时间稀释成万分之一秒，因为，商品只有一种，它有15000个
库存，对应的数据库记录只有一行，所有的交易请求都要到这里来处理。
能不能把这15000个拆分成5000个商品并分配到5000台服务器上呢？那样不就可以5000
台服务器同时处理了吗？答案是不能，首先，5000个商品，意味着有5000个商品详情页
，5000个购买按钮，这对前期的营销、引流是个灾难。基本上就没法做引流入口了，显
然这违背了商业管理原则，人为增加了信息混乱程度。其次，天猫魔盒秒杀也不是啥大
事，即使按官方标价399元来计算，也就6百万的交易。如果6百万的交易要花费那么大
的配套成本，那就太不划算了。再次，淘宝有十几亿商品，这十几亿商品的展示交易和
管理，本来就是分布到上万台服务器上去了。没有必要再把每个商品按库存拆成多个商
品了。
这789人抢到了，还不一定会付款（99积分换天猫魔盒还好一点，不需要去网银，成本
也极低，大部分是会付款的，3999秒杀iPhone 5S就不一定，有人可能网银有问题，有
人可能改变主意不想要了），所以就又带来订单取消重新恢复库存的问题。还有想要的
消费者们，会认为还有机会，继续在前台刷一会儿，最终这个秒杀会被热情的消费者们
猛刷30秒到1分钟。
（超卖这一部分科普笔法写得有错误，鉴于12306目前全在内存数据库中读写，没有产
生超卖问题，先把这个段落删去。感谢@吹西门的雪 指正）
好了，讲了这半天淘宝，可以说12306了吧？
我以北京西到深圳北的G71次高铁为例（这里只考虑南下的方向，不考虑深圳北到北京
西的，那是另外一个车次，叫G72），它有17个站（北京西是01号站，深圳北是17号站
），3种座位（商务、一等、二等）。表面看起来，这不就是3个商品吗？G71商务座、
G71一等座、G71二等座。大部分轻易喷12306的技术人员（包括某些中等规模公司的专
家、CTO）就是在这里栽第一个跟头的。
实际上，G71有136 * 3 = 408种商品（408个SKU），怎么算来的？请看：
如果卖北京西始发的，有16种卖法（因为后面有16个站），北京西到：保定、石家庄、
郑州、武汉、长沙、广州、虎门、深圳。。。。都是一个独立的商品，
同理，石家庄上车的，有15种下车的可能，以此类推，单以上下车的站来计算，有136
种票：16+15+14....+2+1=136。每种票都有3种座位，一共是408个商品。
好了，再看出票时怎么减库存，由于商务、一等、二等三种座位数是独立的，库存操作
也是一样的，下文我就不再提座位的差别的，只讨论出发与到达站。另外，下文说的是
理论世界的模型，不是说12306的数据库就是这么设计的。
旅客A买了一张北京西（01号站）到保定东（02号站）的，那【北京西到保定东】这个
商品的库存就要减一，同时，北京西到石家庄、郑州、武汉、长沙、广州、虎门、深圳
等15个站台的商品库存也要减一，也就是说，出一张北京到保定东的票，实际上要减16
个商品的库存！
这还不是最复杂的，如果旅客B买了一张北京西（01号站）到深圳北（17号站）的票，
除了【北京西到深圳北】这个商品的库存要减一，北京西到保定东、石家庄、郑州、武
汉、长沙、广州、虎门等15个站台的商品库存也要减1，保定东到石家庄、郑州、武汉
、长沙、广州、虎门、深圳北等15个站台的商品库存要减1。。。总计要减库存的商品
数是16+15+14+。。。。+1=120个。
当然，也不是每一张票都的库存都完全这样实时计算，可以根据往年的运营情况，在黄
金周这样的高峰时段，预先对票做一些分配，比如北京到武汉的长途多一点，保定到石
家庄的短途少一点。我没有证据证实铁道部这样做了，但我相信，在还没有12306网站
的时候，铁道部就有这种人工预分配的策略了。
想象一下，8万人举着钱对你高喊：卖给我。你好不容易在钱堆里找到一只手，拿了他
的钱，转身找120个同事，告诉他们减库存，而这120个同事也和你一样被8万人围着；
也和你一样，每卖出一个商品要找几十个人减库存。。。这就是12306动态库存的变态
之处。比你平时买东西的任何网站的库存机制都复杂几十上百倍。
再说一下抢票插件，机器永远比人快，当你好不容易从8万人里突出重围，来到了柜台
前，你发现，我操，来了10万根绑着钱的竹竿，而且当有退票出来的时候，你要闯过3
层人肉才能接近柜台，竹竿在8个人身后一伸，钱就到了柜台前。你低头看了一眼手机
，票就没了，竹竿却永远在那里伸着，永不低头，永不眨眼。如果没有这10万根竹竿，
虽然你很可能还是抢不到票，但不至于沮丧成这样：我TM为什么总是手最慢的一个？！！
防机器人抢票，也不是加个图片验证码那么简单。我写过文章系统性分析过，图片验证
码有6种机器暴力破解的办法，抢票插件用的是我说的第三种，OCR识别。Google采用的
Wave波形字母已经能比较好地防住机器OCR了，ems.com.cn上的验证码就是反面教材，
机器OCR成功率接近100%，12306的比ems的图片验证码强一点。不过，验证码设置得复
杂一点吧，人们要喷：这只是便宜大学生和办公室白领，农民工连26个字母都认不齐，
怎么搞？搞动画验证码吧，也有人喷，视力不好的人怎么办？最后验证码搞得太简单了
，皆大欢喜了，其实最高兴的是开发抢票插件的公司。
就算采用了机器完全不可能识别的验证码，也防不住社会工程学的破解办法。招募一堆
网吧打游戏的青少年朋友，每成功输入50个验证码给1块钱，或者等值的虚拟货币、游
戏装备，我保证想赚这个钱的人数不胜数。这点钱对转卖车票的利润而言，是可以接受
的成本。有没有什么技术可以防住社会工程学的破解办法呢？能防住网吧青少年的验证
码只有【2克浓度为3%的U235在大亚湾核电站能发多少度电】。
以上讨论只是把12306当成和淘宝一样没有历史包袱从零起步的交易系统，实际上，它
不是，它后面的票池，还有电话售票、火车站售票、代售点售票等多个传统渠道要服务
。除了客运服务，12306还有全国最大（很可能也是全球最大）的大宗物资货运系统。
架空政策（包括定价政策、警方打击黄牛政策、身份验证政策）谈技术，是不可能解决
春运抢票困局的，要想让春运的时候每个人在12306抢票都毫无拥挤感（但不一定能抢
到票，铁路运力摆在那），那就是逼着12306买一大堆服务器对付春运，春运过去后，
成为跟amazon一样牛逼的云计算服务商。和逼北京修一条10车道的高速公路去八达岭长
城一个道理。
目前的12306技术上是还有问题，比如，抢票高峰，输入个身份证号和图片验证码都卡
得要死（本人亲测），服务器端繁忙，你浏览器端卡什么呀。
但人家在进步。相信2014年春运的时候，技术已经不再是一票难求的主要问题。在铁路
运力不可能神速增加（孙中山先生计划的20万公里铁路，土共修了快70年，才修到10万
公里）的情况下，要做到春运更公平地买票，需要停靠政策调整。
下文针对的是春节国庆这种非常暑期。其它时期，大部分线路保持现状就行了，问题不
大，极少部分票源紧张的线路可以按春运处理：
1. 拍卖法，价高者得之
当硬座票拍出飞机票价格的时候，相信票就不难买了（可惜就是贵了），也没有那么多
黄牛了。要说淘宝有什么能帮12306一下子搞定技术问题的，淘宝的拍卖系统可以帮忙
，浙江省高院在淘宝拍卖一年多，成交26亿。
可惜这个方法不可能实行。现在的高铁票价都被媒体和意见领袖喷成啥样了，何况是拍
卖。再说，火车票毕竟是生存之刚需，票价20年来不涨本来就有照顾补贴的成分在里面
，全拍卖可能也是不妥当。
2. 抽签法，运气好者得之
开车前2个月开放报名，开车前7天抽签，中途可取消。预存票款，抽不中退款。上传身
份证和正脸自拍照，机器核对。
这样的话，拦截黄牛的成功率就高很多了，黄牛可以预存票款，可以找到大量真实身份
证号，你黄牛再让每个给你身份证号的人把身份证照片和脸部自拍也给你试试？即使有
人真想找黄牛，给身份证照片还是会犹豫一下吧。而且中间手工操作多了很多，黄牛成
本提高，还不一定搞得到票。反正都是碰运气，我想真正的消费者还是会选择自己先去
碰运气吧。
这个方法实施难度也大，无论怎么设计抽签规则，必然有人大叫“有黑幕，不要相信政
府”。
开车前7天出抽签结果，改变行程的人应该在7天前就能决定改还是不改了。没抽到的也
还有时间想别的办法。当然不一定是7天，15天，10天也可以，具体几天要有数据模型
来算。
3. 拍卖 + 抽签
软卧、高铁商务座等高价位的，拍卖，反正买这个的是经济能力相对较强的。那就拼谁
经济能力更强吧。
硬座、站票抽签。
4. 凭身份证进站，车票跟发票一样，是报销凭证，不是进站凭证；退票后钱进入12306
账户，不可提现，只可该乘客下次乘车用；黄金周期间，个人账号最多订购10张票
这个办法可以打击黄牛囤票再转卖
运行一段时间后，按账户余额弄个排行榜就知道谁是黄牛了
可惜这个需要车站设备改造配合。
-----更新-----
收到有同行质疑136个库存的合理性，他提出的方案是：
北京西（01号站）到深圳北（17号站）一共设置16个商品（SKU）：
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门店的人肉查询频率非常低，没有必要为了优化查询性能把库存结构设计成
那样。 |
L******f
发帖数: 5368 | 38 这个说的靠谱。
很多自称专家的程序猿，
通常都只做自己一小块，
没有设计过大规模的系统，
就咋咋呼呼地骂人家系统
烂，其实他们自己才是
最烂的。
【在 m****a 的大作中提到】
: http://www.ccthere.com/article/3965719
: 我曾在淘宝写过一段时间代码，2012年在一家百强民企做电商副总，当时在极为艰苦的
: 条件下带队开发了一个B2C网站，走支付宝和银联支付通道，年营业额千万级（当然实
: 在太少了，我只是说这个网站投入了实际的运营）。
: 也就在那个时候，我对12306嗤之以鼻，觉得他们做得太烂了，认为自己能带队花几百
: 万半年时间做个好的出来。于是我狂妄地想做一个开源的订票系统给他们。我花了一个
: 星期时间思考建立数据模型，思考到库存这一步的时候，我才发现，12306的库存复杂
: 性比淘宝、京东高很多倍，运算量也大很多倍。传统的分布式数据库、缓存、负载均衡
: 技术并不能恰好满足12306的需求。
: 在平时，12306也就是个正常的电商网站。但一到黄金周，12306就是一个全站所有商品
|
A***g
发帖数: 1816 | 39 IBM做不了？别逗了，价钱谈不拢。
题。
【在 h*d 的大作中提到】
: 12306找IBM来的，结果IBM说作不了。
: amazon AWS问题造成netflix都当了好几次了，facebook/gmail最近也都出过一些问题。
|
L******f
发帖数: 5368 | 40 估计又是一个自以为是，其实啥都不懂的程序猿。
【在 A***g 的大作中提到】
: IBM做不了？别逗了，价钱谈不拢。
:
: 题。
|
|
|
A***g
发帖数: 1816 | 41 你这个满嘴喷粪的屎壳郎
【在 L******f 的大作中提到】
: 估计又是一个自以为是，其实啥都不懂的程序猿。
|
A***g
发帖数: 1816 | 42 股票交易所用的软件可是IBM的，说起交易频率，人家那个比个破火车票网站，要高多
了吧。
【在 s*****r 的大作中提到】
: IBM贵而无用，没听说哪个网站用IBM支持
|
c******n
发帖数: 4965 | 43 才注意这个帖子，， 开始觉得是灌水吵架吹牛皮。 仔细想想这个问题还是很有趣的
。。 现有订票系统（travelocity Expedia 等等）
volume 和 qps跟中国铁路根本没法比。 实际上你要保证完全不多卖 (overbooked) 或
少卖， 很简单， 就是 global lock, 没有别的 捷径
所以现在我们经常有见到航空公司 overbooked 然后给乘客 coupon
你看现在航空公司（我记得 united 是这样）， 进去选座位， 输个人信息， 。。
。。。 一串动作后， 最后一部步， 说， 刚才选的位子没了。，
就是说最后一步才 submit transaction, 这样hold locj
k 时间短得多， 如果同时 一列车的2000人同时
竞争， 一个 txn 50---100Ms, 最后delay 20s,还凑活
【在 l*****9 的大作中提到】
: 从12306来看，国内IT水平不高
: 铁道部说，资金管够，问题给解决就行。简直是IT公司的梦想啊，结果竟然找不到一个
: 承包商。最后铁道部自己开发系统，搞了17个节点，再多也不会提高performance,感觉
: 是强耦合的系统。
: 我觉着，设计的关键是分解强耦合，这样系统performance可以通过增加节点来提高。
: 系统自动出联票的计算量很大，代之以用户提出组合票，牺牲的可用性不大，而系统计
: 算量大大降低。不要和航空公司订票系统比，12306工作量要大几个量级。
: ====下面是我的老帖子
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
|
L******f
发帖数: 5368 | 44 股票交易，其实要简单得多。
每个股票维持两个queue。
bid queue/ask queue。
全世界有多少股票，就维持
多少queue。每个交易请求
进来，就在bid queue/ask
queue上减少一个bid/ask
tick，然后生成一个trade
tick。
这比12306要简单多了。
这个贴我回，骂街的贴我就不回了。
【在 A***g 的大作中提到】
: 股票交易所用的软件可是IBM的，说起交易频率，人家那个比个破火车票网站，要高多
: 了吧。
|
A***g
发帖数: 1816 | 45 你连基本的股票交易常识都没有，找本证券101看看再说话吧
骂街是你开始的，少装什么处。
另外，你忘了换登录了，暴露了你的马甲。
【在 L******f 的大作中提到】
: 股票交易，其实要简单得多。
: 每个股票维持两个queue。
: bid queue/ask queue。
: 全世界有多少股票，就维持
: 多少queue。每个交易请求
: 进来，就在bid queue/ask
: queue上减少一个bid/ask
: tick，然后生成一个trade
: tick。
: 这比12306要简单多了。
|
L******f
发帖数: 5368 | 46 这个看来不值得回了。
【在 A***g 的大作中提到】
: 你连基本的股票交易常识都没有，找本证券101看看再说话吧
: 骂街是你开始的，少装什么处。
: 另外，你忘了换登录了，暴露了你的马甲。
|
d******r
发帖数: 16947 | 47 不是搞硬件的，但是感觉算法有问题，为啥一定要实时呢？申请提交后完全可以隔一段
时间处理，而且一旦订票成功
其他作业更容量分开分批处理
【在 l*****9 的大作中提到】
: 从12306来看，国内IT水平不高
: 铁道部说，资金管够，问题给解决就行。简直是IT公司的梦想啊，结果竟然找不到一个
: 承包商。最后铁道部自己开发系统，搞了17个节点，再多也不会提高performance,感觉
: 是强耦合的系统。
: 我觉着，设计的关键是分解强耦合，这样系统performance可以通过增加节点来提高。
: 系统自动出联票的计算量很大，代之以用户提出组合票，牺牲的可用性不大，而系统计
: 算量大大降低。不要和航空公司订票系统比，12306工作量要大几个量级。
: ====下面是我的老帖子
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
|
t***t
发帖数: 6066 | 48 提个问题，这种in memory database, 如果机器down掉了，那大家处于什么状态啊？
比如你已经从人家银行扣了钱，reserve了票，突然机器死机，那如何recover?
【在 h*d 的大作中提到】
: 发信人: helloterran (hello), 信区: ITExpress
: 标 题: 12306毫无疑问是人类历史上最牛鼻的电商网站
: 发信站: 水木社区 (Thu Jan 24 09:31:06 2013), 站内 [累计积分奖励: 100/0]
: 2011年美国疯抢touchpad，我也参和了一下
: 有个找deal 的论坛叫slickdeal，上面有人实时发帖告诉大家哪里还有货
: 问题是，这个帖子发出来以后两分钟内，该目标网站一定瘫痪。一时间slickdeal变成
: 了大规模ddos的指挥中心，打哪指哪，横扫了一大批在线零售站点
: 第一个倒掉的是hp自己的hp store
: 然后bestbuy
: 然后newegg
|
w****n
发帖数: 5749 | 49 说到底根本就不应该鼓励“回家过年”这个概念。本来一年里面随便什么时候能回一次
家就不错了。干吗非要过年？
咱们北美华人这么多，又有几个人能每年回家过年了？不能回家过年怎么了？还不是该
干嘛干嘛，国内变成这么一个政治任务，纯属党国纵容的结果。要说本朝移风易俗的事
情也干了很多了，缺了这么一样就遗憾无穷。
★ 发自iPhone App: ChineseWeb 8.2.1
【在 l*****9 的大作中提到】
: 从12306来看，国内IT水平不高
: 铁道部说，资金管够，问题给解决就行。简直是IT公司的梦想啊，结果竟然找不到一个
: 承包商。最后铁道部自己开发系统，搞了17个节点，再多也不会提高performance,感觉
: 是强耦合的系统。
: 我觉着，设计的关键是分解强耦合，这样系统performance可以通过增加节点来提高。
: 系统自动出联票的计算量很大，代之以用户提出组合票，牺牲的可用性不大，而系统计
: 算量大大降低。不要和航空公司订票系统比，12306工作量要大几个量级。
: ====下面是我的老帖子
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
|
g*****g
发帖数: 34805 | 50 那是因为过年不放假。圣诞，感恩，美国人一样家人团聚，所以机票那么贵。
【在 w****n 的大作中提到】
: 说到底根本就不应该鼓励“回家过年”这个概念。本来一年里面随便什么时候能回一次
: 家就不错了。干吗非要过年？
: 咱们北美华人这么多，又有几个人能每年回家过年了？不能回家过年怎么了？还不是该
: 干嘛干嘛，国内变成这么一个政治任务，纯属党国纵容的结果。要说本朝移风易俗的事
: 情也干了很多了，缺了这么一样就遗憾无穷。
:
: ★ 发自iPhone App: ChineseWeb 8.2.1
|
|
|
d********u
发帖数: 5383 | 51 JAVA“专家”们只会套现成的方案，读书的时候也是死记硬背的呆子。需要创造的时候
，立马萎了。
这年头就是专家多，比狗都多。
【在 L******f 的大作中提到】
: 这个说的靠谱。
: 很多自称专家的程序猿，
: 通常都只做自己一小块，
: 没有设计过大规模的系统，
: 就咋咋呼呼地骂人家系统
: 烂，其实他们自己才是
: 最烂的。
|
g*****g
发帖数: 34805 | 52 大臭臭你说的没错，会创造的都是像魏公公那样，单机一下子就每秒500万交易没压力
，秒杀nasdaq没问题。
臭臭你喜欢创新，最好从物理层做起。啥tcp/ip，udp都是现成的方案，你用你就是狗。
【在 d********u 的大作中提到】
: JAVA“专家”们只会套现成的方案，读书的时候也是死记硬背的呆子。需要创造的时候
: ，立马萎了。
: 这年头就是专家多，比狗都多。
|
w****n
发帖数: 5749 | 53 过年是没有官假，但可以用年假啊，有几个人会用？
我的意思就是像美国人对圣诞感恩一样，平常心对待，不要当政治任务来抓。
不要放长假，就放1-3天（其实国内7天长假的弊端已经很明显了）。也不要增加运力，
谁买得起机票谁回去。CCAV不要宣传回家过年的幸福感。感觉淡了自然就不纠结了。
★ 发自iPhone App: ChineseWeb 8.2.1
【在 g*****g 的大作中提到】
: 那是因为过年不放假。圣诞，感恩，美国人一样家人团聚，所以机票那么贵。
|
g*****g
发帖数: 34805 | 54 那是你没孩子，或者孩子小。等孩子上课了你怎么回去。
【在 w****n 的大作中提到】
: 过年是没有官假，但可以用年假啊，有几个人会用？
: 我的意思就是像美国人对圣诞感恩一样，平常心对待，不要当政治任务来抓。
: 不要放长假，就放1-3天（其实国内7天长假的弊端已经很明显了）。也不要增加运力，
: 谁买得起机票谁回去。CCAV不要宣传回家过年的幸福感。感觉淡了自然就不纠结了。
:
: ★ 发自iPhone App: ChineseWeb 8.2.1
|
w****n
发帖数: 5749 | 55 有孩子了，我的家就在这了，我在这就是回家过年。更不用回去了。
★ 发自iPhone App: ChineseWeb 8.2.1
【在 g*****g 的大作中提到】
: 那是你没孩子，或者孩子小。等孩子上课了你怎么回去。
|
w****n
发帖数: 5749 | 56 而且既然因为孩子不能回家过年是可以接受的，那为什么因为买不到票不能回家过年就
不行呢？不能回家过年本来就很正常，没必要同情。
★ 发自iPhone App: ChineseWeb 8.2.1
【在 g*****g 的大作中提到】
: 那是你没孩子，或者孩子小。等孩子上课了你怎么回去。
|
g*****g
发帖数: 34805 | 57 我不是说了嘛，就跟这里感恩圣诞，只有没钱回去的，没有不想回去的。等你孩子大了
上大学了就很容易理解了。
【在 w****n 的大作中提到】
: 而且既然因为孩子不能回家过年是可以接受的，那为什么因为买不到票不能回家过年就
: 不行呢？不能回家过年本来就很正常，没必要同情。
:
: ★ 发自iPhone App: ChineseWeb 8.2.1
|
t********e
发帖数: 931 | 58 用脚指头想一想就知道，12306复杂程度要比Obama Care高几个数量级
【在 k**o 的大作中提到】
: obamacare网站访问量可能没那么高，巅峰大概只有几百万的级别，平时大概
: 也就不到十万。但是复杂程度绝对高。首先这是个注册ID，然后填表的网站，
: 有几十个field，还得检查信息对错。其次信息填完了还得跟别的机构联网调查，
: 查ss#，查eligibility，查身份，查VA状态。然后做计算，给quote。
: 复杂程度比买张火车票，那确实不是一个级别的。
|
z****e
发帖数: 54598 | 59 创造力不体现在这里
别人做过的东西，你抄一遍算什么创造力
要做别人没做过的东西，新的领域才有最丰厚的汇报
臭臭你这个觉悟不够啊，看过飘没？
里面rhett对scarlett怎么说的？
一个文明在新生之初或者是毁灭的时候，是发财的最好时机
【在 d********u 的大作中提到】
: JAVA“专家”们只会套现成的方案，读书的时候也是死记硬背的呆子。需要创造的时候
: ，立马萎了。
: 这年头就是专家多，比狗都多。
|
L******w
发帖数: 5407 | 60 是这理， obama care的产品option一个州就那么几十种，
也卖不完。 和春运机票能比吗？
【在 t********e 的大作中提到】
: 用脚指头想一想就知道，12306复杂程度要比Obama Care高几个数量级
|
|
|
e****e
发帖数: 884 | 61 不管IBM能不能做，把这种核心服务又交给美国公司，政治责任谁来承担？
中央已经对银行全用DB2和Oracle很头疼了。
感谢12306是自主研发，至少锻炼了队伍，13年底有篇技术文章去读读吧。
【在 z****e 的大作中提到】
: 哪有，当时ibm是很贵，铁道部不同意
:
: 题。
|
f**********r
发帖数: 2158 | 62
【在 l*****9 的大作中提到】
: 从12306来看，国内IT水平不高
: 铁道部说，资金管够，问题给解决就行。简直是IT公司的梦想啊，结果竟然找不到一个
: 承包商。最后铁道部自己开发系统，搞了17个节点，再多也不会提高performance,感觉
: 是强耦合的系统。
: 我觉着，设计的关键是分解强耦合，这样系统performance可以通过增加节点来提高。
: 系统自动出联票的计算量很大，代之以用户提出组合票，牺牲的可用性不大，而系统计
: 算量大大降低。不要和航空公司订票系统比，12306工作量要大几个量级。
: ====下面是我的老帖子
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
|
s*****r
发帖数: 43070 | 63 一旦下了订单就要给人家一个结果，等待的时间越少越好。12306刚出来的时候，等结
果的时间非常长，被骂惨了。有等一个小时的，有的钱被支付了，票却没了。
现在12306已经牛X太多，处理速度很快，抢不到票不能只怪12306
【在 d******r 的大作中提到】
: 不是搞硬件的，但是感觉算法有问题，为啥一定要实时呢？申请提交后完全可以隔一段
: 时间处理，而且一旦订票成功
: 其他作业更容量分开分批处理
|
l*****9
发帖数: 9501 | 64 运力不足，火车票肯定一票难求。关键是要杜绝黄牛：车票实名制，不能改票，可以退
票但是不全额。
【在 s*****r 的大作中提到】
: 一旦下了订单就要给人家一个结果，等待的时间越少越好。12306刚出来的时候，等结
: 果的时间非常长，被骂惨了。有等一个小时的，有的钱被支付了，票却没了。
: 现在12306已经牛X太多，处理速度很快，抢不到票不能只怪12306
|
e**7
发帖数: 819 | 65 LZ从obamacare网站情况看，美国的IT水平如何？ |
s*****e
发帖数: 16824 | 66 现在就是这样啊，实名制，不能改，可以退有罚金。没用，黄牛乌泱乌泱的，直接用刷
票软件抢票，大大增加了12306的压力。黄牛买了票以后再跟买主联系，买主交钱了以
后黄牛退票再同时用买主的信息把票买回来，至于罚金，那全部都算到买主的票价里了。
【在 l*****9 的大作中提到】
: 运力不足，火车票肯定一票难求。关键是要杜绝黄牛：车票实名制，不能改票，可以退
: 票但是不全额。
|
l*****9
发帖数: 9501 | 67 你说的这就是可以改票了
了。
【在 s*****e 的大作中提到】
: 现在就是这样啊，实名制，不能改，可以退有罚金。没用，黄牛乌泱乌泱的，直接用刷
: 票软件抢票，大大增加了12306的压力。黄牛买了票以后再跟买主联系，买主交钱了以
: 后黄牛退票再同时用买主的信息把票买回来，至于罚金，那全部都算到买主的票价里了。
|
h*d
发帖数: 19309 | 68 狗狗家play store purchased item appears as not purchased known issue两年了都
还没解决，搜索GTA出来一堆乱七八糟的，amazon搜索产品也很糟糕，找fanless pc
with usb 3.0很不方便。
【在 L******f 的大作中提到】
: 核心问题是数据库问题。
: 如此大容量，大密度的query，
: 任何商业数据库系统都会崩溃。
: 而且系统投入使用前，
: 系统测试查不出这问题。
: 唯一的办法就是自己开发
: distributed database
: query system。
: Obamacare的问题也是一样。
: Google有这个技术，
|
h*d
发帖数: 19309 | 69 等孩子上大学了难道不等孩子回家团聚？那时候岁数大了10多小时飞机回国更难受了。
春运车票我觉得可以考虑早定便宜但是不能退的票，接近春节开始拍卖剩下的票，本来
就应该鼓励大家错开时间过节。
【在 g*****g 的大作中提到】
: 我不是说了嘛，就跟这里感恩圣诞，只有没钱回去的，没有不想回去的。等你孩子大了
: 上大学了就很容易理解了。
|
h*d
发帖数: 19309 | 70 我觉得黄牛一贯是铁道部自己人赚钱的手段
【在 l*****9 的大作中提到】
: 运力不足，火车票肯定一票难求。关键是要杜绝黄牛：车票实名制，不能改票，可以退
: 票但是不全额。
|
|
|
x*****n
发帖数: 86 | 71 我用了
过年是没有官假，但可以用年假啊，有几个人会用？我的意思就是像美国人对圣诞感恩
一样，平常心对待，不要当政治任务来抓。不要放长假，就放1-3天（其实国内7天长假
的弊端已经很明显了）........
【在 w****n 的大作中提到】
: 过年是没有官假，但可以用年假啊，有几个人会用？
: 我的意思就是像美国人对圣诞感恩一样，平常心对待，不要当政治任务来抓。
: 不要放长假，就放1-3天（其实国内7天长假的弊端已经很明显了）。也不要增加运力，
: 谁买得起机票谁回去。CCAV不要宣传回家过年的幸福感。感觉淡了自然就不纠结了。
:
: ★ 发自iPhone App: ChineseWeb 8.2.1
|
x*****n
发帖数: 86 | 72 黄牛是央企，怎么能搞沒了呢？
现在就是这样啊，实名制，不能改，可以退有罚金。没用，黄牛乌泱乌泱的，直接用刷
票软件抢票，大大增加了12306的压力。黄牛买了票以后再跟买主联系，买主交钱了以
后黄牛退票再同时用买........
【在 s*****e 的大作中提到】
: 现在就是这样啊，实名制，不能改，可以退有罚金。没用，黄牛乌泱乌泱的，直接用刷
: 票软件抢票，大大增加了12306的压力。黄牛买了票以后再跟买主联系，买主交钱了以
: 后黄牛退票再同时用买主的信息把票买回来，至于罚金，那全部都算到买主的票价里了。
|
c****7
发帖数: 4192 | 73 amazon有一个东西叫big red button，按了之后只管收钱，订单处理慢慢来，fraud，
亏损等，再说。
【在 h*d 的大作中提到】
: 发信人: helloterran (hello), 信区: ITExpress
: 标 题: 12306毫无疑问是人类历史上最牛鼻的电商网站
: 发信站: 水木社区 (Thu Jan 24 09:31:06 2013), 站内 [累计积分奖励: 100/0]
: 2011年美国疯抢touchpad，我也参和了一下
: 有个找deal 的论坛叫slickdeal，上面有人实时发帖告诉大家哪里还有货
: 问题是，这个帖子发出来以后两分钟内，该目标网站一定瘫痪。一时间slickdeal变成
: 了大规模ddos的指挥中心，打哪指哪，横扫了一大批在线零售站点
: 第一个倒掉的是hp自己的hp store
: 然后bestbuy
: 然后newegg
|
e****M
发帖数: 280 | 74 看淘宝就知道国内的IT水平还是可以的。
12306的问题跟技术水平无关。纯粹是官僚系统的问题。跟healthcare.gov的问题是一
样的。 |
g*****g
发帖数: 34805 | 75 这是肯定的，obama care没抢票，很容易scale.
【在 t********e 的大作中提到】
: 用脚指头想一想就知道，12306复杂程度要比Obama Care高几个数量级
|
b*******s
发帖数: 5216 | 76 你再仔细想想？
【在 l*****9 的大作中提到】
: 从12306来看，国内IT水平不高
: 铁道部说，资金管够，问题给解决就行。简直是IT公司的梦想啊，结果竟然找不到一个
: 承包商。最后铁道部自己开发系统，搞了17个节点，再多也不会提高performance,感觉
: 是强耦合的系统。
: 我觉着，设计的关键是分解强耦合，这样系统performance可以通过增加节点来提高。
: 系统自动出联票的计算量很大，代之以用户提出组合票，牺牲的可用性不大，而系统计
: 算量大大降低。不要和航空公司订票系统比，12306工作量要大几个量级。
: ====下面是我的老帖子
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
|
h*******u
发帖数: 15326 | 77 航空公司overbook跟网上订票半毛钱关系都没有。overbook后面的概念是根据统计总有
一部分乘客误机，所以利用overbook优化利润。就是全部采用柜台售票，也同样会有
overbook。
【在 c******n 的大作中提到】
: 才注意这个帖子，， 开始觉得是灌水吵架吹牛皮。 仔细想想这个问题还是很有趣的
: 。。 现有订票系统（travelocity Expedia 等等）
: volume 和 qps跟中国铁路根本没法比。 实际上你要保证完全不多卖 (overbooked) 或
: 少卖， 很简单， 就是 global lock, 没有别的 捷径
: 所以现在我们经常有见到航空公司 overbooked 然后给乘客 coupon
: 你看现在航空公司（我记得 united 是这样）， 进去选座位， 输个人信息， 。。
: 。。。 一串动作后， 最后一部步， 说， 刚才选的位子没了。，
: 就是说最后一步才 submit transaction, 这样hold locj
: k 时间短得多， 如果同时 一列车的2000人同时
: 竞争， 一个 txn 50---100Ms, 最后delay 20s,还凑活
|
l*******g
发帖数: 27064 | 78 别找乐子了，人都想做想疯了，可惜项目不给人家
这种破玩意儿很简单，80%都回扣了，剩下20%能开发个出来能用的就不错了
题。
【在 h*d 的大作中提到】
: 12306找IBM来的，结果IBM说作不了。
: amazon AWS问题造成netflix都当了好几次了，facebook/gmail最近也都出过一些问题。
|
l*******g
发帖数: 27064 | 79 看看taobao抢购，上亿都有
【在 m**********j 的大作中提到】
: 没戏，在春运面前，在4000万人南北大移动面前，这是完全无力的。
: 你知道4千万人在同一时间内查询订票是个什么概念吗?
|
s*****e
发帖数: 16824 | 80 淘宝那个没法比，都是不相关的，很容易分散处理。
【在 l*******g 的大作中提到】
: 看看taobao抢购，上亿都有
|
|
|
y*****0
发帖数: 1189 | 81 一段铁路查票数据是分段的。
比如17站的火车，就有16段的数据。
一次查询需要得到16段的最小值。这样整个算法还算是o(n)的。
但如果要直接修改站对站的数据，就是o(n^2)的。
这个应该是查询和修改之间的trade-off。我个人会选择查询O(n)，而不是修改O(n^2)。
估计铁路部门应该是预先分配好站对站的票量，而零售的票，只是非常小的一部分。
【在 m****a 的大作中提到】
: http://www.ccthere.com/article/3965719
: 我曾在淘宝写过一段时间代码，2012年在一家百强民企做电商副总，当时在极为艰苦的
: 条件下带队开发了一个B2C网站，走支付宝和银联支付通道，年营业额千万级（当然实
: 在太少了，我只是说这个网站投入了实际的运营）。
: 也就在那个时候，我对12306嗤之以鼻，觉得他们做得太烂了，认为自己能带队花几百
: 万半年时间做个好的出来。于是我狂妄地想做一个开源的订票系统给他们。我花了一个
: 星期时间思考建立数据模型，思考到库存这一步的时候，我才发现，12306的库存复杂
: 性比淘宝、京东高很多倍，运算量也大很多倍。传统的分布式数据库、缓存、负载均衡
: 技术并不能恰好满足12306的需求。
: 在平时，12306也就是个正常的电商网站。但一到黄金周，12306就是一个全站所有商品
|
s*******d
发帖数: 3991 | 82 应该限制一个身份证能买的票数量，
一个时间段只能一个方向，
只能买往返票
了。
【在 s*****e 的大作中提到】
: 现在就是这样啊，实名制，不能改，可以退有罚金。没用，黄牛乌泱乌泱的，直接用刷
: 票软件抢票，大大增加了12306的压力。黄牛买了票以后再跟买主联系，买主交钱了以
: 后黄牛退票再同时用买主的信息把票买回来，至于罚金，那全部都算到买主的票价里了。
|
s*****e
发帖数: 16824 | 83 早就限制了，问题是黄牛弄了几百个身份证，就跟炒股似的。总之这个是黄牛吃饭的家
伙，他们研究比任何人都透彻。
【在 s*******d 的大作中提到】
: 应该限制一个身份证能买的票数量，
: 一个时间段只能一个方向，
: 只能买往返票
:
: 了。
|
b*******s
发帖数: 5216 | 84 实名制上车，退票收高额手续费
【在 s*****e 的大作中提到】
: 早就限制了，问题是黄牛弄了几百个身份证，就跟炒股似的。总之这个是黄牛吃饭的家
: 伙，他们研究比任何人都透彻。
|
b***l
发帖数: 812 | 85 看央视那个新闻，黄牛用几百个身份证一次hold住几千张票，找到下家后再release1，
2百张，然后用下家信息才能买回来1张。。。 |
s*****e
发帖数: 16824 | 86 实名制上车不现实，现在一般都是买票的时候验证，上车的时候就不管了，因为你一个
一个查身份证太费时间，那要多长时间才能上完，尤其是春运的时候，太没效率了。而
且即使你查也没用，因为黄牛是退票以后用买主的身份信息买的。退票收高额手续费可
能有用，但是第一正常退票的也倒霉了，也会骂你，第二黄牛会把这些费用全加在票价
上，只有这些费用加票价超过买主的承受能力以后才能遏制黄牛票，但是春节回家的需
求太强，恐怕翻一倍别人也照样会买，所以你就是处一倍罚金恐怕都不够。
【在 b*******s 的大作中提到】
: 实名制上车，退票收高额手续费
|
b*******s
发帖数: 5216 | 87 你说得有道理
【在 s*****e 的大作中提到】
: 实名制上车不现实，现在一般都是买票的时候验证，上车的时候就不管了，因为你一个
: 一个查身份证太费时间，那要多长时间才能上完，尤其是春运的时候，太没效率了。而
: 且即使你查也没用，因为黄牛是退票以后用买主的身份信息买的。退票收高额手续费可
: 能有用，但是第一正常退票的也倒霉了，也会骂你，第二黄牛会把这些费用全加在票价
: 上，只有这些费用加票价超过买主的承受能力以后才能遏制黄牛票，但是春节回家的需
: 求太强，恐怕翻一倍别人也照样会买，所以你就是处一倍罚金恐怕都不够。
|
s****y
发帖数: 38 | 88 国内没有真正的招标之说，一切国有的网站都不可能做的好，经常连用也用不起来。相
比之下，12306做的已经很上乘了了。
【在 l*****9 的大作中提到】
: 从12306来看，国内IT水平不高
: 铁道部说，资金管够，问题给解决就行。简直是IT公司的梦想啊，结果竟然找不到一个
: 承包商。最后铁道部自己开发系统，搞了17个节点，再多也不会提高performance,感觉
: 是强耦合的系统。
: 我觉着，设计的关键是分解强耦合，这样系统performance可以通过增加节点来提高。
: 系统自动出联票的计算量很大，代之以用户提出组合票，牺牲的可用性不大，而系统计
: 算量大大降低。不要和航空公司订票系统比，12306工作量要大几个量级。
: ====下面是我的老帖子
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
|
z****g
发帖数: 75 | 89 堂堂中华，这个系统还是能做好的
解决好这个问题，Internet上公开的技术足够了，就是捞到活儿的干不好
这种政府官僚的项目，哪个国家都这样，这个是难点
【在 s****y 的大作中提到】
: 国内没有真正的招标之说，一切国有的网站都不可能做的好，经常连用也用不起来。相
: 比之下，12306做的已经很上乘了了。
|
l*****9
发帖数: 9501 | 90 没什么不现实的。退票费20%就行了。订票本身就和身份证挂钩了，订票时有个选项，
一旦订票成功自动购买，这些订票优先，黄牛就不可能用几百个身份证占票了。黄牛一
旦退票，再买票得和所有人一块儿抢，而且还有waiting list在新订单前面。如果黄牛
提前找好真正乘客，就是正常订票服务了，是允许的，比如规定手续费10%，我想会有
正当生意干这个事情的，可以服务不会上网的人或嫌麻烦的人
【在 s*****e 的大作中提到】
: 实名制上车不现实，现在一般都是买票的时候验证，上车的时候就不管了，因为你一个
: 一个查身份证太费时间，那要多长时间才能上完，尤其是春运的时候，太没效率了。而
: 且即使你查也没用，因为黄牛是退票以后用买主的身份信息买的。退票收高额手续费可
: 能有用，但是第一正常退票的也倒霉了，也会骂你，第二黄牛会把这些费用全加在票价
: 上，只有这些费用加票价超过买主的承受能力以后才能遏制黄牛票，但是春节回家的需
: 求太强，恐怕翻一倍别人也照样会买，所以你就是处一倍罚金恐怕都不够。
|
|
|
l******l
发帖数: 2651 | 91 你哪搞的狗屎小道消息？
信谣传谣，被转500次，要被喝茶的。
13年底，淘宝Stanford在搞了招聘会。
CTO王坚当众说了，当时12306是由IBM实现的方案。淘宝作维护。
另外，服务器是IBM的X-系列。
第一次的招标是清华同方作为项目执行方吃下。继承清华90年代把发射小卫星任务外包
到英国的传统，清华同方继续外包。碰巧砸了。
【在 h*d 的大作中提到】
: 我觉得黄牛一贯是铁道部自己人赚钱的手段
|
