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凋用系统。 |
|
|
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才返回的情况
|
|
|
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 其实大家讨论技术本来就应该切中肯綮。不应该故意纠缠细枝末节。 |
|
|
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 的大作中提到】
: 这个不是问题。后端用数据库系统，所有车次的所有座位的售票状态和相关信息，都由
: 数据库系统管理。
: 中间的那个抢票系统，相当一个中间人，告诉在哪可以买到票。它并不真正负责售票。
: 这个中间人记得所有车次的所有座位的售票状态（在内存里），和数据库基本保持一致
: ，稍稍超前一点。如果它崩溃了，从数据库系统重新读取状态就是了。当然这要花一些
: 时间。
: 声明一下，我是来打酱油的，吵架不要拉上我。:)
|
|
|
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的赌？"
这个比较感兴趣，能大概说说思路吗？找轮子还是自己做？单机的还是分布的？ |
|
|
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？现在抢票请求都是单线程处理的。锁啥？每秒
|
|
|
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再杀出条血路。
: 别的不说，赵策来美的事情至少解决了
|
