g*****g
发帖数: 34805 | 1 只说前端，从下订单到存订单这部分，后端出票部分数据量低几个数量级，而且可以离
线处理，现在就能顶住，不进一步讨论。从前面有文章提到一分钟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年了。
电费，数据中心的开销都是另外的， |
g*****g
发帖数: 34805 | |
d*******r
发帖数: 3299 | |
L******f
发帖数: 5368 | 4 这不仅仅是有多少台机器的问题。
问题是这些机器的数据库
必须实时共享。机器越多，
共享数据库需要时间越长。
每个query之后，所有
机器的数据库必须同时更新。
怎样缩短这个时间才是关键。
【在 g*****g 的大作中提到】
: 靠，技术贴你们不顶，就喜欢吵架。
|
w**z
发帖数: 8232 | 5 刚看完电影回来，周末还看你这样的帖子，太对不起自己了。 再说，对12306 审美疲
劳了。
【在 g*****g 的大作中提到】
: 靠，技术贴你们不顶，就喜欢吵架。
|
g*****g
发帖数: 34805 | 6 如果你知道cassandra的机制，就不会提出这个疑问了。Cassandra的R/W都是linear
scale out的，纯粹的堆机器。
【在 L******f 的大作中提到】
: 这不仅仅是有多少台机器的问题。
: 问题是这些机器的数据库
: 必须实时共享。机器越多，
: 共享数据库需要时间越长。
: 每个query之后，所有
: 机器的数据库必须同时更新。
: 怎样缩短这个时间才是关键。
|
z****g
发帖数: 75 | 7 做这个测试真是浪费钱
就是一个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******f
发帖数: 5368 | 8 没错。哪个所谓的测试，才有
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****g
发帖数: 75 | 9 锁定不是问题，问题是要persistence写log，这个是出票速度瓶颈
如果想把这个提高，两个途径
－ 换成flash，提高IOPS，这个简单
－ 出票并行，这个其实也是可以的，就是一次取多张票，就是一个persistence IO对
应譬如10张票啥的
这样会造成余票不完全准确，但是问题不大，同时可以设个timeout，卖不完退回
去即可，可以保证
在 1sec左右的粒度是精确的，足够实际应用
【在 L******f 的大作中提到】
: 没错。哪个所谓的测试，才有
: 48, 96, 144 and 288 instances
: 跟小孩过家家似的。确实是浪费钱。
: 出票其实就是query。每个query时，
: 数据库必须锁定。query结束，数据库
: 必须同步更新。不可能scale out。
: 要应付12306的需求，现有市场上
: 的商业数据库都不行。
|
g*****g
发帖数: 34805 | 10 所有关于12306都说后台数据库不是问题，你纠结啥。前端订票的人多，后端票少。
往高里估，一个火车3000张票，一个车次20段，6万张，一天一千车次，6千万张。
还分时放票，算分10次发，每次就剩下6百万张，一个始发到终点的就能吃掉20张，平
均算一张票5站就好，总共就是120万个transaction. 稍微像样点的数据库服务器每秒
处理5000到1万个交易没问题，2-4分钟就解决了。但凡票卖完了，应用服务器就直接废
掉订单，或者让剩下的waiting list。无需再操作数据库。
我说了多少次，前端订单数量短时要高票数两到三个数量级，这才是问题。只要前后端
不耦合，后台批量读取，离线处理很容易。
【在 z****g 的大作中提到】
: 做这个测试真是浪费钱
: 就是一个io bound的程序，磁片硬盘，scsi接口，也就是 ～100 IOPS, 测来测去，还
: 不就是这个数字
: 换成flash，快10x没问题
: 如果换OS IO软件，在好的flash disk上能提高100x
: 至于那个12306，唯一不能简单scale out的是出票，修改数据库。
: 看他们自己说的卖票峰值数据，也就是100/sec左右的出票速度。
: transaction要做persistence，这个是瓶颈。它们换成flash disk，理论出票峰值能至
: 少快10x
:
|
|
|
L******f
发帖数: 5368 | 11 如果只是前端问题，那就应当没有任何困难。
简单掏钱买机器就行了。想不通为啥那么多
公司都做不了。
【在 g*****g 的大作中提到】
: 所有关于12306都说后台数据库不是问题，你纠结啥。前端订票的人多，后端票少。
: 往高里估，一个火车3000张票，一个车次20段，6万张，一天一千车次，6千万张。
: 还分时放票，算分10次发，每次就剩下6百万张，一个始发到终点的就能吃掉20张，平
: 均算一张票5站就好，总共就是120万个transaction. 稍微像样点的数据库服务器每秒
: 处理5000到1万个交易没问题，2-4分钟就解决了。但凡票卖完了，应用服务器就直接废
: 掉订单，或者让剩下的waiting list。无需再操作数据库。
: 我说了多少次，前端订单数量短时要高票数两到三个数量级，这才是问题。只要前后端
: 不耦合，后台批量读取，离线处理很容易。
|
g*****g
发帖数: 34805 | 12 因为它的架构做错了，前后端紧密耦合，下单既出票。每秒百万次的余票更新，一下子
要压到后台关系数据库上，顶不住。所以它干脆就不在前端堆机器，让app server拒绝
request.
【在 L******f 的大作中提到】
: 如果只是前端问题，那就应当没有任何困难。
: 简单掏钱买机器就行了。想不通为啥那么多
: 公司都做不了。
|
l*****t
发帖数: 2019 | 13 没错。这种有巨大突发计算需求的，云计算绝对是王道。非常显而易见的道理。
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
|
n****1
发帖数: 1136 | 14 自己搭cassandra和直接用amazon dynamo哪个好? IO bound的话t1.micro都能做
cassandra吧, 而且还是浪费了cpu.
dynamo好像自动用ssd的 |
l*****t
发帖数: 2019 | 15 dynamo现在有这么好么？以前不是说问题多多么？有啥大公司reference?再说
Cassandra和dynamo能差多远。我总觉得抄的或重新搞得系统，从软件层面看更好
【在 n****1 的大作中提到】
: 自己搭cassandra和直接用amazon dynamo哪个好? IO bound的话t1.micro都能做
: cassandra吧, 而且还是浪费了cpu.
: dynamo好像自动用ssd的
|
n****1
发帖数: 1136 | 16 主要是能直接用ssd, 当然cassandra也能用, 但要用很贵的instance. netflix就弄过
ssd, 好像不错但贵:
http://techblog.netflix.com/2012/07/benchmarking-high-performan
Dynamo好像列举了Washington Post在用他们.
【在 l*****t 的大作中提到】
: dynamo现在有这么好么？以前不是说问题多多么？有啥大公司reference?再说
: Cassandra和dynamo能差多远。我总觉得抄的或重新搞得系统，从软件层面看更好
|
L******f
发帖数: 5368 | 17 收到单，当然要query数据库。
所以必然要压到数据库上。
所以，还是后台数据库的问题。
【在 g*****g 的大作中提到】
: 因为它的架构做错了，前后端紧密耦合，下单既出票。每秒百万次的余票更新，一下子
: 要压到后台关系数据库上，顶不住。所以它干脆就不在前端堆机器，让app server拒绝
: request.
|
g*****g
发帖数: 34805 | 18 扯啥呀，下单只要查询静态的数据库，没余票数据也行，每分钟更新一次也行，弄个几
百个数据库拷贝随便查。
至于出票，没有实时要求，不是每个单子都要操作数据库，票卖完了后面的就不用处理
了。
【在 L******f 的大作中提到】
: 收到单，当然要query数据库。
: 所以必然要压到数据库上。
: 所以，还是后台数据库的问题。
|
L******f
发帖数: 5368 | 19 这几百个数据库需要同步实时更新吧？
每分钟更新一次，一定会有票卖重了。
因为系统看到的是一分钟前有票，
就卖了。结果发现一分钟内票已经卖
掉了。这在热门线路肯定会发生，
12306要被骂死了。
下单是为了买票吧？
买票就要数据库query吧？
query就需要锁定这几百数据库吧？
买完票后，这几百个数据库就要
实时更新吧？
几百万个这样的请求压上来，
基本上所有的商业数据库都要
崩溃。
【在 g*****g 的大作中提到】
: 扯啥呀，下单只要查询静态的数据库，没余票数据也行，每分钟更新一次也行，弄个几
: 百个数据库拷贝随便查。
: 至于出票，没有实时要求，不是每个单子都要操作数据库，票卖完了后面的就不用处理
: 了。
|
g*****g
发帖数: 34805 | 20 不需要同步实时更新，纯粹给个非实时的余票信息而已，甚至不给也行。订票就是订票
，订票可不保证有，只有后端锁到票，出了才算出了。后端出票不是实时的，出了票发
email/短信。
【在 L******f 的大作中提到】
: 这几百个数据库需要同步实时更新吧？
: 每分钟更新一次，一定会有票卖重了。
: 因为系统看到的是一分钟前有票，
: 就卖了。结果发现一分钟内票已经卖
: 掉了。这在热门线路肯定会发生，
: 12306要被骂死了。
: 下单是为了买票吧？
: 买票就要数据库query吧？
: query就需要锁定这几百数据库吧？
: 买完票后，这几百个数据库就要
|
|
|
s*****e
发帖数: 16824 | 21 你这种会比现在这样被骂的更惨。到时候别人说我没票，为啥那个啥啥有票，你们一定
搞鬼了。订票系统必须实时，不然就别玩了。
【在 g*****g 的大作中提到】
: 不需要同步实时更新，纯粹给个非实时的余票信息而已，甚至不给也行。订票就是订票
: ，订票可不保证有，只有后端锁到票，出了才算出了。后端出票不是实时的，出了票发
: email/短信。
|
p*****3
发帖数: 488 | 22
感觉实时不大可能吧，如果是查询，订票，出票分离，asynchronous batch 订票(
message
queue啥的)， 如果处理速度够快，用户再刷页面querry request结果等个几分
钟的还可以接受，别等个把小时发邮件通知什么的就可以了
【在 s*****e 的大作中提到】
: 你这种会比现在这样被骂的更惨。到时候别人说我没票，为啥那个啥啥有票，你们一定
: 搞鬼了。订票系统必须实时，不然就别玩了。
|
s*****e
发帖数: 16824 | 23 几分钟还可以，再长肯定不行了。就是几分钟，骂的人都不少，现在网上反映最强烈的
就是
request的时候卡住，再刷一遍已经没票了。这种其实技术上无法避免，但是买票的人
都不懂技术的，也不会理解你。
【在 p*****3 的大作中提到】
:
: 感觉实时不大可能吧，如果是查询，订票，出票分离，asynchronous batch 订票(
: message
: queue啥的)， 如果处理速度够快，用户再刷页面querry request结果等个几分
: 钟的还可以接受，别等个把小时发邮件通知什么的就可以了
|
L******f
发帖数: 5368 | 24 所以我说１２３０６系统很难。
骂１２３０６烂的那些程序猿
根本不懂，在那里瞎骂。
这些程序猿才是真正烂。
鄙视一下。
【在 s*****e 的大作中提到】
: 几分钟还可以，再长肯定不行了。就是几分钟，骂的人都不少，现在网上反映最强烈的
: 就是
: request的时候卡住，再刷一遍已经没票了。这种其实技术上无法避免，但是买票的人
: 都不懂技术的，也不会理解你。
|
e***z
发帖数: 7126 | 25 这种应用显然是自己构建私云更便宜
40天之外还需要跑数据分析对明年的放票/排班次进行优化
而且每天8小时放票这个也可以改。
就这点事情，总计算能力需求大概1000台PC级服务器。
每年花1000wRMB去买云计算还不如自己买机器，数据中心都不用自己盖，几十个机柜就
够了
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
|
g*****g
发帖数: 34805 | 26 每个订单都有时间戳，下订单了就能看见。按时间戳排队，票卖完了也大可以公布最后
一张票出的时间，透明度够了，
你没排上你怪谁。僧多粥少，有人骂是必然的，保证公平就行了。怎么都比现在动不动
就挂强。
【在 s*****e 的大作中提到】
: 你这种会比现在这样被骂的更惨。到时候别人说我没票，为啥那个啥啥有票，你们一定
: 搞鬼了。订票系统必须实时，不然就别玩了。
|
P*****x
发帖数: 72 | 27 这个讨论有点意思。
我特地看了一下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*****x
发帖数: 72 | 28 数据中心还是有必要的。要是有自然灾害什么的，总的有个failover 系统吧。
【在 e***z 的大作中提到】
: 这种应用显然是自己构建私云更便宜
: 40天之外还需要跑数据分析对明年的放票/排班次进行优化
: 而且每天8小时放票这个也可以改。
: 就这点事情，总计算能力需求大概1000台PC级服务器。
: 每年花1000wRMB去买云计算还不如自己买机器，数据中心都不用自己盖，几十个机柜就
: 够了
:
: app
|
s******a
发帖数: 527 | 29 买车票最简单的问题，有A，B，C三辆车回家，优先度是A>B>C，出票的时候第一时间抢
A，没有就抢B，再没有就抢C。
说说你的这种先接受订票，等机器处理完了再告诉你订没订上的策略如何满足上面的需
求？
【在 g*****g 的大作中提到】
: 每个订单都有时间戳，下订单了就能看见。按时间戳排队，票卖完了也大可以公布最后
: 一张票出的时间，透明度够了，
: 你没排上你怪谁。僧多粥少，有人骂是必然的，保证公平就行了。怎么都比现在动不动
: 就挂强。
|
y****i
发帖数: 12114 | 30 request的时候卡住，再刷一遍已经没票了
这request什么意思？
看到了不买，再刷一遍就没票了，这不是很正常么。 |
|
|
a*********0
发帖数: 2727 | 31 我们公司的云存储大概1w台机器，20个结点。300台机器？每台都是天河？ |
g*****g
发帖数: 34805 | 32 订票就可以定A不行B，B不行C. 还是一张单子。
后端是离线处理，没实时要求，怎么都能满足。
【在 s******a 的大作中提到】
: 买车票最简单的问题，有A，B，C三辆车回家，优先度是A>B>C，出票的时候第一时间抢
: A，没有就抢B，再没有就抢C。
: 说说你的这种先接受订票，等机器处理完了再告诉你订没订上的策略如何满足上面的需
: 求？
|
p*****3
发帖数: 488 | 33
为什么用时间戳和cassandra cluster呢， 直接上SQS是不是就可以了，多个SQS队列，
batch存取message, 可以大致保证顺序，同一个message可能被多台机器处理，把所有
message处理做成idempotent, 处理poll和process message的server做成stateless的
，batch update DB，瓶颈最后还在DB上。
【在 g*****g 的大作中提到】
: 每个订单都有时间戳，下订单了就能看见。按时间戳排队，票卖完了也大可以公布最后
: 一张票出的时间，透明度够了，
: 你没排上你怪谁。僧多粥少，有人骂是必然的，保证公平就行了。怎么都比现在动不动
: 就挂强。
|
g*****g
发帖数: 34805 | 34 用queue的思路是可以的，不过sqs有性能问题。
【在 p*****3 的大作中提到】
:
: 为什么用时间戳和cassandra cluster呢， 直接上SQS是不是就可以了，多个SQS队列，
: batch存取message, 可以大致保证顺序，同一个message可能被多台机器处理，把所有
: message处理做成idempotent, 处理poll和process message的server做成stateless的
: ，batch update DB，瓶颈最后还在DB上。
|
e***z
发帖数: 7126 | 35 国内盖数据中心，2013年的行情是政府倒贴钱
备灾一般来说只需数据备份，无需计算能力。
这两项都可以做，自己持有硬件还是更便宜，而且数据保密性更好。 不会被云平台偷
偷卖给航空公司去挖掘。
用云计算比较合算的情况是每年只需几天，但是这几天需要几百几千台机器这种.类似
于原来做个什么实验预约超级计算机几小时这种。
如果每年需要超高计算密度两个月连续使用，就难以提高效率了。人家玩云计算的也要
赚钱。
类比一下就是每年有两个月有足够的运量满足一个1000台卡车的车队，然后有人说养车
队太贵了，不如都用UPS，还能打折。呵呵。读书读傻了。
云计算推广时期，现在还没有峰谷时刻收费不同的概念，将来必然出现。所以铁路这种
，弄到第三方平台上去，现在恐怕人家为了你这单生意赔钱都肯做，不过将来肯定涨价
，然后铁路等着将来挨宰。
所以最佳方案是自己弄一个云平台，然后低峰时段卖给政府，政府再免费送给中科院来
提高效率。
【在 P*****x 的大作中提到】
: 数据中心还是有必要的。要是有自然灾害什么的，总的有个failover 系统吧。
|
g*****g
发帖数: 34805 | 36 Amazon早就有分段收费了。这个一年就40天春运，春运需要平时100倍机器，说云计算
不划算是不可能的。
自己盖数据中心把剩余计算力租出去，那是amazon, taobao, 12306显然不合适。
【在 e***z 的大作中提到】
: 国内盖数据中心，2013年的行情是政府倒贴钱
: 备灾一般来说只需数据备份，无需计算能力。
: 这两项都可以做，自己持有硬件还是更便宜，而且数据保密性更好。 不会被云平台偷
: 偷卖给航空公司去挖掘。
: 用云计算比较合算的情况是每年只需几天，但是这几天需要几百几千台机器这种.类似
: 于原来做个什么实验预约超级计算机几小时这种。
: 如果每年需要超高计算密度两个月连续使用，就难以提高效率了。人家玩云计算的也要
: 赚钱。
: 类比一下就是每年有两个月有足够的运量满足一个1000台卡车的车队，然后有人说养车
: 队太贵了，不如都用UPS，还能打折。呵呵。读书读傻了。
|
p*****3
发帖数: 488 | 37
多分几个message queue
【在 g*****g 的大作中提到】
: 用queue的思路是可以的，不过sqs有性能问题。
|
z****e
发帖数: 54598 | 38 基本正确
以魏老师为代表的程序员对这种系统完全是狗屁不通
【在 L******f 的大作中提到】
: 所以我说１２３０６系统很难。
: 骂１２３０６烂的那些程序猿
: 根本不懂，在那里瞎骂。
: 这些程序猿才是真正烂。
: 鄙视一下。
|
m**********j
发帖数: 8645 | 39 笨啊，当然应该是abc一起抢了，等抢下来再决定退哪张。
【在 g*****g 的大作中提到】
: 订票就可以定A不行B，B不行C. 还是一张单子。
: 后端是离线处理，没实时要求，怎么都能满足。
|
t*********a
发帖数: 366 | 40 同意。问题是我认为现在这个问题无解，如果都要实时的话。
【在 L******f 的大作中提到】
: 这不仅仅是有多少台机器的问题。
: 问题是这些机器的数据库
: 必须实时共享。机器越多，
: 共享数据库需要时间越长。
: 每个query之后，所有
: 机器的数据库必须同时更新。
: 怎样缩短这个时间才是关键。
|
|
|
w*********m
发帖数: 4740 | 41 搞一个透明的队排，让用户知道是在排队，不是买到表了。和实体购表类似
【在 s*****e 的大作中提到】
: 你这种会比现在这样被骂的更惨。到时候别人说我没票，为啥那个啥啥有票，你们一定
: 搞鬼了。订票系统必须实时，不然就别玩了。
|
j********p
发帖数: 9680 | 42 应用程序级别,考虑异步队列处理是对的.
数据库级别,考虑分布式数据库,把重要的Table尽量拆分到性能比较强的机器上.
如果有必要的话,对query进行必要的简化和优化.
设置脏读是有必要的.不要动不动就锁表长时间.
死锁一定要避免.
对实时的理解,在客户和设计者来说概念是不一样的.
在设计者角度来说,只要把整个过程的时间控制在一个范围内,
对于客户,就是实时的. |
w*********m
发帖数: 4740 | 43 每个班次一个队
如果一个队都忙不过来加人，就搞多个队，然后卖票的时候按ts merge sort
当然这只能解决用户输入了班次的情况
如果象一半航空订票的方式，输入起点和终点，有几种路径，不同价格，每个包括几个
车次，必须全订到才可以。那就要跨车次查了，这样就的全国的队一起按ts merge
sort，除非能按graph分好互补联系的clusters。
用storm行不？
如果要象优化，满足最多人订到票的需求则更复杂。如果要优化车次的排放还要更复杂。
【在 w*********m 的大作中提到】
: 搞一个透明的队排，让用户知道是在排队，不是买到表了。和实体购表类似
|
e***z
发帖数: 7126 | 44 扯淡100倍。 而且除了春运还有5/1. 10/1， 暑假
40天可以延长到60天甚至更长
不做UPS但是自己有卡车车队的公司多了。
【在 g*****g 的大作中提到】
: Amazon早就有分段收费了。这个一年就40天春运，春运需要平时100倍机器，说云计算
: 不划算是不可能的。
: 自己盖数据中心把剩余计算力租出去，那是amazon, taobao, 12306显然不合适。
|
g*****g
发帖数: 34805 | 45 你才扯蛋，春运又不是每天都有人抢票，初一出发的票就好买。票也不是一直都抢，要
是票一下子全放出来，一个小时内就弄完了。云计算就是可以动态根据流量来scale up
/down。按最高需要来买机器就是亏本了事。
有自己卡车车队的公司多了，没见到几乎每个公司圣诞出货都得延迟？都按圣诞维护车
队，平时放羊？有点常识好不好。
【在 e***z 的大作中提到】
: 扯淡100倍。 而且除了春运还有5/1. 10/1， 暑假
: 40天可以延长到60天甚至更长
: 不做UPS但是自己有卡车车队的公司多了。
|
a***n
发帖数: 538 | 46 有多少人抢票和出多少张票关系不大吧。其实跟小米学就可以了，直接前台说没票了就
可以。 |
v***a
发帖数: 903 | |
m**********j
发帖数: 8645 | 48 虫，扯大了。
春运一开始售票，就都是蜂拥而上。
因为晚去的可能就根本买不到票了。
你买过春运的票吗?
up
【在 g*****g 的大作中提到】
: 你才扯蛋，春运又不是每天都有人抢票，初一出发的票就好买。票也不是一直都抢，要
: 是票一下子全放出来，一个小时内就弄完了。云计算就是可以动态根据流量来scale up
: /down。按最高需要来买机器就是亏本了事。
: 有自己卡车车队的公司多了，没见到几乎每个公司圣诞出货都得延迟？都按圣诞维护车
: 队，平时放羊？有点常识好不好。
|
m**********j
发帖数: 8645 | 49 小米那招在车票上不好使。
等着回家的人会一直刷新的，你服务器的符合根本就不会下来。
【在 a***n 的大作中提到】
: 有多少人抢票和出多少张票关系不大吧。其实跟小米学就可以了，直接前台说没票了就
: 可以。
|
g*****g
发帖数: 34805 | 50 我当然买过，12306我都用过，还好买的票不热门。你说的蜂拥而上跟我说的矛盾是？
【在 m**********j 的大作中提到】
: 虫，扯大了。
: 春运一开始售票，就都是蜂拥而上。
: 因为晚去的可能就根本买不到票了。
: 你买过春运的票吗?
:
: up
|
|
|
m**********j
发帖数: 8645 | 51 在开始能买春运票的那一瞬间，会有上亿次的点击冲击网站。
就像我单开的帖子说的那样，
第一，你把买春运火车票的类比为500万在北美生活的华人。
第二，你把从北美飞往去世界各地的航班看作春运的火车车次。
第三，你把春运的第一天看作是美国对中国宣战的第一天了。北美的华人一下子就成为
了美国的敌人。
500来万的华人都想最快最早地坐航班离开美国。你是打算早买早走，还是晚买晚走，
要知道晚买了哪怕一分钟就可能一张票都木有，就剩下当靶子了。
这个时候，没有任何一个常规的运力能够解决这个，全瘫痪了。
你这个幸运的从没自己买过春运票的人是不会理解这些的。
【在 g*****g 的大作中提到】
: 我当然买过，12306我都用过，还好买的票不热门。你说的蜂拥而上跟我说的矛盾是？
|
g*****g
发帖数: 34805 | 52 I服了U，感情我说了这半天，我说啥你完全没看呀。你有多少张单子过来，我都给你收
着。后台慢慢处理。运力不够不错，先来的有票，后来的没票。
【在 m**********j 的大作中提到】
: 在开始能买春运票的那一瞬间，会有上亿次的点击冲击网站。
: 就像我单开的帖子说的那样，
: 第一，你把买春运火车票的类比为500万在北美生活的华人。
: 第二，你把从北美飞往去世界各地的航班看作春运的火车车次。
: 第三，你把春运的第一天看作是美国对中国宣战的第一天了。北美的华人一下子就成为
: 了美国的敌人。
: 500来万的华人都想最快最早地坐航班离开美国。你是打算早买早走，还是晚买晚走，
: 要知道晚买了哪怕一分钟就可能一张票都木有，就剩下当靶子了。
: 这个时候，没有任何一个常规的运力能够解决这个，全瘫痪了。
: 你这个幸运的从没自己买过春运票的人是不会理解这些的。
|
m**********j
发帖数: 8645 | 53 你先回答我，你那次没买到特快，是为啥？
【在 g*****g 的大作中提到】
: I服了U，感情我说了这半天，我说啥你完全没看呀。你有多少张单子过来，我都给你收
: 着。后台慢慢处理。运力不够不错，先来的有票，后来的没票。
|
m**********j
发帖数: 8645 | 54 就拿你那次没买到特快只好选择别的方式回家来说。
如果你是5天之后才得知你没有买上特快，你怎么办？去订直快吧？
然后5天之后通知你，抱歉，直快也没了，你怎么办？去订普快吧？
然后5天之后通知你，抱歉，普快也没了，你怎么办？
因为今天已经是大年初二了，你也甭回家了。
【在 g*****g 的大作中提到】
: I服了U，感情我说了这半天，我说啥你完全没看呀。你有多少张单子过来，我都给你收
: 着。后台慢慢处理。运力不够不错，先来的有票，后来的没票。
|
g*****g
发帖数: 34805 | 55 你一张单子，写着
来特快100次一张，100次没有普快200次，200次没有300次也行。
再复杂一点，先大年23的，23没有24，24没有25，车次优先还是时间优先也自己定。
下单后几分钟跟你短信通知结果，有啥不行？你到窗口还不是一样这么问一圈，都写进
单子里系统帮你处理了不好？
【在 m**********j 的大作中提到】
: 就拿你那次没买到特快只好选择别的方式回家来说。
: 如果你是5天之后才得知你没有买上特快，你怎么办？去订直快吧？
: 然后5天之后通知你，抱歉，直快也没了，你怎么办？去订普快吧？
: 然后5天之后通知你，抱歉，普快也没了，你怎么办？
: 因为今天已经是大年初二了，你也甭回家了。
|
m**********j
发帖数: 8645 | 56 几分钟后，比如3分钟吧，服务器处理完了你的申请给你发短信了，你收到短信了，短
信通知你特快没了，普快没了，300次也没了。
但就这3分钟，你耽误了没去买飞机票。
飞机票在你收到短信的时候，刚巧刚刚卖完。
你碰巧赶上中国电信、中国移动、中国联通业务繁忙，出现了短消息发送的滞后，滞后
了5分钟。
你要知道，3分钟加5分钟，一共8分钟，你本来是能够想别的办法的。
【在 g*****g 的大作中提到】
: 你一张单子，写着
: 来特快100次一张，100次没有普快200次，200次没有300次也行。
: 再复杂一点，先大年23的，23没有24，24没有25，车次优先还是时间优先也自己定。
: 下单后几分钟跟你短信通知结果，有啥不行？你到窗口还不是一样这么问一圈，都写进
: 单子里系统帮你处理了不好？
|
g*****g
发帖数: 34805 | 57 有可能。但总比你刷了一整天车票，100次有99次进不去，好容易一次刷到了，提交没
响应想砸电脑。刷票8小时才放弃，飞机票还是8分钟就卖完了。我浪费了8分钟，你浪
费了8小时。
【在 m**********j 的大作中提到】
: 几分钟后，比如3分钟吧，服务器处理完了你的申请给你发短信了，你收到短信了，短
: 信通知你特快没了，普快没了，300次也没了。
: 但就这3分钟，你耽误了没去买飞机票。
: 飞机票在你收到短信的时候，刚巧刚刚卖完。
: 你碰巧赶上中国电信、中国移动、中国联通业务繁忙，出现了短消息发送的滞后，滞后
: 了5分钟。
: 你要知道，3分钟加5分钟，一共8分钟，你本来是能够想别的办法的。
|
m**********j
发帖数: 8645 | 58 不错，我刚才说的也有可能会持续8个多小时你才能收到短消息说你没票。
因为没人能保证你收到短消息需要多长时间。
如果你短消息收到的时间超过了你的预期，是服务器没有处理完你的order呢，还是处
理器准备好给你的消息呢，还是移动服务商没有把处理器准备好的消息发出给你呢....
...
国内、国外短信出现delay，甚至没发出来的事情又不是一次两次了。
【在 g*****g 的大作中提到】
: 有可能。但总比你刷了一整天车票，100次有99次进不去，好容易一次刷到了，提交没
: 响应想砸电脑。刷票8小时才放弃，飞机票还是8分钟就卖完了。我浪费了8分钟，你浪
: 费了8小时。
|
g*****g
发帖数: 34805 | 59 短信，email同时发。不放心还可以到12306刷你的订单状态。我那个网站是有响应的，
不像你的没有。银行设定转账干过吧？到时间帮你转，转了给你发邮件。你不放心移动
可以一直刷银行网站，刷到出来为止。
..
【在 m**********j 的大作中提到】
: 不错，我刚才说的也有可能会持续8个多小时你才能收到短消息说你没票。
: 因为没人能保证你收到短消息需要多长时间。
: 如果你短消息收到的时间超过了你的预期，是服务器没有处理完你的order呢，还是处
: 理器准备好给你的消息呢，还是移动服务商没有把处理器准备好的消息发出给你呢....
: ...
: 国内、国外短信出现delay，甚至没发出来的事情又不是一次两次了。
|
m**********j
发帖数: 8645 | 60 草，说了半天，尼玛还是刷网站。
刷吧，谁让你不早点去排队呢，买不到票真是活该。
【在 g*****g 的大作中提到】
: 短信，email同时发。不放心还可以到12306刷你的订单状态。我那个网站是有响应的，
: 不像你的没有。银行设定转账干过吧？到时间帮你转，转了给你发邮件。你不放心移动
: 可以一直刷银行网站，刷到出来为止。
:
: ..
|
|
|
k********e
发帖数: 702 | 61 趁好虫还没回答，我先来给他添个堵：
他前面已经回答过类似的问题，就是：直接在一单里就选：买特快，不行就买直快，再
次买普快。
让系统后台慢慢处理他这几个选项。
其实。。。这个轻描淡写的解决方法还不够实用。用户需要的是交互选择的功能，A不
行了不是说马上就default到B，而是要问：B多少钱？要多花多少时间？什么时间出发
？我再看看C多少钱。。。
【在 m**********j 的大作中提到】
: 就拿你那次没买到特快只好选择别的方式回家来说。
: 如果你是5天之后才得知你没有买上特快，你怎么办？去订直快吧？
: 然后5天之后通知你，抱歉，直快也没了，你怎么办？去订普快吧？
: 然后5天之后通知你，抱歉，普快也没了，你怎么办？
: 因为今天已经是大年初二了，你也甭回家了。
|
g*****g
发帖数: 34805 | 62 我做不到，也不知道能做到的办法。但是ABC的信息是静态的可以在你查询的时候给出
来。
你下单的时候自己做好决定。
如果智力不够弄不来，也可以一样买一张，回头再退。
【在 k********e 的大作中提到】
: 趁好虫还没回答，我先来给他添个堵：
: 他前面已经回答过类似的问题，就是：直接在一单里就选：买特快，不行就买直快，再
: 次买普快。
: 让系统后台慢慢处理他这几个选项。
: 其实。。。这个轻描淡写的解决方法还不够实用。用户需要的是交互选择的功能，A不
: 行了不是说马上就default到B，而是要问：B多少钱？要多花多少时间？什么时间出发
: ？我再看看C多少钱。。。
|
g*****g
发帖数: 34805 | 63 尼玛要杞人忧天，担心移动耽误你的短信，自然可以刷网站。我老人家放心移动，
该干嘛干嘛去。
【在 m**********j 的大作中提到】
: 草，说了半天，尼玛还是刷网站。
: 刷吧，谁让你不早点去排队呢，买不到票真是活该。
|
m**********j
发帖数: 8645 | 64 喂，退票？
20%的退票费是不是你说的。
【在 g*****g 的大作中提到】
: 我做不到，也不知道能做到的办法。但是ABC的信息是静态的可以在你查询的时候给出
: 来。
: 你下单的时候自己做好决定。
: 如果智力不够弄不来，也可以一样买一张，回头再退。
|
g*****g
发帖数: 34805 | 65 不是我说的，从架构角度不需要。从减少黄牛角度不失一个好的策略。
【在 m**********j 的大作中提到】
: 喂，退票？
: 20%的退票费是不是你说的。
|
m**********j
发帖数: 8645 | 66 是你买票，是你买不到特快票。
是你买不到特快票，只好做3天的火车而不是44个小时的火车回的家。
少了和你家人团聚欢庆春节的时光。
【在 g*****g 的大作中提到】
: 尼玛要杞人忧天，担心移动耽误你的短信，自然可以刷网站。我老人家放心移动，
: 该干嘛干嘛去。
|
m**********j
发帖数: 8645 | 67 尼玛，你直说，退票要不要罚款？
【在 g*****g 的大作中提到】
: 不是我说的，从架构角度不需要。从减少黄牛角度不失一个好的策略。
|
g*****g
发帖数: 34805 | 68 事实上是移动没delay, 我老人家3分钟后收到短信说票都没了，赶在8分钟机票卖完之
前买了机票。
您老刷了一天票，最终放弃，买机票得知8分钟的时候已经卖完了，气得把电脑砸了。
结果就是我多花了钱回家过年，你会不了家连电脑也坏了。
【在 m**********j 的大作中提到】
: 是你买票，是你买不到特快票。
: 是你买不到特快票，只好做3天的火车而不是44个小时的火车回的家。
: 少了和你家人团聚欢庆春节的时光。
|
m**********j
发帖数: 8645 | 69 草，虫虫开始撒娇打滚了。
这招经常看你在篮球版上使，想不到有一天你居然真会用到了这里。
【在 g*****g 的大作中提到】
: 事实上是移动没delay, 我老人家3分钟后收到短信说票都没了，赶在8分钟机票卖完之
: 前买了机票。
: 您老刷了一天票，最终放弃，买机票得知8分钟的时候已经卖完了，气得把电脑砸了。
: 结果就是我多花了钱回家过年，你会不了家连电脑也坏了。
|
g*****g
发帖数: 34805 | 70 这都是按照你的设计走，3分钟delay也是你说的，8分钟机票卖完也是你说的。
区别在于移动有没有delay短信5分钟。有我跟你一样回不了家，但8分钟就知道了，你8
小时知道。
没有delay 5分钟我就买了机票。
怎么，自己划下道道，被打脸又不服了？
【在 m**********j 的大作中提到】
: 草，虫虫开始撒娇打滚了。
: 这招经常看你在篮球版上使，想不到有一天你居然真会用到了这里。
|
|
|
m**********j
发帖数: 8645 | 71 你牙这不是胡搅蛮缠吗。
8个小时，你看看多少个人有8个小时的问题？
你用一个你心里琢磨的都没上过PROD的产品，跟一个经历了风风雨雨洗礼的产品比。
还是这个产品出现的一个特例比。
你是不是弱智啊。
还有你牙刚才口口声声说你的计划就没打算让你买到票。
说你是一个弱智那真是对科比的一种侮辱。
你8
【在 g*****g 的大作中提到】
: 这都是按照你的设计走，3分钟delay也是你说的，8分钟机票卖完也是你说的。
: 区别在于移动有没有delay短信5分钟。有我跟你一样回不了家，但8分钟就知道了，你8
: 小时知道。
: 没有delay 5分钟我就买了机票。
: 怎么，自己划下道道，被打脸又不服了？
|
g*****g
发帖数: 34805 | 72 我第一分钟就把单下完了，12306 十分钟能下单页面那是运气。
一个大系统有很多挑战，不是架构能行实现就没问题。
但是架构不行怎么实现都有问题。12306就是对后者的实践。
我的设计就是让排队，排到有票排不到没有。如果照你说的，去排队的都是弱智，谁他
妈保证去排队能买着票。别跟我说你没排过，像你这么老实承认弱智的真不多。
【在 m**********j 的大作中提到】
: 你牙这不是胡搅蛮缠吗。
: 8个小时，你看看多少个人有8个小时的问题？
: 你用一个你心里琢磨的都没上过PROD的产品，跟一个经历了风风雨雨洗礼的产品比。
: 还是这个产品出现的一个特例比。
: 你是不是弱智啊。
: 还有你牙刚才口口声声说你的计划就没打算让你买到票。
: 说你是一个弱智那真是对科比的一种侮辱。
:
: 你8
|
m**********j
发帖数: 8645 | 73 像你这样的人，先让你们N家的架构都让你说了算，再说别的。
知道你有理想，跟科比一样，觉得总冠军是你一个人贡献的绝大部分。
但你先把你自己家里的事情搞定了。
别动不动就说别人弱智，没人比你家科比更弱智的了。
记住，科比虽然弱智，但心底也知道没有奥尼尔和菲儿杰克逊，鸭就什么都不是，连AI
都不如。
【在 g*****g 的大作中提到】
: 我第一分钟就把单下完了，12306 十分钟能下单页面那是运气。
: 一个大系统有很多挑战，不是架构能行实现就没问题。
: 但是架构不行怎么实现都有问题。12306就是对后者的实践。
: 我的设计就是让排队，排到有票排不到没有。如果照你说的，去排队的都是弱智，谁他
: 妈保证去排队能买着票。别跟我说你没排过，像你这么老实承认弱智的真不多。
|
g*****g
发帖数: 34805 | 74 N家架构我说了不算，但之前10M+用户的架构我说了算的做了2个。
怎么，被技术性打脸，现在又要论出身了？
AI
【在 m**********j 的大作中提到】
: 像你这样的人，先让你们N家的架构都让你说了算，再说别的。
: 知道你有理想，跟科比一样，觉得总冠军是你一个人贡献的绝大部分。
: 但你先把你自己家里的事情搞定了。
: 别动不动就说别人弱智，没人比你家科比更弱智的了。
: 记住，科比虽然弱智，但心底也知道没有奥尼尔和菲儿杰克逊，鸭就什么都不是，连AI
: 都不如。
|
m**********j
发帖数: 8645 | 75 草，你鸭买不到票就撒泼打滚就转进了。
你就嚷嚷你就没打算让人买到票。
我好心劝你一句让你自己努力，你反倒登鼻子上脸教训起我了？
好，你鸭现在就说，你打算把你说的那句"从来没打算让所有人买到票"放在12306网页
的哪一段？
你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
【在 g*****g 的大作中提到】
: N家架构我说了不算，但之前10M+用户的架构我说了算的做了2个。
: 怎么，被技术性打脸，现在又要论出身了？
:
: AI
|
g*****g
发帖数: 34805 | 76 尼玛人多票少，系统无论如何设计难道能让所有人买着票？这个买票的是个人都知道，
也就你这种弱智，还要纠缠这个问题。
【在 m**********j 的大作中提到】
: 草，你鸭买不到票就撒泼打滚就转进了。
: 你就嚷嚷你就没打算让人买到票。
: 我好心劝你一句让你自己努力，你反倒登鼻子上脸教训起我了？
: 好，你鸭现在就说，你打算把你说的那句"从来没打算让所有人买到票"放在12306网页
: 的哪一段？
: 你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
: 你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
: 你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
: 你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
: 你打算把你说的那句"从来没打算让所有人买到票"放在12306网页的哪一段？
|
m**********j
发帖数: 8645 | 77 你这个连弱智科比都不如的怎么就还不明白，那么多人骂12306就是因为他们没买到他
们想要的票。
只要票不够，只要他们想早一点回家的那张车票他们买不到，他们就要骂。
他们就是要买到票，买到他们想要的特快票。
你这个弱智敢把你那句话贴在购票网站，就是个死。
【在 g*****g 的大作中提到】
: 尼玛人多票少，系统无论如何设计难道能让所有人买着票？这个买票的是个人都知道，
: 也就你这种弱智，还要纠缠这个问题。
|
