p*****2
发帖数: 21240 | 1 前两天没参加讨论，今天想了想，用Storm就可以搞定了
Storm就是干real time, big data的，一个node每秒的吞吐量上million, 下边上
goodbug推荐的cassandra，感觉没啥问题呀。
前端node，后端clojure这个组合不就搞定了吗？ |
b*******s
发帖数: 5216 | 2 介绍下吧，像好虫和魏老师讲得都不错，你也来一个? |
g*****g
发帖数: 34805 | 3 有问题，银行撑不了那么快的交易速度。所以订单下到cassandra里，弄个几十个线程
的threadpool
慢慢做后台处理才是王道。
【在 p*****2 的大作中提到】
: 前两天没参加讨论，今天想了想，用Storm就可以搞定了
: Storm就是干real time, big data的，一个node每秒的吞吐量上million, 下边上
: goodbug推荐的cassandra，感觉没啥问题呀。
: 前端node，后端clojure这个组合不就搞定了吗？
|
p*****2
发帖数: 21240 | 4
交易可以用异步呀。Storm可以把任务分发出去呀。有专门的bolt管transaction的。
【在 g*****g 的大作中提到】
: 有问题，银行撑不了那么快的交易速度。所以订单下到cassandra里，弄个几十个线程
: 的threadpool
: 慢慢做后台处理才是王道。
|
p*****2
发帖数: 21240 | 5
Storm能handle多大的数据量就不用解释了吧？不服气的去看看Twitter的流量。
Storm怎么工作的也很简单，不熟悉的看看Nathan的video去。
Storm支持stream和RPC，这个系统可以利用Storm的RPC。接口也很简单，query和book
query和book从spout进去，然后可以根据车次的hash发送到不同的bolt上去。也就是说
同一个车次的query和book会发送到同一个bolt上去。bolt里面保存车次的信息，in
memory。query不用说了，直接返回车次的信息即可。关键是book。book的时候bolt
mark一下，先到先得，后到返回失败。然后把transaction发到下一层bolt中去。下一
个bolt去bank charge，成功就ack这个请求，失败就fail请求，上一级的bolt unmark
，并且返回失败回去。
topology 就是三层
第一层spout，接受query和book
中间一层bolt保存列车信息， respond查询
最后一层管transaction的
log保存在cassandra里。
【在 b*******s 的大作中提到】
: 介绍下吧，像好虫和魏老师讲得都不错，你也来一个?
|
g*****g
发帖数: 34805 | 6 前端写订单，上一web cluster发到app cluster上生写cassandra就行了。storm啥的不
需要。
当然web server你要用node是可以的。
【在 p*****2 的大作中提到】
:
: Storm能handle多大的数据量就不用解释了吧？不服气的去看看Twitter的流量。
: Storm怎么工作的也很简单，不熟悉的看看Nathan的video去。
: Storm支持stream和RPC，这个系统可以利用Storm的RPC。接口也很简单，query和book
: query和book从spout进去，然后可以根据车次的hash发送到不同的bolt上去。也就是说
: 同一个车次的query和book会发送到同一个bolt上去。bolt里面保存车次的信息，in
: memory。query不用说了，直接返回车次的信息即可。关键是book。book的时候bolt
: mark一下，先到先得，后到返回失败。然后把transaction发到下一层bolt中去。下一
: 个bolt去bank charge，成功就ack这个请求，失败就fail请求，上一级的bolt unmark
: ，并且返回失败回去。
|
p*****2
发帖数: 21240 | 7
这不是又一个解决方案吗？没有说你的不对呀。storm的好处是infrastructure都有了
。开发起来很easy。你的方案开发起来就要慢一些了。
【在 g*****g 的大作中提到】
: 前端写订单，上一web cluster发到app cluster上生写cassandra就行了。storm啥的不
: 需要。
: 当然web server你要用node是可以的。
|
p*****2
发帖数: 21240 | 8
对了。你这个怎么保证consistency呀？从cassandra读到的信息可能是inconsistent的
。
【在 g*****g 的大作中提到】
: 前端写订单，上一web cluster发到app cluster上生写cassandra就行了。storm啥的不
: 需要。
: 当然web server你要用node是可以的。
|
g*****g
发帖数: 34805 | 9 我说的是个典型的三层方案，web cluster和 app cluster分开。所有的工具都是现成
的，各种类库一堆。web我不懂，app不觉得你那么做会更快。
【在 p*****2 的大作中提到】
:
: 对了。你这个怎么保证consistency呀？从cassandra读到的信息可能是inconsistent的
: 。
|
g*****g
发帖数: 34805 | 10 我不说了吗，replica factor 3, quorum read/write，这个是strong consistency的。
【在 p*****2 的大作中提到】
:
: 对了。你这个怎么保证consistency呀？从cassandra读到的信息可能是inconsistent的
: 。
|
|
|
n*w
发帖数: 3393 | 11 CASSandra对transaction的支持怎样？ 如果差的话会不会不能用在下订单？
【在 p*****2 的大作中提到】
: 前两天没参加讨论，今天想了想，用Storm就可以搞定了
: Storm就是干real time, big data的，一个node每秒的吞吐量上million, 下边上
: goodbug推荐的cassandra，感觉没啥问题呀。
: 前端node，后端clojure这个组合不就搞定了吗？
|
p*****2
发帖数: 21240 | 12
快不快不好说。因为我不觉得订票系统实时性要求特别高。storm的优点是非常容易
scale。不过目前确实有个大缺陷，就是可能有downtime。不过时间很短，感觉也不是
致命的。我觉得storm主要是已经解决了scalability, availability, fail over,
transaction这些问题了，不用自己写app再去考虑了。
【在 g*****g 的大作中提到】
: 我说的是个典型的三层方案，web cluster和 app cluster分开。所有的工具都是现成
: 的，各种类库一堆。web我不懂，app不觉得你那么做会更快。
|
p*****2
发帖数: 21240 | 13
的。
这么设置性能有影响吗？
【在 g*****g 的大作中提到】
: 我不说了吗，replica factor 3, quorum read/write，这个是strong consistency的。
|
p*****2
发帖数: 21240 | 14
nosql都不支持transaction, 不过app可以handle。具体细节我也没看goodbug怎么
handle。
感觉还是event driven更自然。
@goodbug
你起threadpool去poll cassandra， 具体任务怎么分配呢？这个能zkss吗？比如同一
个车次的booking如果不同的thread拿到如何？
【在 n*w 的大作中提到】
: CASSandra对transaction的支持怎样？ 如果差的话会不会不能用在下订单？
|
g*****g
发帖数: 34805 | 15 有，读写比CL1慢一倍。但是可以支持任意三个结点里坏掉一个。CL1写，相当于魏老师
的一个主力，加两个standby，主力在传给standby之前挂掉，数据就丢了。另外一个好
处就是绝对的strong consistency。虽然CL1，复制通常也在毫秒级，对这个应用可能
没啥区别。
【在 p*****2 的大作中提到】
:
: nosql都不支持transaction, 不过app可以handle。具体细节我也没看goodbug怎么
: handle。
: 感觉还是event driven更自然。
: @goodbug
: 你起threadpool去poll cassandra， 具体任务怎么分配呢？这个能zkss吗？比如同一
: 个车次的booking如果不同的thread拿到如何？
|
g*****g
发帖数: 34805 | 16 前面下订单，就是web传来，写到cassandra里。后台处理瓶颈纯粹在银行交易，你用啥
都没用。
【在 p*****2 的大作中提到】
:
: nosql都不支持transaction, 不过app可以handle。具体细节我也没看goodbug怎么
: handle。
: 感觉还是event driven更自然。
: @goodbug
: 你起threadpool去poll cassandra， 具体任务怎么分配呢？这个能zkss吗？比如同一
: 个车次的booking如果不同的thread拿到如何？
|
p*****2
发帖数: 21240 | 17
你这个到提醒了我。用Storm的话，还是得上Redis呀。我刚才想的是data in memory，
忘记考虑persistence了.
中间的bolt保存信息应该用Redis来做。这样bolt crash就不怕了。
再说cassandra这个配置，题外话了。如果cross data center的话，performance
impact就要大很多了吧？
【在 g*****g 的大作中提到】
: 有，读写比CL1慢一倍。但是可以支持任意三个结点里坏掉一个。CL1写，相当于魏老师
: 的一个主力，加两个standby，主力在传给standby之前挂掉，数据就丢了。另外一个好
: 处就是绝对的strong consistency。虽然CL1，复制通常也在毫秒级，对这个应用可能
: 没啥区别。
|
g*****g
发帖数: 34805 | 18 Cassandra可以做到row级别的atomic。一个订单只要在一行里，要吗写了返回成功，要
吗没写返回失败，不会有问题。
http://www.datastax.com/dev/blog/row-level-isolation
【在 p*****2 的大作中提到】
:
: 你这个到提醒了我。用Storm的话，还是得上Redis呀。我刚才想的是data in memory，
: 忘记考虑persistence了.
: 中间的bolt保存信息应该用Redis来做。这样bolt crash就不怕了。
: 再说cassandra这个配置，题外话了。如果cross data center的话，performance
: impact就要大很多了吧？
|
n*w
发帖数: 3393 | 19 如果storm能很处理transaction的话。保证所有访问一定通过storm应该可以。如果
storm能很好处理command query分开的话就无问题
【在 p*****2 的大作中提到】
:
: 你这个到提醒了我。用Storm的话，还是得上Redis呀。我刚才想的是data in memory，
: 忘记考虑persistence了.
: 中间的bolt保存信息应该用Redis来做。这样bolt crash就不怕了。
: 再说cassandra这个配置，题外话了。如果cross data center的话，performance
: impact就要大很多了吧？
|
p*****2
发帖数: 21240 | 20
现在银行一般的concurrency啥情况呀？每秒能handle多少transaction呢？不能支持这
个流量吗？
我现在不太明白写到cassandra之后，你用thread pool怎么分配这些订单呢？
【在 g*****g 的大作中提到】
: 前面下订单，就是web传来，写到cassandra里。后台处理瓶颈纯粹在银行交易，你用啥
: 都没用。
|
|
|
n*w
发帖数: 3393 | 21 看到。。。。 算了
【在 n*w 的大作中提到】
: 如果storm能很处理transaction的话。保证所有访问一定通过storm应该可以。如果
: storm能很好处理command query分开的话就无问题
|
p*****2
发帖数: 21240 | 22
你的处理怎么并行呀？
【在 g*****g 的大作中提到】
: Cassandra可以做到row级别的atomic。一个订单只要在一行里，要吗写了返回成功，要
: 吗没写返回失败，不会有问题。
: http://www.datastax.com/dev/blog/row-level-isolation
|
p*****2
发帖数: 21240 | 23
嗯。storm上边很多好东西。Nathan不是盖的。
【在 n*w 的大作中提到】
: 如果storm能很处理transaction的话。保证所有访问一定通过storm应该可以。如果
: storm能很好处理command query分开的话就无问题
|
g*****g
发帖数: 34805 | 24 多数据中心，一般consistency只做Local_quorum。对性能基本没有影响。订单的key是
一个UUID，不管从哪个数据中心出来的订单都没有冲突。后面的如果有更新，也是单线
程，
不会有问题。
【在 p*****2 的大作中提到】
:
: 嗯。storm上边很多好东西。Nathan不是盖的。
|
z****e
发帖数: 54598 | 25 可行
不过storm不负责web server
找一个地方汇总所有数据流就好了
流式处理是王道 |
p*****2
发帖数: 21240 | 26
如果多数据中心的话，每个数据中心都会处理所有的车次的订单吗？如果这样的话同一
个车次在几个数据中心都有订单怎么办呢？
【在 g*****g 的大作中提到】
: 多数据中心，一般consistency只做Local_quorum。对性能基本没有影响。订单的key是
: 一个UUID，不管从哪个数据中心出来的订单都没有冲突。后面的如果有更新，也是单线
: 程，
: 不会有问题。
|
g*****g
发帖数: 34805 | 27 不同车次可以并行，同一车次不并行比较公平。就是按时间顺序读出来，顺序处理。显
然你要并行也可以，就是没那么公平。
【在 p*****2 的大作中提到】
:
: 如果多数据中心的话，每个数据中心都会处理所有的车次的订单吗？如果这样的话同一
: 个车次在几个数据中心都有订单怎么办呢？
|
p*****2
发帖数: 21240 | 28
我感觉AKKA也很适合这个项目。不过还没有好好思考。
【在 z****e 的大作中提到】
: 可行
: 不过storm不负责web server
: 找一个地方汇总所有数据流就好了
: 流式处理是王道
|
p*****2
发帖数: 21240 | 29
同意这个。那对于一个车次来说，怎样同步比较合适呢？还是你保证一个车次只是由固
定的thread来处理呢？
【在 g*****g 的大作中提到】
: 不同车次可以并行，同一车次不并行比较公平。就是按时间顺序读出来，顺序处理。显
: 然你要并行也可以，就是没那么公平。
|
g*****g
发帖数: 34805 | 30 Cassandra的架构底下，所有的数据在一个小的延迟之后都复制到了其他的数据中心，
所有
数据中心的数据都是一样的。我说了单线程处理一个车次比较公平，因为排队问题。总
共几千
张票也没啥瓶颈问题。纯技术讲，如果不考虑排队。多线程可以用time split来拿这些
订单，
这样就不会有冲突。比如每10分钟的第1，2...到10分钟分给10个不同线程。这样不同
线程可以
同时来拿。另一个常见的做法就是用ZK 来分发给几个独立的queue。
【在 p*****2 的大作中提到】
:
: 同意这个。那对于一个车次来说，怎样同步比较合适呢？还是你保证一个车次只是由固
: 定的thread来处理呢？
|
|
|
g*****g
发帖数: 34805 | 31 反正就是一个车次一个线程，完全没有冲突，不需要啥同步。多数据中心你都可以pre-
configure，
那些车次在那个数据中心处理。另外，这个异步的处理进程对availability要求也不高，
你弄个monitor进程监视即可，不需要冗余。
【在 p*****2 的大作中提到】
:
: 同意这个。那对于一个车次来说，怎样同步比较合适呢？还是你保证一个车次只是由固
: 定的thread来处理呢？
|
p*****2
发帖数: 21240 | 32
多谢大牛。我想我最后不明白的问题就是线程之间的同步问题。同一个车次的订单给几
个线程，怎么保证先到先得。
【在 g*****g 的大作中提到】
: Cassandra的架构底下，所有的数据在一个小的延迟之后都复制到了其他的数据中心，
: 所有
: 数据中心的数据都是一样的。我说了单线程处理一个车次比较公平，因为排队问题。总
: 共几千
: 张票也没啥瓶颈问题。纯技术讲，如果不考虑排队。多线程可以用time split来拿这些
: 订单，
: 这样就不会有冲突。比如每10分钟的第1，2...到10分钟分给10个不同线程。这样不同
: 线程可以
: 同时来拿。另一个常见的做法就是用ZK 来分发给几个独立的queue。
|
p*****2
发帖数: 21240 | 33
pre-
OK。那就全明白了。这个处理跟我想的Storm那个类似。
多谢大牛了。先去睡了。明天再好好研究大牛的架构。
【在 g*****g 的大作中提到】
: 反正就是一个车次一个线程，完全没有冲突，不需要啥同步。多数据中心你都可以pre-
: configure，
: 那些车次在那个数据中心处理。另外，这个异步的处理进程对availability要求也不高，
: 你弄个monitor进程监视即可，不需要冗余。
|
g*****g
发帖数: 34805 | 34 要公平多线程做不到，我排队在你后面，但是我用的银行交易比较快，我的票就先出了。
当然公平是相对的，这个地方不公平用户也不知道。
【在 p*****2 的大作中提到】
:
: pre-
: OK。那就全明白了。这个处理跟我想的Storm那个类似。
: 多谢大牛了。先去睡了。明天再好好研究大牛的架构。
|
B***i
发帖数: 724 | 35 你自己用过storm吗？
twitter内部的人用抱怨storm 一堆堆的bug. real time data 都对不上后来batch
process的data.
【在 p*****2 的大作中提到】
: 前两天没参加讨论，今天想了想，用Storm就可以搞定了
: Storm就是干real time, big data的，一个node每秒的吞吐量上million, 下边上
: goodbug推荐的cassandra，感觉没啥问题呀。
: 前端node，后端clojure这个组合不就搞定了吗？
|
z****e
发帖数: 54598 | 36 你给zkss
【在 B***i 的大作中提到】
: 你自己用过storm吗？
: twitter内部的人用抱怨storm 一堆堆的bug. real time data 都对不上后来batch
: process的data.
|
p*****2
发帖数: 21240 | 37
大牛，先说说你自己有没有用过吧？
【在 B***i 的大作中提到】
: 你自己用过storm吗？
: twitter内部的人用抱怨storm 一堆堆的bug. real time data 都对不上后来batch
: process的data.
|
B***i
发帖数: 724 | 38 不是大牛，没有用过。
【在 p*****2 的大作中提到】
:
: 大牛，先说说你自己有没有用过吧？
|
s*****V
发帖数: 21731 | 39 那信用卡拒付怎么办？
【在 g*****g 的大作中提到】
: 有问题，银行撑不了那么快的交易速度。所以订单下到cassandra里，弄个几十个线程
: 的threadpool
: 慢慢做后台处理才是王道。
|
p*****2
发帖数: 21240 | 40
那你说说都有什么问题好吗？
【在 B***i 的大作中提到】
: 不是大牛，没有用过。
|
|
|
g*****g
发帖数: 34805 | 41 拒付，难道不就是直接打回，连余票数据库都不用更新？
【在 s*****V 的大作中提到】
: 那信用卡拒付怎么办？
|
s*****V
发帖数: 21731 | 42 你不是说银行支付不了那么快，让CASSANDRA在后台慢慢处理，那人家提交了信用卡，
你是多长时间回复？
【在 g*****g 的大作中提到】
: 拒付，难道不就是直接打回，连余票数据库都不用更新？
|
f****4
发帖数: 1359 | 43 听着可行，给个预算吧。
book
unmark
【在 p*****2 的大作中提到】
:
: 那你说说都有什么问题好吗？
|
p*****2
发帖数: 21240 | 44
都是open source的技术。上机器就好了。
【在 f****4 的大作中提到】
: 听着可行，给个预算吧。
:
: book
: unmark
|
g*****g
发帖数: 34805 | 45 不是Cassandra后台慢慢处理，是应用后台慢慢处理，读Cassandra，写RDBMS。
银行能处理多快，就多快回复。快的话几秒钟，慢的话几个小时。又不是我的系统决定
的。
【在 s*****V 的大作中提到】
: 你不是说银行支付不了那么快，让CASSANDRA在后台慢慢处理，那人家提交了信用卡，
: 你是多长时间回复？
|
z****e
发帖数: 54598 | 46 就看ibm出多少，按照ibm出价的一半，三分之一，四分之一甚至五分之一出价
ibm那种价格，哪怕只拿到十分之一，都赚翻了
【在 f****4 的大作中提到】
: 听着可行，给个预算吧。
:
: book
: unmark
|
m******t
发帖数: 635 | 47 魏老师的路子感觉象IBM的大型机那样scale up，不知道IBM怎么解决这种单机方案的问
题。
【在 z****e 的大作中提到】
: 就看ibm出多少，按照ibm出价的一半，三分之一，四分之一甚至五分之一出价
: ibm那种价格，哪怕只拿到十分之一，都赚翻了
|
g*****g
发帖数: 34805 | 48 魏老师如果上主机，有可能能行。问题他又要吹牛1万块的机器。
【在 m******t 的大作中提到】
: 魏老师的路子感觉象IBM的大型机那样scale up，不知道IBM怎么解决这种单机方案的问
: 题。
|
z****e
发帖数: 54598 | 49 ibm主机和分布式都有，看客户需要什么就上什么
这种已经有sybase系统的，多半上分布式
主机远比分布式贵
分布式之所以后来那么流行
很重要一个原因是大多数公司用不起主机
ibm最近又开始不行了一个主因就是当家的又跑去战略投资主机
女人当家，这个眼光稍微有点问题
【在 m******t 的大作中提到】
: 魏老师的路子感觉象IBM的大型机那样scale up，不知道IBM怎么解决这种单机方案的问
: 题。
|
m******t
发帖数: 635 | 50 那ibm主机怎么解决类似有掉电，io带宽（磁盘和网络）的问题的呢？
【在 z****e 的大作中提到】
: ibm主机和分布式都有，看客户需要什么就上什么
: 这种已经有sybase系统的，多半上分布式
: 主机远比分布式贵
: 分布式之所以后来那么流行
: 很重要一个原因是大多数公司用不起主机
: ibm最近又开始不行了一个主因就是当家的又跑去战略投资主机
: 女人当家，这个眼光稍微有点问题
|
|
|
h**********y
发帖数: 1293 | 51 还需要kafka做缓冲
【在 p*****2 的大作中提到】
: 前两天没参加讨论，今天想了想，用Storm就可以搞定了
: Storm就是干real time, big data的，一个node每秒的吞吐量上million, 下边上
: goodbug推荐的cassandra，感觉没啥问题呀。
: 前端node，后端clojure这个组合不就搞定了吗？
|
g*****g
发帖数: 34805 | 52 掉电的影响有很多区别。如果你每次都写，掉电了，网站当。我修复了供电系统，重启
机器，
发出的订单没有丢。如果你用一内存数据库，没写入硬盘的就都丢了。
mongoDB之所以快，就是journal之前可以不写硬盘。但大家都知道这个的风险。
没有人敢用在金钱部分。
【在 m******t 的大作中提到】
: 那ibm主机怎么解决类似有掉电，io带宽（磁盘和网络）的问题的呢？
|
z****e
发帖数: 54598 | 53 主机很大，里面什么都有，而且机房什么都是定制的
科罗拉多丹佛那个主机机房就是定制
之所以放科罗拉多，因为科罗拉多有很多美军用来防御核打击的军事设施
带宽之类的，也都是专线接入，不成问题
主机这种环境做到理想是相对可行的，分布式是钓丝的解决方案，便宜
但是环境就别太挑剔了
【在 m******t 的大作中提到】
: 那ibm主机怎么解决类似有掉电，io带宽（磁盘和网络）的问题的呢？
|
m******t
发帖数: 635 | 54 不知道哪里可以看到ibm主机的性能参数，比如cpu的benchmark，io吞吐量什么的？一
直很好奇它的性能，PC机要攒类似的大概要多少钱（如果可能的话）？
【在 z****e 的大作中提到】
: 主机很大，里面什么都有，而且机房什么都是定制的
: 科罗拉多丹佛那个主机机房就是定制
: 之所以放科罗拉多，因为科罗拉多有很多美军用来防御核打击的军事设施
: 带宽之类的，也都是专线接入，不成问题
: 主机这种环境做到理想是相对可行的，分布式是钓丝的解决方案，便宜
: 但是环境就别太挑剔了
|
m******t
发帖数: 635 | 55 不知道好虫对Oracle的Times Ten有什么评价，不知道能否解决你说的问题。
【在 g*****g 的大作中提到】
: 掉电的影响有很多区别。如果你每次都写，掉电了，网站当。我修复了供电系统，重启
: 机器，
: 发出的订单没有丢。如果你用一内存数据库，没写入硬盘的就都丢了。
: mongoDB之所以快，就是journal之前可以不写硬盘。但大家都知道这个的风险。
: 没有人敢用在金钱部分。
|
t*******y
发帖数: 1289 | 56 主机和分布式我觉是就像中国老话说的，合久必分，分久必合。还是看硬件和需求。
不过目前来看，需求真的是爆炸式的，分布式是趋势。
【在 z****e 的大作中提到】
: ibm主机和分布式都有，看客户需要什么就上什么
: 这种已经有sybase系统的，多半上分布式
: 主机远比分布式贵
: 分布式之所以后来那么流行
: 很重要一个原因是大多数公司用不起主机
: ibm最近又开始不行了一个主因就是当家的又跑去战略投资主机
: 女人当家，这个眼光稍微有点问题
|
p*****2
发帖数: 21240 | 57
kafka用在哪个部分？storm自己也可以有缓存吧？
【在 h**********y 的大作中提到】
: 还需要kafka做缓冲
|
g*****g
发帖数: 34805 | 58 说实话我不懂这些商业数据库的高级特性，但是我知道任何一个特性要打开都是钱。以
前性能不够好，
让DBA partition Oracle，跟我说做不了。一做一年几十万就出去了。我一怒就改了
MySQL。
【在 m******t 的大作中提到】
: 不知道好虫对Oracle的Times Ten有什么评价，不知道能否解决你说的问题。
|
z****e
发帖数: 54598 | 59 centralisation -> decentralisation -> recentralisation
但是recentralisation说的是cloud，不是主机
【在 t*******y 的大作中提到】
: 主机和分布式我觉是就像中国老话说的，合久必分，分久必合。还是看硬件和需求。
: 不过目前来看，需求真的是爆炸式的，分布式是趋势。
|
z****e
发帖数: 54598 | 60 ft，pc机怎么可能跟主机比
主机的cpu,内存,硬盘都远比一般的server来得大
更不要说跟pc机比了
而且搞主机主要是写cobol，而不是c也不是java
现在搞主机的除了ibm以外，也就是日本那几家，还在做
其它国家和公司大多数已经不做了
【在 m******t 的大作中提到】
: 不知道哪里可以看到ibm主机的性能参数，比如cpu的benchmark，io吞吐量什么的？一
: 直很好奇它的性能，PC机要攒类似的大概要多少钱（如果可能的话）？
|
