由买买提看人间百态

boards

本页内容为未名空间相应帖子的节选和存档,一周内的贴子最多显示50字,超过一周显示500字 访问原贴
Programming版 - 请老魏给出一个简单的文字解释
相关主题
简单介绍一下老魏的结构静态计数器和订票系统的区别
其实就是两党党争对非程序员而言,好虫的架构很有问题
TeacherWei 的订票机的问题每秒500万, 结论出来看了
学术贴,1M/s ACID Message Queue大规模多核并发的系统PK大规模多机并发的系统
顺便和nod101说说做产品给nod101一个最优化的实时分配车票座位的算法
这坑实在没劲,都是些嘴炮王什么叫直接丢单?说话和做人要有底线,不能张口就来
搞技术的,要有起码的是非观念 by 老魏12306平稳渡过抢票高峰期 最多每秒售出近700张 (转载)
赌约在此说到底还是app 层 engineer 和 系统层engineer在斗法
相关话题的讨论汇总
话题: 抢票话题: acid话题: 老魏话题: mq话题: 请求
进入Programming版参与讨论
1 (共1页)
b***i
发帖数: 3043
1
我也是去了加勒比海溜达了一圈,错过了这个赌局。
略看了一下,一共两个文件,请问哪个函数写了查询?哪个是搜索联票?
现在还晕船,看不太懂。
能否用300字以内的文字,说说关键内容和目的?这样我们检查的时候可以省些精力去
猜。
T********i
发帖数: 2416
2
实在对不起,我代码已经开源了。我说过了,不解释,看个人的悟性,和机缘了。
n*****t
发帖数: 22014
3
没有联程、没有查询,全部是锁票,古德猫宁要求一个请求一个车次

【在 b***i 的大作中提到】
: 我也是去了加勒比海溜达了一圈,错过了这个赌局。
: 略看了一下,一共两个文件,请问哪个函数写了查询?哪个是搜索联票?
: 现在还晕船,看不太懂。
: 能否用300字以内的文字,说说关键内容和目的?这样我们检查的时候可以省些精力去
: 猜。

b***i
发帖数: 3043
4
是吗?goodbug同意了?
没有联程我理解,老魏是客户端来查询,比如javascript,完成联程的搜索。然后用户
点击买票,才发送一个请求到最后面的那个抢票线程来完成。
有没有查询,估计差不多。我估计老魏这个思路,搜索联程票也许经过几毫秒的延时,
最后信息变了,但是只要最后买票是否正确不出错就行。这个在票卖差不多的时候用户
多点几次不同线路。
这个就是这个赌约和老魏的解决方案?那么,怎么保存结果到文件,讨论了吗?效率足
够吗?

【在 n*****t 的大作中提到】
: 没有联程、没有查询,全部是锁票,古德猫宁要求一个请求一个车次
n*****t
发帖数: 22014
5
http://www.mitbbs.com/article_t1/Programming/31462913_0_1.html

【在 b***i 的大作中提到】
: 是吗?goodbug同意了?
: 没有联程我理解,老魏是客户端来查询,比如javascript,完成联程的搜索。然后用户
: 点击买票,才发送一个请求到最后面的那个抢票线程来完成。
: 有没有查询,估计差不多。我估计老魏这个思路,搜索联程票也许经过几毫秒的延时,
: 最后信息变了,但是只要最后买票是否正确不出错就行。这个在票卖差不多的时候用户
: 多点几次不同线路。
: 这个就是这个赌约和老魏的解决方案?那么,怎么保存结果到文件,讨论了吗?效率足
: 够吗?

m********5
发帖数: 17667
6
根本没同意,赵老师和古老师在魏老师写code之前就说清楚了,就算魏老师实现了赌约
,也是白搭,因为他们已经论证了好多次了,就算实现了也不能证明魏老师的系统在实
际卖票中有用。
只有魏老师这一派傻不拉基埋头写code, 这赌还没打,魏老师就已经输定了。

【在 b***i 的大作中提到】
: 是吗?goodbug同意了?
: 没有联程我理解,老魏是客户端来查询,比如javascript,完成联程的搜索。然后用户
: 点击买票,才发送一个请求到最后面的那个抢票线程来完成。
: 有没有查询,估计差不多。我估计老魏这个思路,搜索联程票也许经过几毫秒的延时,
: 最后信息变了,但是只要最后买票是否正确不出错就行。这个在票卖差不多的时候用户
: 多点几次不同线路。
: 这个就是这个赌约和老魏的解决方案?那么,怎么保存结果到文件,讨论了吗?效率足
: 够吗?

n*****t
发帖数: 22014
7
赌约是狗爸提出来的,不过你虽然猜错了开头,结局猜对了,这货是打死不会认账的,
最坏结果也想好了:大不了自杀 goodbug 这个 id,马甲人没说一起自杀。

【在 m********5 的大作中提到】
: 根本没同意,赵老师和古老师在魏老师写code之前就说清楚了,就算魏老师实现了赌约
: ,也是白搭,因为他们已经论证了好多次了,就算实现了也不能证明魏老师的系统在实
: 际卖票中有用。
: 只有魏老师这一派傻不拉基埋头写code, 这赌还没打,魏老师就已经输定了。

b***i
发帖数: 3043
8
reserve(int start, int length, TicketPool *tp, Ticket *t)
里面这个t干啥的?
141 int startDelta = start - t->_start;
142 if (startDelta > 0) {
这个干啥?
我突然deja vu了,最近这个版有人提到吗,很多人争吵Micro Kernel, 还是
monolithic kernel好,整不出个所以然来,只有做出来看一看能不能用才行。

【在 n*****t 的大作中提到】
: http://www.mitbbs.com/article_t1/Programming/31462913_0_1.html
n*****t
发帖数: 22014
9
其实我没细看,刚才匆匆搂了一眼,应该是先 allocate 再 reserve,大概就是找到票
了,然后锁定,t 就是找到的票了吧。感觉两个要结合起来看。

【在 b***i 的大作中提到】
: reserve(int start, int length, TicketPool *tp, Ticket *t)
: 里面这个t干啥的?
: 141 int startDelta = start - t->_start;
: 142 if (startDelta > 0) {
: 这个干啥?
: 我突然deja vu了,最近这个版有人提到吗,很多人争吵Micro Kernel, 还是
: monolithic kernel好,整不出个所以然来,只有做出来看一看能不能用才行。

w****w
发帖数: 521
10
开始有3000张空票,都是从第一站到最后一站。allocate()是找空票,找到后reserve(
)是把空票分成3张空票,中间那张填好返回,剩下的空票放回去以后用.
allocate()用的是实时OS scheduler实现常用的lookup的手段,这是关键一。关键二是
IO用poll不陷入内核,只有开关socket凋用系统。
相关主题
这坑实在没劲,都是些嘴炮王静态计数器和订票系统的区别
搞技术的,要有起码的是非观念 by 老魏对非程序员而言,好虫的架构很有问题
赌约在此每秒500万, 结论出来看了
进入Programming版参与讨论
b***i
发帖数: 3043
11
有两个allocate,我都糊涂了。
用了很多先进技术倒是,就这两个allocate不懂

reserve(

【在 w****w 的大作中提到】
: 开始有3000张空票,都是从第一站到最后一站。allocate()是找空票,找到后reserve(
: )是把空票分成3张空票,中间那张填好返回,剩下的空票放回去以后用.
: allocate()用的是实时OS scheduler实现常用的lookup的手段,这是关键一。关键二是
: IO用poll不陷入内核,只有开关socket凋用系统。

z****e
发帖数: 54598
12

说明根本没有实际干过项目
需求不明确的时候,就开始写代码
基本上是大忌

【在 m********5 的大作中提到】
: 根本没同意,赵老师和古老师在魏老师写code之前就说清楚了,就算魏老师实现了赌约
: ,也是白搭,因为他们已经论证了好多次了,就算实现了也不能证明魏老师的系统在实
: 际卖票中有用。
: 只有魏老师这一派傻不拉基埋头写code, 这赌还没打,魏老师就已经输定了。

z****e
发帖数: 54598
13

认什么账?
你们谁敢说这个是12306?
自己都承认了不是12306,忘记了?
计数器的笑话需要强调一遍?

【在 n*****t 的大作中提到】
: 赌约是狗爸提出来的,不过你虽然猜错了开头,结局猜对了,这货是打死不会认账的,
: 最坏结果也想好了:大不了自杀 goodbug 这个 id,马甲人没说一起自杀。

b******7
发帖数: 123
14
老魏这个方案看到:
1. 把本来的long transaction 切割,分解为前期只读的查询,中期的可以失败的单点
抢票机,和后期带transaction的出票部分,最大限度的缩短了transaction; 巧妙利用
了抢票机出错不影响persistent 数据的设计。
2. 前期,后期容易scale或者partition,因为面对是分解过的问题。
3. 单点抢票无需数据同步。
带来的问题可能有:
1.查到不一定抢到,因为persistent数据和i抢票机数据有延迟;这个用户体验可能会
不好。
2.复杂的联程票等等算法被推到前期部分,这个程序真的和计数器差不多,不过设计理
念还是可取的,起码是一种可以尝试的设计。
z****e
发帖数: 54598
15

re这个

【在 b******7 的大作中提到】
: 老魏这个方案看到:
: 1. 把本来的long transaction 切割,分解为前期只读的查询,中期的可以失败的单点
: 抢票机,和后期带transaction的出票部分,最大限度的缩短了transaction; 巧妙利用
: 了抢票机出错不影响persistent 数据的设计。
: 2. 前期,后期容易scale或者partition,因为面对是分解过的问题。
: 3. 单点抢票无需数据同步。
: 带来的问题可能有:
: 1.查到不一定抢到,因为persistent数据和i抢票机数据有延迟;这个用户体验可能会
: 不好。
: 2.复杂的联程票等等算法被推到前期部分,这个程序真的和计数器差不多,不过设计理

n*****t
发帖数: 22014
16
问题一不存在,这个不同步即使有也是 usec 级的,现实中票的动态变化决定查到抢不
到是常态。实际现在的吞吐也足够应付查询,看业务需要了。

【在 b******7 的大作中提到】
: 老魏这个方案看到:
: 1. 把本来的long transaction 切割,分解为前期只读的查询,中期的可以失败的单点
: 抢票机,和后期带transaction的出票部分,最大限度的缩短了transaction; 巧妙利用
: 了抢票机出错不影响persistent 数据的设计。
: 2. 前期,后期容易scale或者partition,因为面对是分解过的问题。
: 3. 单点抢票无需数据同步。
: 带来的问题可能有:
: 1.查到不一定抢到,因为persistent数据和i抢票机数据有延迟;这个用户体验可能会
: 不好。
: 2.复杂的联程票等等算法被推到前期部分,这个程序真的和计数器差不多,不过设计理

b******7
发帖数: 123
17
到了persistent阶段,有了加锁,同车次/table数据耦合,付款等分布式transaction
两阶段提交等等,性能还会有这么好吗?

问题一不存在,这个不同步即使有也是 usec 级的,现实中票的动态变化决定查到抢不
到是常态。实际现在的吞吐也足够应付查询,看业务需要了。

【在 n*****t 的大作中提到】
: 问题一不存在,这个不同步即使有也是 usec 级的,现实中票的动态变化决定查到抢不
: 到是常态。实际现在的吞吐也足够应付查询,看业务需要了。

n*****t
发帖数: 22014
18
后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票,
也没有数据耦合。抢票节点就是解决加锁和耦合问题的。
付款本身没有耦合问题,每个订单、用户都是独立的,当然付款失败需要返回票源。

transaction

【在 b******7 的大作中提到】
: 到了persistent阶段,有了加锁,同车次/table数据耦合,付款等分布式transaction
: 两阶段提交等等,性能还会有这么好吗?
:
: 问题一不存在,这个不同步即使有也是 usec 级的,现实中票的动态变化决定查到抢不
: 到是常态。实际现在的吞吐也足够应付查询,看业务需要了。

z****e
发帖数: 54598
19

那就把计数器一个车次分配一个
直接用redis做就好了
另外付款本身可能同样存在耦合问题
你是不是从来没思考过多个用户用同一张卡付款的情况?
一个人可以买多张票诶
付款才是真正的麻烦,2-3s是最快的,支付宝现在多长时间返回?
你说说,我遇到过支付宝有长达20min才返回的情况

【在 n*****t 的大作中提到】
: 后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票,
: 也没有数据耦合。抢票节点就是解决加锁和耦合问题的。
: 付款本身没有耦合问题,每个订单、用户都是独立的,当然付款失败需要返回票源。
:
: transaction

n*****t
发帖数: 22014
20
又开始胡扯,真服了。你一万个人用一张卡我也无所谓,只要支付宝告诉我付款成功就
行,有个毛耦合。这些都是传统电商的活,跟抢票毫无关系。

【在 z****e 的大作中提到】
:
: 那就把计数器一个车次分配一个
: 直接用redis做就好了
: 另外付款本身可能同样存在耦合问题
: 你是不是从来没思考过多个用户用同一张卡付款的情况?
: 一个人可以买多张票诶
: 付款才是真正的麻烦,2-3s是最快的,支付宝现在多长时间返回?
: 你说说,我遇到过支付宝有长达20min才返回的情况

相关主题
大规模多核并发的系统PK大规模多机并发的系统12306平稳渡过抢票高峰期 最多每秒售出近700张 (转载)
给nod101一个最优化的实时分配车票座位的算法说到底还是app 层 engineer 和 系统层engineer在斗法
什么叫直接丢单?说话和做人要有底线,不能张口就来应该给魏大师发10个图灵奖。
进入Programming版参与讨论
p*****y
发帖数: 529
21
你说的问题如果你经常买飞机票都会遇到。 航空公司都这么做有两个愿意, 第一是实
际上只有很少一部分人会遇到这样的情况, 通常是在最后大部分票都卖光且路径非常
fragmental的情况下。 第二对航空公司最有利。 商业行为, 不一定都是用户至上的

这种情况基本用户是接受的。

【在 b******7 的大作中提到】
: 老魏这个方案看到:
: 1. 把本来的long transaction 切割,分解为前期只读的查询,中期的可以失败的单点
: 抢票机,和后期带transaction的出票部分,最大限度的缩短了transaction; 巧妙利用
: 了抢票机出错不影响persistent 数据的设计。
: 2. 前期,后期容易scale或者partition,因为面对是分解过的问题。
: 3. 单点抢票无需数据同步。
: 带来的问题可能有:
: 1.查到不一定抢到,因为persistent数据和i抢票机数据有延迟;这个用户体验可能会
: 不好。
: 2.复杂的联程票等等算法被推到前期部分,这个程序真的和计数器差不多,不过设计理

b***i
发帖数: 3043
22
你说的可行,差别不是问题。
但是,联票的话,前端找到两个车次,然后生成两个请求,这个是要同时进行的。我看
老魏的代码reserve只处理一个车。没看到同时检查两个车,或者多个车次的票都存在
才处理的。这个有吗?

【在 n*****t 的大作中提到】
: 问题一不存在,这个不同步即使有也是 usec 级的,现实中票的动态变化决定查到抢不
: 到是常态。实际现在的吞吐也足够应付查询,看业务需要了。

p*****y
发帖数: 529
23
他根本就没懂整个的architecture是什么样的, 你跟他讲一千遍还是没用。

【在 n*****t 的大作中提到】
: 又开始胡扯,真服了。你一万个人用一张卡我也无所谓,只要支付宝告诉我付款成功就
: 行,有个毛耦合。这些都是传统电商的活,跟抢票毫无关系。

n*****t
发帖数: 22014
24
赌约里没有,但这实际恰恰是老魏方案长处,一个请求可以包含多张票,因为是顺序执
行,不会与其他请求冲突产生互锁。

【在 b***i 的大作中提到】
: 你说的可行,差别不是问题。
: 但是,联票的话,前端找到两个车次,然后生成两个请求,这个是要同时进行的。我看
: 老魏的代码reserve只处理一个车。没看到同时检查两个车,或者多个车次的票都存在
: 才处理的。这个有吗?

b***i
发帖数: 3043
25
你是说,老魏的数据结构可以处理这种请求:一种是多个人同乘一趟车,另一种是一个
人换乘。那么,如果客户端的请求发来包含了多个车票的一致请求,那么,老魏的程序
经过简单修改可以处理这样的请求?
怪就怪在这里。为什么当初不在赌约里呢?

【在 n*****t 的大作中提到】
: 赌约里没有,但这实际恰恰是老魏方案长处,一个请求可以包含多张票,因为是顺序执
: 行,不会与其他请求冲突产生互锁。

n*****t
发帖数: 22014
26
架构没问题,争议在性能,一个请求多票和多个请求单票是等价的,如果这些请求连续
执行。古德吧认为每秒不会超过 10 万票,这个节点会成为新瓶颈。
不要求这个是为了验证结果方便,因此还额外增加了 respID。约定多票算多个请求,
古德吧对自己没信心,怕老魏批处理反而提升性能了。

【在 b***i 的大作中提到】
: 你是说,老魏的数据结构可以处理这种请求:一种是多个人同乘一趟车,另一种是一个
: 人换乘。那么,如果客户端的请求发来包含了多个车票的一致请求,那么,老魏的程序
: 经过简单修改可以处理这样的请求?
: 怪就怪在这里。为什么当初不在赌约里呢?

g****u
发帖数: 252
27
我记得在lajixiaoliu2那个赌约出来之前是有的。我不知道为什么最终合同出来
就没了,而且也没有人提出异议。不过只要请求按票数算吞吐量,做不做对性能
没影响。

【在 b***i 的大作中提到】
: 你是说,老魏的数据结构可以处理这种请求:一种是多个人同乘一趟车,另一种是一个
: 人换乘。那么,如果客户端的请求发来包含了多个车票的一致请求,那么,老魏的程序
: 经过简单修改可以处理这样的请求?
: 怪就怪在这里。为什么当初不在赌约里呢?

n*****t
发帖数: 22014
28
一个请求多票对老魏是划算的,一是减少 IO,另外如果第一票没有就不用检查第二张
了,这样也算成功处理 2 单。这是古的吧鸡贼的地方,呵呵。

【在 g****u 的大作中提到】
: 我记得在lajixiaoliu2那个赌约出来之前是有的。我不知道为什么最终合同出来
: 就没了,而且也没有人提出异议。不过只要请求按票数算吞吐量,做不做对性能
: 没影响。

b***i
发帖数: 3043
29
我还有另一个问题,就是如何persist,这个频率多少?或者说,persist在交钱出票那
个环节?
就是说如果系统崩溃了,根据谁交钱来恢复当前状态?

【在 n*****t 的大作中提到】
: 架构没问题,争议在性能,一个请求多票和多个请求单票是等价的,如果这些请求连续
: 执行。古德吧认为每秒不会超过 10 万票,这个节点会成为新瓶颈。
: 不要求这个是为了验证结果方便,因此还额外增加了 respID。约定多票算多个请求,
: 古德吧对自己没信心,怕老魏批处理反而提升性能了。

T********i
发帖数: 2416
30
其实大家讨论技术本来就应该切中肯綮。不应该故意纠缠细枝末节。
相关主题
zz 12306是怎样做成的其实就是两党党争
从12306来看,国内IT水平不高TeacherWei 的订票机的问题
简单介绍一下老魏的结构学术贴,1M/s ACID Message Queue
进入Programming版参与讨论
b***i
发帖数: 3043
31
所以让你提出个300个字的描述,结果你让大家自己想。这不就看到一些细枝末节
为什么你有的函数在.h,有的在.cpp?都在.h岂不是容易看?

【在 T********i 的大作中提到】
: 其实大家讨论技术本来就应该切中肯綮。不应该故意纠缠细枝末节。
w****w
发帖数: 521
32
系统崩溃,丢掉的是client送出去没得到结果的,拿到rain check没付钱的很多。

【在 b***i 的大作中提到】
: 我还有另一个问题,就是如何persist,这个频率多少?或者说,persist在交钱出票那
: 个环节?
: 就是说如果系统崩溃了,根据谁交钱来恢复当前状态?

n*****t
发帖数: 22014
33
抢票节点只保留有票无票这个信息,最坏情况,比如内存挨雷劈了,前端认为抢到票了
到后端一查:没得咯,也就重现抢一次拉倒,用户甚至都不会察觉。

【在 b***i 的大作中提到】
: 我还有另一个问题,就是如何persist,这个频率多少?或者说,persist在交钱出票那
: 个环节?
: 就是说如果系统崩溃了,根据谁交钱来恢复当前状态?

d***a
发帖数: 13752
34
这个是以前mainframe的做法,在不超过极限的情况下可行,效率也很高。
就这么个问题,从2014年初12306崩溃就开始吵了,吵到今年年底?

【在 n*****t 的大作中提到】
: 架构没问题,争议在性能,一个请求多票和多个请求单票是等价的,如果这些请求连续
: 执行。古德吧认为每秒不会超过 10 万票,这个节点会成为新瓶颈。
: 不要求这个是为了验证结果方便,因此还额外增加了 respID。约定多票算多个请求,
: 古德吧对自己没信心,怕老魏批处理反而提升性能了。

b***i
发帖数: 3043
35
假设重启了,那么抢票节点从哪里恢复所有票的状态?

【在 n*****t 的大作中提到】
: 抢票节点只保留有票无票这个信息,最坏情况,比如内存挨雷劈了,前端认为抢到票了
: 到后端一查:没得咯,也就重现抢一次拉倒,用户甚至都不会察觉。

T********i
发帖数: 2416
36
其实很多都是业务逻辑,跟技术没有任何关系。
比如,外围机报有票,给了用户几条路线,用户选了说没票了。这不是很正常?美国网
上抢deal也是这样。
再有就是支付部分。支付可以无限scale这个我想无需争论。大家问到下行支付系统的
latency问题。我说了,下行放一个ACID Message Queue。我暂定1M/s。也就是下行保
证1M/s的下单率。
进了ACID MQ就是进了保险箱了。还可以随意反向查询。保证反向查询>10M/s。每天
1000万票10秒,1亿票100秒出完。够不够?
谁要打一个1M/s ACID MQ的赌?

【在 w****w 的大作中提到】
: 系统崩溃,丢掉的是client送出去没得到结果的,拿到rain check没付钱的很多。
n*****t
发帖数: 22014
37
关键古的吧对这方面的技术一无所知,对你说的极限毫无概念,套用轮子已经成为惯性
。如果就这样也就算了,还连续两年拿这事叫骂老魏。。。。。。

【在 d***a 的大作中提到】
: 这个是以前mainframe的做法,在不超过极限的情况下可行,效率也很高。
: 就这么个问题,从2014年初12306崩溃就开始吵了,吵到今年年底?

n*****t
发帖数: 22014
38
db 记录最终付款、出票状态。实际上出票后还是要通知一下抢票节点,这样可以安全
split 这张票剩余路段了。

【在 b***i 的大作中提到】
: 假设重启了,那么抢票节点从哪里恢复所有票的状态?
d***a
发帖数: 13752
39
这个不是问题。后端用数据库系统,所有车次的所有座位的售票状态和相关信息,都由
数据库系统管理。
中间的那个抢票系统,相当一个中间人,告诉在哪可以买到票。它并不真正负责售票。
这个中间人记得所有车次的所有座位的售票状态(在内存里),和数据库基本保持一致
,稍稍超前一点。如果它崩溃了,从数据库系统重新读取状态就是了。当然这要花一些
时间。
声明一下,我是来打酱油的,吵架不要拉上我。:)

【在 b***i 的大作中提到】
: 假设重启了,那么抢票节点从哪里恢复所有票的状态?
n*****t
发帖数: 22014
40
这个解释很好,就是医院挂号的。腿折了?二楼骨科。淌鼻涕?内科。不生孩子?隔壁
仁爱医院。鸡鸡张豆豆?明天乘早。
挂上号了一般就能看上病,住不住院问医生去。

【在 d***a 的大作中提到】
: 这个不是问题。后端用数据库系统,所有车次的所有座位的售票状态和相关信息,都由
: 数据库系统管理。
: 中间的那个抢票系统,相当一个中间人,告诉在哪可以买到票。它并不真正负责售票。
: 这个中间人记得所有车次的所有座位的售票状态(在内存里),和数据库基本保持一致
: ,稍稍超前一点。如果它崩溃了,从数据库系统重新读取状态就是了。当然这要花一些
: 时间。
: 声明一下,我是来打酱油的,吵架不要拉上我。:)

相关主题
学术贴,1M/s ACID Message Queue搞技术的,要有起码的是非观念 by 老魏
顺便和nod101说说做产品赌约在此
这坑实在没劲,都是些嘴炮王静态计数器和订票系统的区别
进入Programming版参与讨论
w****w
发帖数: 521
41
只能感叹现在的硬件。当年我写程序的时候,ram只有几十个bytes, code要switch ROM
bank, 大点应用还要multitasking,那才是真正的上世纪老古董。

【在 T********i 的大作中提到】
: 其实很多都是业务逻辑,跟技术没有任何关系。
: 比如,外围机报有票,给了用户几条路线,用户选了说没票了。这不是很正常?美国网
: 上抢deal也是这样。
: 再有就是支付部分。支付可以无限scale这个我想无需争论。大家问到下行支付系统的
: latency问题。我说了,下行放一个ACID Message Queue。我暂定1M/s。也就是下行保
: 证1M/s的下单率。
: 进了ACID MQ就是进了保险箱了。还可以随意反向查询。保证反向查询>10M/s。每天
: 1000万票10秒,1亿票100秒出完。够不够?
: 谁要打一个1M/s ACID MQ的赌?

T********i
发帖数: 2416
42
看你用啥硬件吧?51,98之类的也没那么不堪。
虽然我43都不到,53俱乐部那些DJS130我还是看着它运行看着它退役的。
VAX11780也用过。

ROM

【在 w****w 的大作中提到】
: 只能感叹现在的硬件。当年我写程序的时候,ram只有几十个bytes, code要switch ROM
: bank, 大点应用还要multitasking,那才是真正的上世纪老古董。

w****w
发帖数: 521
43
6800, VAX11/725,HC11...

【在 T********i 的大作中提到】
: 看你用啥硬件吧?51,98之类的也没那么不堪。
: 虽然我43都不到,53俱乐部那些DJS130我还是看着它运行看着它退役的。
: VAX11780也用过。
:
: ROM

T********i
发帖数: 2416
44
您是老前辈,我多有失礼,还请见谅。

【在 w****w 的大作中提到】
: 6800, VAX11/725,HC11...
w****w
发帖数: 521
45
不敢不敢,我十几年前已经被淘汰了。

【在 T********i 的大作中提到】
: 您是老前辈,我多有失礼,还请见谅。
d***a
发帖数: 13752
46
前辈啊!我读书时已经可以用256KB的内存了。

ROM

【在 w****w 的大作中提到】
: 只能感叹现在的硬件。当年我写程序的时候,ram只有几十个bytes, code要switch ROM
: bank, 大点应用还要multitasking,那才是真正的上世纪老古董。

T********i
发帖数: 2416
47
我就纳闷了。能细抠我源码的,不像现在那些小毛孩的做派。
严谨的态度,是应该代代相传的。

【在 w****w 的大作中提到】
: 不敢不敢,我十几年前已经被淘汰了。
T********i
发帖数: 2416
48
那是一个没有人需要超过640K内存的时代。 :)

【在 d***a 的大作中提到】
: 前辈啊!我读书时已经可以用256KB的内存了。
:
: ROM

f******2
发帖数: 2455
49
老魏你还狠年轻啊,任正非在你这个年纪还住着农民房,拎着皮包到处转呢。
我被好虫赵策二人转忽悠的以为你都奔五了呢。
好好干,争取把老姜拉入伙,真心看好你们。美国安全领域当年出了一批华人企业,你
们在iot再杀出条血路。
别的不说,赵策来美的事情至少解决了

【在 T********i 的大作中提到】
: 看你用啥硬件吧?51,98之类的也没那么不堪。
: 虽然我43都不到,53俱乐部那些DJS130我还是看着它运行看着它退役的。
: VAX11780也用过。
:
: ROM

b******7
发帖数: 123
50
"谁要打一个1M/s ACID MQ的赌?"
这个比较感兴趣,能大概说说思路吗?找轮子还是自己做?单机的还是分布的?
相关主题
对非程序员而言,好虫的架构很有问题给nod101一个最优化的实时分配车票座位的算法
每秒500万, 结论出来看了什么叫直接丢单?说话和做人要有底线,不能张口就来
大规模多核并发的系统PK大规模多机并发的系统12306平稳渡过抢票高峰期 最多每秒售出近700张 (转载)
进入Programming版参与讨论
b******7
发帖数: 123
51
同车次出票呢?小概率也还是会发生的,应该还是要锁吧。而且这个transaction要和
支付包在一起,和同一个请求的其它车次包在一起。就成了跨db的transaction提交了。

后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票,
也没有数据耦合。抢票节点就是解决加锁和耦合问题的。付款本身没有耦合问题,每个
订单、用户都是独立的,........

【在 n*****t 的大作中提到】
: 后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票,
: 也没有数据耦合。抢票节点就是解决加锁和耦合问题的。
: 付款本身没有耦合问题,每个订单、用户都是独立的,当然付款失败需要返回票源。
:
: transaction

n*****t
发帖数: 22014
52
抢票给出的是座位,不单单是车次,不需要加锁

了。

【在 b******7 的大作中提到】
: 同车次出票呢?小概率也还是会发生的,应该还是要锁吧。而且这个transaction要和
: 支付包在一起,和同一个请求的其它车次包在一起。就成了跨db的transaction提交了。
:
: 后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票,
: 也没有数据耦合。抢票节点就是解决加锁和耦合问题的。付款本身没有耦合问题,每个
: 订单、用户都是独立的,........

b***i
发帖数: 3043
53
原来不是抢票就分?看来还挺合理的。



【在 n*****t 的大作中提到】
: db 记录最终付款、出票状态。实际上出票后还是要通知一下抢票节点,这样可以安全
: split 这张票剩余路段了。

T********i
发帖数: 2416
54
你有没有读我的code?现在抢票请求都是单线程处理的。锁啥?
每秒>5M是guarantee的。

了。

【在 b******7 的大作中提到】
: 同车次出票呢?小概率也还是会发生的,应该还是要锁吧。而且这个transaction要和
: 支付包在一起,和同一个请求的其它车次包在一起。就成了跨db的transaction提交了。
:
: 后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票,
: 也没有数据耦合。抢票节点就是解决加锁和耦合问题的。付款本身没有耦合问题,每个
: 订单、用户都是独立的,........

T********i
发帖数: 2416
55
刚给老姜发了封gmail。

【在 f******2 的大作中提到】
: 老魏你还狠年轻啊,任正非在你这个年纪还住着农民房,拎着皮包到处转呢。
: 我被好虫赵策二人转忽悠的以为你都奔五了呢。
: 好好干,争取把老姜拉入伙,真心看好你们。美国安全领域当年出了一批华人企业,你
: 们在iot再杀出条血路。
: 别的不说,赵策来美的事情至少解决了

f******2
发帖数: 2455
56
你们两个要是齐了(其他的都放下不干),需要销售经理的时候和兄弟说一声啊。

【在 T********i 的大作中提到】
: 刚给老姜发了封gmail。
T********i
发帖数: 2416
57
没问题。你老兄顺便也要负责啥时候打开笼子放赵策。

【在 f******2 的大作中提到】
: 你们两个要是齐了(其他的都放下不干),需要销售经理的时候和兄弟说一声啊。
l*********s
发帖数: 5409
58
re this, 牛逼的日本和德意志民族都是以严谨细致著称的

【在 T********i 的大作中提到】
: 我就纳闷了。能细抠我源码的,不像现在那些小毛孩的做派。
: 严谨的态度,是应该代代相传的。

b******7
发帖数: 123
59
我指的是后期的persistent。

你有没有读我的code?现在抢票请求都是单线程处理的。锁啥?每秒

【在 T********i 的大作中提到】
: 你有没有读我的code?现在抢票请求都是单线程处理的。锁啥?
: 每秒>5M是guarantee的。
:
: 了。

T********i
发帖数: 2416
60
外围机是前端,抢票服务器居中,支付ACID MQ是后端。
抢票机抢到票,放到一个memory queue里面,往后端ACID MQ送。
假定ACID MQ throughput 1M/s。抢票机memory queue搞1B大总行吧?
ACID MQ给抢票机ACK,抢票机给外围机。或者抢票机给外围机一个pending,外围机每
10秒轮询poll一个redis都好。有unique ReqID都好办。
抢票机死掉了,前端外围机根据ReqID直接查询ACID MQ好了。
其实有问题你应该自己先想办法解决。如果自己能解决还要故意问,那是故意难为人家
,有意思么?

【在 b******7 的大作中提到】
: 我指的是后期的persistent。
:
: 你有没有读我的code?现在抢票请求都是单线程处理的。锁啥?每秒

相关主题
说到底还是app 层 engineer 和 系统层engineer在斗法从12306来看,国内IT水平不高
应该给魏大师发10个图灵奖。简单介绍一下老魏的结构
zz 12306是怎样做成的其实就是两党党争
进入Programming版参与讨论
T********i
发帖数: 2416
61
其实ACID MQ也能无限scale。对性能没要求,只要ACID就好。

【在 T********i 的大作中提到】
: 外围机是前端,抢票服务器居中,支付ACID MQ是后端。
: 抢票机抢到票,放到一个memory queue里面,往后端ACID MQ送。
: 假定ACID MQ throughput 1M/s。抢票机memory queue搞1B大总行吧?
: ACID MQ给抢票机ACK,抢票机给外围机。或者抢票机给外围机一个pending,外围机每
: 10秒轮询poll一个redis都好。有unique ReqID都好办。
: 抢票机死掉了,前端外围机根据ReqID直接查询ACID MQ好了。
: 其实有问题你应该自己先想办法解决。如果自己能解决还要故意问,那是故意难为人家
: ,有意思么?

b******7
发帖数: 123
62
对性能有整体要求啊,不然抢票机堵塞了。

其实ACID MQ也能无限scale。对性能没要求,只要ACID就好。


【在 T********i 的大作中提到】
: 其实ACID MQ也能无限scale。对性能没要求,只要ACID就好。
z****e
发帖数: 54598
63

哈哈哈,老姜的电商怎么样了?
连个支付宝都不去做,去搞这个?傻逼了不是?
老姜,看这个新闻,傻蛋,你不做,别人已经行动了
http://www.cnr.cn/jingji/gs/20151218/t20151218_520846846.shtml

【在 f******2 的大作中提到】
: 老魏你还狠年轻啊,任正非在你这个年纪还住着农民房,拎着皮包到处转呢。
: 我被好虫赵策二人转忽悠的以为你都奔五了呢。
: 好好干,争取把老姜拉入伙,真心看好你们。美国安全领域当年出了一批华人企业,你
: 们在iot再杀出条血路。
: 别的不说,赵策来美的事情至少解决了

1 (共1页)
进入Programming版参与讨论
相关主题
说到底还是app 层 engineer 和 系统层engineer在斗法顺便和nod101说说做产品
应该给魏大师发10个图灵奖。这坑实在没劲,都是些嘴炮王
zz 12306是怎样做成的搞技术的,要有起码的是非观念 by 老魏
从12306来看,国内IT水平不高赌约在此
简单介绍一下老魏的结构静态计数器和订票系统的区别
其实就是两党党争对非程序员而言,好虫的架构很有问题
TeacherWei 的订票机的问题每秒500万, 结论出来看了
学术贴,1M/s ACID Message Queue大规模多核并发的系统PK大规模多机并发的系统
相关话题的讨论汇总
话题: 抢票话题: acid话题: 老魏话题: mq话题: 请求