b*i
2 楼
我也是去了加勒比海溜达了一圈，错过了这个赌局。
略看了一下，一共两个文件，请问哪个函数写了查询？哪个是搜索联票？
现在还晕船，看不太懂。
能否用300字以内的文字，说说关键内容和目的？这样我们检查的时候可以省些精力去
猜。
略看了一下，一共两个文件，请问哪个函数写了查询？哪个是搜索联票？
现在还晕船，看不太懂。
能否用300字以内的文字，说说关键内容和目的？这样我们检查的时候可以省些精力去
猜。
v*s
3 楼
最后除了约纳都会死吧……
龙尊君太强了！要被他逆降临，灭掉神之子很轻松吧。
幽灵以前怎么和兄弟会抗衡的？逆降临是自杀性攻击，只能用一次，还只有几分钟的时
间。万一降临过来的是个弱人，完全没用，不降临的话，基本都是杂兵的档次，根本打
不过神之子啊。
【在 p********a 的大作中提到】
: 挂人了，疯狂挂人中
: 干草叉征异界损兵折将阿！
龙尊君太强了！要被他逆降临，灭掉神之子很轻松吧。
幽灵以前怎么和兄弟会抗衡的？逆降临是自杀性攻击，只能用一次，还只有几分钟的时
间。万一降临过来的是个弱人，完全没用，不降临的话，基本都是杂兵的档次，根本打
不过神之子啊。
【在 p********a 的大作中提到】
: 挂人了，疯狂挂人中
: 干草叉征异界损兵折将阿！
T*i
4 楼
实在对不起，我代码已经开源了。我说过了，不解释，看个人的悟性，和机缘了。
l*s
5 楼
这个逆降临到底是怎么个机制？
【在 v*****s 的大作中提到】
: 最后除了约纳都会死吧……
: 龙尊君太强了！要被他逆降临，灭掉神之子很轻松吧。
: 幽灵以前怎么和兄弟会抗衡的？逆降临是自杀性攻击，只能用一次，还只有几分钟的时
: 间。万一降临过来的是个弱人，完全没用，不降临的话，基本都是杂兵的档次，根本打
: 不过神之子啊。
【在 v*****s 的大作中提到】
: 最后除了约纳都会死吧……
: 龙尊君太强了！要被他逆降临，灭掉神之子很轻松吧。
: 幽灵以前怎么和兄弟会抗衡的？逆降临是自杀性攻击，只能用一次，还只有几分钟的时
: 间。万一降临过来的是个弱人，完全没用，不降临的话，基本都是杂兵的档次，根本打
: 不过神之子啊。
n*t
6 楼
没有联程、没有查询，全部是锁票，古德猫宁要求一个请求一个车次
【在 b***i 的大作中提到】
: 我也是去了加勒比海溜达了一圈，错过了这个赌局。
: 略看了一下，一共两个文件，请问哪个函数写了查询？哪个是搜索联票？
: 现在还晕船，看不太懂。
: 能否用300字以内的文字，说说关键内容和目的？这样我们检查的时候可以省些精力去
: 猜。
【在 b***i 的大作中提到】
: 我也是去了加勒比海溜达了一圈，错过了这个赌局。
: 略看了一下，一共两个文件，请问哪个函数写了查询？哪个是搜索联票？
: 现在还晕船，看不太懂。
: 能否用300字以内的文字，说说关键内容和目的？这样我们检查的时候可以省些精力去
: 猜。
p*a
7 楼
matrix reversed, lol
【在 l*******s 的大作中提到】
: 这个逆降临到底是怎么个机制？
【在 l*******s 的大作中提到】
: 这个逆降临到底是怎么个机制？
b*i
8 楼
是吗？goodbug同意了？
没有联程我理解，老魏是客户端来查询，比如javascript,完成联程的搜索。然后用户
点击买票，才发送一个请求到最后面的那个抢票线程来完成。
有没有查询，估计差不多。我估计老魏这个思路，搜索联程票也许经过几毫秒的延时，
最后信息变了，但是只要最后买票是否正确不出错就行。这个在票卖差不多的时候用户
多点几次不同线路。
这个就是这个赌约和老魏的解决方案？那么，怎么保存结果到文件，讨论了吗？效率足
够吗？
【在 n*****t 的大作中提到】
: 没有联程、没有查询，全部是锁票，古德猫宁要求一个请求一个车次
没有联程我理解，老魏是客户端来查询，比如javascript,完成联程的搜索。然后用户
点击买票，才发送一个请求到最后面的那个抢票线程来完成。
有没有查询，估计差不多。我估计老魏这个思路，搜索联程票也许经过几毫秒的延时，
最后信息变了，但是只要最后买票是否正确不出错就行。这个在票卖差不多的时候用户
多点几次不同线路。
这个就是这个赌约和老魏的解决方案？那么，怎么保存结果到文件，讨论了吗？效率足
够吗？
【在 n*****t 的大作中提到】
: 没有联程、没有查询，全部是锁票，古德猫宁要求一个请求一个车次
ay
9 楼
“世界”源于人界，人界源于更高阶世界，原本同源
“世界”里头的人格发展了魔法，人界也存在只不过人界里的人没有开发出来
【在 l*******s 的大作中提到】
: 这个逆降临到底是怎么个机制？
“世界”里头的人格发展了魔法，人界也存在只不过人界里的人没有开发出来
【在 l*******s 的大作中提到】
: 这个逆降临到底是怎么个机制？
n*t
10 楼
http://www.mitbbs.com/article_t1/Programming/31462913_0_1.html
【在 b***i 的大作中提到】
: 是吗？goodbug同意了？
: 没有联程我理解，老魏是客户端来查询，比如javascript,完成联程的搜索。然后用户
: 点击买票，才发送一个请求到最后面的那个抢票线程来完成。
: 有没有查询，估计差不多。我估计老魏这个思路，搜索联程票也许经过几毫秒的延时，
: 最后信息变了，但是只要最后买票是否正确不出错就行。这个在票卖差不多的时候用户
: 多点几次不同线路。
: 这个就是这个赌约和老魏的解决方案？那么，怎么保存结果到文件，讨论了吗？效率足
: 够吗？
【在 b***i 的大作中提到】
: 是吗？goodbug同意了？
: 没有联程我理解，老魏是客户端来查询，比如javascript,完成联程的搜索。然后用户
: 点击买票，才发送一个请求到最后面的那个抢票线程来完成。
: 有没有查询，估计差不多。我估计老魏这个思路，搜索联程票也许经过几毫秒的延时，
: 最后信息变了，但是只要最后买票是否正确不出错就行。这个在票卖差不多的时候用户
: 多点几次不同线路。
: 这个就是这个赌约和老魏的解决方案？那么，怎么保存结果到文件，讨论了吗？效率足
: 够吗？
m*e
11 楼
参考matrix的Neo
m*5
12 楼
根本没同意，赵老师和古老师在魏老师写code之前就说清楚了，就算魏老师实现了赌约
，也是白搭，因为他们已经论证了好多次了，就算实现了也不能证明魏老师的系统在实
际卖票中有用。
只有魏老师这一派傻不拉基埋头写code, 这赌还没打，魏老师就已经输定了。
【在 b***i 的大作中提到】
: 是吗？goodbug同意了？
: 没有联程我理解，老魏是客户端来查询，比如javascript,完成联程的搜索。然后用户
: 点击买票，才发送一个请求到最后面的那个抢票线程来完成。
: 有没有查询，估计差不多。我估计老魏这个思路，搜索联程票也许经过几毫秒的延时，
: 最后信息变了，但是只要最后买票是否正确不出错就行。这个在票卖差不多的时候用户
: 多点几次不同线路。
: 这个就是这个赌约和老魏的解决方案？那么，怎么保存结果到文件，讨论了吗？效率足
: 够吗？
，也是白搭，因为他们已经论证了好多次了，就算实现了也不能证明魏老师的系统在实
际卖票中有用。
只有魏老师这一派傻不拉基埋头写code, 这赌还没打，魏老师就已经输定了。
【在 b***i 的大作中提到】
: 是吗？goodbug同意了？
: 没有联程我理解，老魏是客户端来查询，比如javascript,完成联程的搜索。然后用户
: 点击买票，才发送一个请求到最后面的那个抢票线程来完成。
: 有没有查询，估计差不多。我估计老魏这个思路，搜索联程票也许经过几毫秒的延时，
: 最后信息变了，但是只要最后买票是否正确不出错就行。这个在票卖差不多的时候用户
: 多点几次不同线路。
: 这个就是这个赌约和老魏的解决方案？那么，怎么保存结果到文件，讨论了吗？效率足
: 够吗？
b*s
13 楼
看上去像代码注入，但是最终会写坏原进程的结构
【在 l*******s 的大作中提到】
: 这个逆降临到底是怎么个机制？
【在 l*******s 的大作中提到】
: 这个逆降临到底是怎么个机制？
n*t
14 楼
赌约是狗爸提出来的，不过你虽然猜错了开头，结局猜对了，这货是打死不会认账的，
最坏结果也想好了：大不了自杀 goodbug 这个 id，马甲人没说一起自杀。
【在 m********5 的大作中提到】
: 根本没同意，赵老师和古老师在魏老师写code之前就说清楚了，就算魏老师实现了赌约
: ，也是白搭，因为他们已经论证了好多次了，就算实现了也不能证明魏老师的系统在实
: 际卖票中有用。
: 只有魏老师这一派傻不拉基埋头写code, 这赌还没打，魏老师就已经输定了。
最坏结果也想好了：大不了自杀 goodbug 这个 id，马甲人没说一起自杀。
【在 m********5 的大作中提到】
: 根本没同意，赵老师和古老师在魏老师写code之前就说清楚了，就算魏老师实现了赌约
: ，也是白搭，因为他们已经论证了好多次了，就算实现了也不能证明魏老师的系统在实
: 际卖票中有用。
: 只有魏老师这一派傻不拉基埋头写code, 这赌还没打，魏老师就已经输定了。
T*c
15 楼
我攒了几天没看了，刚看到骑士挂
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
里面这个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
T*e
17 楼
写得真是很燃
你以为洋洋得意站在那里就能打倒我们吗？我们可是在血、火和悲伤里成长起来的干草
叉小队啊混蛋
你以为洋洋得意站在那里就能打倒我们吗？我们可是在血、火和悲伤里成长起来的干草
叉小队啊混蛋
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好，整不出个所以然来，只有做出来看一看能不能用才行。
了，然后锁定，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好，整不出个所以然来，只有做出来看一看能不能用才行。
k*a
19 楼
幽灵的首脑在量子计算机有特别权限，可以搞些东西出来（比如计算机用来自杀的炸弹
之类），所以可以抗衡？
【在 v*****s 的大作中提到】
: 最后除了约纳都会死吧……
: 龙尊君太强了！要被他逆降临，灭掉神之子很轻松吧。
: 幽灵以前怎么和兄弟会抗衡的？逆降临是自杀性攻击，只能用一次，还只有几分钟的时
: 间。万一降临过来的是个弱人，完全没用，不降临的话，基本都是杂兵的档次，根本打
: 不过神之子啊。
之类），所以可以抗衡？
【在 v*****s 的大作中提到】
: 最后除了约纳都会死吧……
: 龙尊君太强了！要被他逆降临，灭掉神之子很轻松吧。
: 幽灵以前怎么和兄弟会抗衡的？逆降临是自杀性攻击，只能用一次，还只有几分钟的时
: 间。万一降临过来的是个弱人，完全没用，不降临的话，基本都是杂兵的档次，根本打
: 不过神之子啊。
w*w
20 楼
开始有3000张空票，都是从第一站到最后一站。allocate()是找空票，找到后reserve(
)是把空票分成3张空票，中间那张填好返回，剩下的空票放回去以后用.
allocate()用的是实时OS scheduler实现常用的lookup的手段，这是关键一。关键二是
IO用poll不陷入内核，只有开关socket凋用系统。
)是把空票分成3张空票，中间那张填好返回，剩下的空票放回去以后用.
allocate()用的是实时OS scheduler实现常用的lookup的手段，这是关键一。关键二是
IO用poll不陷入内核，只有开关socket凋用系统。
f*n
21 楼
稍微观察一下保留区，破除量子态，就可以引发巨变（开挂）了
【在 k*****a 的大作中提到】
: 幽灵的首脑在量子计算机有特别权限，可以搞些东西出来（比如计算机用来自杀的炸弹
: 之类），所以可以抗衡？
【在 k*****a 的大作中提到】
: 幽灵的首脑在量子计算机有特别权限，可以搞些东西出来（比如计算机用来自杀的炸弹
: 之类），所以可以抗衡？
b*i
22 楼
有两个allocate,我都糊涂了。
用了很多先进技术倒是，就这两个allocate不懂
reserve(
【在 w****w 的大作中提到】
: 开始有3000张空票，都是从第一站到最后一站。allocate()是找空票，找到后reserve(
: )是把空票分成3张空票，中间那张填好返回，剩下的空票放回去以后用.
: allocate()用的是实时OS scheduler实现常用的lookup的手段，这是关键一。关键二是
: IO用poll不陷入内核，只有开关socket凋用系统。
用了很多先进技术倒是，就这两个allocate不懂
reserve(
【在 w****w 的大作中提到】
: 开始有3000张空票，都是从第一站到最后一站。allocate()是找空票，找到后reserve(
: )是把空票分成3张空票，中间那张填好返回，剩下的空票放回去以后用.
: allocate()用的是实时OS scheduler实现常用的lookup的手段，这是关键一。关键二是
: IO用poll不陷入内核，只有开关socket凋用系统。
f*e
23 楼
这个应许之地是什么地方？
老太太是matrix里面的architect？
【在 p********a 的大作中提到】
: 挂人了，疯狂挂人中
: 干草叉征异界损兵折将阿！
老太太是matrix里面的architect？
【在 p********a 的大作中提到】
: 挂人了，疯狂挂人中
: 干草叉征异界损兵折将阿！
z*e
24 楼
说明根本没有实际干过项目
需求不明确的时候，就开始写代码
基本上是大忌
【在 m********5 的大作中提到】
: 根本没同意，赵老师和古老师在魏老师写code之前就说清楚了，就算魏老师实现了赌约
: ，也是白搭，因为他们已经论证了好多次了，就算实现了也不能证明魏老师的系统在实
: 际卖票中有用。
: 只有魏老师这一派傻不拉基埋头写code, 这赌还没打，魏老师就已经输定了。
T*c
25 楼
唉我感觉我攒了很久了，结果也才4章，瞬间读完，灰常不过瘾
z*e
26 楼
认什么账？
你们谁敢说这个是12306？
自己都承认了不是12306，忘记了？
计数器的笑话需要强调一遍？
【在 n*****t 的大作中提到】
: 赌约是狗爸提出来的，不过你虽然猜错了开头，结局猜对了，这货是打死不会认账的，
: 最坏结果也想好了：大不了自杀 goodbug 这个 id，马甲人没说一起自杀。
T*c
27 楼
神之子数量少吧，而且除了顶尖的骑士，一般的也不是不可抵挡的，按设定配备精良的
精锐还是有得打
【在 v*****s 的大作中提到】
: 最后除了约纳都会死吧……
: 龙尊君太强了！要被他逆降临，灭掉神之子很轻松吧。
: 幽灵以前怎么和兄弟会抗衡的？逆降临是自杀性攻击，只能用一次，还只有几分钟的时
: 间。万一降临过来的是个弱人，完全没用，不降临的话，基本都是杂兵的档次，根本打
: 不过神之子啊。
精锐还是有得打
【在 v*****s 的大作中提到】
: 最后除了约纳都会死吧……
: 龙尊君太强了！要被他逆降临，灭掉神之子很轻松吧。
: 幽灵以前怎么和兄弟会抗衡的？逆降临是自杀性攻击，只能用一次，还只有几分钟的时
: 间。万一降临过来的是个弱人，完全没用，不降临的话，基本都是杂兵的档次，根本打
: 不过神之子啊。
b*7
28 楼
老魏这个方案看到：
1. 把本来的long transaction 切割，分解为前期只读的查询，中期的可以失败的单点
抢票机，和后期带transaction的出票部分，最大限度的缩短了transaction; 巧妙利用
了抢票机出错不影响persistent 数据的设计。
2. 前期，后期容易scale或者partition，因为面对是分解过的问题。
3. 单点抢票无需数据同步。
带来的问题可能有:
1.查到不一定抢到，因为persistent数据和i抢票机数据有延迟；这个用户体验可能会
不好。
2.复杂的联程票等等算法被推到前期部分，这个程序真的和计数器差不多，不过设计理
念还是可取的，起码是一种可以尝试的设计。
1. 把本来的long transaction 切割，分解为前期只读的查询，中期的可以失败的单点
抢票机，和后期带transaction的出票部分，最大限度的缩短了transaction; 巧妙利用
了抢票机出错不影响persistent 数据的设计。
2. 前期，后期容易scale或者partition，因为面对是分解过的问题。
3. 单点抢票无需数据同步。
带来的问题可能有:
1.查到不一定抢到，因为persistent数据和i抢票机数据有延迟；这个用户体验可能会
不好。
2.复杂的联程票等等算法被推到前期部分，这个程序真的和计数器差不多，不过设计理
念还是可取的，起码是一种可以尝试的设计。
z*e
29 楼
re这个
【在 b******7 的大作中提到】
: 老魏这个方案看到：
: 1. 把本来的long transaction 切割，分解为前期只读的查询，中期的可以失败的单点
: 抢票机，和后期带transaction的出票部分，最大限度的缩短了transaction; 巧妙利用
: 了抢票机出错不影响persistent 数据的设计。
: 2. 前期，后期容易scale或者partition，因为面对是分解过的问题。
: 3. 单点抢票无需数据同步。
: 带来的问题可能有:
: 1.查到不一定抢到，因为persistent数据和i抢票机数据有延迟；这个用户体验可能会
: 不好。
: 2.复杂的联程票等等算法被推到前期部分，这个程序真的和计数器差不多，不过设计理
n*t
30 楼
问题一不存在，这个不同步即使有也是 usec 级的，现实中票的动态变化决定查到抢不
到是常态。实际现在的吞吐也足够应付查询，看业务需要了。
【在 b******7 的大作中提到】
: 老魏这个方案看到：
: 1. 把本来的long transaction 切割，分解为前期只读的查询，中期的可以失败的单点
: 抢票机，和后期带transaction的出票部分，最大限度的缩短了transaction; 巧妙利用
: 了抢票机出错不影响persistent 数据的设计。
: 2. 前期，后期容易scale或者partition，因为面对是分解过的问题。
: 3. 单点抢票无需数据同步。
: 带来的问题可能有:
: 1.查到不一定抢到，因为persistent数据和i抢票机数据有延迟；这个用户体验可能会
: 不好。
: 2.复杂的联程票等等算法被推到前期部分，这个程序真的和计数器差不多，不过设计理
到是常态。实际现在的吞吐也足够应付查询，看业务需要了。
【在 b******7 的大作中提到】
: 老魏这个方案看到：
: 1. 把本来的long transaction 切割，分解为前期只读的查询，中期的可以失败的单点
: 抢票机，和后期带transaction的出票部分，最大限度的缩短了transaction; 巧妙利用
: 了抢票机出错不影响persistent 数据的设计。
: 2. 前期，后期容易scale或者partition，因为面对是分解过的问题。
: 3. 单点抢票无需数据同步。
: 带来的问题可能有:
: 1.查到不一定抢到，因为persistent数据和i抢票机数据有延迟；这个用户体验可能会
: 不好。
: 2.复杂的联程票等等算法被推到前期部分，这个程序真的和计数器差不多，不过设计理
b*7
31 楼
到了persistent阶段，有了加锁，同车次/table数据耦合，付款等分布式transaction
两阶段提交等等，性能还会有这么好吗？
问题一不存在，这个不同步即使有也是 usec 级的，现实中票的动态变化决定查到抢不
到是常态。实际现在的吞吐也足够应付查询，看业务需要了。
【在 n*****t 的大作中提到】
: 问题一不存在，这个不同步即使有也是 usec 级的，现实中票的动态变化决定查到抢不
: 到是常态。实际现在的吞吐也足够应付查询，看业务需要了。
两阶段提交等等，性能还会有这么好吗？
问题一不存在，这个不同步即使有也是 usec 级的，现实中票的动态变化决定查到抢不
到是常态。实际现在的吞吐也足够应付查询，看业务需要了。
【在 n*****t 的大作中提到】
: 问题一不存在，这个不同步即使有也是 usec 级的，现实中票的动态变化决定查到抢不
: 到是常态。实际现在的吞吐也足够应付查询，看业务需要了。
n*t
32 楼
后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票，
也没有数据耦合。抢票节点就是解决加锁和耦合问题的。
付款本身没有耦合问题，每个订单、用户都是独立的，当然付款失败需要返回票源。
transaction
【在 b******7 的大作中提到】
: 到了persistent阶段，有了加锁，同车次/table数据耦合，付款等分布式transaction
: 两阶段提交等等，性能还会有这么好吗？
:
: 问题一不存在，这个不同步即使有也是 usec 级的，现实中票的动态变化决定查到抢不
: 到是常态。实际现在的吞吐也足够应付查询，看业务需要了。
也没有数据耦合。抢票节点就是解决加锁和耦合问题的。
付款本身没有耦合问题，每个订单、用户都是独立的，当然付款失败需要返回票源。
transaction
【在 b******7 的大作中提到】
: 到了persistent阶段，有了加锁，同车次/table数据耦合，付款等分布式transaction
: 两阶段提交等等，性能还会有这么好吗？
:
: 问题一不存在，这个不同步即使有也是 usec 级的，现实中票的动态变化决定查到抢不
: 到是常态。实际现在的吞吐也足够应付查询，看业务需要了。
z*e
33 楼
那就把计数器一个车次分配一个
直接用redis做就好了
另外付款本身可能同样存在耦合问题
你是不是从来没思考过多个用户用同一张卡付款的情况？
一个人可以买多张票诶
付款才是真正的麻烦，2-3s是最快的，支付宝现在多长时间返回？
你说说，我遇到过支付宝有长达20min才返回的情况
【在 n*****t 的大作中提到】
: 后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票，
: 也没有数据耦合。抢票节点就是解决加锁和耦合问题的。
: 付款本身没有耦合问题，每个订单、用户都是独立的，当然付款失败需要返回票源。
:
: transaction
n*t
34 楼
又开始胡扯，真服了。你一万个人用一张卡我也无所谓，只要支付宝告诉我付款成功就
行，有个毛耦合。这些都是传统电商的活，跟抢票毫无关系。
【在 z****e 的大作中提到】
:
: 那就把计数器一个车次分配一个
: 直接用redis做就好了
: 另外付款本身可能同样存在耦合问题
: 你是不是从来没思考过多个用户用同一张卡付款的情况？
: 一个人可以买多张票诶
: 付款才是真正的麻烦，2-3s是最快的，支付宝现在多长时间返回？
: 你说说，我遇到过支付宝有长达20min才返回的情况
行，有个毛耦合。这些都是传统电商的活，跟抢票毫无关系。
【在 z****e 的大作中提到】
:
: 那就把计数器一个车次分配一个
: 直接用redis做就好了
: 另外付款本身可能同样存在耦合问题
: 你是不是从来没思考过多个用户用同一张卡付款的情况？
: 一个人可以买多张票诶
: 付款才是真正的麻烦，2-3s是最快的，支付宝现在多长时间返回？
: 你说说，我遇到过支付宝有长达20min才返回的情况
p*y
35 楼
你说的问题如果你经常买飞机票都会遇到。 航空公司都这么做有两个愿意， 第一是实
际上只有很少一部分人会遇到这样的情况， 通常是在最后大部分票都卖光且路径非常
fragmental的情况下。 第二对航空公司最有利。 商业行为， 不一定都是用户至上的
。
这种情况基本用户是接受的。
【在 b******7 的大作中提到】
: 老魏这个方案看到：
: 1. 把本来的long transaction 切割，分解为前期只读的查询，中期的可以失败的单点
: 抢票机，和后期带transaction的出票部分，最大限度的缩短了transaction; 巧妙利用
: 了抢票机出错不影响persistent 数据的设计。
: 2. 前期，后期容易scale或者partition，因为面对是分解过的问题。
: 3. 单点抢票无需数据同步。
: 带来的问题可能有:
: 1.查到不一定抢到，因为persistent数据和i抢票机数据有延迟；这个用户体验可能会
: 不好。
: 2.复杂的联程票等等算法被推到前期部分，这个程序真的和计数器差不多，不过设计理
际上只有很少一部分人会遇到这样的情况， 通常是在最后大部分票都卖光且路径非常
fragmental的情况下。 第二对航空公司最有利。 商业行为， 不一定都是用户至上的
。
这种情况基本用户是接受的。
【在 b******7 的大作中提到】
: 老魏这个方案看到：
: 1. 把本来的long transaction 切割，分解为前期只读的查询，中期的可以失败的单点
: 抢票机，和后期带transaction的出票部分，最大限度的缩短了transaction; 巧妙利用
: 了抢票机出错不影响persistent 数据的设计。
: 2. 前期，后期容易scale或者partition，因为面对是分解过的问题。
: 3. 单点抢票无需数据同步。
: 带来的问题可能有:
: 1.查到不一定抢到，因为persistent数据和i抢票机数据有延迟；这个用户体验可能会
: 不好。
: 2.复杂的联程票等等算法被推到前期部分，这个程序真的和计数器差不多，不过设计理
b*i
36 楼
你说的可行，差别不是问题。
但是，联票的话，前端找到两个车次，然后生成两个请求，这个是要同时进行的。我看
老魏的代码reserve只处理一个车。没看到同时检查两个车，或者多个车次的票都存在
才处理的。这个有吗？
【在 n*****t 的大作中提到】
: 问题一不存在，这个不同步即使有也是 usec 级的，现实中票的动态变化决定查到抢不
: 到是常态。实际现在的吞吐也足够应付查询，看业务需要了。
但是，联票的话，前端找到两个车次，然后生成两个请求，这个是要同时进行的。我看
老魏的代码reserve只处理一个车。没看到同时检查两个车，或者多个车次的票都存在
才处理的。这个有吗？
【在 n*****t 的大作中提到】
: 问题一不存在，这个不同步即使有也是 usec 级的，现实中票的动态变化决定查到抢不
: 到是常态。实际现在的吞吐也足够应付查询，看业务需要了。
p*y
37 楼
他根本就没懂整个的architecture是什么样的， 你跟他讲一千遍还是没用。
【在 n*****t 的大作中提到】
: 又开始胡扯，真服了。你一万个人用一张卡我也无所谓，只要支付宝告诉我付款成功就
: 行，有个毛耦合。这些都是传统电商的活，跟抢票毫无关系。
【在 n*****t 的大作中提到】
: 又开始胡扯，真服了。你一万个人用一张卡我也无所谓，只要支付宝告诉我付款成功就
: 行，有个毛耦合。这些都是传统电商的活，跟抢票毫无关系。
n*t
38 楼
赌约里没有，但这实际恰恰是老魏方案长处，一个请求可以包含多张票，因为是顺序执
行，不会与其他请求冲突产生互锁。
【在 b***i 的大作中提到】
: 你说的可行，差别不是问题。
: 但是，联票的话，前端找到两个车次，然后生成两个请求，这个是要同时进行的。我看
: 老魏的代码reserve只处理一个车。没看到同时检查两个车，或者多个车次的票都存在
: 才处理的。这个有吗？
行，不会与其他请求冲突产生互锁。
【在 b***i 的大作中提到】
: 你说的可行，差别不是问题。
: 但是，联票的话，前端找到两个车次，然后生成两个请求，这个是要同时进行的。我看
: 老魏的代码reserve只处理一个车。没看到同时检查两个车，或者多个车次的票都存在
: 才处理的。这个有吗？
b*i
39 楼
你是说，老魏的数据结构可以处理这种请求：一种是多个人同乘一趟车，另一种是一个
人换乘。那么，如果客户端的请求发来包含了多个车票的一致请求，那么，老魏的程序
经过简单修改可以处理这样的请求？
怪就怪在这里。为什么当初不在赌约里呢？
【在 n*****t 的大作中提到】
: 赌约里没有，但这实际恰恰是老魏方案长处，一个请求可以包含多张票，因为是顺序执
: 行，不会与其他请求冲突产生互锁。
人换乘。那么，如果客户端的请求发来包含了多个车票的一致请求，那么，老魏的程序
经过简单修改可以处理这样的请求？
怪就怪在这里。为什么当初不在赌约里呢？
【在 n*****t 的大作中提到】
: 赌约里没有，但这实际恰恰是老魏方案长处，一个请求可以包含多张票，因为是顺序执
: 行，不会与其他请求冲突产生互锁。
n*t
40 楼
架构没问题，争议在性能，一个请求多票和多个请求单票是等价的，如果这些请求连续
执行。古德吧认为每秒不会超过 10 万票，这个节点会成为新瓶颈。
不要求这个是为了验证结果方便，因此还额外增加了 respID。约定多票算多个请求，
古德吧对自己没信心，怕老魏批处理反而提升性能了。
【在 b***i 的大作中提到】
: 你是说，老魏的数据结构可以处理这种请求：一种是多个人同乘一趟车，另一种是一个
: 人换乘。那么，如果客户端的请求发来包含了多个车票的一致请求，那么，老魏的程序
: 经过简单修改可以处理这样的请求？
: 怪就怪在这里。为什么当初不在赌约里呢？
执行。古德吧认为每秒不会超过 10 万票，这个节点会成为新瓶颈。
不要求这个是为了验证结果方便，因此还额外增加了 respID。约定多票算多个请求，
古德吧对自己没信心，怕老魏批处理反而提升性能了。
【在 b***i 的大作中提到】
: 你是说，老魏的数据结构可以处理这种请求：一种是多个人同乘一趟车，另一种是一个
: 人换乘。那么，如果客户端的请求发来包含了多个车票的一致请求，那么，老魏的程序
: 经过简单修改可以处理这样的请求？
: 怪就怪在这里。为什么当初不在赌约里呢？
g*u
41 楼
我记得在lajixiaoliu2那个赌约出来之前是有的。我不知道为什么最终合同出来
就没了，而且也没有人提出异议。不过只要请求按票数算吞吐量，做不做对性能
没影响。
【在 b***i 的大作中提到】
: 你是说，老魏的数据结构可以处理这种请求：一种是多个人同乘一趟车，另一种是一个
: 人换乘。那么，如果客户端的请求发来包含了多个车票的一致请求，那么，老魏的程序
: 经过简单修改可以处理这样的请求？
: 怪就怪在这里。为什么当初不在赌约里呢？
就没了，而且也没有人提出异议。不过只要请求按票数算吞吐量，做不做对性能
没影响。
【在 b***i 的大作中提到】
: 你是说，老魏的数据结构可以处理这种请求：一种是多个人同乘一趟车，另一种是一个
: 人换乘。那么，如果客户端的请求发来包含了多个车票的一致请求，那么，老魏的程序
: 经过简单修改可以处理这样的请求？
: 怪就怪在这里。为什么当初不在赌约里呢？
n*t
42 楼
一个请求多票对老魏是划算的，一是减少 IO，另外如果第一票没有就不用检查第二张
了，这样也算成功处理 2 单。这是古的吧鸡贼的地方，呵呵。
【在 g****u 的大作中提到】
: 我记得在lajixiaoliu2那个赌约出来之前是有的。我不知道为什么最终合同出来
: 就没了，而且也没有人提出异议。不过只要请求按票数算吞吐量，做不做对性能
: 没影响。
了，这样也算成功处理 2 单。这是古的吧鸡贼的地方，呵呵。
【在 g****u 的大作中提到】
: 我记得在lajixiaoliu2那个赌约出来之前是有的。我不知道为什么最终合同出来
: 就没了，而且也没有人提出异议。不过只要请求按票数算吞吐量，做不做对性能
: 没影响。
b*i
43 楼
我还有另一个问题，就是如何persist，这个频率多少？或者说，persist在交钱出票那
个环节？
就是说如果系统崩溃了，根据谁交钱来恢复当前状态？
【在 n*****t 的大作中提到】
: 架构没问题，争议在性能，一个请求多票和多个请求单票是等价的，如果这些请求连续
: 执行。古德吧认为每秒不会超过 10 万票，这个节点会成为新瓶颈。
: 不要求这个是为了验证结果方便，因此还额外增加了 respID。约定多票算多个请求，
: 古德吧对自己没信心，怕老魏批处理反而提升性能了。
个环节？
就是说如果系统崩溃了，根据谁交钱来恢复当前状态？
【在 n*****t 的大作中提到】
: 架构没问题，争议在性能，一个请求多票和多个请求单票是等价的，如果这些请求连续
: 执行。古德吧认为每秒不会超过 10 万票，这个节点会成为新瓶颈。
: 不要求这个是为了验证结果方便，因此还额外增加了 respID。约定多票算多个请求，
: 古德吧对自己没信心，怕老魏批处理反而提升性能了。
T*i
44 楼
其实大家讨论技术本来就应该切中肯綮。不应该故意纠缠细枝末节。
b*i
45 楼
所以让你提出个300个字的描述，结果你让大家自己想。这不就看到一些细枝末节
为什么你有的函数在.h,有的在.cpp?都在.h岂不是容易看？
【在 T********i 的大作中提到】
: 其实大家讨论技术本来就应该切中肯綮。不应该故意纠缠细枝末节。
为什么你有的函数在.h,有的在.cpp?都在.h岂不是容易看？
【在 T********i 的大作中提到】
: 其实大家讨论技术本来就应该切中肯綮。不应该故意纠缠细枝末节。
w*w
46 楼
系统崩溃，丢掉的是client送出去没得到结果的，拿到rain check没付钱的很多。
【在 b***i 的大作中提到】
: 我还有另一个问题，就是如何persist，这个频率多少？或者说，persist在交钱出票那
: 个环节？
: 就是说如果系统崩溃了，根据谁交钱来恢复当前状态？
【在 b***i 的大作中提到】
: 我还有另一个问题，就是如何persist，这个频率多少？或者说，persist在交钱出票那
: 个环节？
: 就是说如果系统崩溃了，根据谁交钱来恢复当前状态？
n*t
47 楼
抢票节点只保留有票无票这个信息，最坏情况，比如内存挨雷劈了，前端认为抢到票了
到后端一查：没得咯，也就重现抢一次拉倒，用户甚至都不会察觉。
【在 b***i 的大作中提到】
: 我还有另一个问题，就是如何persist，这个频率多少？或者说，persist在交钱出票那
: 个环节？
: 就是说如果系统崩溃了，根据谁交钱来恢复当前状态？
到后端一查：没得咯，也就重现抢一次拉倒，用户甚至都不会察觉。
【在 b***i 的大作中提到】
: 我还有另一个问题，就是如何persist，这个频率多少？或者说，persist在交钱出票那
: 个环节？
: 就是说如果系统崩溃了，根据谁交钱来恢复当前状态？
d*a
48 楼
这个是以前mainframe的做法，在不超过极限的情况下可行，效率也很高。
就这么个问题，从2014年初12306崩溃就开始吵了，吵到今年年底？
【在 n*****t 的大作中提到】
: 架构没问题，争议在性能，一个请求多票和多个请求单票是等价的，如果这些请求连续
: 执行。古德吧认为每秒不会超过 10 万票，这个节点会成为新瓶颈。
: 不要求这个是为了验证结果方便，因此还额外增加了 respID。约定多票算多个请求，
: 古德吧对自己没信心，怕老魏批处理反而提升性能了。
就这么个问题，从2014年初12306崩溃就开始吵了，吵到今年年底？
【在 n*****t 的大作中提到】
: 架构没问题，争议在性能，一个请求多票和多个请求单票是等价的，如果这些请求连续
: 执行。古德吧认为每秒不会超过 10 万票，这个节点会成为新瓶颈。
: 不要求这个是为了验证结果方便，因此还额外增加了 respID。约定多票算多个请求，
: 古德吧对自己没信心，怕老魏批处理反而提升性能了。
b*i
49 楼
假设重启了，那么抢票节点从哪里恢复所有票的状态？
【在 n*****t 的大作中提到】
: 抢票节点只保留有票无票这个信息，最坏情况，比如内存挨雷劈了，前端认为抢到票了
: 到后端一查：没得咯，也就重现抢一次拉倒，用户甚至都不会察觉。
【在 n*****t 的大作中提到】
: 抢票节点只保留有票无票这个信息，最坏情况，比如内存挨雷劈了，前端认为抢到票了
: 到后端一查：没得咯，也就重现抢一次拉倒，用户甚至都不会察觉。
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没付钱的很多。
比如，外围机报有票，给了用户几条路线，用户选了说没票了。这不是很正常？美国网
上抢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
51 楼
关键古的吧对这方面的技术一无所知，对你说的极限毫无概念，套用轮子已经成为惯性
。如果就这样也就算了，还连续两年拿这事叫骂老魏。。。。。。
【在 d***a 的大作中提到】
: 这个是以前mainframe的做法，在不超过极限的情况下可行，效率也很高。
: 就这么个问题，从2014年初12306崩溃就开始吵了，吵到今年年底？
。如果就这样也就算了，还连续两年拿这事叫骂老魏。。。。。。
【在 d***a 的大作中提到】
: 这个是以前mainframe的做法，在不超过极限的情况下可行，效率也很高。
: 就这么个问题，从2014年初12306崩溃就开始吵了，吵到今年年底？
n*t
52 楼
db 记录最终付款、出票状态。实际上出票后还是要通知一下抢票节点，这样可以安全
split 这张票剩余路段了。
【在 b***i 的大作中提到】
: 假设重启了，那么抢票节点从哪里恢复所有票的状态？
split 这张票剩余路段了。
【在 b***i 的大作中提到】
: 假设重启了，那么抢票节点从哪里恢复所有票的状态？
d*a
53 楼
这个不是问题。后端用数据库系统，所有车次的所有座位的售票状态和相关信息，都由
数据库系统管理。
中间的那个抢票系统，相当一个中间人，告诉在哪可以买到票。它并不真正负责售票。
这个中间人记得所有车次的所有座位的售票状态（在内存里），和数据库基本保持一致
，稍稍超前一点。如果它崩溃了，从数据库系统重新读取状态就是了。当然这要花一些
时间。
声明一下，我是来打酱油的，吵架不要拉上我。:)
【在 b***i 的大作中提到】
: 假设重启了，那么抢票节点从哪里恢复所有票的状态？
数据库系统管理。
中间的那个抢票系统，相当一个中间人，告诉在哪可以买到票。它并不真正负责售票。
这个中间人记得所有车次的所有座位的售票状态（在内存里），和数据库基本保持一致
，稍稍超前一点。如果它崩溃了，从数据库系统重新读取状态就是了。当然这要花一些
时间。
声明一下，我是来打酱油的，吵架不要拉上我。:)
【在 b***i 的大作中提到】
: 假设重启了，那么抢票节点从哪里恢复所有票的状态？
n*t
54 楼
这个解释很好，就是医院挂号的。腿折了？二楼骨科。淌鼻涕？内科。不生孩子？隔壁
仁爱医院。鸡鸡张豆豆？明天乘早。
挂上号了一般就能看上病，住不住院问医生去。
【在 d***a 的大作中提到】
: 这个不是问题。后端用数据库系统，所有车次的所有座位的售票状态和相关信息，都由
: 数据库系统管理。
: 中间的那个抢票系统，相当一个中间人，告诉在哪可以买到票。它并不真正负责售票。
: 这个中间人记得所有车次的所有座位的售票状态（在内存里），和数据库基本保持一致
: ，稍稍超前一点。如果它崩溃了，从数据库系统重新读取状态就是了。当然这要花一些
: 时间。
: 声明一下，我是来打酱油的，吵架不要拉上我。:)
仁爱医院。鸡鸡张豆豆？明天乘早。
挂上号了一般就能看上病，住不住院问医生去。
【在 d***a 的大作中提到】
: 这个不是问题。后端用数据库系统，所有车次的所有座位的售票状态和相关信息，都由
: 数据库系统管理。
: 中间的那个抢票系统，相当一个中间人，告诉在哪可以买到票。它并不真正负责售票。
: 这个中间人记得所有车次的所有座位的售票状态（在内存里），和数据库基本保持一致
: ，稍稍超前一点。如果它崩溃了，从数据库系统重新读取状态就是了。当然这要花一些
: 时间。
: 声明一下，我是来打酱油的，吵架不要拉上我。:)
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的赌？
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
56 楼
看你用啥硬件吧？51，98之类的也没那么不堪。
虽然我43都不到，53俱乐部那些DJS130我还是看着它运行看着它退役的。
VAX11780也用过。
ROM
【在 w****w 的大作中提到】
: 只能感叹现在的硬件。当年我写程序的时候，ram只有几十个bytes, code要switch ROM
: bank, 大点应用还要multitasking，那才是真正的上世纪老古董。
虽然我43都不到，53俱乐部那些DJS130我还是看着它运行看着它退役的。
VAX11780也用过。
ROM
【在 w****w 的大作中提到】
: 只能感叹现在的硬件。当年我写程序的时候，ram只有几十个bytes, code要switch ROM
: bank, 大点应用还要multitasking，那才是真正的上世纪老古董。
w*w
57 楼
6800, VAX11/725,HC11...
【在 T********i 的大作中提到】
: 看你用啥硬件吧？51，98之类的也没那么不堪。
: 虽然我43都不到，53俱乐部那些DJS130我还是看着它运行看着它退役的。
: VAX11780也用过。
:
: ROM
【在 T********i 的大作中提到】
: 看你用啥硬件吧？51，98之类的也没那么不堪。
: 虽然我43都不到，53俱乐部那些DJS130我还是看着它运行看着它退役的。
: VAX11780也用过。
:
: ROM
T*i
58 楼
您是老前辈，我多有失礼，还请见谅。
【在 w****w 的大作中提到】
: 6800, VAX11/725,HC11...
【在 w****w 的大作中提到】
: 6800, VAX11/725,HC11...
w*w
59 楼
不敢不敢，我十几年前已经被淘汰了。
【在 T********i 的大作中提到】
: 您是老前辈，我多有失礼，还请见谅。
【在 T********i 的大作中提到】
: 您是老前辈，我多有失礼，还请见谅。
d*a
60 楼
前辈啊！我读书时已经可以用256KB的内存了。
ROM
【在 w****w 的大作中提到】
: 只能感叹现在的硬件。当年我写程序的时候，ram只有几十个bytes, code要switch ROM
: bank, 大点应用还要multitasking，那才是真正的上世纪老古董。
ROM
【在 w****w 的大作中提到】
: 只能感叹现在的硬件。当年我写程序的时候，ram只有几十个bytes, code要switch ROM
: bank, 大点应用还要multitasking，那才是真正的上世纪老古董。
T*i
61 楼
我就纳闷了。能细抠我源码的，不像现在那些小毛孩的做派。
严谨的态度，是应该代代相传的。
【在 w****w 的大作中提到】
: 不敢不敢，我十几年前已经被淘汰了。
严谨的态度，是应该代代相传的。
【在 w****w 的大作中提到】
: 不敢不敢，我十几年前已经被淘汰了。
T*i
62 楼
那是一个没有人需要超过640K内存的时代。 :)
【在 d***a 的大作中提到】
: 前辈啊！我读书时已经可以用256KB的内存了。
:
: ROM
【在 d***a 的大作中提到】
: 前辈啊！我读书时已经可以用256KB的内存了。
:
: ROM
f*2
63 楼
老魏你还狠年轻啊，任正非在你这个年纪还住着农民房，拎着皮包到处转呢。
我被好虫赵策二人转忽悠的以为你都奔五了呢。
好好干，争取把老姜拉入伙，真心看好你们。美国安全领域当年出了一批华人企业，你
们在iot再杀出条血路。
别的不说，赵策来美的事情至少解决了
【在 T********i 的大作中提到】
: 看你用啥硬件吧？51，98之类的也没那么不堪。
: 虽然我43都不到，53俱乐部那些DJS130我还是看着它运行看着它退役的。
: VAX11780也用过。
:
: ROM
我被好虫赵策二人转忽悠的以为你都奔五了呢。
好好干，争取把老姜拉入伙，真心看好你们。美国安全领域当年出了一批华人企业，你
们在iot再杀出条血路。
别的不说，赵策来美的事情至少解决了
【在 T********i 的大作中提到】
: 看你用啥硬件吧？51，98之类的也没那么不堪。
: 虽然我43都不到，53俱乐部那些DJS130我还是看着它运行看着它退役的。
: VAX11780也用过。
:
: ROM
b*7
64 楼
"谁要打一个1M/s ACID MQ的赌？"
这个比较感兴趣，能大概说说思路吗？找轮子还是自己做？单机的还是分布的？
这个比较感兴趣，能大概说说思路吗？找轮子还是自己做？单机的还是分布的？
b*7
65 楼
同车次出票呢？小概率也还是会发生的，应该还是要锁吧。而且这个transaction要和
支付包在一起，和同一个请求的其它车次包在一起。就成了跨db的transaction提交了。
后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票，
也没有数据耦合。抢票节点就是解决加锁和耦合问题的。付款本身没有耦合问题，每个
订单、用户都是独立的，........
【在 n*****t 的大作中提到】
: 后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票，
: 也没有数据耦合。抢票节点就是解决加锁和耦合问题的。
: 付款本身没有耦合问题，每个订单、用户都是独立的，当然付款失败需要返回票源。
:
: transaction
支付包在一起，和同一个请求的其它车次包在一起。就成了跨db的transaction提交了。
后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票，
也没有数据耦合。抢票节点就是解决加锁和耦合问题的。付款本身没有耦合问题，每个
订单、用户都是独立的，........
【在 n*****t 的大作中提到】
: 后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票，
: 也没有数据耦合。抢票节点就是解决加锁和耦合问题的。
: 付款本身没有耦合问题，每个订单、用户都是独立的，当然付款失败需要返回票源。
:
: transaction
n*t
66 楼
抢票给出的是座位，不单单是车次，不需要加锁
了。
【在 b******7 的大作中提到】
: 同车次出票呢？小概率也还是会发生的，应该还是要锁吧。而且这个transaction要和
: 支付包在一起，和同一个请求的其它车次包在一起。就成了跨db的transaction提交了。
:
: 后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票，
: 也没有数据耦合。抢票节点就是解决加锁和耦合问题的。付款本身没有耦合问题，每个
: 订单、用户都是独立的，........
了。
【在 b******7 的大作中提到】
: 同车次出票呢？小概率也还是会发生的，应该还是要锁吧。而且这个transaction要和
: 支付包在一起，和同一个请求的其它车次包在一起。就成了跨db的transaction提交了。
:
: 后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票，
: 也没有数据耦合。抢票节点就是解决加锁和耦合问题的。付款本身没有耦合问题，每个
: 订单、用户都是独立的，........
b*i
67 楼
原来不是抢票就分？看来还挺合理的。
全
【在 n*****t 的大作中提到】
: db 记录最终付款、出票状态。实际上出票后还是要通知一下抢票节点，这样可以安全
: split 这张票剩余路段了。
全
【在 n*****t 的大作中提到】
: db 记录最终付款、出票状态。实际上出票后还是要通知一下抢票节点，这样可以安全
: split 这张票剩余路段了。
T*i
68 楼
你有没有读我的code？现在抢票请求都是单线程处理的。锁啥？
每秒>5M是guarantee的。
了。
【在 b******7 的大作中提到】
: 同车次出票呢？小概率也还是会发生的，应该还是要锁吧。而且这个transaction要和
: 支付包在一起，和同一个请求的其它车次包在一起。就成了跨db的transaction提交了。
:
: 后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票，
: 也没有数据耦合。抢票节点就是解决加锁和耦合问题的。付款本身没有耦合问题，每个
: 订单、用户都是独立的，........
每秒>5M是guarantee的。
了。
【在 b******7 的大作中提到】
: 同车次出票呢？小概率也还是会发生的，应该还是要锁吧。而且这个transaction要和
: 支付包在一起，和同一个请求的其它车次包在一起。就成了跨db的transaction提交了。
:
: 后端可以一个车次一个 DB、不需要锁记录了。抢票节点保证了不会冲突、没有重票，
: 也没有数据耦合。抢票节点就是解决加锁和耦合问题的。付款本身没有耦合问题，每个
: 订单、用户都是独立的，........
T*i
69 楼
刚给老姜发了封gmail。
【在 f******2 的大作中提到】
: 老魏你还狠年轻啊，任正非在你这个年纪还住着农民房，拎着皮包到处转呢。
: 我被好虫赵策二人转忽悠的以为你都奔五了呢。
: 好好干，争取把老姜拉入伙，真心看好你们。美国安全领域当年出了一批华人企业，你
: 们在iot再杀出条血路。
: 别的不说，赵策来美的事情至少解决了
【在 f******2 的大作中提到】
: 老魏你还狠年轻啊，任正非在你这个年纪还住着农民房，拎着皮包到处转呢。
: 我被好虫赵策二人转忽悠的以为你都奔五了呢。
: 好好干，争取把老姜拉入伙，真心看好你们。美国安全领域当年出了一批华人企业，你
: 们在iot再杀出条血路。
: 别的不说，赵策来美的事情至少解决了
f*2
70 楼
你们两个要是齐了（其他的都放下不干），需要销售经理的时候和兄弟说一声啊。
【在 T********i 的大作中提到】
: 刚给老姜发了封gmail。
【在 T********i 的大作中提到】
: 刚给老姜发了封gmail。
T*i
71 楼
没问题。你老兄顺便也要负责啥时候打开笼子放赵策。
【在 f******2 的大作中提到】
: 你们两个要是齐了（其他的都放下不干），需要销售经理的时候和兄弟说一声啊。
【在 f******2 的大作中提到】
: 你们两个要是齐了（其他的都放下不干），需要销售经理的时候和兄弟说一声啊。
l*s
72 楼
re this, 牛逼的日本和德意志民族都是以严谨细致著称的
【在 T********i 的大作中提到】
: 我就纳闷了。能细抠我源码的，不像现在那些小毛孩的做派。
: 严谨的态度，是应该代代相传的。
【在 T********i 的大作中提到】
: 我就纳闷了。能细抠我源码的，不像现在那些小毛孩的做派。
: 严谨的态度，是应该代代相传的。
b*7
73 楼
我指的是后期的persistent。
你有没有读我的code？现在抢票请求都是单线程处理的。锁啥？每秒
【在 T********i 的大作中提到】
: 你有没有读我的code？现在抢票请求都是单线程处理的。锁啥？
: 每秒>5M是guarantee的。
:
: 了。
你有没有读我的code？现在抢票请求都是单线程处理的。锁啥？每秒
【在 T********i 的大作中提到】
: 你有没有读我的code？现在抢票请求都是单线程处理的。锁啥？
: 每秒>5M是guarantee的。
:
: 了。
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？现在抢票请求都是单线程处理的。锁啥？每秒
抢票机抢到票，放到一个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？现在抢票请求都是单线程处理的。锁啥？每秒
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好了。
: 其实有问题你应该自己先想办法解决。如果自己能解决还要故意问，那是故意难为人家
: ，有意思么？
【在 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
76 楼
对性能有整体要求啊，不然抢票机堵塞了。
其实ACID MQ也能无限scale。对性能没要求，只要ACID就好。
其实ACID MQ也能无限scale。对性能没要求，只要ACID就好。
z*e
77 楼
哈哈哈，老姜的电商怎么样了？
连个支付宝都不去做，去搞这个？傻逼了不是？
老姜，看这个新闻，傻蛋，你不做，别人已经行动了
http://www.cnr.cn/jingji/gs/20151218/t20151218_520846846.shtml
【在 f******2 的大作中提到】
: 老魏你还狠年轻啊，任正非在你这个年纪还住着农民房，拎着皮包到处转呢。
: 我被好虫赵策二人转忽悠的以为你都奔五了呢。
: 好好干，争取把老姜拉入伙，真心看好你们。美国安全领域当年出了一批华人企业，你
: 们在iot再杀出条血路。
: 别的不说，赵策来美的事情至少解决了
相关阅读
akka能和C++程序通信吗？python代码写成这样，什么鬼阿。fp适合小孩学报告大家一个好消息是用ssh action好还是用mapreduce action好？用react的试过中文么？求面试用的c#,java复习材料一个较难的pythpn输出函数运行信息的project.如何快速学习R或Python这类开源类语言的加盟包？听说n家99％的代码都是java请教大牛, 大家为什么不用jsp了angular 2怎么跑？test据说TS要开始支持ES6了Node.js 为什么升级这么快请教个git的问题ruby还有市场么？除了rails, chef。看CRDT又想到了火车票对PyCharm屈服了……html input如果处理非常大的数怎么搞？