Redian新闻
>
请老魏给出一个简单的文字解释
avatar
请老魏给出一个简单的文字解释# Programming - 葵花宝典
p*a
1
挂人了,疯狂挂人中
干草叉征异界损兵折将阿!
avatar
b*i
2
我也是去了加勒比海溜达了一圈,错过了这个赌局。
略看了一下,一共两个文件,请问哪个函数写了查询?哪个是搜索联票?
现在还晕船,看不太懂。
能否用300字以内的文字,说说关键内容和目的?这样我们检查的时候可以省些精力去
猜。
avatar
v*s
3
最后除了约纳都会死吧……
龙尊君太强了!要被他逆降临,灭掉神之子很轻松吧。
幽灵以前怎么和兄弟会抗衡的?逆降临是自杀性攻击,只能用一次,还只有几分钟的时
间。万一降临过来的是个弱人,完全没用,不降临的话,基本都是杂兵的档次,根本打
不过神之子啊。

【在 p********a 的大作中提到】
: 挂人了,疯狂挂人中
: 干草叉征异界损兵折将阿!

avatar
T*i
4
实在对不起,我代码已经开源了。我说过了,不解释,看个人的悟性,和机缘了。
avatar
l*s
5
这个逆降临到底是怎么个机制?

【在 v*****s 的大作中提到】
: 最后除了约纳都会死吧……
: 龙尊君太强了!要被他逆降临,灭掉神之子很轻松吧。
: 幽灵以前怎么和兄弟会抗衡的?逆降临是自杀性攻击,只能用一次,还只有几分钟的时
: 间。万一降临过来的是个弱人,完全没用,不降临的话,基本都是杂兵的档次,根本打
: 不过神之子啊。

avatar
n*t
6
没有联程、没有查询,全部是锁票,古德猫宁要求一个请求一个车次

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

avatar
p*a
7
matrix reversed, lol

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

【在 n*****t 的大作中提到】
: 没有联程、没有查询,全部是锁票,古德猫宁要求一个请求一个车次
avatar
ay
9
“世界”源于人界,人界源于更高阶世界,原本同源
“世界”里头的人格发展了魔法,人界也存在只不过人界里的人没有开发出来

【在 l*******s 的大作中提到】
: 这个逆降临到底是怎么个机制?
avatar
n*t
10
http://www.mitbbs.com/article_t1/Programming/31462913_0_1.html

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

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

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

avatar
b*s
13
看上去像代码注入,但是最终会写坏原进程的结构

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

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

avatar
T*c
15
我攒了几天没看了,刚看到骑士挂
avatar
b*i
16
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
avatar
T*e
17
写得真是很燃
你以为洋洋得意站在那里就能打倒我们吗?我们可是在血、火和悲伤里成长起来的干草
叉小队啊混蛋
avatar
n*t
18
其实我没细看,刚才匆匆搂了一眼,应该是先 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好,整不出个所以然来,只有做出来看一看能不能用才行。

avatar
k*a
19
幽灵的首脑在量子计算机有特别权限,可以搞些东西出来(比如计算机用来自杀的炸弹
之类),所以可以抗衡?

【在 v*****s 的大作中提到】
: 最后除了约纳都会死吧……
: 龙尊君太强了!要被他逆降临,灭掉神之子很轻松吧。
: 幽灵以前怎么和兄弟会抗衡的?逆降临是自杀性攻击,只能用一次,还只有几分钟的时
: 间。万一降临过来的是个弱人,完全没用,不降临的话,基本都是杂兵的档次,根本打
: 不过神之子啊。

avatar
w*w
20
开始有3000张空票,都是从第一站到最后一站。allocate()是找空票,找到后reserve(
)是把空票分成3张空票,中间那张填好返回,剩下的空票放回去以后用.
allocate()用的是实时OS scheduler实现常用的lookup的手段,这是关键一。关键二是
IO用poll不陷入内核,只有开关socket凋用系统。
avatar
f*n
21
稍微观察一下保留区,破除量子态,就可以引发巨变(开挂)了

【在 k*****a 的大作中提到】
: 幽灵的首脑在量子计算机有特别权限,可以搞些东西出来(比如计算机用来自杀的炸弹
: 之类),所以可以抗衡?

avatar
b*i
22
有两个allocate,我都糊涂了。
用了很多先进技术倒是,就这两个allocate不懂

reserve(

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

avatar
f*e
23
这个应许之地是什么地方?
老太太是matrix里面的architect?

【在 p********a 的大作中提到】
: 挂人了,疯狂挂人中
: 干草叉征异界损兵折将阿!

avatar
z*e
24

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

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

avatar
T*c
25
唉我感觉我攒了很久了,结果也才4章,瞬间读完,灰常不过瘾
avatar
z*e
26

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

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

avatar
T*c
27
神之子数量少吧,而且除了顶尖的骑士,一般的也不是不可抵挡的,按设定配备精良的
精锐还是有得打

【在 v*****s 的大作中提到】
: 最后除了约纳都会死吧……
: 龙尊君太强了!要被他逆降临,灭掉神之子很轻松吧。
: 幽灵以前怎么和兄弟会抗衡的?逆降临是自杀性攻击,只能用一次,还只有几分钟的时
: 间。万一降临过来的是个弱人,完全没用,不降临的话,基本都是杂兵的档次,根本打
: 不过神之子啊。

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

re这个

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

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

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

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

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

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

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

transaction

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

avatar
z*e
33

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

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

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

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

avatar
p*y
35
你说的问题如果你经常买飞机票都会遇到。 航空公司都这么做有两个愿意, 第一是实
际上只有很少一部分人会遇到这样的情况, 通常是在最后大部分票都卖光且路径非常
fragmental的情况下。 第二对航空公司最有利。 商业行为, 不一定都是用户至上的

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

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

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

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

avatar
p*y
37
他根本就没懂整个的architecture是什么样的, 你跟他讲一千遍还是没用。

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

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

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

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

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

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

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

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

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

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

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

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

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

avatar
T*i
44
其实大家讨论技术本来就应该切中肯綮。不应该故意纠缠细枝末节。
avatar
b*i
45
所以让你提出个300个字的描述,结果你让大家自己想。这不就看到一些细枝末节
为什么你有的函数在.h,有的在.cpp?都在.h岂不是容易看?

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

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

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

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

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

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

avatar
b*i
49
假设重启了,那么抢票节点从哪里恢复所有票的状态?

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

avatar
T*i
50
其实很多都是业务逻辑,跟技术没有任何关系。
比如,外围机报有票,给了用户几条路线,用户选了说没票了。这不是很正常?美国网
上抢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没付钱的很多。
avatar
n*t
51
关键古的吧对这方面的技术一无所知,对你说的极限毫无概念,套用轮子已经成为惯性
。如果就这样也就算了,还连续两年拿这事叫骂老魏。。。。。。

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

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

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

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

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

avatar
w*w
55
只能感叹现在的硬件。当年我写程序的时候,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的赌?

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

ROM

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

avatar
w*w
57
6800, VAX11/725,HC11...

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

avatar
T*i
58
您是老前辈,我多有失礼,还请见谅。

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

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

ROM

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

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

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

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

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

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

avatar
b*7
64
"谁要打一个1M/s ACID MQ的赌?"
这个比较感兴趣,能大概说说思路吗?找轮子还是自己做?单机的还是分布的?
avatar
b*7
65
同车次出票呢?小概率也还是会发生的,应该还是要锁吧。而且这个transaction要和
支付包在一起,和同一个请求的其它车次包在一起。就成了跨db的transaction提交了。

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

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

avatar
n*t
66
抢票给出的是座位,不单单是车次,不需要加锁

了。

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

avatar
b*i
67
原来不是抢票就分?看来还挺合理的。



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

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

了。

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

avatar
T*i
69
刚给老姜发了封gmail。

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

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

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

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

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

avatar
b*7
73
我指的是后期的persistent。

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

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

avatar
T*i
74
外围机是前端,抢票服务器居中,支付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?现在抢票请求都是单线程处理的。锁啥?每秒

avatar
T*i
75
其实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好了。
: 其实有问题你应该自己先想办法解决。如果自己能解决还要故意问,那是故意难为人家
: ,有意思么?

avatar
b*7
76
对性能有整体要求啊,不然抢票机堵塞了。

其实ACID MQ也能无限scale。对性能没要求,只要ACID就好。
avatar
z*e
77

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

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

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。