m******t
发帖数: 635 | 1 http://www.zhihu.com/question/22451397
水木上也在讨论
http://www.newsmth.net/nForum/#!article/ITExpress/1385553
这里是硬件配置：
以前12306用的是小型机，发现性能严重不足，遂改用x86系统+linux平台（原平台为HP
Superdome小型机，UNIX系统，Sybase ASE数据库）。最后他们的核心系统用了十几个
节点（现在应该是17节点）的多路Xeon E7（具体几路待考），每个节点配1TB内存，数
据库全部在内存中运行。2013年春运，12306系统峰值负载11万tps，与2012年淘宝双11
活动峰值负载相当，新的系统基本经受住了考验。
我这么感觉这个就是魏老师的cluster加强版啊 |
m*******l
发帖数: 12782 | 2 是的,特别是内存数据库
HP
11
【在 m******t 的大作中提到】
: http://www.zhihu.com/question/22451397
: 水木上也在讨论
: http://www.newsmth.net/nForum/#!article/ITExpress/1385553
: 这里是硬件配置：
: 以前12306用的是小型机，发现性能严重不足，遂改用x86系统+linux平台（原平台为HP
: Superdome小型机，UNIX系统，Sybase ASE数据库）。最后他们的核心系统用了十几个
: 节点（现在应该是17节点）的多路Xeon E7（具体几路待考），每个节点配1TB内存，数
: 据库全部在内存中运行。2013年春运，12306系统峰值负载11万tps，与2012年淘宝双11
: 活动峰值负载相当，新的系统基本经受住了考验。
: 我这么感觉这个就是魏老师的cluster加强版啊
|
m*******l
发帖数: 12782 | 3 这个是古的吧反对的好像
【在 m*******l 的大作中提到】
: 是的,特别是内存数据库
:
: HP
: 11
|
b*******s
发帖数: 5216 | 4 这个是内存数据库系统，魏老师的严格来说只是个内存里的数据结构
从效率来看，魏老师来做不需要17节点
HP
11
【在 m******t 的大作中提到】
: http://www.zhihu.com/question/22451397
: 水木上也在讨论
: http://www.newsmth.net/nForum/#!article/ITExpress/1385553
: 这里是硬件配置：
: 以前12306用的是小型机，发现性能严重不足，遂改用x86系统+linux平台（原平台为HP
: Superdome小型机，UNIX系统，Sybase ASE数据库）。最后他们的核心系统用了十几个
: 节点（现在应该是17节点）的多路Xeon E7（具体几路待考），每个节点配1TB内存，数
: 据库全部在内存中运行。2013年春运，12306系统峰值负载11万tps，与2012年淘宝双11
: 活动峰值负载相当，新的系统基本经受住了考验。
: 我这么感觉这个就是魏老师的cluster加强版啊
|
n****1
发帖数: 1136 | 5 我一直就认为这种情况用内存数据库没啥大不了的, 但魏老师把话说太死, 把事做太绝
了,没有给自己留任何余地. 80GB的全工网卡都说得出来,自然漏洞一大堆.
17个节点很好了, 莫非为了追求单机极限, 任凭CPU跑到起火吗? |
b*******s
发帖数: 5216 | 6 他只是从他的行业背景提出了可行性分析
【在 n****1 的大作中提到】
: 我一直就认为这种情况用内存数据库没啥大不了的, 但魏老师把话说太死, 把事做太绝
: 了,没有给自己留任何余地. 80GB的全工网卡都说得出来,自然漏洞一大堆.
: 17个节点很好了, 莫非为了追求单机极限, 任凭CPU跑到起火吗?
|
g*****g
发帖数: 34805 | 7 12306离high availability还差很远。
http://finance.people.com.cn/n/2014/0108/c1004-24054118.html
原标题：12306网站为啥“逢节就瘫”？
新华社电 春运开始购票以来，12306网站的间歇性“瘫痪病”发作了三四次，遭到
与购票网站“搏斗”多日网友抱怨：“‘逢节就瘫’何时了！”
http://www.25pp.com/news/news_55667.html
回家无望 12306崩溃提交订单立马死机
更新日期：2014年01月06日 关键字：资讯 12306 互联网 作者：佚名 1条评论
12306崩溃了！最近，有不少网友反应在12306订票过程碰到的问题很多，比如眼睁
睁的看到有票状态而无法购买，好不容易能够购票，却又在提交订单显示不成功，不仅
网速奇慢，连12306客服电话也打不通。虽然12306崩溃，但也各位订票的用户也整得快
要崩溃掉了。
http://news.xinhuanet.com/local/2014-01/08/c_118870898.htm
话务员常挨骂压力大 12306客服中心专设“发泄区” |
g*****g
发帖数: 34805 | 8 我以前提到过，不管你怎么弄，最核心的部分就是要把订票和出票完全分开。相当于
waiting list。这样订票可以linear scale out，出票量小很多，有很多方案可以解决
。事实上大量新闻也证明问题也一直出在订票环节上。
现有的方案把订票出票耦合，有票才能订票，订票即出票。一到高峰就挂。这跟魏老师
方案是错误的架构，内存数据库什么的都是不得已的做法，而且还不能解决问题。
铁道部难道买不起更多的服务器吗？这么个应用只有17台服务器，只能说明架构错了，
不好scale out。你要是把淘宝挂在17台服务器上，到光棍节也挂。 |
g*****g
发帖数: 34805 | 9 Hoho，作为老鸟，我看个症状就知道原因。说了他们不是买不起机器，是架构不对，果
然。
http://www.zhihu.com/question/22451397
另外，关于第三方合作对方给出的信息是IBM、Oracle、Sybase全部不能满足要求，主
要是这些厂商的方案部署以后，要升级时不能做到不停机灵活扩展。也就是说，IBM没
有做到是他们技术不足“搞不定”。阿里巴巴参与了改造，负责了排队系统。此外，虽
然后端经受住了压力，前端却如大家所看到的那样还是频频卡死。到底卡死的原因是前
端水平太低还是访问压力太大，暂时没有可靠的信息供判断。
淘宝的问题是其系统架构是分散度较高的，各个订单之间关联度不大；而12306每出一
张票都要对全线路做数据更新（因为一条线路存在多个站点），因此系统负载相较淘宝
来说集中很多，直接搬淘宝的方案也无法解决问题。淘宝的应用类型决定了阿里巴巴可
以通过部署大量的服务器来分散压力，但12306就不行。其实他们的核心系统的硬件成
本不过数百万，不是他们不想采购更多服务器，而是买更多的服务器也没什么用途。最
后，在经过软件层面的优化之后，12306的瓶颈其实是核心节点的CPU、内存性能。但是
这个性能的提升不是朝夕的事情，而是受限于摩尔定律，基本上每两年才能翻一倍多些
。（这段话是我自己的分析，不过现在12306的后端数据库系统应付现有需求已经够用
了） |
g*****g
发帖数: 34805 | 10 国内也不是没有懂架构的。预约服务才是王道。
http://stock.gucheng.com/201401/2625749.shtml
对于服务器无响应的现象，奇虎360公司技术团队相关负责人张勇建议，提供2个开放接
口，查购分开。在核心功能之外，可由第三方充分利用大数据提供便民信息和服务。推
出预约服务，像购买股票一样挂单，在出现余票的情况下自动成交。 |
|
|
m******t
发帖数: 635 | 11 今年流量肯定比去年多不少，抢票软件都排苹果appstore中国区付费榜第2名了 |
g*****g
发帖数: 34805 | 12 先注册再下单，要限制抢票软件是很容易的事情，限IP，限每个账户下单的张数等等。
问题的核心还是不能linear scale out。
【在 m******t 的大作中提到】
: 今年流量肯定比去年多不少，抢票软件都排苹果appstore中国区付费榜第2名了
|
m******t
发帖数: 635 | 13 这些措施现在那个架构应该也可以用吧
【在 g*****g 的大作中提到】
: 先注册再下单，要限制抢票软件是很容易的事情，限IP，限每个账户下单的张数等等。
: 问题的核心还是不能linear scale out。
|
g*****g
发帖数: 34805 | 14 当然，还有最有效的captura。我的意思就是流量是会因为抢票软件增加，但不是根本
问题。
【在 m******t 的大作中提到】
: 这些措施现在那个架构应该也可以用吧
|
n****1
发帖数: 1136 | 15 你的做法就是先把订单收着, 后台慢慢做schedule出票对吧.
魏老师的系统也可以这样哦, 只不过表面形式不一样:
1.建一个内部隐藏队列, 用户只要初始查询了这个路线就把他扔到队列里.每个初始查
询给一个寿命长度, 几分钟或几小时, 这个可以调.
2.让用户手动刷新, 只对队列中的靠前用户显示有票, 其他通通无票. 注意这个架构下
网站上显示的无票是假的, 事实上也是假的,这个你懂的.给出无票这个动作非常简单,
无需计算.
3.一旦显示了有票,绝大部分乘客都会立即下单.也就是说,这里的暴露有票等价于你的
atomic出票动作.
这样做技术上和你的方案是等价的, 政治上更靠谱, 因为人们看到票貌似是源源不断地
放出, 而会觉得你的方案是暗箱操作.另外就是更改表面买票机制很容易引起媒体和大
众非议,别人说你只顾自己技术上方便随便改规则.
魏老师太诚实了, 非要显示真实余票, 但稍作调整就能稳定很多.
这种对性能要求很高的系统, 我觉得逻辑层与数据层分离是不妥的,哪怕是cassandra.
把你和魏老师的方案折中以下,就是mapreduce, 它能够把计算余票和管理队列的能力加
强很多, 还能榨干data node上的cpu潜力.
【在 g*****g 的大作中提到】
: 我以前提到过，不管你怎么弄，最核心的部分就是要把订票和出票完全分开。相当于
: waiting list。这样订票可以linear scale out，出票量小很多，有很多方案可以解决
: 。事实上大量新闻也证明问题也一直出在订票环节上。
: 现有的方案把订票出票耦合，有票才能订票，订票即出票。一到高峰就挂。这跟魏老师
: 方案是错误的架构，内存数据库什么的都是不得已的做法，而且还不能解决问题。
: 铁道部难道买不起更多的服务器吗？这么个应用只有17台服务器，只能说明架构错了，
: 不好scale out。你要是把淘宝挂在17台服务器上，到光棍节也挂。
|
t*****n
发帖数: 4908 | 16 魏老师是12306组的马甲？
HP
11
【在 m******t 的大作中提到】
: http://www.zhihu.com/question/22451397
: 水木上也在讨论
: http://www.newsmth.net/nForum/#!article/ITExpress/1385553
: 这里是硬件配置：
: 以前12306用的是小型机，发现性能严重不足，遂改用x86系统+linux平台（原平台为HP
: Superdome小型机，UNIX系统，Sybase ASE数据库）。最后他们的核心系统用了十几个
: 节点（现在应该是17节点）的多路Xeon E7（具体几路待考），每个节点配1TB内存，数
: 据库全部在内存中运行。2013年春运，12306系统峰值负载11万tps，与2012年淘宝双11
: 活动峰值负载相当，新的系统基本经受住了考验。
: 我这么感觉这个就是魏老师的cluster加强版啊
|
h*******u
发帖数: 15326 | 17 这玩意儿是不是要看看联航和三角的系统？好像相似度很高。航空售票也必须是有票才
能下单
HP
11
【在 m******t 的大作中提到】
: http://www.zhihu.com/question/22451397
: 水木上也在讨论
: http://www.newsmth.net/nForum/#!article/ITExpress/1385553
: 这里是硬件配置：
: 以前12306用的是小型机，发现性能严重不足，遂改用x86系统+linux平台（原平台为HP
: Superdome小型机，UNIX系统，Sybase ASE数据库）。最后他们的核心系统用了十几个
: 节点（现在应该是17节点）的多路Xeon E7（具体几路待考），每个节点配1TB内存，数
: 据库全部在内存中运行。2013年春运，12306系统峰值负载11万tps，与2012年淘宝双11
: 活动峰值负载相当，新的系统基本经受住了考验。
: 我这么感觉这个就是魏老师的cluster加强版啊
|
g*****g
发帖数: 34805 | 18 单机是收不了每秒10万到百万这个级别的订单的， 12306只是再证实一遍而已，你再粉
也没用。
他还两万美刀的预算，12306硬件也几百万人民币了。
你按我说的一条条去改良他的架构，还不如干脆我用的架构呢。还elastic, zone
redundancy.
【在 n****1 的大作中提到】
: 你的做法就是先把订单收着, 后台慢慢做schedule出票对吧.
: 魏老师的系统也可以这样哦, 只不过表面形式不一样:
: 1.建一个内部隐藏队列, 用户只要初始查询了这个路线就把他扔到队列里.每个初始查
: 询给一个寿命长度, 几分钟或几小时, 这个可以调.
: 2.让用户手动刷新, 只对队列中的靠前用户显示有票, 其他通通无票. 注意这个架构下
: 网站上显示的无票是假的, 事实上也是假的,这个你懂的.给出无票这个动作非常简单,
: 无需计算.
: 3.一旦显示了有票,绝大部分乘客都会立即下单.也就是说,这里的暴露有票等价于你的
: atomic出票动作.
: 这样做技术上和你的方案是等价的, 政治上更靠谱, 因为人们看到票貌似是源源不断地
|
j********x
发帖数: 2330 | 19 连订票的业务流程都没搞清楚就在scale out。。。能讲讲scale out一个复杂业务流程
和一个简单的key value store的区别么？我很好奇12306的业务逻辑流程啥样的，如果
本身业务流程耦合很严重，除非改善铁路订票的工作流程，怎么可能说scale out就
scale out。。。 |
n****1
发帖数: 1136 | 20 我可谁都没粉, 我也从来不相信他的单机能做production system. 而且他的作风不是
能踏实做系统的类型. 可老魏也不在这,你咋还像搞阶级斗争似的.
你以前的方案提了cassandra这个persistence layer,解决IO scaling问题, 但没提
logic layer. 上面的帖子你也认了系统瓶颈在于cpu/memory, 这个你怎么处理cpu
horizontal scaling呢?
【在 g*****g 的大作中提到】
: 单机是收不了每秒10万到百万这个级别的订单的， 12306只是再证实一遍而已，你再粉
: 也没用。
: 他还两万美刀的预算，12306硬件也几百万人民币了。
: 你按我说的一条条去改良他的架构，还不如干脆我用的架构呢。还elastic, zone
: redundancy.
|
|
|
j********x
发帖数: 2330 | 21 航空售票众所周知是超额出票的吧
【在 h*******u 的大作中提到】
: 这玩意儿是不是要看看联航和三角的系统？好像相似度很高。航空售票也必须是有票才
: 能下单
:
: HP
: 11
|
h*******u
发帖数: 15326 | 22 超额是有限度的，根据统计预测超售比。最终每个航班可售票也是一定的。
【在 j********x 的大作中提到】
: 航空售票众所周知是超额出票的吧
|
g*****g
发帖数: 34805 | 23 我哪里提过系统瓶颈在cpu/memory? 我提过stored procedure可以导致RDBMS cpu/
memory瓶颈，跟这个完全没关系。一个正常的cassandra cluster, 瓶颈在I/O上，而且
可以线性scale out.
至于logic layer, 我的设计里是stateless的service，简单粗暴的加机器就可以scale
out了。
【在 n****1 的大作中提到】
: 我可谁都没粉, 我也从来不相信他的单机能做production system. 而且他的作风不是
: 能踏实做系统的类型. 可老魏也不在这,你咋还像搞阶级斗争似的.
: 你以前的方案提了cassandra这个persistence layer,解决IO scaling问题, 但没提
: logic layer. 上面的帖子你也认了系统瓶颈在于cpu/memory, 这个你怎么处理cpu
: horizontal scaling呢?
|
g*****g
发帖数: 34805 | 24 现在的业务流程是不能scale out的，所以我提了一个新流程，订单不查余票，从而去
掉耦合，可以达到scale out.
在低流量的时候仍然可以达到实时订票，高流量的时候把结果发邮件／短信。
【在 j********x 的大作中提到】
: 连订票的业务流程都没搞清楚就在scale out。。。能讲讲scale out一个复杂业务流程
: 和一个简单的key value store的区别么？我很好奇12306的业务逻辑流程啥样的，如果
: 本身业务流程耦合很严重，除非改善铁路订票的工作流程，怎么可能说scale out就
: scale out。。。
|
n****1
发帖数: 1136 | 25 >>12306的瓶颈其实是核心节点的CPU、内存性能。但是这个性能的提升不是朝夕的事情
，而是受限于摩尔定律，基本上每两年才能翻一倍多些。
还有这种排队/名额分派算法是cs里很tricky的东西，因为名额是inter-dependent
among services. 极端例子就是md5 checksum， 加机器可以scale out吗？
scale
【在 g*****g 的大作中提到】
: 我哪里提过系统瓶颈在cpu/memory? 我提过stored procedure可以导致RDBMS cpu/
: memory瓶颈，跟这个完全没关系。一个正常的cassandra cluster, 瓶颈在I/O上，而且
: 可以线性scale out.
: 至于logic layer, 我的设计里是stateless的service，简单粗暴的加机器就可以scale
: out了。
|
g*****g
发帖数: 34805 | 26 这个没有问题，常见的做法就是time-based uuid作为key, uuid是app cluster产生的
，不会有冲突，所以可以线性scale out往里写，而且进数据库顺序就定好了。一个宽
行就可以排序索引。
后台批量顺序读出来分给多个节点处理即可，这个处理是离线的，不需要实时，所以只
有延迟大小，没有爆掉的问题。
严格意义上的公平也是不需要的，我比你晚10ms下单，我拿着票，你没拿着，都是并发
下正常的结果，谁也不知道。
md5 checksum如果可以mapreduce，当然加机器也能scale out.
【在 n****1 的大作中提到】
: >>12306的瓶颈其实是核心节点的CPU、内存性能。但是这个性能的提升不是朝夕的事情
: ，而是受限于摩尔定律，基本上每两年才能翻一倍多些。
: 还有这种排队/名额分派算法是cs里很tricky的东西，因为名额是inter-dependent
: among services. 极端例子就是md5 checksum， 加机器可以scale out吗？
:
: scale
|
z****e
发帖数: 54598 | 27 跑了17个节点，比魏老师吹牛的单节点多了整整17倍 |
z****e
发帖数: 54598 | 28 老魏压根没有用cluster
是后面吹牛被喷后加上去的
单机是老魏说的，后来做成cluster还是主机，这个是别人给他的建议
他本人还是倾向于用主机的，至少我记得我建议用主机之后，他表达了一定程度的赞同
HP
11
【在 m******t 的大作中提到】
: http://www.zhihu.com/question/22451397
: 水木上也在讨论
: http://www.newsmth.net/nForum/#!article/ITExpress/1385553
: 这里是硬件配置：
: 以前12306用的是小型机，发现性能严重不足，遂改用x86系统+linux平台（原平台为HP
: Superdome小型机，UNIX系统，Sybase ASE数据库）。最后他们的核心系统用了十几个
: 节点（现在应该是17节点）的多路Xeon E7（具体几路待考），每个节点配1TB内存，数
: 据库全部在内存中运行。2013年春运，12306系统峰值负载11万tps，与2012年淘宝双11
: 活动峰值负载相当，新的系统基本经受住了考验。
: 我这么感觉这个就是魏老师的cluster加强版啊
|
a****i
发帖数: 1182 | 29 你这样硬往TW上贴，当心他跟你急
他的核心就是宇宙超级至尊无敌单机，每秒5百万的io，两秒干掉几百万的订单
他的方案会考虑什么clustering？十个节点平均直接就把性能要求下降了一个数量级
那还有什么可吹的？
HP
11
【在 m******t 的大作中提到】
: http://www.zhihu.com/question/22451397
: 水木上也在讨论
: http://www.newsmth.net/nForum/#!article/ITExpress/1385553
: 这里是硬件配置：
: 以前12306用的是小型机，发现性能严重不足，遂改用x86系统+linux平台（原平台为HP
: Superdome小型机，UNIX系统，Sybase ASE数据库）。最后他们的核心系统用了十几个
: 节点（现在应该是17节点）的多路Xeon E7（具体几路待考），每个节点配1TB内存，数
: 据库全部在内存中运行。2013年春运，12306系统峰值负载11万tps，与2012年淘宝双11
: 活动峰值负载相当，新的系统基本经受住了考验。
: 我这么感觉这个就是魏老师的cluster加强版啊
|
s*****r
发帖数: 43070 | 30 铁路每天就几千个车次，meta data的量并不大，放进内存完全可能
【在 m*******l 的大作中提到】
: 是的,特别是内存数据库
:
: HP
: 11
|
