One paper please! Thanks a lot! - 未名空间MITBBS历史存档

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

Redian新闻

>未名空间

>Chemistry - 化学

One paper please! Thanks a lot!

One paper please! Thanks a lot!# Chemistry - 化学

B*s2010-06-15 07:06

1 楼

【以下文字转载自 Travel 讨论区】
发信人: BrazilRocks (花脸), 信区: Travel
标题: UA+国航里程联票能在美国就打出所有登机牌吗
发信站: BBS 未名空间站 (Fri Apr 5 14:42:45 2013, 美东)
UA到北京，然后连接国航到二级城市的里程票，能在美国第一站check in的时候就打出
所有（包括中国国航段）登机牌吗？

d*i2010-06-15 07:06

2 楼

g*g2010-06-15 07:06

3 楼

只说前端，从下订单到存订单这部分，后端出票部分数据量低几个数量级，而且可以离
线处理，现在就能顶住，不进一步讨论。从前面有文章提到一分钟40M来看，需要能撑
住每秒1M的订单。
用Cassandra, 底下这个测试用EC2 m1.x1，大约300个节点撑住了每秒1M/秒的写，当然
实际是3备份，3M/秒。
http://techblog.netflix.com/2011/11/benchmarking-cassandra-scal
这不是ec2上最好的机器，但反正是io bound. 这个测试大约每小时280美刀，包括了
stress client的费用，去掉test client, 大约每小时$220 / 288台机器。
前端界面假定需要10次交互才能下订单，1M订单就是10M次，经验而言没状态的web app
server每秒可以撑住10K/次，所以需要1000台，同样的跑business logic的app
server也需要1000台。另外需要几百台web server放图片，css, js这些静态文件。需
要监控的cluster, 需要load balancer，需要一些cache server. 总共我估计在3000台
左右。
费用方面，春运40天，每天8小时分时放票，需要3000台，其余时间热点没票，下单会
被简单拒绝，300台足以。这样是3000*8 ＋ 300 ＊ 16 ＝ 28800 ＊ 40天＊$220 /
288 = $880K = ￥5M。也就是春运大约500万运营费用，全年平时跑300台，10个多月
，大约加一倍，1千万人刀足够。
12306的机器比那个blog里的m1.x1 和 m2.x4牛逼我是相信的，但基本上快10倍，每秒
处理10万次request, 1万次订单也到头了。我需要3000个节点，它至少需要300个节点
。现在17个，至少差1个数量级，这个scale up基本无望。所以基本上每次放票高峰都
无响应就不奇怪了。
春运500万运营费用，摊到2亿6票子上，每张票不过2分钱而已。这种弹性极大的应用，
云计算是必须的，才是省钱的王道。现在12306这些机器买300台，费用估计也要1亿，
都够跑10年了。
电费，数据中心的开销都是另外的，

d*i2010-06-15 07:06

4 楼

One paper please! Thanks a lot! E-mail: x**********[email protected]
Peptide Targeting of Platinum Anti-Cancer Drugs
@
http://pubs.acs.org/doi/abs/10.1021/bc900065r

x*n2010-06-15 07:06

5 楼

这个在国航的checkin柜台或者登机口柜台可以打出来，
如果没有行李要托运的话，到了北京直接过安检

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

: 【以下文字转载自 Travel 讨论区】
: 发信人: BrazilRocks (花脸), 信区: Travel
: 标题: UA+国航里程联票能在美国就打出所有登机牌吗
: 发信站: BBS 未名空间站 (Fri Apr 5 14:42:45 2013, 美东)
: UA到北京，然后连接国航到二级城市的里程票，能在美国第一站check in的时候就打出
: 所有（包括中国国航段）登机牌吗？

y*n2010-06-15 07:06

6 楼

谢谢，回家看

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

g*g2010-06-15 07:06

7 楼

靠，技术贴你们不顶，就喜欢吵架。

m*32010-06-15 07:06

8 楼

http://www.sendspace.com/file/bjhk31

t*e2010-06-15 07:06

9 楼

请问有行李托运的话是直接在目的地取还是要在北京先提出来再托运啊？我是联程票，
ua飞多伦多-加拿大航空到北京-国航飞国内省会

★ 发自iPhone App: ChineseWeb 7.8

【在 x***n 的大作中提到】

: 这个在国航的checkin柜台或者登机口柜台可以打出来，
: 如果没有行李要托运的话，到了北京直接过安检

y*n2010-06-15 07:06

10 楼

喜欢简单的配器，谁做的MV，油菜

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

d*r2010-06-15 07:06

11 楼

顶啊，干货太多，还在慢慢看

m*32010-06-15 07:06

12 楼

请我曾经帮过的童鞋们去投诉版支持我

w*d2010-06-15 07:06

13 楼

我上次飞要提行李，都是航站楼T3，有个中转柜台可以重新托运。

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

: 请问有行李托运的话是直接在目的地取还是要在北京先提出来再托运啊？我是联程票，
: ua飞多伦多-加拿大航空到北京-国航飞国内省会
:
: ★ 发自iPhone App: ChineseWeb 7.8

c*m2010-06-15 07:06

14 楼

还看不到土豆，帮你顶一下。

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

L*f2010-06-15 07:06

15 楼

这不仅仅是有多少台机器的问题。
问题是这些机器的数据库
必须实时共享。机器越多，
共享数据库需要时间越长。
每个query之后，所有
机器的数据库必须同时更新。
怎样缩短这个时间才是关键。

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

: 靠，技术贴你们不顶，就喜欢吵架。

y*n2010-06-15 07:06

16 楼

为啥不能看土豆？

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

: 还看不到土豆，帮你顶一下。

w*z2010-06-15 07:06

17 楼

刚看完电影回来，周末还看你这样的帖子，太对不起自己了。再说，对12306 审美疲
劳了。

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

: 靠，技术贴你们不顶，就喜欢吵架。

g*g2010-06-15 07:06

18 楼

如果你知道cassandra的机制，就不会提出这个疑问了。Cassandra的R/W都是linear
scale out的，纯粹的堆机器。

【在 L******f 的大作中提到】

: 这不仅仅是有多少台机器的问题。
: 问题是这些机器的数据库
: 必须实时共享。机器越多，
: 共享数据库需要时间越长。
: 每个query之后，所有
: 机器的数据库必须同时更新。
: 怎样缩短这个时间才是关键。

z*g2010-06-15 07:06

19 楼

做这个测试真是浪费钱
就是一个io bound的程序，磁片硬盘，scsi接口，也就是～100 IOPS, 测来测去，还
不就是这个数字
换成flash，快10x没问题
如果换OS IO软件，在好的flash disk上能提高100x
至于那个12306，唯一不能简单scale out的是出票，修改数据库。
看他们自己说的卖票峰值数据，也就是100/sec左右的出票速度。
transaction要做persistence，这个是瓶颈。它们换成flash disk，理论出票峰值能至
少快10x

app

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

: 只说前端，从下订单到存订单这部分，后端出票部分数据量低几个数量级，而且可以离
: 线处理，现在就能顶住，不进一步讨论。从前面有文章提到一分钟40M来看，需要能撑
: 住每秒1M的订单。
: 用Cassandra, 底下这个测试用EC2 m1.x1，大约300个节点撑住了每秒1M/秒的写，当然
: 实际是3备份，3M/秒。
: http://techblog.netflix.com/2011/11/benchmarking-cassandra-scal
: 这不是ec2上最好的机器，但反正是io bound. 这个测试大约每小时280美刀，包括了
: stress client的费用，去掉test client, 大约每小时$220 / 288台机器。
: 前端界面假定需要10次交互才能下订单，1M订单就是10M次，经验而言没状态的web app
: server每秒可以撑住10K/次，所以需要1000台，同样的跑business logic的app

L*f2010-06-15 07:06

20 楼

没错。哪个所谓的测试，才有
48, 96, 144 and 288 instances
跟小孩过家家似的。确实是浪费钱。
出票其实就是query。每个query时，
数据库必须锁定。query结束，数据库
必须同步更新。不可能scale out。
要应付12306的需求，现有市场上
的商业数据库都不行。

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

: 做这个测试真是浪费钱
: 就是一个io bound的程序，磁片硬盘，scsi接口，也就是～100 IOPS, 测来测去，还
: 不就是这个数字
: 换成flash，快10x没问题
: 如果换OS IO软件，在好的flash disk上能提高100x
: 至于那个12306，唯一不能简单scale out的是出票，修改数据库。
: 看他们自己说的卖票峰值数据，也就是100/sec左右的出票速度。
: transaction要做persistence，这个是瓶颈。它们换成flash disk，理论出票峰值能至
: 少快10x
:

z*g2010-06-15 07:06

21 楼

锁定不是问题，问题是要persistence写log，这个是出票速度瓶颈
如果想把这个提高，两个途径
－换成flash，提高IOPS，这个简单
－出票并行，这个其实也是可以的，就是一次取多张票，就是一个persistence IO对
应譬如10张票啥的
这样会造成余票不完全准确，但是问题不大，同时可以设个timeout，卖不完退回
去即可，可以保证
在 1sec左右的粒度是精确的，足够实际应用

【在 L******f 的大作中提到】

: 没错。哪个所谓的测试，才有
: 48, 96, 144 and 288 instances
: 跟小孩过家家似的。确实是浪费钱。
: 出票其实就是query。每个query时，
: 数据库必须锁定。query结束，数据库
: 必须同步更新。不可能scale out。
: 要应付12306的需求，现有市场上
: 的商业数据库都不行。

g*g2010-06-15 07:06

22 楼

所有关于12306都说后台数据库不是问题，你纠结啥。前端订票的人多，后端票少。
往高里估，一个火车3000张票，一个车次20段，6万张，一天一千车次，6千万张。
还分时放票，算分10次发，每次就剩下6百万张，一个始发到终点的就能吃掉20张，平
均算一张票5站就好，总共就是120万个transaction. 稍微像样点的数据库服务器每秒
处理5000到1万个交易没问题，2-4分钟就解决了。但凡票卖完了，应用服务器就直接废
掉订单，或者让剩下的waiting list。无需再操作数据库。
我说了多少次，前端订单数量短时要高票数两到三个数量级，这才是问题。只要前后端
不耦合，后台批量读取，离线处理很容易。

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

L*f2010-06-15 07:06

23 楼

如果只是前端问题，那就应当没有任何困难。
简单掏钱买机器就行了。想不通为啥那么多
公司都做不了。

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

: 所有关于12306都说后台数据库不是问题，你纠结啥。前端订票的人多，后端票少。
: 往高里估，一个火车3000张票，一个车次20段，6万张，一天一千车次，6千万张。
: 还分时放票，算分10次发，每次就剩下6百万张，一个始发到终点的就能吃掉20张，平
: 均算一张票5站就好，总共就是120万个transaction. 稍微像样点的数据库服务器每秒
: 处理5000到1万个交易没问题，2-4分钟就解决了。但凡票卖完了，应用服务器就直接废
: 掉订单，或者让剩下的waiting list。无需再操作数据库。
: 我说了多少次，前端订单数量短时要高票数两到三个数量级，这才是问题。只要前后端
: 不耦合，后台批量读取，离线处理很容易。

g*g2010-06-15 07:06

24 楼

因为它的架构做错了，前后端紧密耦合，下单既出票。每秒百万次的余票更新，一下子
要压到后台关系数据库上，顶不住。所以它干脆就不在前端堆机器，让app server拒绝
request.

【在 L******f 的大作中提到】

: 如果只是前端问题，那就应当没有任何困难。
: 简单掏钱买机器就行了。想不通为啥那么多
: 公司都做不了。

l*t2010-06-15 07:06

25 楼

没错。这种有巨大突发计算需求的，云计算绝对是王道。非常显而易见的道理。

app

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

n*12010-06-15 07:06

26 楼

自己搭cassandra和直接用amazon dynamo哪个好? IO bound的话t1.micro都能做
cassandra吧, 而且还是浪费了cpu.
dynamo好像自动用ssd的

l*t2010-06-15 07:06

27 楼

dynamo现在有这么好么？以前不是说问题多多么？有啥大公司reference?再说
Cassandra和dynamo能差多远。我总觉得抄的或重新搞得系统，从软件层面看更好

【在 n****1 的大作中提到】

: 自己搭cassandra和直接用amazon dynamo哪个好? IO bound的话t1.micro都能做
: cassandra吧, 而且还是浪费了cpu.
: dynamo好像自动用ssd的

n*12010-06-15 07:06

28 楼

主要是能直接用ssd, 当然cassandra也能用, 但要用很贵的instance. netflix就弄过
ssd, 好像不错但贵:
http://techblog.netflix.com/2012/07/benchmarking-high-performan
Dynamo好像列举了Washington Post在用他们.

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

: dynamo现在有这么好么？以前不是说问题多多么？有啥大公司reference?再说
: Cassandra和dynamo能差多远。我总觉得抄的或重新搞得系统，从软件层面看更好

L*f2010-06-15 07:06

29 楼

收到单，当然要query数据库。
所以必然要压到数据库上。
所以，还是后台数据库的问题。

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

: 因为它的架构做错了，前后端紧密耦合，下单既出票。每秒百万次的余票更新，一下子
: 要压到后台关系数据库上，顶不住。所以它干脆就不在前端堆机器，让app server拒绝
: request.

g*g2010-06-15 07:06

30 楼

扯啥呀，下单只要查询静态的数据库，没余票数据也行，每分钟更新一次也行，弄个几
百个数据库拷贝随便查。
至于出票，没有实时要求，不是每个单子都要操作数据库，票卖完了后面的就不用处理
了。

【在 L******f 的大作中提到】

: 收到单，当然要query数据库。
: 所以必然要压到数据库上。
: 所以，还是后台数据库的问题。

L*f2010-06-15 07:06

31 楼

这几百个数据库需要同步实时更新吧？
每分钟更新一次，一定会有票卖重了。
因为系统看到的是一分钟前有票，
就卖了。结果发现一分钟内票已经卖
掉了。这在热门线路肯定会发生，
12306要被骂死了。
下单是为了买票吧？
买票就要数据库query吧？
query就需要锁定这几百数据库吧？
买完票后，这几百个数据库就要
实时更新吧？
几百万个这样的请求压上来，
基本上所有的商业数据库都要
崩溃。

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

: 扯啥呀，下单只要查询静态的数据库，没余票数据也行，每分钟更新一次也行，弄个几
: 百个数据库拷贝随便查。
: 至于出票，没有实时要求，不是每个单子都要操作数据库，票卖完了后面的就不用处理
: 了。

g*g2010-06-15 07:06

32 楼

不需要同步实时更新，纯粹给个非实时的余票信息而已，甚至不给也行。订票就是订票
，订票可不保证有，只有后端锁到票，出了才算出了。后端出票不是实时的，出了票发
email/短信。

【在 L******f 的大作中提到】

: 这几百个数据库需要同步实时更新吧？
: 每分钟更新一次，一定会有票卖重了。
: 因为系统看到的是一分钟前有票，
: 就卖了。结果发现一分钟内票已经卖
: 掉了。这在热门线路肯定会发生，
: 12306要被骂死了。
: 下单是为了买票吧？
: 买票就要数据库query吧？
: query就需要锁定这几百数据库吧？
: 买完票后，这几百个数据库就要

s*e2010-06-15 07:06

33 楼

你这种会比现在这样被骂的更惨。到时候别人说我没票，为啥那个啥啥有票，你们一定
搞鬼了。订票系统必须实时，不然就别玩了。

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

: 不需要同步实时更新，纯粹给个非实时的余票信息而已，甚至不给也行。订票就是订票
: ，订票可不保证有，只有后端锁到票，出了才算出了。后端出票不是实时的，出了票发
: email/短信。

p*32010-06-15 07:06

34 楼

感觉实时不大可能吧，如果是查询，订票，出票分离，asynchronous batch 订票(
message
queue啥的)，如果处理速度够快，用户再刷页面querry request结果等个几分
钟的还可以接受，别等个把小时发邮件通知什么的就可以了

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

: 你这种会比现在这样被骂的更惨。到时候别人说我没票，为啥那个啥啥有票，你们一定
: 搞鬼了。订票系统必须实时，不然就别玩了。

s*e2010-06-15 07:06

35 楼

几分钟还可以，再长肯定不行了。就是几分钟，骂的人都不少，现在网上反映最强烈的
就是
request的时候卡住，再刷一遍已经没票了。这种其实技术上无法避免，但是买票的人
都不懂技术的，也不会理解你。

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

:
: 感觉实时不大可能吧，如果是查询，订票，出票分离，asynchronous batch 订票(
: message
: queue啥的)，如果处理速度够快，用户再刷页面querry request结果等个几分
: 钟的还可以接受，别等个把小时发邮件通知什么的就可以了

L*f2010-06-15 07:06

36 楼

所以我说１２３０６系统很难。
骂１２３０６烂的那些程序猿
根本不懂，在那里瞎骂。
这些程序猿才是真正烂。
鄙视一下。

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

: 几分钟还可以，再长肯定不行了。就是几分钟，骂的人都不少，现在网上反映最强烈的
: 就是
: request的时候卡住，再刷一遍已经没票了。这种其实技术上无法避免，但是买票的人
: 都不懂技术的，也不会理解你。

e*z2010-06-15 07:06

37 楼

这种应用显然是自己构建私云更便宜
40天之外还需要跑数据分析对明年的放票/排班次进行优化
而且每天8小时放票这个也可以改。
就这点事情，总计算能力需求大概1000台PC级服务器。
每年花1000wRMB去买云计算还不如自己买机器，数据中心都不用自己盖，几十个机柜就
够了

app

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

g*g2010-06-15 07:06

38 楼

每个订单都有时间戳，下订单了就能看见。按时间戳排队，票卖完了也大可以公布最后
一张票出的时间，透明度够了，
你没排上你怪谁。僧多粥少，有人骂是必然的，保证公平就行了。怎么都比现在动不动
就挂强。

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

: 你这种会比现在这样被骂的更惨。到时候别人说我没票，为啥那个啥啥有票，你们一定
: 搞鬼了。订票系统必须实时，不然就别玩了。

P*x2010-06-15 07:06

39 楼

这个讨论有点意思。
我特地看了一下Sabre的ppt. （sabre是定机票的系统）
几个关键的benchmark - 85k transaction per/second at peek.
926B transaction per year.
当然这个不是苹果对苹果比较。
architecture presentation
http://www.opentravel.org/resources/uploads/pdf/ota07_soasabre.

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

: 每个订单都有时间戳，下订单了就能看见。按时间戳排队，票卖完了也大可以公布最后
: 一张票出的时间，透明度够了，
: 你没排上你怪谁。僧多粥少，有人骂是必然的，保证公平就行了。怎么都比现在动不动
: 就挂强。

P*x2010-06-15 07:06

40 楼

数据中心还是有必要的。要是有自然灾害什么的，总的有个failover 系统吧。

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

: 这种应用显然是自己构建私云更便宜
: 40天之外还需要跑数据分析对明年的放票/排班次进行优化
: 而且每天8小时放票这个也可以改。
: 就这点事情，总计算能力需求大概1000台PC级服务器。
: 每年花1000wRMB去买云计算还不如自己买机器，数据中心都不用自己盖，几十个机柜就
: 够了
:
: app

s*a2010-06-15 07:06

41 楼

买车票最简单的问题，有A，B，C三辆车回家，优先度是A>B>C，出票的时候第一时间抢
A，没有就抢B，再没有就抢C。
说说你的这种先接受订票，等机器处理完了再告诉你订没订上的策略如何满足上面的需
求？

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

y*i2010-06-15 07:06

42 楼

request的时候卡住，再刷一遍已经没票了
这request什么意思？
看到了不买，再刷一遍就没票了，这不是很正常么。

a*02010-06-15 07:06

43 楼

我们公司的云存储大概1w台机器，20个结点。300台机器？每台都是天河？

g*g2010-06-15 07:06

44 楼

订票就可以定A不行B，B不行C. 还是一张单子。
后端是离线处理，没实时要求，怎么都能满足。

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

: 买车票最简单的问题，有A，B，C三辆车回家，优先度是A>B>C，出票的时候第一时间抢
: A，没有就抢B，再没有就抢C。
: 说说你的这种先接受订票，等机器处理完了再告诉你订没订上的策略如何满足上面的需
: 求？

p*32010-06-15 07:06

45 楼

为什么用时间戳和cassandra cluster呢，直接上SQS是不是就可以了，多个SQS队列，
batch存取message, 可以大致保证顺序，同一个message可能被多台机器处理，把所有
message处理做成idempotent, 处理poll和process message的server做成stateless的
，batch update DB，瓶颈最后还在DB上。

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

g*g2010-06-15 07:06

46 楼

用queue的思路是可以的，不过sqs有性能问题。

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

:
: 为什么用时间戳和cassandra cluster呢，直接上SQS是不是就可以了，多个SQS队列，
: batch存取message, 可以大致保证顺序，同一个message可能被多台机器处理，把所有
: message处理做成idempotent, 处理poll和process message的server做成stateless的
: ，batch update DB，瓶颈最后还在DB上。

e*z2010-06-15 07:06

47 楼

国内盖数据中心，2013年的行情是政府倒贴钱
备灾一般来说只需数据备份，无需计算能力。
这两项都可以做，自己持有硬件还是更便宜，而且数据保密性更好。不会被云平台偷
偷卖给航空公司去挖掘。
用云计算比较合算的情况是每年只需几天，但是这几天需要几百几千台机器这种.类似
于原来做个什么实验预约超级计算机几小时这种。
如果每年需要超高计算密度两个月连续使用，就难以提高效率了。人家玩云计算的也要
赚钱。
类比一下就是每年有两个月有足够的运量满足一个1000台卡车的车队，然后有人说养车
队太贵了，不如都用UPS，还能打折。呵呵。读书读傻了。
云计算推广时期，现在还没有峰谷时刻收费不同的概念，将来必然出现。所以铁路这种
，弄到第三方平台上去，现在恐怕人家为了你这单生意赔钱都肯做，不过将来肯定涨价
，然后铁路等着将来挨宰。
所以最佳方案是自己弄一个云平台，然后低峰时段卖给政府，政府再免费送给中科院来
提高效率。

【在 P*****x 的大作中提到】

: 数据中心还是有必要的。要是有自然灾害什么的，总的有个failover 系统吧。

g*g2010-06-15 07:06

48 楼

Amazon早就有分段收费了。这个一年就40天春运，春运需要平时100倍机器，说云计算
不划算是不可能的。
自己盖数据中心把剩余计算力租出去，那是amazon, taobao, 12306显然不合适。

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

: 国内盖数据中心，2013年的行情是政府倒贴钱
: 备灾一般来说只需数据备份，无需计算能力。
: 这两项都可以做，自己持有硬件还是更便宜，而且数据保密性更好。不会被云平台偷
: 偷卖给航空公司去挖掘。
: 用云计算比较合算的情况是每年只需几天，但是这几天需要几百几千台机器这种.类似
: 于原来做个什么实验预约超级计算机几小时这种。
: 如果每年需要超高计算密度两个月连续使用，就难以提高效率了。人家玩云计算的也要
: 赚钱。
: 类比一下就是每年有两个月有足够的运量满足一个1000台卡车的车队，然后有人说养车
: 队太贵了，不如都用UPS，还能打折。呵呵。读书读傻了。

p*32010-06-15 07:06

49 楼

多分几个message queue

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

: 用queue的思路是可以的，不过sqs有性能问题。

z*e2010-06-15 07:06

50 楼

基本正确
以魏老师为代表的程序员对这种系统完全是狗屁不通

【在 L******f 的大作中提到】

: 所以我说１２３０６系统很难。
: 骂１２３０６烂的那些程序猿
: 根本不懂，在那里瞎骂。
: 这些程序猿才是真正烂。
: 鄙视一下。

m*j2010-06-15 07:06

51 楼

笨啊，当然应该是abc一起抢了，等抢下来再决定退哪张。

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

: 订票就可以定A不行B，B不行C. 还是一张单子。
: 后端是离线处理，没实时要求，怎么都能满足。

t*a2010-06-15 07:06

52 楼

同意。问题是我认为现在这个问题无解，如果都要实时的话。

【在 L******f 的大作中提到】

w*m2010-06-15 07:06

53 楼

搞一个透明的队排，让用户知道是在排队，不是买到表了。和实体购表类似

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

: 你这种会比现在这样被骂的更惨。到时候别人说我没票，为啥那个啥啥有票，你们一定
: 搞鬼了。订票系统必须实时，不然就别玩了。

j*p2010-06-15 07:06

54 楼

应用程序级别,考虑异步队列处理是对的.
数据库级别,考虑分布式数据库,把重要的Table尽量拆分到性能比较强的机器上.
如果有必要的话,对query进行必要的简化和优化.
设置脏读是有必要的.不要动不动就锁表长时间.
死锁一定要避免.
对实时的理解,在客户和设计者来说概念是不一样的.
在设计者角度来说,只要把整个过程的时间控制在一个范围内,
对于客户,就是实时的.

w*m2010-06-15 07:06

55 楼

每个班次一个队
如果一个队都忙不过来加人，就搞多个队，然后卖票的时候按ts merge sort
当然这只能解决用户输入了班次的情况
如果象一半航空订票的方式，输入起点和终点，有几种路径，不同价格，每个包括几个
车次，必须全订到才可以。那就要跨车次查了，这样就的全国的队一起按ts merge
sort，除非能按graph分好互补联系的clusters。
用storm行不？
如果要象优化，满足最多人订到票的需求则更复杂。如果要优化车次的排放还要更复杂。

【在 w*********m 的大作中提到】

: 搞一个透明的队排，让用户知道是在排队，不是买到表了。和实体购表类似

e*z2010-06-15 07:06

56 楼

扯淡100倍。而且除了春运还有5/1. 10/1，暑假
40天可以延长到60天甚至更长
不做UPS但是自己有卡车车队的公司多了。

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

: Amazon早就有分段收费了。这个一年就40天春运，春运需要平时100倍机器，说云计算
: 不划算是不可能的。
: 自己盖数据中心把剩余计算力租出去，那是amazon, taobao, 12306显然不合适。

g*g2010-06-15 07:06

57 楼

你才扯蛋，春运又不是每天都有人抢票，初一出发的票就好买。票也不是一直都抢，要
是票一下子全放出来，一个小时内就弄完了。云计算就是可以动态根据流量来scale up
/down。按最高需要来买机器就是亏本了事。
有自己卡车车队的公司多了，没见到几乎每个公司圣诞出货都得延迟？都按圣诞维护车
队，平时放羊？有点常识好不好。

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

: 扯淡100倍。而且除了春运还有5/1. 10/1，暑假
: 40天可以延长到60天甚至更长
: 不做UPS但是自己有卡车车队的公司多了。

a*n2010-06-15 07:06

58 楼

有多少人抢票和出多少张票关系不大吧。其实跟小米学就可以了，直接前台说没票了就
可以。

v*a2010-06-15 07:06

59 楼

摇号儿？

m*j2010-06-15 07:06

60 楼

虫，扯大了。
春运一开始售票，就都是蜂拥而上。
因为晚去的可能就根本买不到票了。
你买过春运的票吗?

up

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

: 你才扯蛋，春运又不是每天都有人抢票，初一出发的票就好买。票也不是一直都抢，要
: 是票一下子全放出来，一个小时内就弄完了。云计算就是可以动态根据流量来scale up
: /down。按最高需要来买机器就是亏本了事。
: 有自己卡车车队的公司多了，没见到几乎每个公司圣诞出货都得延迟？都按圣诞维护车
: 队，平时放羊？有点常识好不好。

m*j2010-06-15 07:06

61 楼

小米那招在车票上不好使。
等着回家的人会一直刷新的，你服务器的符合根本就不会下来。

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

: 有多少人抢票和出多少张票关系不大吧。其实跟小米学就可以了，直接前台说没票了就
: 可以。

g*g2010-06-15 07:06

62 楼

我当然买过，12306我都用过，还好买的票不热门。你说的蜂拥而上跟我说的矛盾是？

【在 m**********j 的大作中提到】

: 虫，扯大了。
: 春运一开始售票，就都是蜂拥而上。
: 因为晚去的可能就根本买不到票了。
: 你买过春运的票吗?
:
: up

m*j2010-06-15 07:06

63 楼

在开始能买春运票的那一瞬间，会有上亿次的点击冲击网站。
就像我单开的帖子说的那样，
第一，你把买春运火车票的类比为500万在北美生活的华人。
第二，你把从北美飞往去世界各地的航班看作春运的火车车次。
第三，你把春运的第一天看作是美国对中国宣战的第一天了。北美的华人一下子就成为
了美国的敌人。
500来万的华人都想最快最早地坐航班离开美国。你是打算早买早走，还是晚买晚走，
要知道晚买了哪怕一分钟就可能一张票都木有，就剩下当靶子了。
这个时候，没有任何一个常规的运力能够解决这个，全瘫痪了。
你这个幸运的从没自己买过春运票的人是不会理解这些的。

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

: 我当然买过，12306我都用过，还好买的票不热门。你说的蜂拥而上跟我说的矛盾是？

g*g2010-06-15 07:06

64 楼

I服了U，感情我说了这半天，我说啥你完全没看呀。你有多少张单子过来，我都给你收
着。后台慢慢处理。运力不够不错，先来的有票，后来的没票。

【在 m**********j 的大作中提到】

: 在开始能买春运票的那一瞬间，会有上亿次的点击冲击网站。
: 就像我单开的帖子说的那样，
: 第一，你把买春运火车票的类比为500万在北美生活的华人。
: 第二，你把从北美飞往去世界各地的航班看作春运的火车车次。
: 第三，你把春运的第一天看作是美国对中国宣战的第一天了。北美的华人一下子就成为
: 了美国的敌人。
: 500来万的华人都想最快最早地坐航班离开美国。你是打算早买早走，还是晚买晚走，
: 要知道晚买了哪怕一分钟就可能一张票都木有，就剩下当靶子了。
: 这个时候，没有任何一个常规的运力能够解决这个，全瘫痪了。
: 你这个幸运的从没自己买过春运票的人是不会理解这些的。

m*j2010-06-15 07:06

65 楼

你先回答我，你那次没买到特快，是为啥？

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

: I服了U，感情我说了这半天，我说啥你完全没看呀。你有多少张单子过来，我都给你收
: 着。后台慢慢处理。运力不够不错，先来的有票，后来的没票。

m*j2010-06-15 07:06

66 楼

就拿你那次没买到特快只好选择别的方式回家来说。
如果你是5天之后才得知你没有买上特快，你怎么办？去订直快吧？
然后5天之后通知你，抱歉，直快也没了，你怎么办？去订普快吧？
然后5天之后通知你，抱歉，普快也没了，你怎么办？
因为今天已经是大年初二了，你也甭回家了。

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

g*g2010-06-15 07:06

67 楼

你一张单子，写着
来特快100次一张，100次没有普快200次，200次没有300次也行。
再复杂一点，先大年23的，23没有24，24没有25，车次优先还是时间优先也自己定。
下单后几分钟跟你短信通知结果，有啥不行？你到窗口还不是一样这么问一圈，都写进
单子里系统帮你处理了不好？

【在 m**********j 的大作中提到】

: 就拿你那次没买到特快只好选择别的方式回家来说。
: 如果你是5天之后才得知你没有买上特快，你怎么办？去订直快吧？
: 然后5天之后通知你，抱歉，直快也没了，你怎么办？去订普快吧？
: 然后5天之后通知你，抱歉，普快也没了，你怎么办？
: 因为今天已经是大年初二了，你也甭回家了。

m*j2010-06-15 07:06

68 楼

几分钟后，比如3分钟吧，服务器处理完了你的申请给你发短信了，你收到短信了，短
信通知你特快没了，普快没了，300次也没了。
但就这3分钟，你耽误了没去买飞机票。
飞机票在你收到短信的时候，刚巧刚刚卖完。
你碰巧赶上中国电信、中国移动、中国联通业务繁忙，出现了短消息发送的滞后，滞后
了5分钟。
你要知道，3分钟加5分钟，一共8分钟，你本来是能够想别的办法的。

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

: 你一张单子，写着
: 来特快100次一张，100次没有普快200次，200次没有300次也行。
: 再复杂一点，先大年23的，23没有24，24没有25，车次优先还是时间优先也自己定。
: 下单后几分钟跟你短信通知结果，有啥不行？你到窗口还不是一样这么问一圈，都写进
: 单子里系统帮你处理了不好？

g*g2010-06-15 07:06

69 楼

有可能。但总比你刷了一整天车票，100次有99次进不去，好容易一次刷到了，提交没
响应想砸电脑。刷票8小时才放弃，飞机票还是8分钟就卖完了。我浪费了8分钟，你浪
费了8小时。

【在 m**********j 的大作中提到】

: 几分钟后，比如3分钟吧，服务器处理完了你的申请给你发短信了，你收到短信了，短
: 信通知你特快没了，普快没了，300次也没了。
: 但就这3分钟，你耽误了没去买飞机票。
: 飞机票在你收到短信的时候，刚巧刚刚卖完。
: 你碰巧赶上中国电信、中国移动、中国联通业务繁忙，出现了短消息发送的滞后，滞后
: 了5分钟。
: 你要知道，3分钟加5分钟，一共8分钟，你本来是能够想别的办法的。

m*j2010-06-15 07:06

70 楼

不错，我刚才说的也有可能会持续8个多小时你才能收到短消息说你没票。
因为没人能保证你收到短消息需要多长时间。
如果你短消息收到的时间超过了你的预期，是服务器没有处理完你的order呢，还是处
理器准备好给你的消息呢，还是移动服务商没有把处理器准备好的消息发出给你呢....
...
国内、国外短信出现delay，甚至没发出来的事情又不是一次两次了。

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

: 有可能。但总比你刷了一整天车票，100次有99次进不去，好容易一次刷到了，提交没
: 响应想砸电脑。刷票8小时才放弃，飞机票还是8分钟就卖完了。我浪费了8分钟，你浪
: 费了8小时。

g*g2010-06-15 07:06

71 楼

短信，email同时发。不放心还可以到12306刷你的订单状态。我那个网站是有响应的，
不像你的没有。银行设定转账干过吧？到时间帮你转，转了给你发邮件。你不放心移动
可以一直刷银行网站，刷到出来为止。

..

【在 m**********j 的大作中提到】

: 不错，我刚才说的也有可能会持续8个多小时你才能收到短消息说你没票。
: 因为没人能保证你收到短消息需要多长时间。
: 如果你短消息收到的时间超过了你的预期，是服务器没有处理完你的order呢，还是处
: 理器准备好给你的消息呢，还是移动服务商没有把处理器准备好的消息发出给你呢....
: ...
: 国内、国外短信出现delay，甚至没发出来的事情又不是一次两次了。

m*j2010-06-15 07:06

72 楼

草，说了半天，尼玛还是刷网站。
刷吧，谁让你不早点去排队呢，买不到票真是活该。

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

: 短信，email同时发。不放心还可以到12306刷你的订单状态。我那个网站是有响应的，
: 不像你的没有。银行设定转账干过吧？到时间帮你转，转了给你发邮件。你不放心移动
: 可以一直刷银行网站，刷到出来为止。
:
: ..

k*e2010-06-15 07:06

73 楼

趁好虫还没回答，我先来给他添个堵：
他前面已经回答过类似的问题，就是：直接在一单里就选：买特快，不行就买直快，再
次买普快。
让系统后台慢慢处理他这几个选项。
其实。。。这个轻描淡写的解决方法还不够实用。用户需要的是交互选择的功能，A不
行了不是说马上就default到B，而是要问：B多少钱？要多花多少时间？什么时间出发
？我再看看C多少钱。。。

【在 m**********j 的大作中提到】

g*g2010-06-15 07:06

74 楼

我做不到，也不知道能做到的办法。但是ABC的信息是静态的可以在你查询的时候给出
来。
你下单的时候自己做好决定。
如果智力不够弄不来，也可以一样买一张，回头再退。

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

: 趁好虫还没回答，我先来给他添个堵：
: 他前面已经回答过类似的问题，就是：直接在一单里就选：买特快，不行就买直快，再
: 次买普快。
: 让系统后台慢慢处理他这几个选项。
: 其实。。。这个轻描淡写的解决方法还不够实用。用户需要的是交互选择的功能，A不
: 行了不是说马上就default到B，而是要问：B多少钱？要多花多少时间？什么时间出发
: ？我再看看C多少钱。。。

g*g2010-06-15 07:06

75 楼

尼玛要杞人忧天，担心移动耽误你的短信，自然可以刷网站。我老人家放心移动，
该干嘛干嘛去。

【在 m**********j 的大作中提到】

: 草，说了半天，尼玛还是刷网站。
: 刷吧，谁让你不早点去排队呢，买不到票真是活该。

m*j2010-06-15 07:06

76 楼

喂，退票？
20%的退票费是不是你说的。

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

: 我做不到，也不知道能做到的办法。但是ABC的信息是静态的可以在你查询的时候给出
: 来。
: 你下单的时候自己做好决定。
: 如果智力不够弄不来，也可以一样买一张，回头再退。

g*g2010-06-15 07:06

77 楼

不是我说的，从架构角度不需要。从减少黄牛角度不失一个好的策略。

【在 m**********j 的大作中提到】

: 喂，退票？
: 20%的退票费是不是你说的。

m*j2010-06-15 07:06

78 楼

是你买票，是你买不到特快票。
是你买不到特快票，只好做3天的火车而不是44个小时的火车回的家。
少了和你家人团聚欢庆春节的时光。

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

: 尼玛要杞人忧天，担心移动耽误你的短信，自然可以刷网站。我老人家放心移动，
: 该干嘛干嘛去。

m*j2010-06-15 07:06

79 楼

尼玛，你直说，退票要不要罚款？

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

: 不是我说的，从架构角度不需要。从减少黄牛角度不失一个好的策略。

g*g2010-06-15 07:06

80 楼

事实上是移动没delay, 我老人家3分钟后收到短信说票都没了，赶在8分钟机票卖完之
前买了机票。
您老刷了一天票，最终放弃，买机票得知8分钟的时候已经卖完了，气得把电脑砸了。
结果就是我多花了钱回家过年，你会不了家连电脑也坏了。

【在 m**********j 的大作中提到】

: 是你买票，是你买不到特快票。
: 是你买不到特快票，只好做3天的火车而不是44个小时的火车回的家。
: 少了和你家人团聚欢庆春节的时光。

m*j2010-06-15 07:06

81 楼

草，虫虫开始撒娇打滚了。
这招经常看你在篮球版上使，想不到有一天你居然真会用到了这里。

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

: 事实上是移动没delay, 我老人家3分钟后收到短信说票都没了，赶在8分钟机票卖完之
: 前买了机票。
: 您老刷了一天票，最终放弃，买机票得知8分钟的时候已经卖完了，气得把电脑砸了。
: 结果就是我多花了钱回家过年，你会不了家连电脑也坏了。

g*g2010-06-15 07:06

82 楼

这都是按照你的设计走，3分钟delay也是你说的，8分钟机票卖完也是你说的。
区别在于移动有没有delay短信5分钟。有我跟你一样回不了家，但8分钟就知道了，你8
小时知道。
没有delay 5分钟我就买了机票。
怎么，自己划下道道，被打脸又不服了？

【在 m**********j 的大作中提到】

: 草，虫虫开始撒娇打滚了。
: 这招经常看你在篮球版上使，想不到有一天你居然真会用到了这里。

m*j2010-06-15 07:06

83 楼

你牙这不是胡搅蛮缠吗。
8个小时，你看看多少个人有8个小时的问题？
你用一个你心里琢磨的都没上过PROD的产品，跟一个经历了风风雨雨洗礼的产品比。
还是这个产品出现的一个特例比。
你是不是弱智啊。
还有你牙刚才口口声声说你的计划就没打算让你买到票。
说你是一个弱智那真是对科比的一种侮辱。

你8

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

: 这都是按照你的设计走，3分钟delay也是你说的，8分钟机票卖完也是你说的。
: 区别在于移动有没有delay短信5分钟。有我跟你一样回不了家，但8分钟就知道了，你8
: 小时知道。
: 没有delay 5分钟我就买了机票。
: 怎么，自己划下道道，被打脸又不服了？

g*g2010-06-15 07:06

84 楼

我第一分钟就把单下完了，12306 十分钟能下单页面那是运气。
一个大系统有很多挑战，不是架构能行实现就没问题。
但是架构不行怎么实现都有问题。12306就是对后者的实践。
我的设计就是让排队，排到有票排不到没有。如果照你说的，去排队的都是弱智，谁他
妈保证去排队能买着票。别跟我说你没排过，像你这么老实承认弱智的真不多。

【在 m**********j 的大作中提到】

: 你牙这不是胡搅蛮缠吗。
: 8个小时，你看看多少个人有8个小时的问题？
: 你用一个你心里琢磨的都没上过PROD的产品，跟一个经历了风风雨雨洗礼的产品比。
: 还是这个产品出现的一个特例比。
: 你是不是弱智啊。
: 还有你牙刚才口口声声说你的计划就没打算让你买到票。
: 说你是一个弱智那真是对科比的一种侮辱。
:
: 你8

m*j2010-06-15 07:06

85 楼

像你这样的人，先让你们N家的架构都让你说了算，再说别的。
知道你有理想，跟科比一样，觉得总冠军是你一个人贡献的绝大部分。
但你先把你自己家里的事情搞定了。
别动不动就说别人弱智，没人比你家科比更弱智的了。
记住，科比虽然弱智，但心底也知道没有奥尼尔和菲儿杰克逊，鸭就什么都不是，连AI
都不如。

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

: 我第一分钟就把单下完了，12306 十分钟能下单页面那是运气。
: 一个大系统有很多挑战，不是架构能行实现就没问题。
: 但是架构不行怎么实现都有问题。12306就是对后者的实践。
: 我的设计就是让排队，排到有票排不到没有。如果照你说的，去排队的都是弱智，谁他
: 妈保证去排队能买着票。别跟我说你没排过，像你这么老实承认弱智的真不多。

g*g2010-06-15 07:06

86 楼

N家架构我说了不算，但之前10M+用户的架构我说了算的做了2个。
怎么，被技术性打脸，现在又要论出身了？

AI

【在 m**********j 的大作中提到】

: 像你这样的人，先让你们N家的架构都让你说了算，再说别的。
: 知道你有理想，跟科比一样，觉得总冠军是你一个人贡献的绝大部分。
: 但你先把你自己家里的事情搞定了。
: 别动不动就说别人弱智，没人比你家科比更弱智的了。
: 记住，科比虽然弱智，但心底也知道没有奥尼尔和菲儿杰克逊，鸭就什么都不是，连AI
: 都不如。

m*j2010-06-15 07:06

87 楼

草，你鸭买不到票就撒泼打滚就转进了。
你就嚷嚷你就没打算让人买到票。
我好心劝你一句让你自己努力，你反倒登鼻子上脸教训起我了？
好，你鸭现在就说，你打算把你说的那句"从来没打算让所有人买到票"放在12306网页
的哪一段？
你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？

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

: N家架构我说了不算，但之前10M+用户的架构我说了算的做了2个。
: 怎么，被技术性打脸，现在又要论出身了？
:
: AI

g*g2010-06-15 07:06

88 楼

尼玛人多票少，系统无论如何设计难道能让所有人买着票？这个买票的是个人都知道，
也就你这种弱智，还要纠缠这个问题。

【在 m**********j 的大作中提到】

: 草，你鸭买不到票就撒泼打滚就转进了。
: 你就嚷嚷你就没打算让人买到票。
: 我好心劝你一句让你自己努力，你反倒登鼻子上脸教训起我了？
: 好，你鸭现在就说，你打算把你说的那句"从来没打算让所有人买到票"放在12306网页
: 的哪一段？
: 你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
: 你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
: 你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
: 你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
: 你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？

m*j2010-06-15 07:06

89 楼

你这个连弱智科比都不如的怎么就还不明白，那么多人骂12306就是因为他们没买到他
们想要的票。
只要票不够，只要他们想早一点回家的那张车票他们买不到，他们就要骂。
他们就是要买到票，买到他们想要的特快票。
你这个弱智敢把你那句话贴在购票网站，就是个死。

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

: 尼玛人多票少，系统无论如何设计难道能让所有人买着票？这个买票的是个人都知道，
: 也就你这种弱智，还要纠缠这个问题。