高手详解12306 IT架构与困境(转载) - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Programming - 葵花宝典

高手详解12306 IT架构与困境(转载)

高手详解12306 IT架构与困境(转载)# Programming - 葵花宝典

G*s2014-02-09 08:02

1 楼

我本来在A州工作，但下个月要随老公一起relocate到B州去，我们公司同意我在B州
remotely work from home. 这样我工作的公司没有变，但是我工作的地点变了，这样
需要重新申请H1B吗？还是说完全无所谓？
另外我刚递了140，那么我是不是需要file什么表格去通知移民局我的status变了呢？
多谢！

g*l2014-02-09 08:02

2 楼

PERIOD

o*32014-02-09 08:02

3 楼

Game & 3D Animation, thx!

b*n2014-02-09 08:02

4 楼

c*32014-02-09 08:02

5 楼

http://server.chinabyte.com/333/12831833.shtml
自从12306购票系统上线以来，春运期间的崩溃、卡死、页面无响应就伴随着12306的成
长。当然，随之而来的便是普通百姓的一片嘘声和所有IT媒体对铁道部IT架构的各种质
疑。之后，各种技术大牛和媒体都开始质问12306，为什么不用IBM的解决方案？为什么
不找阿里巴巴来做？为什么不增加服务器和网络带宽？
面对几乎一边倒的口诛笔伐，知乎上一位名叫王强的网友在日前给出了自己的分析
答案。去掉其中的吐槽部分，分析结果如下：
12306IT系统：
12306以前的IT系统主要采用Superdome小型机(具体型号不详)+HP-UX+Sybase ASE
数据库。但在发现性能不足之后全部改为x86+Linux平台，基本配置为(大约)17台多路
至强E7服务器(具体路数不详)，每节点1TB内存，而数据库则应该还是Sybase ASE(只不
过数据库全部放在内存中运行，想要换数据库难度太高，停机时间太长)。
12306系统在2013年春运中的峰值负载约为11万TPS，新的系统在2013年虽然时有崩
溃，但都能在短时间内恢复，而这也说明新系统基本抗住了2013年的春运压力。11万
TPS的水平与2012年淘宝双11时水平相当。
12306痛点分析：
从12306在2013年春运高峰时每日放票400万张的水平来看，12306虽然在总量上不
及13年淘宝双11的水平，但因为12306放票主要集中在10个放票时段，而余票在每个时
段刚开始的3分钟内就能够基本售罄，所以12306所承受的压力基本可简化为30分钟内承
受300多万的放票，当然，还要有更多的刷新和查询请求。如果以这个标准来衡量，
12306所面临的压力堪称全球最大。
另外，12306的每一次出票都会对原有数据库进行更新，交易关联度更大。而淘宝
双11的交易则分散在了众多商家中，虽然每次交易也会对数据库进行更新，但其密集程
度和关联程度仍不及12306.
为什么不用IBM或者Oracle系统？
这是个尖锐的问题，抛去信息安全和贸易保护的因素不谈，王强给出的答案是IBM
Power系统无法与12306现有的系统做到灵活扩展，升级也无法做到不停机。另一方面，
IBM Power解决方案在金融方面表现突出，但针对12306这种典型的票务系统，优势则并
不明显。当然，价格因素也必须考虑在内(以经验来看，通常小型机及其他核心系统每
年的维护费用约为整套系统采购价格的20-30%，甚至更高)。而Oracle的解决方案也有
着类似的问题。
王强表示，实际上12306在之前就已经接触过包括IBM和Oracle在内众多全球顶级IT
解决方案提供商。但这些提供商纷纷以各种理由拒绝了合作(也包括其解决方案在灵活
性、扩展性等方面不符合12306需求的情况)。
为什么不让阿里巴巴来做？
作为国内IT应用水平最高的公司之一，12306当然也不会忘记向阿里巴巴取经。王
强在文章中表示，阿里巴巴团队实际上已经参与到了12306系统的建设中来，并且帮助
12306构建了其排队系统，这一系统对于帮助12306系统免于彻底崩溃起着巨大作用(免
于崩溃指的是系统后端的数据库等核心系统，而对于前端的卡死和崩溃原因目前仍没有
确切的定论)。当然，由于两种应用本身的区别性很大，阿里巴巴团队也没能在更大的
层面上帮助12306。
怎么拯救12306？
王强在文中并没有直接给出这个最核心问题的答案，不过从以上的分析来看，
12306系统的主要问题集中在单个处理节点的处理能力以及系统总线的峰值吞吐量上。
而12306已经将数据库放在了内存上，而每个节点的内存容量达到了1TB的量级，从目前
的情况来看，这已经是目前IT的最高水平，短期内再无其他办法(12306采用了Pivotal
的GemFire分布式内存数据平台，该平台虽然宣称可以通过增加服务器规模线型提升性
能，但从实际的情况来看17台多路E7应该就是其性能上线了)。
客观来讲，王强所给出的分析还是非常理性的，而就目前整个业界的IT水平来讲，
12306确实已经站在了最前沿，虽然其效果仍不够理想，但其努力仍然是值得肯定的。
相信随着单个处理器性能的增强，内存总线带宽的增加，数据中心网络带宽的增加以及
延迟的降低，12306的表现会越来越好，当然，这个过程可能会比我们所期望的要漫长
很多.

m*p2014-02-09 08:02

6 楼

paycheck上payroll地址不是没变么？

【在 G******s 的大作中提到】

: 我本来在A州工作，但下个月要随老公一起relocate到B州去，我们公司同意我在B州
: remotely work from home. 这样我工作的公司没有变，但是我工作的地点变了，这样
: 需要重新申请H1B吗？还是说完全无所谓？
: 另外我刚递了140，那么我是不是需要file什么表格去通知移民局我的status变了呢？
: 多谢！

d*a2014-02-09 08:02

7 楼

俺乱评论一下。
1. 用HP Superdome是一大失误。Superdome用的是Itanium处理器。Itanium处理器在设
计时有很好的想法，但实现出来后，和预期相差很远。
而且这种处理器适合科学计算，不适合commercial workload。
2. 如果用IBM Power系列服务器，我觉得系统后端的数据库等核心系统
不会出问题。IBM有一款服务器（“单机”），最多支持1024路线程，最大
16TB内存。这种集中处理方式，对12306这样的数据库应用来说，比分布
式系统在各方面，包括性能，可靠性，易维护性，都要好得多。但这款服务
器很贵，配足了据说是五百万美元。
3. 我觉得系统功能划分可能也有问题，可能数据库系统实现的功能过多。
如果是这样，把一些不适合数据库实现的功能从数据库系统划分出去，
能大大提高整个系统的效率。

b*s2014-02-09 08:02

8 楼

传统关系数据库是个笨拙的东西，所以这两年nosql越来越流行就是一种反动
慢慢的也应该除非必须，否则尽量避免传统数据库

【在 d***a 的大作中提到】

: 俺乱评论一下。
: 1. 用HP Superdome是一大失误。Superdome用的是Itanium处理器。Itanium处理器在设
: 计时有很好的想法，但实现出来后，和预期相差很远。
: 而且这种处理器适合科学计算，不适合commercial workload。
: 2. 如果用IBM Power系列服务器，我觉得系统后端的数据库等核心系统
: 不会出问题。IBM有一款服务器（“单机”），最多支持1024路线程，最大
: 16TB内存。这种集中处理方式，对12306这样的数据库应用来说，比分布
: 式系统在各方面，包括性能，可靠性，易维护性，都要好得多。但这款服务
: 器很贵，配足了据说是五百万美元。
: 3. 我觉得系统功能划分可能也有问题，可能数据库系统实现的功能过多。

h*c2014-02-09 08:02

9 楼

没把所有的包听下来，以后模拟用。
17台机器，哪个老板出点钱，找个地方弄几个机器模拟一下

g*t2014-02-09 08:02

10 楼

这就是传说中的洗地文吧？
铁路是半军事单位，不可能用IBM,Oracle的。

ASE

【在 c******3 的大作中提到】

: http://server.chinabyte.com/333/12831833.shtml
: 自从12306购票系统上线以来，春运期间的崩溃、卡死、页面无响应就伴随着12306的成
: 长。当然，随之而来的便是普通百姓的一片嘘声和所有IT媒体对铁道部IT架构的各种质
: 疑。之后，各种技术大牛和媒体都开始质问12306，为什么不用IBM的解决方案？为什么
: 不找阿里巴巴来做？为什么不增加服务器和网络带宽？
: 面对几乎一边倒的口诛笔伐，知乎上一位名叫王强的网友在日前给出了自己的分析
: 答案。去掉其中的吐槽部分，分析结果如下：
: 12306IT系统：
: 12306以前的IT系统主要采用Superdome小型机(具体型号不详)+HP-UX+Sybase ASE
: 数据库。但在发现性能不足之后全部改为x86+Linux平台，基本配置为(大约)17台多路

z*e2014-02-09 08:02

11 楼

民航都能用
你说呢？

【在 g****t 的大作中提到】

: 这就是传说中的洗地文吧？
: 铁路是半军事单位，不可能用IBM,Oracle的。
:
: ASE

g*t2014-02-09 08:02

12 楼

民航购票系统是谁做的？哪年做的。你给个link,我去看看。
我不是说的机器。说的是solution.

民航都能用
你说呢？

【在 z****e 的大作中提到】

: 民航都能用
: 你说呢？

d*a2014-02-09 08:02

13 楼

nosql适合big data这样的应用
但它没有完整的ACID事务处理支持，不能用在12306这种应用上
我的看法是，12306的后端其实是最传统的数据库应用
相对big data而言，12306的数据库一点都不大，和big data扯不上关系
其实我并不觉得它一定要用IBM Power服务器
按理说，要是把软件系统的框架和核心做好了，各个子系统划分清晰
以它那个不大的规模（真的不算大），x86服务器应该足够了
当然，这么重大的应用，保守一点上IBM Power服务器也是值得的

【在 b*******s 的大作中提到】

: 传统关系数据库是个笨拙的东西，所以这两年nosql越来越流行就是一种反动
: 慢慢的也应该除非必须，否则尽量避免传统数据库

g*t2014-02-09 08:02

14 楼

12306数据不多。主要是数据并发规模大，耦合复杂。
其实解决耦合最重要的是需求分析,不是具体的技术。
先要问清楚以前实践中人工卖票怎么
trade off的。不懂这一条的，显然都是没有领导过项目的。
需求本身也是个逻辑系统。弄好一致性，完备性等等也是个技术活。
复杂点的需求，可能要从原子公理或者字典做起。

nosql适合big data这样的应用
但它没有完整的ACID事务处理支持，不能用在12306这种应用上
我的看法是，12306的后端其实是最传统的数据库应用
相对big data而言，12306的数据库一点都不大，和big data扯不上关系
其实我并不觉得它一定要用IBM Power服务器
按理说，要是把软件系统的框架和核心做好了，各个子系统划分清晰
以它那个不大的规模（真的不算大），x86服务器应该足够了
当然，这么重大的应用，保守一点上IBM Power服务器也是值得的

【在 d***a 的大作中提到】

: nosql适合big data这样的应用
: 但它没有完整的ACID事务处理支持，不能用在12306这种应用上
: 我的看法是，12306的后端其实是最传统的数据库应用
: 相对big data而言，12306的数据库一点都不大，和big data扯不上关系
: 其实我并不觉得它一定要用IBM Power服务器
: 按理说，要是把软件系统的框架和核心做好了，各个子系统划分清晰
: 以它那个不大的规模（真的不算大），x86服务器应该足够了
: 当然，这么重大的应用，保守一点上IBM Power服务器也是值得的

z*e2014-02-09 08:02

15 楼

怎么给你link阿？
谁没事把自己公司用什么都放网络上？
民航的系统用美帝公司的产品多了

【在 g****t 的大作中提到】

: 民航购票系统是谁做的？哪年做的。你给个link,我去看看。
: 我不是说的机器。说的是solution.
:
: 民航都能用
: 你说呢？

g*t2014-02-09 08:02

16 楼

我这儿说的是铁道部的这个solution不可能用 IBM,etc
你举个民航的例子，又拿不出根据。
用的美帝产品多，不等于用了solution.
你用个美帝的显示器也是用。但这不是胡扯么。

怎么给你link阿？
谁没事把自己公司用什么都放网络上？
民航的系统用美帝公司的产品多了

【在 z****e 的大作中提到】

: 怎么给你link阿？
: 谁没事把自己公司用什么都放网络上？
: 民航的系统用美帝公司的产品多了

e*o2014-02-09 08:02

17 楼

这个是我见过最靠谱的分析了。
12306只能铁道部自己解决，
或者他们提要求，承包商尽量满足要求，而不是承包商说服铁道部改变需求。
只有他们知道针对中国国情怎么卖票最好。

12306数据不多。主要是数据并发规模大，耦合复杂。
其实解决耦合最重要的是需求分析,不是具体的技术。
先要问清楚以前实践中人工卖票怎么
trade off的。不懂这一条的，显然都是没有领导过项目的。
需求本身也是个逻辑系统。弄好一致性，完备性等等也是个技术活。
复杂点的需求，可能要从原子公理或者字典做起。
nosql适合big data这样的应用
但它没有完整的ACID事务处理支持，不能用在12306这种应用上
我的看法是，12306的后端其实是最传统的数据库应用
相对big data而言，12306的数据库一点都不大，和big data扯不上关系
其实我并不觉得它一定要用IBM Power服务器
按理说，要是把软件系统的框架和核心做好了，各个子系统划分清晰
以它那个不大的规模（真的不算大），x86服务器应该足够了
当然，这么重大的应用，保守一点上IBM Power服务器也是值得的

【在 g****t 的大作中提到】

: 12306数据不多。主要是数据并发规模大，耦合复杂。
: 其实解决耦合最重要的是需求分析,不是具体的技术。
: 先要问清楚以前实践中人工卖票怎么
: trade off的。不懂这一条的，显然都是没有领导过项目的。
: 需求本身也是个逻辑系统。弄好一致性，完备性等等也是个技术活。
: 复杂点的需求，可能要从原子公理或者字典做起。
:
: nosql适合big data这样的应用
: 但它没有完整的ACID事务处理支持，不能用在12306这种应用上
: 我的看法是，12306的后端其实是最传统的数据库应用

d*a2014-02-09 08:02

18 楼

这正是为什么要用集中式数据库来处理
需求分析与架构，大概是设计这种系统的最重要的两个环节
我不知道需要分析做得如何，但那个架构，给我的感觉不好

【在 g****t 的大作中提到】

g*t2014-02-09 08:02

19 楼

来这儿的多数都是技术单一很狭窄方向的。
我没看出来这里有任何一个人，领导过一个大公司的主要产品从
idea,到实现，到销售，到产生现金流走起来的过程。
所以他们的讨论有知识内容。但讨论越多就偏的越离谱。

这个是我见过最靠谱的分析了。
12306只能铁道部自己解决，
或者他们提要求，承包商尽量满足要求，而不是承包商说服铁道部改变需求。
只有他们知道针对中国国情怎么卖票最好。
12306数据不多。主要是数据并发规模大，耦合复杂。
其实解决耦合最重要的是需求分析,不是具体的技术。
先要问清楚以前实践中人工卖票怎么
trade off的。不懂这一条的，显然都是没有领导过项目的。
需求本身也是个逻辑系统。弄好一致性，完备性等等也是个技术活。
复杂点的需求，可能要从原子公理或者字典做起。
nosql适合big data这样的应用
但它没有完整的ACID事务处理支持，不能用在12306这种应用上
我的看法是，12306的后端其实是最传统的数据库应用
相对big data而言，12306的数据库一点都不大，和big data扯不上关系
其实我并不觉得它一定要用IBM Power服务器
按理说，要是把软件系统的框架和核心做好了，各个子系统划分清晰
以它那个不大的规模（真的不算大），x86服务器应该足够了
当然，这么重大的应用，保守一点上IBM Power服务器也是值得的

【在 e**o 的大作中提到】

: 这个是我见过最靠谱的分析了。
: 12306只能铁道部自己解决，
: 或者他们提要求，承包商尽量满足要求，而不是承包商说服铁道部改变需求。
: 只有他们知道针对中国国情怎么卖票最好。
:
: 12306数据不多。主要是数据并发规模大，耦合复杂。
: 其实解决耦合最重要的是需求分析,不是具体的技术。
: 先要问清楚以前实践中人工卖票怎么
: trade off的。不懂这一条的，显然都是没有领导过项目的。
: 需求本身也是个逻辑系统。弄好一致性，完备性等等也是个技术活。

g*t2014-02-09 08:02

20 楼

这玩意儿不能拍脑袋的。
好虫方案看上去延伸性好些，但我确实也觉得强耦合那部分很不舒服。

【在 d***a 的大作中提到】

: 这正是为什么要用集中式数据库来处理
: 需求分析与架构，大概是设计这种系统的最重要的两个环节
: 我不知道需要分析做得如何，但那个架构，给我的感觉不好

z*e2014-02-09 08:02

21 楼

问题在于我怎么给你呢？
这种东西显然不会放到网络上
你要不信，我只能说，你赢了

【在 g****t 的大作中提到】

: 我这儿说的是铁道部的这个solution不可能用 IBM,etc
: 你举个民航的例子，又拿不出根据。
: 用的美帝产品多，不等于用了solution.
: 你用个美帝的显示器也是用。但这不是胡扯么。
:
: 怎么给你link阿？
: 谁没事把自己公司用什么都放网络上？
: 民航的系统用美帝公司的产品多了

z*e2014-02-09 08:02

22 楼

那就贵了呀
铁道部LEGACY DB是SYBASE做的

【在 d***a 的大作中提到】

g*t2014-02-09 08:02

23 楼

网上讨论自然是从网上来去。
你拿不出来，就不要发言。

问题在于我怎么给你呢？
这种东西显然不会放到网络上
你要不信，我只能说，你赢了

【在 z****e 的大作中提到】

: 问题在于我怎么给你呢？
: 这种东西显然不会放到网络上
: 你要不信，我只能说，你赢了

e*o2014-02-09 08:02

24 楼

我的感觉是他们总想用技术和计算机解决一切问题。
包括策略，决策，政治，政策问题都要用计算机和程序解决。

【在 g****t 的大作中提到】

: 来这儿的多数都是技术单一很狭窄方向的。
: 我没看出来这里有任何一个人，领导过一个大公司的主要产品从
: idea,到实现，到销售，到产生现金流走起来的过程。
: 所以他们的讨论有知识内容。但讨论越多就偏的越离谱。
:
: 这个是我见过最靠谱的分析了。
: 12306只能铁道部自己解决，
: 或者他们提要求，承包商尽量满足要求，而不是承包商说服铁道部改变需求。
: 只有他们知道针对中国国情怎么卖票最好。
: 12306数据不多。主要是数据并发规模大，耦合复杂。

g*t2014-02-09 08:02

25 楼

钱压根不是大问题。这种系统属于基础设施。可靠安全肯定会第一位。

那就贵了呀
铁道部LEGACY DB是SYBASE做的

【在 z****e 的大作中提到】

: 那就贵了呀
: 铁道部LEGACY DB是SYBASE做的

z*e2014-02-09 08:02

26 楼

所以说，你赢了

【在 g****t 的大作中提到】

: 网上讨论自然是从网上来去。
: 你拿不出来，就不要发言。
:
: 问题在于我怎么给你呢？
: 这种东西显然不会放到网络上
: 你要不信，我只能说，你赢了

z*e2014-02-09 08:02

27 楼

翻番三个月前的贴
多少人说这不是一个技术问题

【在 e**o 的大作中提到】

: 我的感觉是他们总想用技术和计算机解决一切问题。
: 包括策略，决策，政治，政策问题都要用计算机和程序解决。

z*e2014-02-09 08:02

28 楼

铁道部觉得是问题啊
ibm当时就参与了竞标
铁道部嫌贵
安全的话，怎样都不会比外包更不安全把？
间谍要是想搞，一个外包公司能保密什么？
12306是外包作的，跟obamacare一样

【在 g****t 的大作中提到】

: 钱压根不是大问题。这种系统属于基础设施。可靠安全肯定会第一位。
:
: 那就贵了呀
: 铁道部LEGACY DB是SYBASE做的

d*a2014-02-09 08:02

29 楼

这种说法是有问题的
这样大的系统，极少可能用户要什么就给什么
用户提出的需求，很多时候不make sense
往往要反复商量和妥协，才能达成协议
铁道部用自己的人来做系统，一个很大的问题就是
自己的人可能不敢和领导对着干，不该答应的事情就答应了
俺年轻的时候做过数据库系统的需求分析
说实话，比设计架构和编程繁琐得多
如果铁道部担心包给外商有安全性问题，有另一种办法
可以委托外面的公司来做需求分析（自己的人参与）
再交给自己的人来做

【在 e**o 的大作中提到】

: 我的感觉是他们总想用技术和计算机解决一切问题。
: 包括策略，决策，政治，政策问题都要用计算机和程序解决。

b*g2014-02-09 08:02

30 楼

他们很明显面临没法再scale up的困境。数据库性能做到头了。所以我说的缓冲订单才
是王道。几分钟延迟可比网站没响应强多了。
“但因为12306放票主要集中在10个放票时段，而余票在每个时
段刚开始的3分钟内就能够基本售罄”
就这两句话，足以证明，前面弄个收单系统缓冲，沿用现有的出票系统，就可以做到我
说得延迟不超过3分钟。
网站能正常运行。

g*t2014-02-09 08:02

31 楼

一遍肯定不行。需求和实现多次迭代的方法论多年前就有了。拿我当年亲历的来说。把
几百人拉到带
宾馆别墅游乐场的一个度假村，各科室人员和IT公司人员分组。业务精英人员讲业务，
IT人
员写文档和各种图表。领导天天吃喝嫖赌。然后实现一个假系统。然后上负载。然后找
出问题就再来一遍。

【在 d***a 的大作中提到】

:
: 这种说法是有问题的
: 这样大的系统，极少可能用户要什么就给什么
: 用户提出的需求，很多时候不make sense
: 往往要反复商量和妥协，才能达成协议
: 铁道部用自己的人来做系统，一个很大的问题就是
: 自己的人可能不敢和领导对着干，不该答应的事情就答应了
: 俺年轻的时候做过数据库系统的需求分析
: 说实话，比设计架构和编程繁琐得多
: 如果铁道部担心包给外商有安全性问题，有另一种办法

g*t2014-02-09 08:02

32 楼

缓冲订单就做不到有票就必须出了吧？
这和你列的需求不一致了。

【在 b*******g 的大作中提到】

: 他们很明显面临没法再scale up的困境。数据库性能做到头了。所以我说的缓冲订单才
: 是王道。几分钟延迟可比网站没响应强多了。
: “但因为12306放票主要集中在10个放票时段，而余票在每个时
: 段刚开始的3分钟内就能够基本售罄”
: 就这两句话，足以证明，前面弄个收单系统缓冲，沿用现有的出票系统，就可以做到我
: 说得延迟不超过3分钟。
: 网站能正常运行。

d*a2014-02-09 08:02

33 楼

呵呵...其实也是很好玩的事情。我当时做的项目人数比你说的少得多，
但吃吃喝喝玩玩也是少不了的。
现在想想，当时按那个路子做下去，现在在帝都也该有好几套房了。:)

【在 g****t 的大作中提到】

: 一遍肯定不行。需求和实现多次迭代的方法论多年前就有了。拿我当年亲历的来说。把
: 几百人拉到带
: 宾馆别墅游乐场的一个度假村，各科室人员和IT公司人员分组。业务精英人员讲业务，
: IT人
: 员写文档和各种图表。领导天天吃喝嫖赌。然后实现一个假系统。然后上负载。然后找
: 出问题就再来一遍。

b*g2014-02-09 08:02

34 楼

这跟有票必须出有什么矛盾？

【在 g****t 的大作中提到】

: 缓冲订单就做不到有票就必须出了吧？
: 这和你列的需求不一致了。

e*o2014-02-09 08:02

35 楼

一般只有一个需求就是降低成本。
你总不能说客户用算盘，纸，笔都能实现的业务到你这里不make sense吧？
难为计算机和程序了吧？

【在 d***a 的大作中提到】

: 呵呵...其实也是很好玩的事情。我当时做的项目人数比你说的少得多，
: 但吃吃喝喝玩玩也是少不了的。
: 现在想想，当时按那个路子做下去，现在在帝都也该有好几套房了。:)

d*a2014-02-09 08:02

36 楼

老兄，你以为这是山寨啊？
对大公司来说，用在IT上的钱是公司运营cost中比较小的一部分
他们往往在系统上愿意花钱，要的是千万别出问题

【在 e**o 的大作中提到】

: 一般只有一个需求就是降低成本。
: 你总不能说客户用算盘，纸，笔都能实现的业务到你这里不make sense吧？
: 难为计算机和程序了吧？

f*52014-02-09 08:02

37 楼

洗地文是知乎上另一篇文章，主要为了讲做这个系统如何难。这篇讲了性能是靠
gemfire的内存pool来改善的。其实类似构架在一年前4399的caoz就提出了。

【在 g****t 的大作中提到】

: 这就是传说中的洗地文吧？
: 铁路是半军事单位，不可能用IBM,Oracle的。
:
: ASE

c*32014-02-09 08:02

38 楼

“3分钟内就能够基本售罄，所以12306所承受的压力基本可简化为30分钟内承受300多
万的放票”
12306后端集中式机器出票速度是167K/s.
“前端的卡死和崩溃原因目前仍没有确切的定论”
这句话可能有俩个意思：
1。前端没问题，有多少收多少。300多万的出票请求加上更多的刷新和查询请求都能放
进来，但后端出票速度还不够快，所以客户端卡死没响应了。
2。后端没问题，167K/s的出票速度轻松秒杀前端过来的任何请求，但前端挤暴了，300
多万的出票请求加上更多的刷新和查询请求都挤在那里，很多都送不到后端，所以客户
端卡死没响应了。