n****1
发帖数: 1136 | 1 魏老师方案做不到出票时确定座位,而且还需要其他机器来最后关头定座位; goodbug方
案做不到实时, 而且最多要3000台机器.
人家12306只用了17台机器就搞定了实时出票+实时确定座位, 绝对不是盖的. 再加点机
器改善前台UI和反机器人逻辑, 那就完美了. |
T********i
发帖数: 2416 | 2 实时确定座位并不麻烦，多做n次加法就好了。运算最多多50%。
器.
【在 n****1 的大作中提到】
: 魏老师方案做不到出票时确定座位,而且还需要其他机器来最后关头定座位; goodbug方
: 案做不到实时, 而且最多要3000台机器.
: 人家12306只用了17台机器就搞定了实时出票+实时确定座位, 绝对不是盖的. 再加点机
: 器改善前台UI和反机器人逻辑, 那就完美了.
|
b*******s
发帖数: 5216 | 3 你看看我写的关于魏老师设计的一个理解，可以选座
【在 n****1 的大作中提到】
: 魏老师方案做不到出票时确定座位,而且还需要其他机器来最后关头定座位; goodbug方
: 案做不到实时, 而且最多要3000台机器.
: 人家12306只用了17台机器就搞定了实时出票+实时确定座位, 绝对不是盖的. 再加点机
: 器改善前台UI和反机器人逻辑, 那就完美了.
|
n****1
发帖数: 1136 | 4 选座位用啥算法? 是不是像memory allocator一样, 尽最大可能来避免座位
fragmentation?
给个链接吧!
【在 b*******s 的大作中提到】
: 你看看我写的关于魏老师设计的一个理解，可以选座
|
g*****g
发帖数: 34805 | 5 一高峰就挂，根本就是架构设计不能接受的方案。我做的方案是每秒100万的冲击来了
，后端每秒能处理1万张票，我让排着队处理，确实不实时，但公平，用户体验也好，
下单有响应。12306就是随机挑1万个，出了，100个99个没响应，实时没错。公平就完
全说不上，体验也很糟糕。
【在 n****1 的大作中提到】
: 魏老师方案做不到出票时确定座位,而且还需要其他机器来最后关头定座位; goodbug方
: 案做不到实时, 而且最多要3000台机器.
: 人家12306只用了17台机器就搞定了实时出票+实时确定座位, 绝对不是盖的. 再加点机
: 器改善前台UI和反机器人逻辑, 那就完美了.
|
b*******s
发帖数: 5216 | 6 http://www.mitbbs.com/article0/Programming/31283143_0.html
比较简略，不清楚的你指出了我尽力回答
【在 n****1 的大作中提到】
: 选座位用啥算法? 是不是像memory allocator一样, 尽最大可能来避免座位
: fragmentation?
: 给个链接吧!
|
l*****9
发帖数: 9501 | 7 这么大冲击量的应用，要啥实时。可以scale out,杜绝黄牛，就好了 |
n****1
发帖数: 1136 | 8 "用户选中一个座位，递交请求，web server发送对某个位置的请求，就是对那个38个
bytes的一个掩码，想要占据的bits设1，其余0"
你这个步骤步子太大, 不符合实际. memory allocator/seat allocator最难的就是寻
找该向用户提供哪个座位, 而不是回复某个座位是否被占了.
【在 b*******s 的大作中提到】
: http://www.mitbbs.com/article0/Programming/31283143_0.html
: 比较简略，不清楚的你指出了我尽力回答
|
l*****9
发帖数: 9501 | |
n****1
发帖数: 1136 | 10 别这么书生意气, 做非实时系统得首长点头, 不是你个才毕业两年的码农说了算的.
【在 l*****9 的大作中提到】
: 这么大冲击量的应用，要啥实时。可以scale out,杜绝黄牛，就好了
|
|
|
b*******s
发帖数: 5216 | 11 寻找座位是靠cache的数据，这个后台服务器的数据结构是定期同步到cache的
这样在前端你就能判断哪些座位当前是“空”的，不牵涉到对核心服务器的任何操作
【在 n****1 的大作中提到】
: "用户选中一个座位，递交请求，web server发送对某个位置的请求，就是对那个38个
: bytes的一个掩码，想要占据的bits设1，其余0"
: 你这个步骤步子太大, 不符合实际. memory allocator/seat allocator最难的就是寻
: 找该向用户提供哪个座位, 而不是回复某个座位是否被占了.
|
l*****9
发帖数: 9501 | 12 关键是scale out
【在 n****1 的大作中提到】
: 别这么书生意气, 做非实时系统得首长点头, 不是你个才毕业两年的码农说了算的.
|
n****1
发帖数: 1136 | 13 现有系统偏偏都已经做到了, 你可以消停了.
【在 l*****9 的大作中提到】
: 一票难求，还选神马座位
|
l*****9
发帖数: 9501 | 14 所以不能 scale out
【在 n****1 的大作中提到】
: 现有系统偏偏都已经做到了, 你可以消停了.
|
n****1
发帖数: 1136 | 15 我不管你cache不cache, 这个算法复杂度至少是个memory allocator级别的, 同意否?
【在 b*******s 的大作中提到】
: 寻找座位是靠cache的数据，这个后台服务器的数据结构是定期同步到cache的
: 这样在前端你就能判断哪些座位当前是“空”的，不牵涉到对核心服务器的任何操作
|
b*******s
发帖数: 5216 | 16 这个数据结构是可以采用非阻塞同步机制的
在核心服务器上速度是很快的，而且同步可以从某台backup／standby发起
【在 n****1 的大作中提到】
: "用户选中一个座位，递交请求，web server发送对某个位置的请求，就是对那个38个
: bytes的一个掩码，想要占据的bits设1，其余0"
: 你这个步骤步子太大, 不符合实际. memory allocator/seat allocator最难的就是寻
: 找该向用户提供哪个座位, 而不是回复某个座位是否被占了.
|
g*****g
发帖数: 34805 | 17 票少人多，现有系统当然能把票卖完。买票就是撞大运。就跟火车站不排队，大家窗口
前挤着，一样能把票卖完不是。
12306现在就是这样。
【在 n****1 的大作中提到】
: 现有系统偏偏都已经做到了, 你可以消停了.
|
b*******s
发帖数: 5216 | 18 嗯，这点我同意，本质上是个mem allocator
【在 n****1 的大作中提到】
: 我不管你cache不cache, 这个算法复杂度至少是个memory allocator级别的, 同意否?
|
b*******s
发帖数: 5216 | 19 严格来说是个定址的memory allocator，你同意否？
【在 n****1 的大作中提到】
: 我不管你cache不cache, 这个算法复杂度至少是个memory allocator级别的, 同意否?
|
b*******s
发帖数: 5216 | 20 定址的话，查询速度是常量 o（1）
【在 b*******s 的大作中提到】
: 严格来说是个定址的memory allocator，你同意否？
|
|
|
n****1
发帖数: 1136 | 21 这个"局部定址"的allocator查询速度与已经分配的内存块数量有关. 已经分配了n张票
的话, 就相当与有n块可能插入的座位. naive algorithm可以到o(n), 不可能是o(1)
【在 b*******s 的大作中提到】
: 定址的话，查询速度是常量 o（1）
|
b*******s
发帖数: 5216 | 22 不存在避免fragmentation的问题，先到先得
比如连续8站，有人已经占据了后4站，那么任何和后四站有交的请求直接都fail
就是一个comp and swap的操作
【在 n****1 的大作中提到】
: 选座位用啥算法? 是不是像memory allocator一样, 尽最大可能来避免座位
: fragmentation?
: 给个链接吧!
|
b*******s
发帖数: 5216 | 23 顺序数据，我给个例子
比如有1024个车次
我先做一次hash查找，得到某列车的数组的起始地址，这个是o(1)
然后比如10车5号座，假定每车256座，直接从首地址加一个偏移，一样是o（1）
这个数据结构我是lock在内存里的
实际上一个查询 某车某车厢某座的查询，就是两次查表
【在 n****1 的大作中提到】
: 这个"局部定址"的allocator查询速度与已经分配的内存块数量有关. 已经分配了n张票
: 的话, 就相当与有n块可能插入的座位. naive algorithm可以到o(n), 不可能是o(1)
|
n****1
发帖数: 1136 | 24 既然你同意这个是整个12306计算最复杂的地方, 那么我们就可以通过研究这个算法,
来确定一大堆之前很模糊的东西. 包括:
1.设计方案的大O小o
2.方案是否强耦合, 是否能够实现分布计算
3.是否有希望做到实时, 还是goodbug的非实时是唯一方案
把问题抽象化, 分析透彻了, 问题就自然简单了. 而他们争来争去, 就是因为用了不同
的假设(强耦合vs弱耦合), 而从不质疑自己假设的合理性.
【在 b*******s 的大作中提到】
: 嗯，这点我同意，本质上是个mem allocator
|
b*******s
发帖数: 5216 | 25 起始是一次查表加一次简单数学运算，o（1） ＋ o（1）
【在 b*******s 的大作中提到】
: 顺序数据，我给个例子
: 比如有1024个车次
: 我先做一次hash查找，得到某列车的数组的起始地址，这个是o(1)
: 然后比如10车5号座，假定每车256座，直接从首地址加一个偏移，一样是o（1）
: 这个数据结构我是lock在内存里的
: 实际上一个查询 某车某车厢某座的查询，就是两次查表
|
b*******s
发帖数: 5216 | 26 好啊
【在 n****1 的大作中提到】
: 既然你同意这个是整个12306计算最复杂的地方, 那么我们就可以通过研究这个算法,
: 来确定一大堆之前很模糊的东西. 包括:
: 1.设计方案的大O小o
: 2.方案是否强耦合, 是否能够实现分布计算
: 3.是否有希望做到实时, 还是goodbug的非实时是唯一方案
: 把问题抽象化, 分析透彻了, 问题就自然简单了. 而他们争来争去, 就是因为用了不同
: 的假设(强耦合vs弱耦合), 而从不质疑自己假设的合理性.
|
n****1
发帖数: 1136 | 27 譬如一列车广州->北京的车有500个座位, 而且全部被污染(至少有一段被占用). 现在
有个订单是武汉到郑州, 最naive的算法不就是遍历这500个座位, 看看那些座位在武汉
与郑州间是否空缺么? 这明显是o(n)对吧.
如果有多个这样的空缺: 座位1是长沙到郑州空, 座位2是韶关到郑州空, 那么最好是把
座位1分给这个订单, 而不是座位2, 对吗?
【在 b*******s 的大作中提到】
: 顺序数据，我给个例子
: 比如有1024个车次
: 我先做一次hash查找，得到某列车的数组的起始地址，这个是o(1)
: 然后比如10车5号座，假定每车256座，直接从首地址加一个偏移，一样是o（1）
: 这个数据结构我是lock在内存里的
: 实际上一个查询 某车某车厢某座的查询，就是两次查表
|
b*******s
发帖数: 5216 | 28 这个问题我考虑过，但实际中不存在一列车换座这种业务逻辑，都是一张票上车
不过这个想法是大幅度提高资源利用率的好办法
【在 n****1 的大作中提到】
: 譬如一列车广州->北京的车有500个座位, 而且全部被污染(至少有一段被占用). 现在
: 有个订单是武汉到郑州, 最naive的算法不就是遍历这500个座位, 看看那些座位在武汉
: 与郑州间是否空缺么? 这明显是o(n)对吧.
: 如果有多个这样的空缺: 座位1是长沙到郑州空, 座位2是韶关到郑州空, 那么最好是把
: 座位1分给这个订单, 而不是座位2, 对吗?
|
n****1
发帖数: 1136 | 29 我这不就是为了给乘客方便, 做到一张票上车么. 否则就按魏老师那样最后关头定座位
了.
他那样搞法最后肯定要逼着乘客不停换座位.
【在 b*******s 的大作中提到】
: 这个问题我考虑过，但实际中不存在一列车换座这种业务逻辑，都是一张票上车
: 不过这个想法是大幅度提高资源利用率的好办法
|
n****1
发帖数: 1136 | 30 所以应该先读读关于memory allocation最经典的论文, 看看是否有并行算法.
然后参考下jemalloc之类的是怎么做的.
【在 b*******s 的大作中提到】
: 好啊
|
|
|
g*****g
发帖数: 34805 | 31 不用考虑算法也知道实时不可行。就算你后端算法简单，出票很快，也没法跟上前端每
秒百万级的冲击。
冲击来了怎么办？除了缓冲到queue上只有扔单一种做法。而缓冲就不能实时。
12306现在无疑是扔单了，我认为这是不可接受的。架构没有这么弄的，如果这个达不
成一致后面这些讨论就没意义了。
【在 n****1 的大作中提到】
: 既然你同意这个是整个12306计算最复杂的地方, 那么我们就可以通过研究这个算法,
: 来确定一大堆之前很模糊的东西. 包括:
: 1.设计方案的大O小o
: 2.方案是否强耦合, 是否能够实现分布计算
: 3.是否有希望做到实时, 还是goodbug的非实时是唯一方案
: 把问题抽象化, 分析透彻了, 问题就自然简单了. 而他们争来争去, 就是因为用了不同
: 的假设(强耦合vs弱耦合), 而从不质疑自己假设的合理性.
|
n****1
发帖数: 1136 | 32 如果算法简单, 百万级冲击也能加机器实时搞定.
还有就是做好反机器人工作, 这个由前端来做. 查出来了直接列黑名单, 爆料给媒体,
杀一儆百, 看谁还敢搞ddos?
【在 g*****g 的大作中提到】
: 不用考虑算法也知道实时不可行。就算你后端算法简单，出票很快，也没法跟上前端每
: 秒百万级的冲击。
: 冲击来了怎么办？除了缓冲到queue上只有扔单一种做法。而缓冲就不能实时。
: 12306现在无疑是扔单了，我认为这是不可接受的。架构没有这么弄的，如果这个达不
: 成一致后面这些讨论就没意义了。
|
b*******s
发帖数: 5216 | 33 这类算法很多了，你可以推荐一个，但我觉得和选票是有矛盾的，我这个设计里，选票
是用户行为
实际上由于需求巨大，产生的碎片基本都会被填掉，所以一定程度上这不是个问题
【在 n****1 的大作中提到】
: 所以应该先读读关于memory allocation最经典的论文, 看看是否有并行算法.
: 然后参考下jemalloc之类的是怎么做的.
|
n****1
发帖数: 1136 | 34 如果你用过12306就知道, 用户只能选座票或卧铺, 连上中下都没得选的. 现在的却很
多碎片, 他们填碎片的方式就是卖无座票, NND!
出票逻辑比内存分配要更复杂, 因为一个内存分配request只说明大小, 而车票request
要说明在整个内存块中的相对位置. 但我肯定mem allocator一定能给这个问题带来启
发.
【在 b*******s 的大作中提到】
: 这类算法很多了，你可以推荐一个，但我觉得和选票是有矛盾的，我这个设计里，选票
: 是用户行为
: 实际上由于需求巨大，产生的碎片基本都会被填掉，所以一定程度上这不是个问题
|
g*****g
发帖数: 34805 | 35 如果后端可以有效分票，我前后分开的机制仍然是实时的。无非是个queue, 处理快就
是实时，处理慢才是离线。
不矛盾，但我觉得后端处理能力差俩数量级，靠RDBMS分库达不到。前后耦合的风险就
是，一旦冲击比预想大，就要丢单。
就像现在一样。
,
【在 n****1 的大作中提到】
: 如果算法简单, 百万级冲击也能加机器实时搞定.
: 还有就是做好反机器人工作, 这个由前端来做. 查出来了直接列黑名单, 爆料给媒体,
: 杀一儆百, 看谁还敢搞ddos?
|
b*******s
发帖数: 5216 | 36 对于后端能否对付百万次冲击要看分析和实验，我感觉是冲击应该主要在前端上，后面
核心服务器应该能顶住的，毕竟不过是几百万次数学操作而已
【在 g*****g 的大作中提到】
: 不用考虑算法也知道实时不可行。就算你后端算法简单，出票很快，也没法跟上前端每
: 秒百万级的冲击。
: 冲击来了怎么办？除了缓冲到queue上只有扔单一种做法。而缓冲就不能实时。
: 12306现在无疑是扔单了，我认为这是不可接受的。架构没有这么弄的，如果这个达不
: 成一致后面这些讨论就没意义了。
|
n****1
发帖数: 1136 | 37 这个你说得没错,算法好了你的也变实时了.
我只是觉得你在对待12306的问题上太过于纠结数据库, 在核心算法上只是采取粗暴加
机器的态度, 没啥建设性意见. 而老魏的方案虽然漏洞百出, 但是还是有自己思考的过
程的.
还有就是关于丢单, 这个也是看领导/老板的态度, 不该由技术人员拍板.
【在 g*****g 的大作中提到】
: 如果后端可以有效分票，我前后分开的机制仍然是实时的。无非是个queue, 处理快就
: 是实时，处理慢才是离线。
: 不矛盾，但我觉得后端处理能力差俩数量级，靠RDBMS分库达不到。前后耦合的风险就
: 是，一旦冲击比预想大，就要丢单。
: 就像现在一样。
:
: ,
|
g*****g
发帖数: 34805 | 38 内存数据库不了解，x86的机器没见过能撑百万次交易的单机数据库。
【在 b*******s 的大作中提到】
: 对于后端能否对付百万次冲击要看分析和实验，我感觉是冲击应该主要在前端上，后面
: 核心服务器应该能顶住的，毕竟不过是几百万次数学操作而已
|
b*******s
发帖数: 5216 | 39 什么叫实时?
【在 g*****g 的大作中提到】
: 如果后端可以有效分票，我前后分开的机制仍然是实时的。无非是个queue, 处理快就
: 是实时，处理慢才是离线。
: 不矛盾，但我觉得后端处理能力差俩数量级，靠RDBMS分库达不到。前后耦合的风险就
: 是，一旦冲击比预想大，就要丢单。
: 就像现在一样。
:
: ,
|
g*****g
发帖数: 34805 | 40 这不叫纠结，所有大型互联网应用的瓶颈都在数据库上，不在数据库上的那就是有bug.
12306为啥用内存数据库，那就是瓶颈在数据库上。
优化可以有，跟架构没关系。好的架构，先scale out，保证流量大可以加机器来顶住
，算法是后期优化时用的。
你拼命优化，好不容易够了，到时候流量比预想大一倍，架构不scale out就歇菜了，
除了换大机器scale up别无选择，
魏老师的就是这种做法。
【在 n****1 的大作中提到】
: 这个你说得没错,算法好了你的也变实时了.
: 我只是觉得你在对待12306的问题上太过于纠结数据库, 在核心算法上只是采取粗暴加
: 机器的态度, 没啥建设性意见. 而老魏的方案虽然漏洞百出, 但是还是有自己思考的过
: 程的.
: 还有就是关于丢单, 这个也是看领导/老板的态度, 不该由技术人员拍板.
|
|
|
g*****g
发帖数: 34805 | 41 就是下单我可以在用户可以接受的时间内给个确认订上没，通常不能超过1分钟。
【在 b*******s 的大作中提到】
: 什么叫实时?
|
g*****g
发帖数: 34805 | 42 大量丢单是不能接受的，丢单就没有high availability。所有scale out的架构, high
availability是基本原则。
【在 n****1 的大作中提到】
: 这个你说得没错,算法好了你的也变实时了.
: 我只是觉得你在对待12306的问题上太过于纠结数据库, 在核心算法上只是采取粗暴加
: 机器的态度, 没啥建设性意见. 而老魏的方案虽然漏洞百出, 但是还是有自己思考的过
: 程的.
: 还有就是关于丢单, 这个也是看领导/老板的态度, 不该由技术人员拍板.
|
g*********e
发帖数: 14401 | 43
不是实时的出票，就是无能的表现。
农民工兄弟无法接受。任何正常买过票的人都无法接受。
网吧上网容易吗？还等你的破队列 又不是买彩票
【在 g*****g 的大作中提到】
: 一高峰就挂，根本就是架构设计不能接受的方案。我做的方案是每秒100万的冲击来了
: ，后端每秒能处理1万张票，我让排着队处理，确实不实时，但公平，用户体验也好，
: 下单有响应。12306就是随机挑1万个，出了，100个99个没响应，实时没错。公平就完
: 全说不上，体验也很糟糕。
|
n****1
发帖数: 1136 | 44 首先我个人是会坚决上机群的, 我只是说老魏的方案的却有些启发性的东西, 比如内存
数据库.
其次, 12306不只是个普通的互联网应用,而是肩负人类最宏伟的突发性迁移的引导任务
. CPU bound+高要求算法是很正常的. 你应该打破"大型互联网应用的瓶颈都在数据库
上"这种思维定势, 再来看这个问题.
换句话说, 如果你的野心只是想做好"互联网应用", 那这个问题在你的domain之外.
bug.
【在 g*****g 的大作中提到】
: 这不叫纠结，所有大型互联网应用的瓶颈都在数据库上，不在数据库上的那就是有bug.
: 12306为啥用内存数据库，那就是瓶颈在数据库上。
: 优化可以有，跟架构没关系。好的架构，先scale out，保证流量大可以加机器来顶住
: ，算法是后期优化时用的。
: 你拼命优化，好不容易够了，到时候流量比预想大一倍，架构不scale out就歇菜了，
: 除了换大机器scale up别无选择，
: 魏老师的就是这种做法。
|
l*****9
发帖数: 9501 | 45 弃单不可接受。不知为什么没有搞waiting list,那就不需要不断刷票了 |
g*****g
发帖数: 34805 | 46 你舒服舒服下个单子，等几分钟通知你买到没，没买着也在waiting list上。还是疯狂
刷票一天，页面10次有9次打不开，好不容易开了看到有票，下了单没反应，你也不知
道买着没。后面这个
就是正在发生的故事。这年头大家都有手机，发个短信罢了，谁让你在网吧等。
【在 g*********e 的大作中提到】
:
: 不是实时的出票，就是无能的表现。
: 农民工兄弟无法接受。任何正常买过票的人都无法接受。
: 网吧上网容易吗？还等你的破队列 又不是买彩票
|
l*****9
发帖数: 9501 | 47 空想家
【在 n****1 的大作中提到】
: 首先我个人是会坚决上机群的, 我只是说老魏的方案的却有些启发性的东西, 比如内存
: 数据库.
: 其次, 12306不只是个普通的互联网应用,而是肩负人类最宏伟的突发性迁移的引导任务
: . CPU bound+高要求算法是很正常的. 你应该打破"大型互联网应用的瓶颈都在数据库
: 上"这种思维定势, 再来看这个问题.
: 换句话说, 如果你的野心只是想做好"互联网应用", 那这个问题在你的domain之外.
:
: bug.
|
g*****g
发帖数: 34805 | 48 只要低流量没问题，高流量不行的都是I/O bound。只要能分，算法再复杂，机器多也
就算出来了。
12306平时显然没事。
你就别想全人类的伟大事业了，这不是算PI。 我说的只是个常识。
【在 n****1 的大作中提到】
: 首先我个人是会坚决上机群的, 我只是说老魏的方案的却有些启发性的东西, 比如内存
: 数据库.
: 其次, 12306不只是个普通的互联网应用,而是肩负人类最宏伟的突发性迁移的引导任务
: . CPU bound+高要求算法是很正常的. 你应该打破"大型互联网应用的瓶颈都在数据库
: 上"这种思维定势, 再来看这个问题.
: 换句话说, 如果你的野心只是想做好"互联网应用", 那这个问题在你的domain之外.
:
: bug.
|
n****1
发帖数: 1136 | 49 你架构里的"单"是用户知情的情况下下的单, 丢了的却不好.
但目前12306里面, 用户只是查询, 没有"下单"动作(还记得我提的隐形队列么?). 你那
里丢单了, 在目前系统的表现无非就是余票显示不准确罢了, so what?
high
【在 g*****g 的大作中提到】
: 大量丢单是不能接受的，丢单就没有high availability。所有scale out的架构, high
: availability是基本原则。
|
g*****g
发帖数: 34805 | 50 怎么没丢单，网站本身就没啥反应。有打开的时候没反映的，有下单的时候没反映的。
下单没反应就是丢单。网站打不开就叫做没availablity, 这么没啥好争的。
【在 n****1 的大作中提到】
: 你架构里的"单"是用户知情的情况下下的单, 丢了的却不好.
: 但目前12306里面, 用户只是查询, 没有"下单"动作(还记得我提的隐形队列么?). 你那
: 里丢单了, 在目前系统的表现无非就是余票显示不准确罢了, so what?
:
: high
|
|
|
n****1
发帖数: 1136 | 51 为了自己编程方便, 妄图改变世界运作方式的人才是空想家! 订个票还要模仿医院挂号
, 问问你周围非码农, 看看你是不是一根筋.
【在 l*****9 的大作中提到】
: 空想家
|
n****1
发帖数: 1136 | 52 前端做个timeout动作, 直接抛出个cache过的没票页面不就行了. 你这么喜欢把前后端
紧密耦合啊?
【在 g*****g 的大作中提到】
: 怎么没丢单，网站本身就没啥反应。有打开的时候没反映的，有下单的时候没反映的。
: 下单没反应就是丢单。网站打不开就叫做没availablity, 这么没啥好争的。
|
n****1
发帖数: 1136 | 53 你不就想说这帮做互联网的猴子不过在写CRUD的东西罢了, 我同意.
bug.
【在 g*****g 的大作中提到】
: 这不叫纠结，所有大型互联网应用的瓶颈都在数据库上，不在数据库上的那就是有bug.
: 12306为啥用内存数据库，那就是瓶颈在数据库上。
: 优化可以有，跟架构没关系。好的架构，先scale out，保证流量大可以加机器来顶住
: ，算法是后期优化时用的。
: 你拼命优化，好不容易够了，到时候流量比预想大一倍，架构不scale out就歇菜了，
: 除了换大机器scale up别无选择，
: 魏老师的就是这种做法。
|
l*****9
发帖数: 9501 | 54 世界运作方式本来没有网上订票的。现在的方案不能scale out,用户要不断刷票，一旦
高峰期就不能用，不杜绝黄牛。这就是你认为最强的。obviously one cannot talk
sense into stupid brains.
【在 n****1 的大作中提到】
: 为了自己编程方便, 妄图改变世界运作方式的人才是空想家! 订个票还要模仿医院挂号
: , 问问你周围非码农, 看看你是不是一根筋.
|
g*****g
发帖数: 34805 | 55 个把timeout是允许的，大部分request 都timeout, 那就没有availability.
availability本来就是以是否能完成网站定义的正常操作决定的，不是弄个timeout页
面就叫做
没事了。
【在 n****1 的大作中提到】
: 前端做个timeout动作, 直接抛出个cache过的没票页面不就行了. 你这么喜欢把前后端
: 紧密耦合啊?
|
n****1
发帖数: 1136 | 56 So stop posting here, genius!
I'm so stupid that I'm only interested in algorithms, not dictating the
world.
【在 l*****9 的大作中提到】
: 世界运作方式本来没有网上订票的。现在的方案不能scale out,用户要不断刷票，一旦
: 高峰期就不能用，不杜绝黄牛。这就是你认为最强的。obviously one cannot talk
: sense into stupid brains.
|
l*****9
发帖数: 9501 | 57 你根本不懂什么是前后端紧密耦合，鼓吹实时太可笑了
【在 n****1 的大作中提到】
: 前端做个timeout动作, 直接抛出个cache过的没票页面不就行了. 你这么喜欢把前后端
: 紧密耦合啊?
|
g*****g
发帖数: 34805 | 58 Then stop bullshitting in area you don't know. After all, we are talking
about internet application.
This is out of your expertise and interest.
【在 n****1 的大作中提到】
: So stop posting here, genius!
: I'm so stupid that I'm only interested in algorithms, not dictating the
: world.
|
n****1
发帖数: 1136 | 59 我不是这个意思, 我是说cache的页面是一个所有车票显示为0的假消息. 其实也不是假
的, 因为:
1. 我提倡的架构是分布式的, 及时加机器一般不丢单, 要加到3000台肯定不丢单. 别
老拿对老魏的单机那套来压我
2. 丢单就表明的却没票了
如果你没兴趣谈算法的话, 还是别回这帖算了.
【在 g*****g 的大作中提到】
: 个把timeout是允许的，大部分request 都timeout, 那就没有availability.
: availability本来就是以是否能完成网站定义的正常操作决定的，不是弄个timeout页
: 面就叫做
: 没事了。
|
n****1
发帖数: 1136 | 60 OMG, you want to use 3000 nodes to do the backend job, and still claims "
Internet application is IO bound".
And even you believe the problem is IO, you didn't even consider the ec2 SSD
instance, or the ssd-optimized dynamo. You simply add more instance, and
add more cost.
Now we learned 3000 nodes is IO bound.
【在 g*****g 的大作中提到】
: Then stop bullshitting in area you don't know. After all, we are talking
: about internet application.
: This is out of your expertise and interest.
|
|
|
n****1
发帖数: 1136 | 61 You don't know sync vs flush before Wei correct you. So either "Internet
application is IO bound" is wrong, or you just suck at your job.
【在 g*****g 的大作中提到】
: Then stop bullshitting in area you don't know. After all, we are talking
: about internet application.
: This is out of your expertise and interest.
|
g*****g
发帖数: 34805 | 62 Of course the application is IO bound, because the bottleneck is at DB
throughput. It doesn't matter how many nodes are being used elsewhere.
SSD
【在 n****1 的大作中提到】
: OMG, you want to use 3000 nodes to do the backend job, and still claims "
: Internet application is IO bound".
: And even you believe the problem is IO, you didn't even consider the ec2 SSD
: instance, or the ssd-optimized dynamo. You simply add more instance, and
: add more cost.
: Now we learned 3000 nodes is IO bound.
|
g*********e
发帖数: 14401 | 63
re
为了用上自己熟悉的design pattern和架构设计，非要人家改变需求。这算什么码农
【在 n****1 的大作中提到】
: 为了自己编程方便, 妄图改变世界运作方式的人才是空想家! 订个票还要模仿医院挂号
: , 问问你周围非码农, 看看你是不是一根筋.
|
g*****g
发帖数: 34805 | 64 不改需求，宁可网站挂最牛逼。
【在 g*********e 的大作中提到】
:
: re
: 为了用上自己熟悉的design pattern和架构设计，非要人家改变需求。这算什么码农
|
g*****g
发帖数: 34805 | 65 The difference between sync or flush is just a delay. Either way, it's still
IO, and both are still slow compared to in memory operation. Internet app
is IO bound is just a common sense. You just can't stop bullshitting on an
industry you have no idea of.
【在 n****1 的大作中提到】
: You don't know sync vs flush before Wei correct you. So either "Internet
: application is IO bound" is wrong, or you just suck at your job.
|
l*****9
发帖数: 9501 | 66 露珠对超高流量internet application狗皮不通。现有方案最大的问题是不能scale
out,高峰期总当机，performance不可接受。啥时候排座位是再简单和枝节不过的小东
西。
是实时而高峰当掉，还是不实时而时刻available,其实真不需要选择。
没有waiting list,用户要不断刷票，这得多么蠢的工程师才会认为是最好的 |
q*c
发帖数: 9453 | 67 排队几小时买不到票就啥话不敢说，上网买票等 1分钟就不行了？
goosbug 那方案绝对是实践出真知的，简单，稳定 能扩展，没什么华丽的实时。
1 分钟 和 1 秒钟在买票上差别不大～只要保证公平就行。
【在 g*********e 的大作中提到】
:
: re
: 为了用上自己熟悉的design pattern和架构设计，非要人家改变需求。这算什么码农
|
q*c
发帖数: 9453 | 68 简单稳定可靠最重要，启发什么的毫无意义。
【在 n****1 的大作中提到】
: 首先我个人是会坚决上机群的, 我只是说老魏的方案的却有些启发性的东西, 比如内存
: 数据库.
: 其次, 12306不只是个普通的互联网应用,而是肩负人类最宏伟的突发性迁移的引导任务
: . CPU bound+高要求算法是很正常的. 你应该打破"大型互联网应用的瓶颈都在数据库
: 上"这种思维定势, 再来看这个问题.
: 换句话说, 如果你的野心只是想做好"互联网应用", 那这个问题在你的domain之外.
:
: bug.
|
q*c
发帖数: 9453 | 69 世界真正运作方式正是你在太阳底下排队挂号。
知足吧！
【在 n****1 的大作中提到】
: 为了自己编程方便, 妄图改变世界运作方式的人才是空想家! 订个票还要模仿医院挂号
: , 问问你周围非码农, 看看你是不是一根筋.
|
q*c
发帖数: 9453 | 70 强！为了自己需求要求上帝改物理规律那的却是牛叉
【在 g*********e 的大作中提到】
:
: re
: 为了用上自己熟悉的design pattern和架构设计，非要人家改变需求。这算什么码农
|
|
|
b*******s
发帖数: 5216 | 71 好虫兄啊，人不是无所不知的
【在 g*****g 的大作中提到】
: 就是下单我可以在用户可以接受的时间内给个确认订上没，通常不能超过1分钟。
|
g*****g
发帖数: 34805 | 72 我的确知识有限，所以我只谈我懂的互联网应用领域，只用我熟悉的技术。你没看到无
数人已经给我贴标签了，
只懂得套方案。这班上前仆后继的明明连入门级互联网应用经验都没有，非要自己造轮
子，还秒这个秒那个，才
真是无所不知。
【在 b*******s 的大作中提到】
: 好虫兄啊，人不是无所不知的
|
d******r
发帖数: 16947 | 73 网站不能down是first proirity ,
这个做不到，什么算法再好都木有用
【在 n****1 的大作中提到】
: 魏老师方案做不到出票时确定座位,而且还需要其他机器来最后关头定座位; goodbug方
: 案做不到实时, 而且最多要3000台机器.
: 人家12306只用了17台机器就搞定了实时出票+实时确定座位, 绝对不是盖的. 再加点机
: 器改善前台UI和反机器人逻辑, 那就完美了.
|
