s***d
发帖数: 15421 | 1 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 2344 条评论 感谢 分享 收藏 • 没有帮助 • 举报
更多回答
984
林布，攒钱买玛莎
看了几个高票答案，有点着急。
12306最让人诟病的是频繁崩溃，而洗地的人讨论的是票够不够卖。
话放在这里，12306根本没有用心在做。
我以前是干前端的，sever端很多东西我不懂，也知道难度极大。我无意于评论后端的
水平，但是我们可以通过看得见的东西来讨论太极是用什么人，什么态度去做这个网站。
简单的说：无论数据库那边有多难，至少前端都不应该做成这么落后，混乱，业余的样
子。
数据库上面的问题讨论的很多了，我不搀和。最差的情况下，哪怕数据库方面直接挂掉
了，至少页面也应该是活着的啊。
这里我负责任的说一句，12306的前端，到目前为止依旧是一滩狗屎（目前:2014.8.25
默认使用的版本）
你可以说IBM和阿里解决不了所有的问题，起码他们不能帮你造铁路。不过就12306前端
体现出的本科毕设水平，也好意思这么说吗？
「挟太山以超北海，语人曰『我不能』，是诚不能也。为长者折枝，语人曰『我不
能』，是不为也，非不能也。
算了先不吐槽，上点啥内容
我为什么说，12306的前端是落后过时的
----------郑重声明：我欢迎任何形式的讨论，但是认为我在讨论外观/体验，UI/UE的
请回去重新学习中学语文再来评论--------------
很多细节，我随便列举
页内js写的到处都是，东一片西一片，很难维护
css技术落后，多个icon图片分开加载，完全可以用css切割来减少请求次数，提高
效率
js技术老旧且极不成熟：使用jquery 1.4.2也就罢了，页内有大量字符串拼接html
然后用$jq.html()方法写入的语句，很难维护，可读性低。
许多本应私有方法暴露在window对象下，比如getQueryParamValue这种，对安全性
和可维护性都十分不利
资源加载未优化：除了现成的控件以外，js没有经过压缩和混淆，不过比我上一次
看（12年底）的时候，大段大段的注释要好一些。此外资源加载次序没有优化调整，一
些不重要的js文件在head处加载，没必要
前端技术不但落后，而且混乱，没有统一。在选取dom元素方面，一个页面里同时
存在jQuery的选择器以及document.getElementById的方法。同时Jquery控件和接近被
淘汰的flash控件混用来呈现了一个很混乱的前端代码
html的命名简直不知所谓，indexLeft下面是newLeft，newRight...谁知道这是什
么跟什么啊。对后来的维护势必造成困扰。相比之下二维码的div叫做erweima还算比较萌
@stone moai 同学在评论里提及，打开这个页面https://kyfw.12306.cn/otn/
queryTrainInfo/init，结果发现head里加载了这样一个js文件https://kyfw.12306.cn
/otn/resources/js/query/train_list.js?scriptVersion=1.3462。请求大小是1.7M。
存储的是全国所有车次的 ([车次号(路线],[对应数据库ID])。为了完成一个输入框自
动完成的功能。
简直不可思议！
这就是一个小型的静态数据表，完全可以存放在数据库中用ajax来查询。如果担心
请求次数对服务器的压力的话，可以租用一个第三方的服务器来解决。但是他们的做法
是，把这个丢在了JS里。
丢在JS里不是不可以，但是这种巨大的非必须文件本应在document.load事件里来
异步加载。但是他们的做法是，把这个丢在了head下面。我...一口老血
UI设计过时丑陋那真的不用我多说了，设计问题我也管不着。不过这分明就是5000块钱
的外包模板而已啊。
总体来说，以12306前端技术的落后，业余，低效，混乱。以此来看，我很难相信他们
的在数据库方面能够有多么好的表现。我还是得说，这就是一帮子大学生现学现卖的毕
设水平，作为这个级别的网站而言，就是一滩屎，连个坨都没有——好歹一坨屎也是成
形的屎。
说起来我之前看到他们的大段注释的时候，还看的出来他们在规章制度上挺严格，注释
写的一板一眼的。但是实际上也就是制度上严格而已，管理上十分混乱，连一个统一前
端技术方案都没有，才会闹getElementById和jQuery选择器大规模混用的笑话。
至于其他一些不利于快速加载，不利于减少请求，减少响应时间的小毛病，不是大问题
，对于学生毕设来说可以接受。但是连这些很低级很基础的举手之劳都做不好或者不想
做的，你网站崩溃确实是有客观的原因，但是就这样还好意思说什么客观条件？
项羽说天要亡我非战之罪情有可原，你一马谡自己不好好做事把自己弄死了，还怪王平
不给力，好意思吗。
几点说明
前端的代码浏览器里都能看到，写的好坏大家一看便知。至于后台，不了解，不多
说。对于某些对技术一无所知还来摆酸话的，我希望知乎能出一个自定义评论验证码。
比如现在我就想弄一个"写一个超链接"的验证码，能过滤到很多没有价值的评论。
重复：我真的没有在讨论任何和外观体验有关的话题
针对“虽然前端硬伤但是不影响整体，后台多努力你造吗”——或者根本选择无视
前端硬伤的：
我更关注的是开发团队的技术实力，而就其前端而言，选用的技术古旧体现出的落
后，基本优化缺失体现出的毛糙业余，同一个页面使用不同技术方案体现出的毫无管理
，都是伴随团队的整个开发过程的。
做出这样一个落后业余混乱前端的团队，是绝对没有实力做出一套好的解决方案的。
前端的性能问题或者别的问题相对于其数据问题确实不是一个大问题，但是前端落
后业余混乱的硬伤表现出的开发者团队能力的问题，则比起数据来说是一个更具体更现
实的问题了，除非有证据能证明后台开发的团队是另一个技术实力远强于前端的团队。
更何况以前端的业余程度来说，他们负责代码审查和白盒测试的团队恐怕也....
竟然真的看到了类似于，出于高并发系统的难度，前端代码质量和水平要为其让路
这样的神论断。我希望持有这个论断的知友能够把他的理论依据就事论事的和目前我们
能看到的前端代码结合在一起。
简单的说，就是指出某一段具体的代码”为什么不能写成更高质量，而只能以目前
这种水平完成“。talk is cheap
显示全部
670
匿名用户
现有的部分讨论，双方缺少对基本事实的共识。
在下转一篇文章，给诸位提供一些材料，不管是支持还是反对，至少可以指出支持反对
哪一点，免得鸡同鸭讲。文章是两年前的，欢迎知情人士指出两年来是否有什么变化。
文章主要说了12306这个网站有多独特，技术难点在哪里，有什么可能的改善方法。
==================
由http://12306.cn谈谈网站性能技术
2012年1月16日 陈皓
http://12306.cn网站挂了，被全国人民骂了。我这两天也在思考这个事
业务
任何技术都离不开业务需求，所以，要说明性能问题，首先还是想先说说业务问题。
其一，有人可能把这个东西和QQ或是网游相比。但我觉得这两者是不一样的，网游
和QQ在线或是登录时访问的更多的是用户自己的数据，而订票系统访问的是中心的票量
数据，这是不一样的。不要觉得网游或是QQ能行你就以为这是一样的。网游和QQ 的后
端负载相对于电子商务的系统还是简单。
其二，有人说春节期间订火车的这个事好像网站的秒杀活动。的确很相似，但是如
果你的思考不在表面的话，你会发现这也有些不一样。火车票这个事，还有很多查询操
作，查时间，查座位，查铺位，一个车次不 行，又查另一个车次，其伴随着大量的查
询操作，下单的时候需要对数据库操作。而秒杀，直接杀就好了。另外，关于秒杀，完
全可以做成只接受前N个用户的请求（完全不操作后端的任何数据， 仅仅只是对用户的
下单操作log），这种业务，只需要在内存cache中放好可秒杀的数量，还可以把数据分
布开来放，100商品，10台服务器一台放10个，无需在当时操作任何数据库。可以订单
数够后，停止秒杀，然后批量写数据库。而且秒杀的商品不多。火车票这个不是像秒杀
那么简单的，春运时间，几乎所有的票都是热门票，而且几乎是全国人民都来了。（淘
宝的双十一也就3百万用户，而火车票瞬时有千万级别甚至是亿级别的）
其三，有人拿这个系统和奥运会的票务系统比较。我觉得还是不一样。虽然奥运会
的票务系统当年也一上线就废了。但是奥运会用的是抽奖的方式，也就是说不存在先来
先得的抢的方式，而且，是事后抽奖，事前只需要收信息，事前不需要保证数据一致性
，没有锁，很容易水平扩展。
其四，订票系统应该和电子商务的订单系统很相似，都是需要对库存进行：1）占
住库存，2）支付（可选），3）扣除库存的操作。这个是需要有一致性的检查的，也就
是在并发时需要对数据加锁的。B2C的电商基本上都会把这个事干成异步的，也就是说
，你下的订单并不是马上处理的，而是延时处理的，只有成功处理了，系统才会给你一
封确认邮件说是订单成功。我相信有很多朋友都收到认单不成功的邮件。这就是说，数
据一致性在并发下是一个瓶颈。
其五，铁路的票务业务很变态，其采用的是突然放票，而有的票又远远不够大家分
，所以，大家才会有抢票这种有中国特色的业务的做法。于是当票放出来的时候，就会
有几百万人甚至上千万人杀上去，查询，下单。几十分钟内，一个网站能接受几千万的
访问量，这个是很恐怖的事情。据说12306的高峰访问是10亿PV，集中在早8点到10点，
每秒PV在高峰时上千万。
多说几句：
库存是B2C的恶梦，库存管理相当的复杂。不信，你可以问问所有传统和电务零售
业的企业，看看他们管理库存是多么难的一件事。不然，就不会有那么多人在问凡客的
库存问题了。（你还可以看看《乔布斯传》，你就知道为什么Tim会接任Apple的CEO了
，最主要的原因是他搞定了苹果的库存周期问题）
对于一个网站来说，浏览网页的高负载很容易搞定，查询的负载有一定的难度去处
理，不过还是可以通过缓存查询结果来搞定，最难的就是下单的负载。因为要访问库存
啊，对于下单，基本上是用异步来搞定的。去年双11节，淘宝的每小时的订单数大约在
60万左右，京东一天也才能支持40万（居然比12306还差），亚马逊5年前一小时可支持
70万订单量。可见，下订单的操作并没有我们相像的那么性能高。
淘宝要比B2C的网站要简单得多，因为没有仓库，所以，不存在像B2C这样有N个仓
库对同一商品库存更新和查询的操作。下单的时候，B2C的 网站要去找一个仓库，又要
离用户近，又要有库存，这需要很多计算。试想，你在北京买了一本书，北京的仓库没
货了，就要从周边的仓库调，那就要去看看沈阳或 是西安的仓库有没有货，如果没有
，又得看看江苏的仓库，等等。淘宝的就没有那么多事了，每个商户有自己的库存，库
存就是一个数字，并且库存分到商户头上了，反而有利于性能扩展。
数据一致性才是真正的性能瓶颈。有 人说nginx可以搞定每秒10万的静态请求，我
不怀疑。但这只是静态请求，理论值，只要带宽、I/O够强，服务器计算能力够，并支
持的并发连接数顶得住10万TCP链接的建立 的话，那没有问题。但在数据一致性面前，
这10万就完完全全成了一个可望不可及的理论值了。
我说那么多，我只是想从业务上告诉大家，我们需要从业务上真正了解春运铁路订票这
样业务的变态之处。
前端性能优化技术
要解决性能的问题，有很多种常用的方法，我在下面列举一下，我相信12306这个网站
使用下面的这些技术会让其性能有质的飞跃。
一、前端负载均衡
通过DNS的负载均衡器（一般在路由器上根据路由的负载重定向）可以把用户的访问均
匀地分散在多个Web服务器上。这样可以减少Web服务器的请求负载。因为http的请求都
是短作业，所以，可以通过很简单的负载均衡器来完成这一功能。最好是有CDN网络让
用户连接与其最近的服务器（CDN通常伴随着分布式存储）。（关于负载均衡更为详细
的说明见“后端的负载均衡”）
二、减少前端链接数
我看了一下http://12306.cn，打开主页需要建60多个HTTP连接，车票预订页面则有70多个HTTP请求，现在的浏览器都是并发请求的（当然，浏览器的一个页面的并发数是有限的，但是你挡不住用户开多个页面，而且，后端服务器TCP链接在前端断开始，还不会马上释放或重要）。所以，只要有100万个用户，就有可能会有6000万个链接（访问第一次后有了浏览器端的cache，这个数会下来，就算只有20%也是百万级的链接数），太多了。一个登录查询页面就好了。把js打成一个文件，把css也打成一个文件，把图标也打成一个文件，用css分块展示。把链接数减到最低。
三、减少网页大小增加带宽
这个世界不是哪个公司都敢做图片服务的，因为图片太耗带宽了。现在宽带时代很难有
人能体会到当拨号时代做个图页都不敢用图片的情形（现在在手机端浏览也是这个情形
）。我查看了一下12306首页的需要下载的总文件大小大约在900KB左右，如果你访问过
了，浏览器会帮你缓存很多，只需下载10K左右的文件。但是我们可以想像一个极端一
点的案例，1百万用户同时访问，且都是第一次访问，每人下载量需要1M，如果需要在
120秒内返回，那么就需要，1M * 1M /120 * 8 = 66Gbps的带宽。很惊人吧。所以，我
估计在当天，12306的阻塞基本上应该是网络带宽，所以，你可能看到的是没有响应。
后面随着浏览器的缓存帮助12306减少很多带宽占用，于是负载一下就到了后端，后端
的数据处理瓶颈一下就出来。于是你会看到很多http 500之类的错误。这说明后端服务
器垮了。
四、前端页面静态化
静态化一些不常变的页面和数据，并gzip一下。还有一个变态的方法是把这些静态页面
放在/dev/shm下，这个目录就是内存，直接从内存中把文件读出来返回，这样可以减少
昂贵的磁盘I/O。使用nginx的sendfile功能可以让这些静态文件直接在内核心态交换，
可以极大增加性能。
五、优化查询
很多人查询都是在查一样的，完全可以用反向代理合并这些并发的相同的查询。这样的
技术主要用查询结果缓存来实现，第一次查询走数据库获得数据，并把数据放到缓存，
后面的查询统统直接访问高速缓存。为每个查询做Hash，使用NoSQL的技术可以完成这
个优化。（这个技术也可以用做静态页面）
对于火车票量的查询，个人觉得不要显示数字，就显示一个“有”或“无”就好了，这
样可以大大简化系统复杂度，并提升性能。把查询对数据库的负载分出去，从而让数据
库可以更好地为下单的人服务。
六、缓存的问题
缓存可以用来缓存动态页面，也可以用来缓存查询的数据。缓存通常有那么几个问题：
1）缓存的更新。也叫缓存和数据库的同步。有这么几种方法，一是缓存time out，让
缓存失效，重查，二是，由后端通知更新，一量后端发生变化，通知前端更新。前者实
现起来比较简单，但实时性不高，后者实现起来比较复杂 ，但实时性高。
2）缓存的换页。内存可能不够，所以，需要把一些不活跃的数据换出内存，这个和操
作系统的内存换页和交换内存很相似。FIFO、LRU、LFU都是比较经典的换页算法。相关
内容参看Wikipeida的缓存算法。
3）缓存的重建和持久化。缓存在内存，系统总要维护，所以，缓存就会丢失，如果缓
存没了，就需要重建，如果数据量很大，缓存重建的过程会很慢，这会影响生产环境，
所以，缓存的持久化也是需要考虑的。
诸多强大的NoSQL都很好支持了上述三大缓存的问题。
后端性能优化技术
前面讨论了前端性能的优化技术，于是前端可能就不是瓶颈问题了。那么性能问题就会
到后端数据上来了。下面说几个后端常见的性能优化技术。
一、数据冗余
关于数据冗余，也就是说，把我们的数据库的数据冗余处理，也就是减少表连接这样的
开销比较大的操作，但这样会牺牲数据的一致性。风险比较大。很多人把NoSQL用做数
据，快是快了，因为数据冗余了，但这对数据一致性有大的风险。这需要根据不同的业
务进行分析和处理。（注意：用关系型数据库很容易移植到NoSQL上，但是反过来从
NoSQL到关系型就难了）
二、数据镜像
几乎所有主流的数据库都支持镜像，也就是replication。数据库的镜像带来的好处就
是可以做负载均衡。把一台数据库的负载均分到多台上，同时又保证了数据一致性（
Oracle的SCN）。最重要的是，这样还可以有高可用性，一台废了，还有另一台在服务。
数据镜像的数据一致性可能是个复杂的问题，所以我们要在单条数据上进行数据分区，
也就是说，把一个畅销商品的库存均分到不同的服务器上，如，一个畅销商品有1万的
库存，我们可以设置10台服务器，每台服务器上有1000个库存，这就好像B2C的仓库一
样。
三、数据分区
数据镜像不能解决的一个问题就是数据表里的记录太多，导致数据库操作太慢。所以，
把数据分区。数据分区有很多种做法，一般来说有下面这几种：
1）把数据把某种逻辑来分类。比如火车票的订票系统可以按各铁路局来分，可按各种
车型分，可以按始发站分，可以按目的地分……，反正就是把一张表拆成多张有一样的
字段但是不同种类的表，这样，这些表就可以存在不同的机器上以达到分担负载的目的。
2）把数据按字段分，也就是竖着分表。比如把一些不经常改的数据放在一个表里，经
常改的数据放在另外多个表里。把一张表变成1对1的关系，这样，你可以减少表的字段
个数，同样可以提升一定的性能。另外，字段多会造成一条记录的存储会被放到不同的
页表里，这对于读写性能都有问题。但这样一来会有很多复杂的控制。
3）平均分表。因为第一种方法是并不一定平均分均，可能某个种类的数据还是很多。
所以，也有采用平均分配的方式，通过主键ID的范围来分表。
4）同一数据分区。这个在上面数据镜像提过。也就是把同一商品的库存值分到不同的
服务器上，比如有10000个库存，可以分到10台服务器上，一台上有1000个库存。然后
负载均衡。
这三种分区都有好有坏。最常用的还是第一种。数据一旦分区，你就需要有一个或是多
个调度来让你的前端程序知道去哪里找数据。把火车票的数据分区，并放在各个省市，
会对12306这个系统有非常有意义的质的性能的提高。
四、后端系统负载均衡
前面说了数据分区，数据分区可以在一定程度上减轻负载，但是无法减轻热销商品的负
载，对于火车票来说，可以认为是大城市的某些主干线上的车票。这就需要使用数据镜
像来减轻负载。使用数据镜像，你必然要使用负载均衡，在后端，我们可能很难使用像
路由器上的负载均衡器，因为那是均衡流量的，因为流量并不代表服务器的繁忙程度。
因此，我们需要一个任务分配系统，其还能监控各个服务器的负载情况。
任务分配服务器有一些难点：
负载情况比较复杂。什么叫忙？是CPU高？还是磁盘I/O高？还是内存使用高？还是
并发高？还是内存换页率高？你可能需要全部都要考虑。这些信息要发送给那个任务分
配器上，由任务分配器挑选一台负载最轻的服务器来处理。
任务分配服务器上需要对任务队列，不能丢任务啊，所以还需要持久化。并且可以
以批量的方式把任务分配给计算服务器。
任务分配服务器死了怎么办？这里需要一些如Live-Standby或是failover等高可用
性的技术。我们还需要注意那些持久化了的任务的队列如何转移到别的服务器上的问题。
我看到有很多系统都用静态的方式来分配，有的用hash，有的就简单地轮流分析。这些
都不够好，一个是不能完美地负载均衡，另一个静态的方法的致命缺陷是，如果有一台
计算服务器死机了，或是我们需要加入新的服务器，对于我们的分配器来说，都需要知
道的。另外，还要重算哈希（一致性hash可以部分解决这个问题）。
还有一种方法是使用抢占式的方式进行负载均衡，由下游的计算服务器去任务服务器上
拿任务。让这些计算服务器自己决定自己是否要任务。这样的好处是可以简化系统的复
杂度，而且还可以任意实时地减少或增加计算服务器。但是唯一不好的就是，如果有一
些任务只能在某种服务器上处理，这可能会引入一些复杂度。不过总体来说，这种方法
可能是比较好的负载均衡。
五、异步、 throttle 和 批量处理
异步、throttle（节流阀） 和批量处理都需要对并发请求数做队列处理的。
异步在业务上一般来说就是收集请求，然后延时处理。在技术上就是可以把各个处
理程序做成并行的，也就可以水平扩展了。但是异步的技术问题大概有这些，a）被调
用方的结果返回，会涉及进程线程间通信的问题。b）如果程序需要回滚，回滚会有点
复杂。c）异步通常都会伴随多线程多进程，并发的控制也相对麻烦一些。d）很多异步
系统都用消息机制，消息的丢失和乱序也会是比较复杂的问题。
throttle 技术其实并不提升性能，这个技术主要是防止系统被超过自己不能处理
的流量给搞垮了，这其实是个保护机制。使用throttle技术一般来说是对于一些自己无
法控制的系统，比如，和你网站对接的银行系统。
批量处理的技术，是把一堆基本相同的请求批量处理。比如，大家同时购买同一个
商品，没有必要你买一个我就写一次数据库，完全可以收集到一定数量的请求，一次操
作。这个技术可以用作很多方面。比如节省网络带宽，我们都知道网络上的MTU（最大
传输单元），以态网是1500字节，光纤可以达到4000多个字节，如果你的一个网络包没
有放满这个MTU，那就是在浪费网络带宽，因为网卡的驱动程序只有一块一块地读效率
才会高。因此，网络发包时，我们需要收集到足够多的信息后再做网络I/O，这也是一
种批量处理的方式。批量处理的敌人是流量低，所以，批量处理的系统一般都会设置上
两个阀值，一个是作业量，另一个是timeout，只要有一个条件满足，就会开始提交处
理。
所以，只要是异步，一般都会有throttle机制，一般都会有队列来排队，有队列，就会
有持久化，而系统一般都会使用批量的方式来处理。
云风同学设计的“排队系统” 就是这个技术。这和电子商务的订单系统很相似，就是
说，我的系统收到了你的购票下单请求，但是我还没有真正处理，我的系统会跟据我自
己的处理能力来throttle住这些大量的请求，并一点一点地处理。一旦处理完成，我就
可以发邮件或短信告诉用户你来可以真正购票了。
在这里，我想通过业务和用户需求方面讨论一下云风同学的这个排队系统，因为其从技
术上看似解决了这个问题，但是从业务和用户需求上来说可能还是有一些值得我们去深
入思考的地方：
1）队列的DoS攻击。首先，我们思考一下，这个队是个单纯地排队的吗？这样做还不够
好，因为这样我们不能杜绝黄牛，而且单纯的ticket_id很容易发生DoS攻击，比如，我
发起N个 ticket_id，进入购票流程后，我不买，我就耗你半个小时，很容易我就可以
让想买票的人几天都买不到票。有人说，用户应该要用身份证来排队， 这样在购买里
就必需要用这个身份证来买，但这也还不能杜绝黄牛排队或是号贩子。因为他们可以注
册N个帐号来排队，但就是不买。黄牛这些人这个时候只需要干一个事，把网站搞得正
常人不能访问，让用户只能通过他们来买。
2）对列的一致性？对这个队列的操作是不是需要锁？只要有锁，性能一定上不去。试
想，100万个人同时要求你来分配位置号，这个队列将会成为性能瓶颈。你一定没有数
据库实现得性能好，所以，可能比现在还差。抢数据库和抢队列本质上是一样的。
3）队列的等待时间。购票时间半小时够不够？多不多？要是那时用户正好不能上网呢
？如果时间短了，用户不够时间操作也会抱怨，如果时间长了，后面在排队的那些人也
会抱怨。这个方法可能在实际操作上会有很多问题。另外，半个小时太长了，这完全不
现实，我们用15分钟来举例：有1千万用户，每一个时刻只能放进去1万个，这1万个用
户需要15分钟完成所有操作，那么，这1千万用户全部处理完，需要1000*15m = 250小
时，10天半，火车早开了。（我并非信口开河，根据铁道部专家的说明：这几天，平均
一天下单100万，所以，处理1000万的用户需要十天。这个计算可能有点简单了，我只
是想说，在这样低负载的系统下用排队可能都不能解决业务问题）
4）队列的分布式。这个排队系统只有一个队列好吗？还不足够好。因为，如果你放进
去的可以购票的人如果在买同一个车次的同样的类型的票（比如某动车卧铺），还是等
于在抢票，也就是说系统的负载还是会有可能集中到其中某台服务器上。因此，最好的
方法是根据用户的需求——提供出发地和目的地，来对用户进行排队。而这样一来，队
列也就可以是多个，只要是多个队列，就可以水平扩展了。这样可以解决性能问题，但
是没有解决用户长时间排队的问题。
我觉得完全可以向网上购物学习。在排队（下单）的时候，收集好用户的信息和想要买
的票，并允许用户设置购票的优先级，比如，A车次卧铺买 不到就买 B车次的卧铺，如
果还买不到就买硬座等等，然后用户把所需的钱先充值好，接下来就是系统完全自动地
异步处理订单。成功不成功都发短信或邮件通知用户。这样，系统不仅可以省去那半个
小时的用户交互时间，自动化加快处理，还可以合并相同购票请求的人，进行批处理（
减少数据库的操作次数）。这种方法最妙的事是可以知道这些排队用户的需求，不但可
以优化用户的队列，把用户分布到不同的队列，还可以像亚马逊的心愿单一样，通过一
些计算就可以让铁道部做车次统筹安排和调整（最后，排队系统（下单系统）还是要保
存在数据库里的或做持久化，不能只放在内存中，不然机器一down，就等着被骂吧）。
小结
写了那么多，我小结一下：
0）无论你怎么设计，你的系统一定要能容易地水平扩展。也就是说，你的整个数据流
中，所有的环节都要能够水平扩展。这样，当你的系统有性能问题时，“加30倍的服务
器”才不会被人讥笑。
1）上述的技术不是一朝一夕能搞定的，没有长期的积累，基本无望。我们可以看到，
无论你用哪种都会引发一些复杂性，设计总是在做一种权衡。
2）集中式的卖票很难搞定，使用上述的技术可以让订票系统能有几佰倍的性能提升。
而在各个省市建分站，分开卖票，是能让现有系统性能有质的提升的最好方法。
3）春运前夕抢票且票量供远小于求这种业务模式是相当变态的，让几千万甚至上亿的
人在某个早晨的8点钟同时登录同时抢票的这种业务模式是变态中的变态。业务形态的
变态决定了无论他们怎么办干一定会被骂。
4）为了那么一两个星期而搞那么大的系统，而其它时间都在闲着，有些可惜了，这也
就是铁路才干得出来这样的事了。
更新2012年9月27日
Alexa 统计的12306的PV （注：Alexa的PV定义是：一个用户在一天内对一个页面的多
次点击只算一次）
（本文转载时请注明作者和出处，请勿于记商业目的）
（转载本站文章请注明作者和出处 酷 壳 – CoolShell.cn ，请勿用于任何商业用途）
====================
注：有个地方要更新一下。文中在比较 12306 和淘宝时提到：
「去年（2011年）双11节，淘宝的每小时的订单数大约在60万左右。」
「淘宝的双十一也就3百万用户，而火车票瞬时有千万级别甚至是亿级别的。」
文中这个数字现在已经不适用。淘宝的容量两年来有了巨大的提升。
2013 年淘宝双11的第一分钟，产生 33.9 万笔交易，有 1370 万人次同时在线。第二
分钟和第三分钟成交笔数分别为 111 万笔和 190 万笔。交易峰值出现在 1 分 27 秒
，1 秒钟内，13637 人同时成功付款。数据来源：双11当天6小时内支付宝交易额突破
百亿_TechWeb 显示全部
查看全部 357 个回答
知乎是一个真实的问答社区，在这里分享知识、经验和见解，发现更大的世界。
使用邮箱注册 »
使用微博登录 使用 QQ 登录
7503 人关注该问题
关于作者 |
O**l
发帖数: 12923 | 2 说这么多都没用
阿里巴巴今年双11的峰值 是一分钟246万个transaction
一秒钟4w多个 这要做不到做cs都可以去跳楼了 |
O**l
发帖数: 12923 | 3 再说一个数字visa一年的均值是一秒3万6个transaction
visa貌似从来没说过自己的技术牛 |
s***d
发帖数: 15421 | 4 你不好好看原文吗？铁道部的订票就是baba做的，ibm oracle sybase都不敢做，订票
不能超卖票，这和transaction不一样，淘宝超卖了可以退钱，这种稀缺车票，你超卖
了人家不敢的。无论怎么说，爸爸也比ibm强不是，ibm的主业可是做企业级别solution
，baba这算是帮忙而已。
【在 O**l 的大作中提到】
: 说这么多都没用
: 阿里巴巴今年双11的峰值 是一分钟246万个transaction
: 一秒钟4w多个 这要做不到做cs都可以去跳楼了
|
s******c
发帖数: 1920 | 5 那里说了淘宝的技术好？
只说了淘宝的transaction藕合度低 很容易scale horizontally 就是堆机器来搞定。
买票网站难做，难在transcation复杂许多。不能直接套用淘宝现成的方案。 |
O**l
发帖数: 12923 | 6 搞笑 你怎么知道别人不敢做 就凭你大嘴一张
牛不牛不就是跟别的系统比较
你的系统峰值也就比别人的均值多10%
【在 s***d 的大作中提到】
: 你不好好看原文吗？铁道部的订票就是baba做的，ibm oracle sybase都不敢做，订票
: 不能超卖票，这和transaction不一样，淘宝超卖了可以退钱，这种稀缺车票，你超卖
: 了人家不敢的。无论怎么说，爸爸也比ibm强不是，ibm的主业可是做企业级别solution
: ，baba这算是帮忙而已。
|
s***d
发帖数: 15421 | 7 但是按照这文章说的，12306后端就是淘宝做的，淘宝后端可以做到秒杀了。
【在 s******c 的大作中提到】
: 那里说了淘宝的技术好？
: 只说了淘宝的transaction藕合度低 很容易scale horizontally 就是堆机器来搞定。
: 买票网站难做，难在transcation复杂许多。不能直接套用淘宝现成的方案。
|
s***d
发帖数: 15421 | 8 不看文章就乱喷。
【在 O**l 的大作中提到】
: 搞笑 你怎么知道别人不敢做 就凭你大嘴一张
: 牛不牛不就是跟别的系统比较
: 你的系统峰值也就比别人的均值多10%
|
s******c
发帖数: 1920 | 9 你绝对不是cs出身的
都是上数据库的话 transcation的atomicity可以保证不会超卖。换句话说 不是难在会
不会超卖，而是你一个事务要锁多少个表
solution
【在 s***d 的大作中提到】
: 你不好好看原文吗？铁道部的订票就是baba做的，ibm oracle sybase都不敢做，订票
: 不能超卖票，这和transaction不一样，淘宝超卖了可以退钱，这种稀缺车票，你超卖
: 了人家不敢的。无论怎么说，爸爸也比ibm强不是，ibm的主业可是做企业级别solution
: ，baba这算是帮忙而已。
|
O**l
发帖数: 12923 | 10 你不就说阿里巴巴有没有技术
我拿阿里巴巴双11峰值和别的系统 做一下比较 没看出任何先进地方
要看文章干什么
【在 s***d 的大作中提到】
: 不看文章就乱喷。
|
|
|
s***v
发帖数: 4924 | 11 知乎的帖子不能太认真的，以前知乎的帖子是7分真实3分忽悠，现在有倒置的倾向，基
本上趋近3分真实7分忽悠了。
哥们你看好或者不看好baba都没问题，但是千万不要参考知乎这一类小资+二逼的网站
的帖子。
PS，我上知乎都是看美女秀脸秀胸秀腿的。 |
T*R
发帖数: 36302 | 12 炒股不要对公司产生感情。
这种公司，做一次就行了，如果过几年价格降到白菜，可以重新做一次。 |
s***d
发帖数: 15421 | 13 我只是单纯的比较一下 ibm oracle baba哪家更强。至于baba有没有fb googl 厉害没
关系，只要比度娘，企鹅 IBM oracle厉害就好。google fb在中国至少是邪恶企业，中
国市场noway。
【在 s***v 的大作中提到】
: 知乎的帖子不能太认真的，以前知乎的帖子是7分真实3分忽悠，现在有倒置的倾向，基
: 本上趋近3分真实7分忽悠了。
: 哥们你看好或者不看好baba都没问题，但是千万不要参考知乎这一类小资+二逼的网站
: 的帖子。
: PS，我上知乎都是看美女秀脸秀胸秀腿的。
|
s***d
发帖数: 15421 | 14 我当然没感情，否则我120卖call跑啥啊。一大半都是unh了。
【在 T*R 的大作中提到】
: 炒股不要对公司产生感情。
: 这种公司，做一次就行了，如果过几年价格降到白菜，可以重新做一次。
|
T*R
发帖数: 36302 | 15 真要是爱一个公司，想长期拥有，最重要的条件就是它得分红。
没有分红的都是忽悠。 |
s***d
发帖数: 15421 | 16 我从来没说自己是cs的。对就是所表，因为车票不想飞机票，有些人只做1站就下车了
。位置就要锁住，这级别的买票系统，这人流量，不是盖的。
【在 s******c 的大作中提到】
: 你绝对不是cs出身的
: 都是上数据库的话 transcation的atomicity可以保证不会超卖。换句话说 不是难在会
: 不会超卖，而是你一个事务要锁多少个表
:
: solution
|
T*R
发帖数: 36302 | 17 你又不是裸卖。
【在 s***d 的大作中提到】
: 我当然没感情，否则我120卖call跑啥啊。一大半都是unh了。
|
s***d
发帖数: 15421 | 18 分红不代表任何。
【在 T*R 的大作中提到】
: 真要是爱一个公司，想长期拥有，最重要的条件就是它得分红。
: 没有分红的都是忽悠。
|
T*R
发帖数: 36302 | 19 分红代表了一切。
可以忽悠一时，不能忽悠一世。
长时间看，还是分红最有说服力。
至于所谓成长，不过是炒短线的借口，小心不要炒成股东就好。
【在 s***d 的大作中提到】
: 分红不代表任何。
|
S*******n
发帖数: 10009 | 20 中国的这种杂文看看就行，堆多些机器就好了，又不用超级中心电脑。
【在 s***d 的大作中提到】
: 12306首秀被骂的狗血喷头后铁道部找来IBM、阿里巴巴等大企业要解决方案，给出的条
: 件是资金管够但是问题得解决。几大企业最后都拒绝了（其中阿里巴巴最后负责了排队
: 系统的建设）。12306开始自己尝试解决问题。他们发现市面上可以买到的成套解决方
: 案都不足以应付春运购票负载，所以只能自己改进已有的数据库（注：其实是改用
: VMware SQLFire/GemFire，这里我之前理解错误）。以前12306用的是小型机，发现性
: 能严重不足，遂改用x86系统+linux平台（原平台为HP Superdome小型机，UNIX系统，
: Sybase ASE数据库）。最后他们的核心系统用了十几个节点（现在应该是17节点）的多
: 路Xeon E7（具体几路待考），每个节点配1TB内存，数据库全部在内存中运行。2013年
: 春运，12306系统峰值负载11万tps，与2012年淘宝双11活动峰值负载相当，新的系统基
: 本经受住了考验。
|
s******c
发帖数: 1920 | 21 如果是和b t 比起来，a是有技术含量的
他们有几个开源的东西 做的都像模像样的
a家从当家的开始，泥腿子草根出身的多，反而能扎实做点儿事。b和t都是高帅富办的
，你懂的
【在 s***d 的大作中提到】
: 我只是单纯的比较一下 ibm oracle baba哪家更强。至于baba有没有fb googl 厉害没
: 关系，只要比度娘，企鹅 IBM oracle厉害就好。google fb在中国至少是邪恶企业，中
: 国市场noway。
|
