k********e
发帖数: 702 | 1 我对非程序员做了个调查，几乎所有人都认为定完票之后要等大半天email或者短信通
知简直是疯了。
想象下生活中，
大家在订票窗口人家不给你确定你的车次和座位，
而是到了订票窗口马上拿个信封回家，给你说下午才能打开看是否订票成功。
不成功再从头来。
窗口倒是不排队不拥挤了。但愤怒群众多半也要打上门了。
不评论技术高低，仅就实用性作个评价。
如果是我理解错了，好虫不要骂。我本来就是小白 |
g*****g
发帖数: 34805 | 2 不是大半天，是10分钟。
你可以把所有备选路线都放入一个单子。
一旦都不成功，没有重来的必要。
如果在 waiting list 上，你可以知道前面有多少人。
绝大多数12306热门线路用户都刷了几个小时才放弃，很难想象他们不能等10分钟。 |
g*****g
发帖数: 34805 | 3 想象一下到火车站领号把你所有打算的线路写上，坐椅子上等通知结果，跟窗口不排队
抢票比，前面的可能被踩死，后面的没准运气好，优劣立分。 |
z****e
发帖数: 54598 | 4 blocking一样让你等
搞不好半天没反映你还以为死机了 |
k********e
发帖数: 702 | 5 嗯，
不重来不可能，有退票呢。
不过，10分钟就比较靠谱。marketing上面可以宣传成：为了防止恶意抢票，每人10分
钟内只能抢一次。。。
哈哈。半路出家技术上我是麻麻的，但是其他方面我思维很灵活。适合当IT manager，
不适合当码工。
【在 g*****g 的大作中提到】
: 不是大半天，是10分钟。
: 你可以把所有备选路线都放入一个单子。
: 一旦都不成功，没有重来的必要。
: 如果在 waiting list 上，你可以知道前面有多少人。
: 绝大多数12306热门线路用户都刷了几个小时才放弃，很难想象他们不能等10分钟。
|
k********e
发帖数: 702 | 6 卫老师的设计理论上就是无限降低这种blocking，
好处是立等可取啊。如果真能实现的话。
符合一般P民期望。
【在 z****e 的大作中提到】
: blocking一样让你等
: 搞不好半天没反映你还以为死机了
|
z****e
发帖数: 54598 | 7 涉及到网络的地方，最大的latency一般都在网络的io上
老魏拼命压缩的是机器内部io，没有找到最关键的地方
分布式减少层与层之间的io是最常见的一个优化手段
到后面光纤什么都上了，成本马上飚上去
【在 k********e 的大作中提到】
: 卫老师的设计理论上就是无限降低这种blocking，
: 好处是立等可取啊。如果真能实现的话。
: 符合一般P民期望。
|
g*****g
发帖数: 34805 | 8 理论而已，实际结果就是现在这样，能看到有票，一提交就出错，反复刷几个小时票没
了。
【在 k********e 的大作中提到】
: 卫老师的设计理论上就是无限降低这种blocking，
: 好处是立等可取啊。如果真能实现的话。
: 符合一般P民期望。
|
g*****g
发帖数: 34805 | 9 waiting list 就是为了不用反复排。
【在 k********e 的大作中提到】
: 嗯，
: 不重来不可能，有退票呢。
: 不过，10分钟就比较靠谱。marketing上面可以宣传成：为了防止恶意抢票，每人10分
: 钟内只能抢一次。。。
: 哈哈。半路出家技术上我是麻麻的，但是其他方面我思维很灵活。适合当IT manager，
: 不适合当码工。
|
k********e
发帖数: 702 | 10 但如果是强耦合的数据的话，分布了也要有数据交流（或者merge排序什么的）情况下
，就会很被动了啊。
老魏的设计如果冗余量足够可行倒是可行，但是一旦需求改变，或者由于不可抗力等原
因造成数据流量突变的话，就很被动了。灵活性是个问题。我觉得。
我也搞不懂了。还是manage一下手下，让他们来设计比较轻松点。自己总是想破头。
【在 z****e 的大作中提到】
: 涉及到网络的地方，最大的latency一般都在网络的io上
: 老魏拼命压缩的是机器内部io，没有找到最关键的地方
: 分布式减少层与层之间的io是最常见的一个优化手段
: 到后面光纤什么都上了，成本马上飚上去
|
|
|
k********e
发帖数: 702 | 11 哦，明白你的意思了。
【在 g*****g 的大作中提到】
: waiting list 就是为了不用反复排。
|
g*****g
发帖数: 34805 | 12 再强耦合对我的系统就是个延迟大小而已。对他直接就是丢单。
【在 k********e 的大作中提到】
: 但如果是强耦合的数据的话，分布了也要有数据交流（或者merge排序什么的）情况下
: ，就会很被动了啊。
: 老魏的设计如果冗余量足够可行倒是可行，但是一旦需求改变，或者由于不可抗力等原
: 因造成数据流量突变的话，就很被动了。灵活性是个问题。我觉得。
: 我也搞不懂了。还是manage一下手下，让他们来设计比较轻松点。自己总是想破头。
|
J*****n
发帖数: 4859 | 13
something too good to be ture, is alway not true.
【在 k********e 的大作中提到】
: 卫老师的设计理论上就是无限降低这种blocking，
: 好处是立等可取啊。如果真能实现的话。
: 符合一般P民期望。
|
h*****a
发帖数: 1718 | 14 我看了一点好虫的设计，等待时间不会有大半天，几分钟而已。
【在 k********e 的大作中提到】
: 我对非程序员做了个调查，几乎所有人都认为定完票之后要等大半天email或者短信通
: 知简直是疯了。
: 想象下生活中，
: 大家在订票窗口人家不给你确定你的车次和座位，
: 而是到了订票窗口马上拿个信封回家，给你说下午才能打开看是否订票成功。
: 不成功再从头来。
: 窗口倒是不排队不拥挤了。但愤怒群众多半也要打上门了。
: 不评论技术高低，仅就实用性作个评价。
: 如果是我理解错了，好虫不要骂。我本来就是小白
|
q*c
发帖数: 9453 | 15 lol 不知道你在哪里混饭，但是据我观察，除了政府国营，底层当官的比马工可要累，
主要是压力大。
管别人干活就好，这是个白痴就知道， 不需要脑子灵活。 只是你要这么干能长久，或
者得有逆天的本事或者得有相当的运气。。。或者就少拿钱了。
【在 k********e 的大作中提到】
: 但如果是强耦合的数据的话，分布了也要有数据交流（或者merge排序什么的）情况下
: ，就会很被动了啊。
: 老魏的设计如果冗余量足够可行倒是可行，但是一旦需求改变，或者由于不可抗力等原
: 因造成数据流量突变的话，就很被动了。灵活性是个问题。我觉得。
: 我也搞不懂了。还是manage一下手下，让他们来设计比较轻松点。自己总是想破头。
|
k********e
发帖数: 702 | 16 不一定啊，假设最差情况下，每个node都必须跟其余node交流，n＊n 的信息交换，你
做到10分钟出结果，信息量多一倍，就需要（2n）＊（2n），是按平方增长啊。100分
钟才能出结果了吗不是？
耦合强的数据下，就有很大危险啊。
可见这个设计跟老魏的设计一样有局限性，没有普适性。
【在 g*****g 的大作中提到】
: 再强耦合对我的系统就是个延迟大小而已。对他直接就是丢单。
|
z****e
发帖数: 54598 | 17 并行处理为什么要通信？
交流了干什么？
你处理你的，我处理我的
最后汇总一下就好了
【在 k********e 的大作中提到】
: 不一定啊，假设最差情况下，每个node都必须跟其余node交流，n＊n 的信息交换，你
: 做到10分钟出结果，信息量多一倍，就需要（2n）＊（2n），是按平方增长啊。100分
: 钟才能出结果了吗不是？
: 耦合强的数据下，就有很大危险啊。
: 可见这个设计跟老魏的设计一样有局限性，没有普适性。
|
k********e
发帖数: 702 | 18 不交流的大部分是做面试题的理想情况下。
【在 z****e 的大作中提到】
: 并行处理为什么要通信？
: 交流了干什么？
: 你处理你的，我处理我的
: 最后汇总一下就好了
|
z****e
发帖数: 54598 | 19 no
现实中你应该尽量不让线程进程去通信
切成一段一段，每一段尽最大可能并行，隔离式并行
最后汇总到一个地方，在同一台机器上再做通信
【在 k********e 的大作中提到】
: 不交流的大部分是做面试题的理想情况下。
|
N********n
发帖数: 8363 | 20
LOL, 你该得图灵奖了。
【在 z****e 的大作中提到】
: 并行处理为什么要通信？
: 交流了干什么？
: 你处理你的，我处理我的
: 最后汇总一下就好了
|
|
|
z****e
发帖数: 54598 | 21 这是看到困难知道自己搞不定，所以绕开
绕开能得图灵奖？你别冒傻了
【在 N********n 的大作中提到】
:
: LOL, 你该得图灵奖了。
|
N********n
发帖数: 8363 | 22
强耦合的东西拆开之后就要交流，否则各干各的操作出来数据是错的。你放
话不用交流听起来很NB啊，我给你预发图灵奖你还不高兴？
【在 z****e 的大作中提到】
: 这是看到困难知道自己搞不定，所以绕开
: 绕开能得图灵奖？你别冒傻了
|
z****e
发帖数: 54598 | 23 那汇总了干什么用？
汇总了之后就不能通信了？
谁告诉你的？
【在 N********n 的大作中提到】
:
: 强耦合的东西拆开之后就要交流，否则各干各的操作出来数据是错的。你放
: 话不用交流听起来很NB啊，我给你预发图灵奖你还不高兴？
|
N********n
发帖数: 8363 | 24
汇总、通信都是有代价的，耦合越深代价越大，蛮干分布会导致代价飙升得
不偿失。
【在 z****e 的大作中提到】
: 那汇总了干什么用？
: 汇总了之后就不能通信了？
: 谁告诉你的？
|
e**o
发帖数: 5509 | 25 不过他这个非实时，也不用交流。
各干各的。然后把结果汇总，再删选处理一遍就行了。
错误结果直接进waiting list。反正结果不是实时公布的。
【在 N********n 的大作中提到】
:
: 汇总、通信都是有代价的，耦合越深代价越大，蛮干分布会导致代价飙升得
: 不偿失。
|
z****e
发帖数: 54598 | 26 对
【在 e**o 的大作中提到】
: 不过他这个非实时，也不用交流。
: 各干各的。然后把结果汇总，再删选处理一遍就行了。
: 错误结果直接进waiting list。反正结果不是实时公布的。
|
N********n
发帖数: 8363 | 27
错误的就是白做了对不对？分部出去互相不交流埋头瞎做，结果做错了还要
汇总时删掉，所以说在紧耦合的条件下强制分布是脱下裤子放屁。
【在 e**o 的大作中提到】
: 不过他这个非实时，也不用交流。
: 各干各的。然后把结果汇总，再删选处理一遍就行了。
: 错误结果直接进waiting list。反正结果不是实时公布的。
|
b*******s
发帖数: 5216 | 28 你没理解好虫方案的要点
【在 e**o 的大作中提到】
: 不过他这个非实时，也不用交流。
: 各干各的。然后把结果汇总，再删选处理一遍就行了。
: 错误结果直接进waiting list。反正结果不是实时公布的。
|
g*****g
发帖数: 34805 | 29 这都啥呀，瓶颈在数据库上，延迟是按单机关系数据库估算的。
【在 k********e 的大作中提到】
: 不一定啊，假设最差情况下，每个node都必须跟其余node交流，n＊n 的信息交换，你
: 做到10分钟出结果，信息量多一倍，就需要（2n）＊（2n），是按平方增长啊。100分
: 钟才能出结果了吗不是？
: 耦合强的数据下，就有很大危险啊。
: 可见这个设计跟老魏的设计一样有局限性，没有普适性。
|
c******3
发帖数: 296 | 30 "10分钟"是根据什么算出来的？
【在 g*****g 的大作中提到】
: 不是大半天，是10分钟。
: 你可以把所有备选路线都放入一个单子。
: 一旦都不成功，没有重来的必要。
: 如果在 waiting list 上，你可以知道前面有多少人。
: 绝大多数12306热门线路用户都刷了几个小时才放弃，很难想象他们不能等10分钟。
|
|
|
c******3
发帖数: 296 | 31 “几分钟而已”是怎么估算出来的？
【在 h*****a 的大作中提到】
: 我看了一点好虫的设计，等待时间不会有大半天，几分钟而已。
|
g*****g
发帖数: 34805 | 32 每天500万成功的单子，数据库每秒1万。
【在 c******3 的大作中提到】
: "10分钟"是根据什么算出来的？
|
c******3
发帖数: 296 | 33 是共用一台数据库写吗？
【在 g*****g 的大作中提到】
: 每天500万成功的单子，数据库每秒1万。
|
g*****g
发帖数: 34805 | 34 sure
【在 c******3 的大作中提到】
: 是共用一台数据库写吗？
|
c******3
发帖数: 296 | 35 每秒1万是Oracle吗？我的印象中到不了那么多。
【在 g*****g 的大作中提到】
: 每天500万成功的单子，数据库每秒1万。
|
g*****g
发帖数: 34805 | 36 看你的 transaction有多复杂，机器有多好，这是个一般的估计。像12306那样上内存
数据库就更快。
【在 c******3 的大作中提到】
: 每秒1万是Oracle吗？我的印象中到不了那么多。
|
k********e
发帖数: 702 | 37 赵老师请解释下，怎样的partition数据才能保证node之间不通信？
做题时当然可以这么说，火车票你用什么model可以把数据在6000台机器上各自运行不
需要交流？
【在 z****e 的大作中提到】
: no
: 现实中你应该尽量不让线程进程去通信
: 切成一段一段，每一段尽最大可能并行，隔离式并行
: 最后汇总到一个地方，在同一台机器上再做通信
|
k********e
发帖数: 702 | 38 好像有点懂你的意思了，track真实的座位数据还是用集中在一台机器上的单个数据库
保证数据一致性，是吗？
其他分布的数据只是为了协助订单过程，不保证最后的出单。
【在 g*****g 的大作中提到】
: sure
|
e**o
发帖数: 5509 | 39 我压根不关心预定系统。
【在 b*******s 的大作中提到】
: 你没理解好虫方案的要点
|
q*c
发帖数: 9453 | 40 关键是前后分离。然后用啥都无所谓，数据库是为了不自己发明各种 acid 轮子。
这样哪怕一下进来 100亿订单，无非就是前面 100万台服务器每人选5个请求给后台，
处理完了最多再送一批请求，票没了，然后 99亿9999。。。请求直接拒绝。
【在 k********e 的大作中提到】
: 好像有点懂你的意思了，track真实的座位数据还是用集中在一台机器上的单个数据库
: 保证数据一致性，是吗？
: 其他分布的数据只是为了协助订单过程，不保证最后的出单。
|
|
|
N********n
发帖数: 8363 | 41
所以说什么CLOUD、HA都是噱头吗，真干活还得走ACID的瓶颈，根本无法分
流。只是前端收REQUEST时分了一下。
【在 q*c 的大作中提到】
: 关键是前后分离。然后用啥都无所谓，数据库是为了不自己发明各种 acid 轮子。
: 这样哪怕一下进来 100亿订单，无非就是前面 100万台服务器每人选5个请求给后台，
: 处理完了最多再送一批请求，票没了，然后 99亿9999。。。请求直接拒绝。
|
q*c
发帖数: 9453 | 42 用户体验不同啊。 你拷贝个大文件要30分钟， 一个系统命令进去就死在那里，也许到
时间搞定也许死机一天完蛋。 另外一个每秒输出当前百分比。。。
你喜欢哪个？
需要的时间物理有极限，没人能改变。体验和效率那是完全不同。
【在 N********n 的大作中提到】
:
: 所以说什么CLOUD、HA都是噱头吗，真干活还得走ACID的瓶颈，根本无法分
: 流。只是前端收REQUEST时分了一下。
|
b*******g
发帖数: 603 | 43 Not everything requires ACID, most services that are not associated with
money don't. Exactly where NoSQL becomes extremely helpful. Don't forget
NoSQL is not only SQL.
And I demo that with 90% fairness, you can reduce 90% of latency. It's all
about tradeoff.
【在 N********n 的大作中提到】
:
: 所以说什么CLOUD、HA都是噱头吗，真干活还得走ACID的瓶颈，根本无法分
: 流。只是前端收REQUEST时分了一下。
|
N********n
发帖数: 8363 | 44
要的就是这句实话。所以不要动辄什么BIG DATA之类的抬出来胡吹一通好像
用个NOSQL一抓就灵包山包海了，差得远呢。一旦后端数据是强耦合啥也没
用, 数据结构的局限性摆在那呢，
【在 q*c 的大作中提到】
: 用户体验不同啊。 你拷贝个大文件要30分钟， 一个系统命令进去就死在那里，也许到
: 时间搞定也许死机一天完蛋。 另外一个每秒输出当前百分比。。。
: 你喜欢哪个？
: 需要的时间物理有极限，没人能改变。体验和效率那是完全不同。
|
q*c
发帖数: 9453 | 45 并不是所有的任务都是强耦合。
就算强耦合任务，也不是每个步骤都强耦合。
就算全部强耦合，也能牺牲少量需求进行分离。
你这是非黑即白，中二青年的人生观。
【在 N********n 的大作中提到】
:
: 要的就是这句实话。所以不要动辄什么BIG DATA之类的抬出来胡吹一通好像
: 用个NOSQL一抓就灵包山包海了，差得远呢。一旦后端数据是强耦合啥也没
: 用, 数据结构的局限性摆在那呢，
|
g*****g
发帖数: 34805 | 46 没有cloud，春运这种比平时高1000倍流量的运营成本就很高。没有NoSQL, 你光把那每
秒百万次的订单写进数据库就很费劲了。取舍一个，你就没HA了。不懂的东西不要瞎评
论。
【在 N********n 的大作中提到】
:
: 要的就是这句实话。所以不要动辄什么BIG DATA之类的抬出来胡吹一通好像
: 用个NOSQL一抓就灵包山包海了，差得远呢。一旦后端数据是强耦合啥也没
: 用, 数据结构的局限性摆在那呢，
|
N********n
发帖数: 8363 | 47
这不就是拿我的话又SPIN了一把吗？CLOUD、HA只是解决了前端收REQUEST的
问题，真处理起来难点还在ACID瓶颈。分布式系统不是想当然，按图索骥把
NOSQL抬出来就什么都可以分流了，一切以数据模型为准，数据如果COUPLE
在一起的啥取巧也没用。
【在 g*****g 的大作中提到】
: 没有cloud，春运这种比平时高1000倍流量的运营成本就很高。没有NoSQL, 你光把那每
: 秒百万次的订单写进数据库就很费劲了。取舍一个，你就没HA了。不懂的东西不要瞎评
: 论。
|
g*****g
发帖数: 34805 | 48 你这不是扯蛋吗，卖票的系统十年以上了，我这架构连上现有的都能用，有什么难的，
你又做不到实时。
【在 N********n 的大作中提到】
:
: 这不就是拿我的话又SPIN了一把吗？CLOUD、HA只是解决了前端收REQUEST的
: 问题，真处理起来难点还在ACID瓶颈。分布式系统不是想当然，按图索骥把
: NOSQL抬出来就什么都可以分流了，一切以数据模型为准，数据如果COUPLE
: 在一起的啥取巧也没用。
|
